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

[bugzilla-daemon at webkit.org]

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

--- Comment #16 from Dustin Kerstein <dustin.kerstein at gmail.com> ---
Ok, so it sounds like the second issue (seeks being squashed when seeking too quickly) is more or less as-designed and there isn't a way to protect against / detect this condition. Is that right?

I'm still curious about the first issue though, where seeking to earlier frames in the buffer (even when they are 100% keyframes) are much slower than seeking later frames. Here's a really simple test that appends 243 keyframes to the buffer and measures seek time to the console - https://jsfiddle.net/o27m5pwt - Hitting the keyboard number keys seeks to various individual frames spaced out through the buffered time range. Here's the behavior I see:

1. When seeking between frames 242 and 241, the seek time is around 1ms
2. When seeking between frames 0 and 1, the seek time is around 40ms
3. When seeking between frames 242 and 0, the seek time is around 20ms (and I am seeing a seeing a flicker of a third frame being decoded somehow)

If I perform this same test when using a Blob as a video source (comment out line #7 and switch lines #20 and #21) then I see near constant seek times of around 20ms (except for the occasional slowness which I believe is caused by https://bugs.webkit.org/show_bug.cgi?id=211295)

I guess even if we figure out the cause of this slowness, I'd probably still run into the squashed seek issue, but the former issue seems like it could be more of a general issue across more normal seeking use-cases. Do you see what could be going on there?

-- 
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/20200503/9dad0181/attachment.htm>