[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 #5 from Dustin Kerstein <dustin.kerstein at gmail.com> ---
Alright, so I think I'm seeing two distinct issues related to seeking with MSE.

1. Seeking to non-latest buffer - When using Mode=Segments, even when I protect against appending an already appended buffer, I still see huge lag when seeking - https://jsfiddle.net/nh97yba3 - I further tested appending the entire video - https://jsfiddle.net/rxjom47L - and I still see this same lag. So I think what it boils down to is seeking to a buffer that isn't the "end/latest". 

2. Seeking too quickly -  Here is an MSE test based on my workaround using Mode=Sequence, using SetInterval to control the seek rate - https://jsfiddle.net/5jtfbh8m - Note you'll need to tweak the SetInterval period to find where your computer is unable to keep up. On my iPad Pro it starts to freeze well below 60fps even at the HD resolution, whereas my Macbook Pro can handle UHD up to over 100fps. But either way, at some combination of computer capabilities + video specs it just stops seeking (ie. displaying frames) and this state can't be easily detected in code during playback. Non-MSE playback behaves differently - https://jsfiddle.net/m4hystc5 - Even when pushed beyond decoding limits, it is still able to display new frames. One further interesting note is that in the MSE version when playback is frozen, you can switch to a different tab and then back, and you'll see a new frame. 

Note that with all of these JSFiddles, you'll need to click into the result/video frame to get it to render at full speed. There is battery saving ad tech in Safari that restricts iFrames from rendering at full speed until they are focused on.

Let me know if you need any further info / debug. Do you feel that either of these issues could be addressed in a fix, or possibly a workaround?

-- 
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/3fd69efb/attachment.htm>