mediaPresentationDuration not fully respected (plays until end of segment) #3152
Comments
|
Also note that Shaka Player seems to behave more correctly: E.g, it shows the media duration as 03:32 from the beginning to the end, and plays exactly until frame 13727, which is at 09:31.958 (the next frame 13728 is exactly at 09:32.000). |
|
Hi @dimitry-unified-streaming , currently dash.js doesn't use appendWindowEnd property of Sourcebuffer. So when a media segment is pushed, duration of video element is updated. In your sample stream, when the last audio segment is pushed, audio buffered range equals So, a new PR has to be done to use this parameter.....and maybe take a look at appendWindowStart could be interessting to resolve start alignment issues.... Nico |
|
Aha, indeed Shaka player seems to use E.g., if I would compose an MPD with the complete Tears of Steel clip (which is 12:14 long) in its timeline, but specified a |
|
@dimitry-unified-streaming Agreed, the MPD is the point of truth. |
|
This is now handed by using the appendWindowEnd of the Sourcebuffer, see #3153 |
Environment
Link to playable MPD file:
https://test.unified-streaming.com/dashif/tears-of-steel-0600-0932/tos.mpd and
https://test.unified-streaming.com/dashif/tears-of-steel-0600-0932/tos-shortened.mpd
Dash.js version: 3.0.1 and nightly (as of 2020-01-10)
Browser name/version: Firefox 74.0a1 (2020-01-07) and Chrome 79.0.3945.117(64-bit)
OS name/version: Ubuntu Linux 18.04
Steps to reproduce
With our Unified Origin product, we have a feature to get virtual subclips from VOD content. Depending on how the original VOD content is fragmented, you can sometimes get slight misalignments between the audio and video tracks. This is perfectly normal, as the sample times and timescales do not always line up.
In one particular case, a user noticed that dash.js seemed to be "hanging" at the end of such a clip. Here, the clip was from 06:00 to 09:32 in the Tears of Steel video, where the alignment of the media fragments is such, that the audio starts at 05:59.957 and ends at 09:35.957 (so 216.0 seconds), and the video starts at 06:00.000 and ends at 09:32.0 (so 212.0 seconds). Our software reported the
mediaPresentationDuration(and thePeriod@duration) as the duration of the longest timeline, so asPT3M36S(03:36). This caused dash.js to stop playing at approximately 03:32, where the video timeline ends, and then hang.While investigating this, we found a nice write up about just this case in the DASH-IF timing model document here on GitHub, talking about just this kind of thing:
https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html#necessary-references-static
E.g., what want to do is to change the
mediaPresentationDuration(andPeriod@duration) toPT3M32S, so the span is always covered by media segments. Also, we want to adjust thepresentationTimeOffsetof eachAdaptationSetto start at exactly 06:00.000.An example playlist for this is here: https://test.unified-streaming.com/dashif/tears-of-steel-0600-0932/tos.mpd. If you play this in dash.js, it seems to work well, and it initially shows a media duration of 03:32 in its scrubber bar. However, near the end of the presentation, as it is downloading the final media segments, it suddenly decides that the media duration becomes 03:35! Then, because it runs out of video at 03:32, it sits for a while emptying its buffers, and eventually decides to stop.
We think dash.js should fully respect the
mediaPresentationDuration(orPeriod@duration) attributes, so if we tell it to not play the media until the end, it should stop exactly at the provided duration.Another synthesized example is https://test.unified-streaming.com/dashif/tears-of-steel-0600-0932/tos-shortened.mpd, which is exactly the same MPD, but with both
mediaPresentationDurationandPeriod@durationset toPT1M32S. In that case, dash.js shows similar behavior as described above: it starts playing and says the media duration is 01:32, then just before the end it increases the duration to 01:35.Observed behaviour
The observed behavior is as described above, while we think it should stop at the specified duration instead.
Console output
The text was updated successfully, but these errors were encountered: