1430715 - Don't update MDSM duration from buffer ranges

Status: NEW

(Core :: Audio/Video: Playback, enhancement, P3)

Description

[JW Wang [:jwwang] [:jw_wang]]

Open the link: http://stream.keygen-fm.ru:8042/live.ogg and you will see a duration that is constantly changing.

The changing duration doesn't add any value but just confusion to the user. We should leave the duration as infinity if we can't get one from the metadata. This is also the approach taken by Chrome.

Comment 1

[JW Wang [:jwwang] [:jw_wang]]

Attachment: Bug 1430715 - don't update duration from buffer ranges in MDSM.

The constantly changing duration only addes confusion to the user. We will
leave it as infinity if we can't get one from the metadata.

Review commit: https://reviewboard.mozilla.org/r/213122/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/213122/

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

Will we still set the duration of MP3s with this patch? They don't have the duration stored in their metadata, so we estimate it, and update our estimate as we decode more of the file.

Comment 3

[JW Wang [:jwwang] [:jw_wang]]

https://searchfox.org/mozilla-central/rev/48cbb200aa027a0a379b6004b6196a167344b865/dom/media/mp3/MP3Demuxer.cpp#383

It looks like the duration is estimated from the header or frame number. No buffer range is checked.

Is it true that now we don't need buffer ranges to calculate the MP3 duration?

Comment 4

[Jean-Yves Avenard [:jya]]

MP3 container doesn't contain metadata's duration. As such, the MP3 duration is entirely based on how much content has been seen so far.
With a live stream, it wouldn't be infinity.
MP3 Seeking doesn't appear to make use of the buffered range no.

In fact, I'm fairly certain that almost no demuxer will give you a duration that is infinity as most containers don't know if they are a live stream or not. Not sure how that bug can be done as you suggest.

Comment 5

[JW Wang [:jwwang] [:jw_wang]]

(In reply to Jean-Yves Avenard [:jya] from comment #4)
> In fact, I'm fairly certain that almost no demuxer will give you a duration
> that is infinity as most containers don't know if they are a live stream or
> not. Not sure how that bug can be done as you suggest.

The demuxer will try to determine the duration either the container header or seeking to the end of the stream and fill the duration in MediaInfo::mMetadataDuration.

In the case where the duration can't be determined, MediaInfo::mMetadataDuration will be left empty by the demuxer and MDSM will set its duration to infinity.

This behavior corresponds to the spec. text: "Update the duration attribute with the time of the last frame of the resource, if known, on the media timeline established above. If it is not known (e.g. a stream that is in principle infinite), update the duration attribute to the value positive Infinity."

Comment 6

[JW Wang [:jwwang] [:jw_wang]]

Btw, all MP3 files have MediaInfo::mMetadataDuration filled without reading buffer ranges. So yes, we will still set MP3 duration correctly with this patch applied.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

This is an icecast stream. The icecast server isn't giving us a Content-Length HTTP header. I think what we should do here is  consider streams without a Content-Length header as "infinite", and show the duration as infinite instead, if the spec allows us to do that.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.