Bug 243837 – MediaRecorder.stop() fires an additional dataavailable event with bytes after MediaRecorder.pause()

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

[David Mannion]

iPad (8th Generation)
iOS 15.6


See: https://jsfiddle.net/drmannion/b184akv7/1/
1) click Start Camera
2) Click Start Recording
3) Click Pause.  The dataavailable event fired.  In the console, notice that event.data.size is > 0
4) Click Stop.  The dataavailable event fired again.  In the console, notice that event.data.size is again > 0 and we now have two separate blobs.  Expected: event.data.size == 0.

When mediaRecorder.pause() is called, the mediaRecorder must stop gathering data into the current blob.
When mediaRecorder.requestData() is called, the mediaRecoder must fire the dataavailable event passing the current blob of all the data collected so far, then create a new blob.
When mediaRecorder.stop() is called, the mediaRecoder must stop gathering data and fire the dataavailable event passing the current blob of all the data collected so far, which should be empty.

Either mediaRecorder.requestData() is not properly returning all the collected data (Bug# 222285) or additional data is being collected after the mediaRecorder.pause().


Similar or possibly related bugs:
https://bugs.webkit.org/show_bug.cgi?id=222285
https://bugs.webkit.org/show_bug.cgi?id=221916

[Radar WebKit Bug Importer]

<rdar://problem/98565949>

[youenn fablet]

Hi David,

As I see it, when calling pause, we stop recording any data.
But there is still some data in transit. For instance, we do not flush audio/video encoders so there might still be some data being encoded and not yet written.
Ditto for the writer that gets the compressed buffer and creates the actual media stream from it.
When stopping, we actually flush encoders and writer to get all available data.
This probably explains why there is some remaining data available when stop is being called.

Can you describe what the impact of this behavior is?

[David Mannion]

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.

[youenn fablet]

Pull request: https://github.com/WebKit/WebKit/pull/3399

[EWS]

Committed 253529@main (f2967879748b): <https://commits.webkit.org/253529@main>

Reviewed commits have been landed. Closing PR #3399 and removing active labels.