Shaka Player stuck (inaccurate manifest)

[akopper]

Shaka Player seems to have problems with a video of mine. I noticed that sometimes
when seeking in the stream, the playback does not start. The manifest is available at [2].

How to reproduce:

1. Open the Shaka-Test site at [1]
2. Start playback.
3. Seek at random positions in the file and wait for playback to continue.
4. Notice that sometimes playback will not start.

My setup:

• uname -a -> Linux akopper-ThinkPad-T540p 3.19.0-58-generic mpd parser: Handle minimumUpdatePeriod being set to 0. #64~14.04.1-Ubuntu SMP Fri Mar 18 19:05:43 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
• Google Chrome Version 49.0.2623.112 (64-bit)

Best Regards,
Alexander

[1] https://storage.googleapis.com/eu-storage-bitcodin/bitStorage/7875_9ef90fef446ac887e6b9a16185086713/191640_7cc1d8535960fed4acf0a1f9edd51dc4/shaka.html
[2] https://eu-storage-bitcodin.storage.googleapis.com/bitStorage/7875_9ef90fef446ac887e6b9a16185086713/191640_7cc1d8535960fed4acf0a1f9edd51dc4/191640.mpd

[joeyparrish]

I was able to reproduce with your test page. It seems that the playhead is outside the buffered range:

video.currentTime => 583.420756
video.buffered.start(0) => 584.005079
video.buffered.end(0) => 587.999999

I found that spot by luck while manually seeking, but if I seek to exactly that spot, it happens every time:

video.currentTime = 583;

In the manifest, the timescale is 24000 and the segment duration is 95760. 95760 / 24000 = 3.99 seconds. To seek to 583, we would calculate 583 / 3.99 = 146.115. Since startNumber is 0, we would fetch segment 146. To analyze this segment in Linux:

wget https://eu-storage-bitcodin.storage.googleapis.com/bitStorage/7875_9ef90fef446ac887e6b9a16185086713/191640_7cc1d8535960fed4acf0a1f9edd51dc4/video_0_4800000/dash/init.mp4
wget https://eu-storage-bitcodin.storage.googleapis.com/bitStorage/7875_9ef90fef446ac887e6b9a16185086713/191640_7cc1d8535960fed4acf0a1f9edd51dc4/video_0_4800000/dash/segment_146.m4s
cat init.mp4 segment_146.m4s > segment_146.mp4
mp4info --verbose --show-samples segment_146.mp4 | grep cts | head

This shows:

[000001] size=277998 duration=  1000 (    41 ms) offset=      2010
    dts=  14016000 (    584000 ms) cts=  14018000 (    584083 ms) [0] [S] <I>

So the first frame of that segment indeed starts at 584 seconds, which is what the browser reports as well. Therefore the manifest is not an accurate description of the underlying stream.

I would recommend you report this to whoever wrote the DASH packager you used to create this stream. I will leave this issue open while we discuss internally what, if anything, we could do to support this kind of broken content without adding complexity to the system.

[akopper]

Thank you a lot for your detailed analysis. I will forward this information to the instance responsible for the mpd creation. This helped me a lot.

[joeyparrish]

No problem. Glad I could help!

[joeyparrish]

The DASH spec permits manifests to be "approximate", and it appears that the definition of approximate is that the accumulated inaccuracy must be less than 50% of the ideal segment duration.

So we will try to be a little more flexible and tolerate being off by at most one segment.