VOD stream cannot playback with "Error code 5002" if the video does not start from t = 0

[faiyeah]

Player used:
http://v2-0-0.shaka-player-demo.appspot.com/demo/

Tested old player does not suffer this issue:
http://v1-6-5.shaka-player-demo.appspot.com

Tested VOD content (which pass both v2-0-0 and v1-6-5 playback test):
https://www.dropbox.com/s/b12s9rlyv47dl1l/ij.tar.gz?dl=0

Corresponding mpd:
ij_manifest.txt

Corresponding Segment Time Line for video:
<SegmentTimeline><S t="0" d="20020000" r="449" /></SegmentTimeline>

Tested VOD content (which pass v1-6-5, but failed v2-0-0 playback test):
https://www.dropbox.com/s/h224hbkad6htnkl/vodBM.tar.gz?dl=0

Corresponding mpd:
vodBM_manifest.txt

Corresponding Segment Time Line for video:
<SegmentTimeline><S t="12537000" d="20000000" r="911" /></SegmentTimeline>

Corresponding debug log from shaka:
v2-0-0.shaka-player-demo.appspot.com-1461148657605.txt

By the way, we hit the playback issue for Live content as well, however i think someone else has created similar issue for that (see #339). And I am not sure if it is related to #302 as well.

Thanks.
Ryan Chan

[tdrews]

Yes, v2 currently requires VOD content to start near t=0; however, it seems like we'll have to change this behavior. See #341 for example.

[faiyeah]

What is the expected tolerance if t is not exactly equal to 0, with the current implementation?

From my past experience, we cannot always expect the VOD contents are with leading video (means video presentation is earlier than other streams like audio). We have a lot of customer contents in which contents with leading audios dominate in their repository. I would appreciate if you can remove this limitation as if what is behaved like v1.6.5, this would eliminate many interop issues.

Also, I am also interested in the root cause of #339, in which I think the same player error applied for live streams.

Thanks for the response.

Ryan Chan

[tdrews]

What is the expected tolerance if t is not exactly equal to 0, with the current implementation?

The current tolerance is 1/15 of a second.

We will implement a new solution to handle content whose first segments don't start at t=0. We'll use this issue to track progress.

There are a few issues with #339: @minimumUpdatePeriod is 0, the last SegmentReference isn't being merged correctly while updating due to some rounding errors, and the default @suggestedPresentationDelay isn't large enough. We'll have a patch up for #339 sometime soon.