[Webkit-unassigned] [Bug 200615] FMP4 segments streamed into a MediaSource results in a black video.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 27 07:59:45 PDT 2019


https://bugs.webkit.org/show_bug.cgi?id=200615

--- Comment #7 from Jer Noble <jer.noble at apple.com> ---
(In reply to Andrew Sampson from comment #6)
> Hey @Jer Noble, just wanted to check on the status of this bug. We're really
> anxious to get Safari support re-enabled. Can we provide any additional
> details?

I'm not entirely sure what the bug _is_ at this point. There's like three different behaviors listed in Roman's comment above:

1) "video freezes shortly after starting"
2) "video pauses when reaching the last available video frame"
3) "video does not resume when appending one additional video frame"

1) and 2) might be the same bug. If you're trying to live on the bleeding edge of realtime, you will inevitably hit network or main thread jank and deliver frames late, and in that case, yes, we will pause playback. It's hard to know without a live test case.
3) is definitely true; we won't resume until we hit HAVE_ENOUGH_DATA. It would be a terrible user experience for most videos if we started playing every time one additional frame was made available from the network. That said, MSE-based players know /exactly/ when additional frames are made available and can call play() at the end of an update().

All of this is moot, however. If you want frames delivered to the screen ASAP, then MSE is the wrong technology. You should be using WebRTC for this, as that's the entire reason for WebRTC to exist: low latency, immediate mode rendering.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190827/91f47d16/attachment.html>


More information about the webkit-unassigned mailing list