[Webkit-unassigned] [Bug 200949] Media Source Extensions performance during seek

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat May 2 13:00:36 PDT 2020


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

--- Comment #9 from Jer Noble <jer.noble at apple.com> ---
(In reply to Dustin Kerstein from comment #8)
> Hi Jer, the videos I'm testing with (and my use-case for PanoMoments.com)
> are entirely comprised of keyframes to minimize the amount of time (and
> frames) needed to seek.

The only thing being all I-frames does is mean you can have a constant seek time for any point in the timeline, not necessarily a fast seek time, and definitely not necessarily a faster-than-realtime seek time.

> We've been using Media Source Extensions on
> Chrome/Firefox to effectively build an "ad-hoc non-sequential frame decoder"
> for the past few years. I understand that seeking isn't cheap when using a
> longer GOP, but when using 100% keyframes, seeking/decoding cost should be
> at its minimum.

Seeking into the middle of a long GOP can be expensive, true. But the general decode cost of an all I-frame movie is much, much higher.  I-frame decoding is expensive, both in file size and decode time.

The MSE specification is built upon the premise of positive playback rates. By seeking backward one frame at a time to simulate a negative playback rate, you're swimming against the stream as far as optimizations we've built into the decoder to support normal playback.

Frankly, the MSE API is not built for what you're trying to achieve, and I think you're barking up the wrong tree here. If the MSE specification explicitly allowed negative playback rates, you could just specify some negative rate and let the media engine do all its optimizations in your favor, including pre-decoding as-of-yet-undisplayed frames, and dropping frames when the decoder can't keep up with the rate you're requesting. But it doesn't, and you're trying to force it to through seeking.

-- 
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/20200502/94948224/attachment-0001.htm>


More information about the webkit-unassigned mailing list