Bug 156316 – Safari 9 refuses to jump small gaps in video buffer

• Status: NEW
• Component: Media

[Joey Parrish]

When MSE/DASH content does not start at exactly 0ms, Safari refuses to play.

To reproduce in Safari 9:

1. Visit http://safari-gap-bug.shaka-player-demo.appspot.com/demo/?asset=https://storage.googleapis.com/shaka-demo-assets/_bugs/safari-non-zero-cts/stream.mpd;play

2. Open the JavaScript console.

3. Evaluate: video.buffered.start(0)

4. The buffered range starts at 83ms.  Playback is hung.

5. Playback begins if you seek to something inside the buffered range: video.currentTime = 0.1;


Try the same steps in Firefox on Mac.  You will see that the buffered range still starts at 83ms, but Firefox is willing to jump this tiny gap and play anyway.

[Radar WebKit Bug Importer]

<rdar://problem/25589105>

[Jer Noble]

We do have something called a "currentTimeFudgeFactor()" <http://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediasource/SourceBuffer.cpp#L68>, hard coded to be the length of a single frame of a 24fps video, or 42ms.  But the gap in the example is nearly double that.

[Jer Noble]

It looks like Mozilla's equivalent "fudge factor" is 250ms:
http://mxr.mozilla.org/mozilla-central/source/dom/media/MediaDecoder.h#577
http://mxr.mozilla.org/mozilla-central/source/dom/media/mediasource/MediaSourceDecoder.cpp#256

[Joey Parrish]

Any updates on this?

[John Plaisted]

I'd like to add here that when you encounter this issue that you apparently cannot set currentTime = buffered.start(0) to resolve it. You must set currentTime = buffered.start(0) + [some small number like 0.1]. In the first example 0.1 > 0.083, so it resumes. Though the amount you need to add isn't consistent.

I would think that buffered.start gives an inclusive time, no? And that the work around for this issue *should* be currentTime = buffered.start(0).

Maybe this deserves its own bug, not sure.