- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2019 13:07:21 +0000
- To: public-webrtc-logs@w3.org
Thanks for the breakdown! To stick with the TPAC decision of only allowing keeping the original encoding from the wire when the constrained mime type is empty, it seems like deferring setting the mimetype until we fire "start" is indeed the simplest solution. I think we should also clarify that "start" is only fired after some data has been encoded then. Today the spec says: > Start recording all tracks in tracks using the MediaRecorder's current configuration, and gather the data into a Blob blob and queue a task, using the DOM manipulation task source, to fire an event named start at recorder, then return undefined. `gather the data into a blob and queue a task, ..., to fire an event named start` is vague. What is the definition of `gather the data`? - "Wait until some data has been gathered and put it into blob, and keep gathering future data into blob as well"? Or - "Gather any incoming data into blob as it comes"? The former would fire "start" after the recorder has seen some data, the latter could fire "start" before the recorder has seen any data. I'll also note that there could be "pause" and "resume" events before "start", which seems unintuitive. Heck, even "stop" could happen before "start" if the blob was empty (and there would be no "start" at all). Also unintuitive. Are we OK with that? FWIW Firefox will currently force the firing of "start" just before it fires "stop" if no "start" was fired yet. This behavior is old so I don't know the full reasoning behind it, but I guess it went like: if we have stopped, we must have started already... -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/139#issuecomment-535493766 using your GitHub account
Received on Thursday, 26 September 2019 13:07:23 UTC