What is the "important"difference between start/stop and pause/resume methods?

[amn]

I tried reading the descriptions of all the four methods, and between stop and pause at least, I can't find any difference for someone using a MediaRecorder object -- I can pause recording and resume it or I can stop it and start it again -- in both cases there is an expected gap time-wise where the stream didn't make it into the recording, but otherwise the recordings should be identical if the blobs are concatenated into a container, no? Or does start write some header information as part of the first blob(s) for some/all codec and container combinations?

[guest271314]

or I can stop it and start it again

Are you sure that is technically possible?

there is an expected gap time-wise where the stream didn't make it into the recording

Not necessarily.

Or does start write some header information as part of the first blob(s) for some/all codec and container combinations?

Yes.

[amn]

or I can stop it and start it again

Are you sure that is technically possible?

Yes, I am sure -- you can verify so yourself. I have tested this with Firefox 73 on Windows 10. Furthermore nothing in the specification prohibits it. Whether the result of concatenating blobs across a stop-start boundary is a valid media container is of course another matter. Hint: it is not a valid media container, at least not when recording into a WebM container embedding a VP9 video track.

there is an expected gap time-wise where the stream didn't make it into the recording

Not necessarily.

Not sure what you mean here? I was referring to a gap when wall clock time passes between a MediaRecorder.prototype.stop and MediaRecorder.prototype.start calls. Since the recorder wasn't recording during that time, the media won't contain any data for that period, and in case of stopping and starting the recorder again, it won't even be valid.

Or does start write some header information as part of the first blob(s) for some/all codec and container combinations?

Yes.

Yes, I have tested this empirically after submitting this issue, so I guess I can close it.

[guest271314]

If the media source is non-line and being played at an HTMLMediaElement then currentTime can be set to the value of the previous pause or stop. FWIW several approaches to recording media files to same media container https://github.com/guest271314/MediaFragmentRecorder/branches.

Concatenating multiple WebM or other container or containerless media into a single file is possible, and the media can be played back in sequence from the discrete recordings as long as a) the length of the various recordings is known; or b) the merged file is parsed to locate the beginning and ends of the merged files, e.g., https://github.com/WebAudio/web-audio-api-v2/issues/61#issue-554979782. Yes, start() does metadata. pause(), resume() does not write new metadata.

Re "valid" and "invalid" that depends on what the criteria is and what you are trying to achieve.

[guest271314]

Technically, between start() and stop() or pause() and resume() the underlying audio or video can still be stored outside of the MediaRecorder process and be recorded later in sequence by utilizing canvas and Web Audio API to save the images and audio. That approach should eliminate any gaps in the playback.

Is the inquiry mainly about start() writing WebM headers and resume() not writing headers?

Or are you trying to meet a specific requirement?

[amn]

I am sorry for not providing you with an answer earlier. My requirements are merely to be able to pause/resume recording while assembling a valid media container (e.g. a WebM file). To that end, I was not originally sure whether stopping and starting the recorder while continuing appending chunks to the same file would result in a valid container. My testing confirmed it does not -- the media recorder produces a header data when starting recording, and normally there is only one header in a WebM file, at as its first chunk. Pausing and resuming, in contrast, merely changes what frames are generated, I assume -- at least it does not invalidate the media container when continuing to flush chunks generated by the media recorder into it.

I hope this kind of explains why I created the issue. I consider it resolved, for my part, now. I'll wait with closing it, because I hope that whoever meets the same issue can draw a satisfactory conclusion here, so if I haven't explained myself, please do tell me.