[Webkit-unassigned] [Bug 243837] MediaRecorder.stop() fires an additional dataavailable event with bytes after MediaRecorder.pause()

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Aug 16 09:45:41 PDT 2022


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

--- Comment #3 from David Mannion <dmannion at propractice.com> ---
Youenn, thanks for being so responsive. I figured it was a stream/buffer not getting flushed correctly, but I think its the requestData(), not pause() that is not flushing correctly. We use pause() and then requestData() so our users can continue recording if they want to (I can provide more details if you'd like).  The user has the option to save/send their recording any time after pausing.  They don't necessarily have to stop().  In fact, we only use the stop() method when they transition to the next section/page or if they Clear out their existing recording and want to start over and overwrite their previous recording.

This works correctly in other browsers, and according to the MediaStream Recording spec, after requestData() the mediaRecoder must fire the dataavailable event passing the current blob of all the data collected so far, then create a new blob.  In this sequence,
start()
pause()
requestData()
stop()

The requestData() call must send all data collected up until the pause() and there should be no more data collected after the pause() because there is no call to resume(), so stop() should call dataavailable with an empty blob.


The impact is that the recorded video file is truncated and missing a variable number of seconds at the end.  In addition, because Webkit iOS is not spec compliant, we'd have to write custom code to handle Safari.

-- 
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/20220816/bfe26e6f/attachment.htm>


More information about the webkit-unassigned mailing list