Bug 156316 - Safari 9 refuses to jump small gaps in video buffer
Summary: Safari 9 refuses to jump small gaps in video buffer
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Media (show other bugs)
Version: Safari 9
Hardware: Mac OS X 10.11
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-04-06 16:14 PDT by Joey Parrish
Modified: 2017-03-06 09:00 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joey Parrish 2016-04-06 16:14:36 PDT
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.
Comment 1 Radar WebKit Bug Importer 2016-04-06 16:32:31 PDT
<rdar://problem/25589105>
Comment 2 Jer Noble 2016-04-06 17:26:34 PDT
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.
Comment 4 Joey Parrish 2016-08-16 15:33:58 PDT
Any updates on this?
Comment 5 John Plaisted 2017-03-06 09:00:48 PST
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.