- From: amn via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Feb 2020 17:26:39 +0000
- To: public-webrtc-logs@w3.org
> > > 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](https://w3c.github.io/mediacapture-record) 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. -- GitHub Notification of comment by amn Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/195#issuecomment-588341525 using your GitHub account
Received on Wednesday, 19 February 2020 17:26:41 UTC