Adjusting constants to deal with media gaps not reflected in manifests

[tfrivold]

What version of Shaka Player are you using? 2.0.0
Can you reproduce the issue with our latest release version? Yes

I am using Shaka to play DASH manifests from a source where the manifest reports no gap, but the underlying video segments, once loaded, do show gaps as evidenced by multiple source buffers in the video element (i.e. video.buffered.end(i+1) - video.buffered.start(i) > 0). These gaps may differ between browsers (e.g. Chrome and Firefox). In an effort to "play through" gaps, I would like the ability to dynamically control, based on the browser and/or manifest source, what are now constants, specifically:

1. shaka.media.TimeRangesUtils.GAP_TOLERANCE (used in shaka.media.TimeRangesUtils.bufferedAheadOf to detect media gaps)
2. shaka.media.Playhead.UNDERFLOW_THRESHOLD_ (used in shaka.media.Playhead.prototype.onWatchdogTimer_ to control signaling of buffering state)

Can these values be changed from constants to variables that may be adjusted at runtime?

[joeyparrish]

These are good questions. Let me give you a bit of context.

The gaps look different between Firefox and Chrome because of a series of bugs in Chrome that confuse DTS and PTS. (http://crbug.com/373039, http://crbug.com/398130, http://crbug.com/398141, and http://crbug.com/402502, collectively tracked by us as #377.) We expect these bugs to be fixed in Chrome eventually, at which point there should be some fair amount of consistency in gap behavior across browsers.

We are also exploring changes in Shaka Player to handle gappy content by jumping over the gaps automatically. See #180 and #555 for details. (You may want to subscribe to these issues so you see updates as we make them.)

So given that the Chrome team is working on fixing timestamp data in the media pipeline, and that my team is working on a way to cope with gaps no matter what the browser does, we are not interested in making those constants into variables right now. I would guess that they would go away in a future version of Shaka Player.

In the mean time, you could certainly make them into variables in your own fork. That's one of the benefits of open-source, after all. We will make an announcement once we have a plan, at which point you can consider switching back to an unmodified version of Shaka Player. Would that work for you?

[tfrivold]

Thank you for the detailed response and bigger picture perspective. I look forward to the changes coming down the pipe in future releases. In the meantime, I will make local changes on a forked version.

Thank you!