Bug 243837

Summary:	MediaRecorder.stop() fires an additional dataavailable event with bytes after MediaRecorder.pause()
Product:	WebKit	Reporter:	David Mannion <dmannion>
Component:	WebRTC	Assignee:	youenn fablet <youennf>
Status:	RESOLVED FIXED
Severity:	Normal	CC:	eric.carlson, jer.noble, webkit-bug-importer, youennf
Priority:	P2	Keywords:	InRadar
Version:	Safari 15
Hardware:	iPhone / iPad
OS:	iOS 15

Description David Mannion 2022-08-11 11:42:20 PDT

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

Comment 1 Radar WebKit Bug Importer 2022-08-12 06:54:57 PDT

<rdar://problem/98565949>

Comment 2 youenn fablet 2022-08-16 06:07:24 PDT

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?

Comment 3 David Mannion 2022-08-16 09:45:41 PDT

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.

Comment 4 youenn fablet 2022-08-17 02:15:22 PDT

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

Comment 5 EWS 2022-08-17 11:48:43 PDT

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

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