[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 #4 from Dustin Kerstein <dustin.kerstein at gmail.com> ---
It looks like some of the above issue was related to appending an already existing frame in the buffer. I was able to utilize a workaround by tricking Safari into setting m_shouldGenerateTimestamps (https://github.com/WebKit/webkit/blob/29271ffbec500cd9c92050fcc0e613adffd0ce6a/Source/WebCore/Modules/mediasource/SourceBuffer.cpp) by using the following code:

sourceBuffer = ms.addSourceBuffer('audio/mpeg'); 
sourceBuffer.mode = 'sequence';

And then seeking to an ever increasing value. See here for a demo - https://jsfiddle.net/dustinkerstein/wsm8gh7e/ - Note that when testing in Safari you'll need to click the video in the iFrame to get the rAF render loop to run at 60fps (otherwise it's stuck at 30fps - and less likely to exhibit the issue mentioned below). 

However, the above workaround only works in certain conditions based on the computer's capabilities / video specs. It appears as though the seek operation (via fastSeek or setting currentTime) gets lost / cancelled out by a subsequent seek. Ie. When seeking quickly, I am missing 'seeked' events (try on an iPad or older laptop / desktop for easier replication with the demo above). No error is shown, the video just gets stuck, either temporarily or permanently. I've tried other possible workarounds that don't rely on seeking, but to no avail. 

Does anyone see any alternative way to get this working? Would it be considered a bug for those 'seeked' events to get lost?

-- 
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/20200501/e56dfd3a/attachment-0001.htm>