Dealing with inaccurate DASH manifests

[andybets]

• What version of Shaka Player are you using? 2.0.4
  • Can you reproduce the issue with our latest release version? Yes
• Are you using the demo app or your own custom app? Custom
  • If custom app, can you reproduce the issue using our demo app? Have not tried, not easy
• What browser and OS are you using? Ubuntu 14.04 / Chrome 48.0.2564.109

Great work on the player! I'm not sure whether this is a bug, but wondered whether you had any pointers?

When seeking to some parts of some videos which seem to have inaccurate manifests, where the video.currentTime is a couple of seconds before the start of the new video.buffered.start(0), the player hangs in the seeking/buffering state.

I have no control over the manifest creation, but am hoping to adapt in the app by loading the previous segment in these cases, but there don't seem to be any events I could use to distinguish the situation from a network delay. A 'error' event or something would be great, so I can check within that, that the video.currentTime is just slightly out of range, and load the previous segment. Is there an accessible method to load the previous segment?

It seems this situation was addressed in #330, but perhaps it never made it to 2.0.0?

Thanks for any help.
Andy

[TheModMaker]

We already fetch the segment before the one we think we need. We should be handling this case already.

First I notice you are using a old version of Chrome (current is 56), you may want to update. Also, is the content multi-Period or does it have a single Period? Can you provide an example manifest?

There is an error event for when problems occur, but this is not an error. You can also listen for a buffering event. This is fired when the Player enters/exits a buffering state. You can use this to seek forward if there are segments ahead of the playhead (using video.buffered). There is no way to alter which segments are being downloaded.

[andybets]

Thank you.

I wonder if it could somehow be two segments out then?

It's single period, the manifest is here.

I've noticed issues begin around the 65-70 minutes into the video, and in this case it was due to ffmpeg libx264 being used for encoding without scenecut disabled (or similar), but I can't always control manifest creation, or the version of Chrome being used.

The buffering event fires when seeking begins, but I never receive an event to show it's complete, I think because the currentTime isn't within the buffered range. I would expect that if on receiving all requested data, the currentTime isn't within buffered range, this might throw an error event.

I could well be misunderstanding something here, and any help is appreciated to make the player resilient even with invalid manifests.

[TheModMaker]

Unfortunately your manifest is bad and we can't support it. We don't want to invest a lot of time to support bad content. Some of the segments are even three segments (up to 23 seconds) off.

We are currently working on gap jumping (see #180 and #555). This may help your case by automatically seeking to the buffer start once we start buffering content.

The buffering event fires when we enter or leave a buffering state. So what you could do is use setTimeout in the callback and if we stay in a buffering state too long, try to seek somewhere else.

Another option is to fork the repository and change StreamingEngine to fetch segments more in the past (changing position - 1 to position - 3). This will increase the time it takes to seek because we stay in a buffering state longer; but it will fix your problem.

[joeyparrish]

DASH Interop Points state that segments must be aligned across Representations and that the manifest must be "approximately" accurate, which turns out to mean within one half segment in either direction at all times during the presentation.

Since Shaka Player is an off-the-shelf component that has to interoperate with many other components (encoders, CDNs, etc) in a complex media ecosystem, it would not be feasible for us to try to support content that does not meet the bar for "interoperable". Sorry!

[andybets]

Thanks very much for the explanations, and again, your great work on the player!

I am using the setTimout approach currently, which I think will do for now. Would automatically seeking to buffer start not interfere with reverse playback? I ask because I also use that.

[TheModMaker]

Unfortunately that will not work with rewind. We don't actually buffer backwards while rewinding, all we do is repeatedly seek backwards. Once we run out of buffer, it is treated as an unbuffered seek and we clear the buffer and start downloading segments forward again.

This means that once you rewind past the start of the buffer, the player will look for the "current" segment to download and will run into the same problem as normal seeking. But rewinding within a buffered range should work fine.

[andybets]

Thanks. Rewinding past the buffered range performs acceptably for our player at the moment (with the obvious pause whilst the previous segment loads).

I was concerned that the proposed change you mention ('automatically seeking to the buffer start') could break this for us, by jumping from the end to the start of buffer. Is that the case?