- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Oct 2019 15:03:08 +0000
- To: public-webrtc-logs@w3.org
> > Ok. If we can't solve this I'd rather see us skip the mimetype deferral and only add a note. > > Let's not throw everything out over a difference of opinion about whether or not to wait for data to become available, I'm happy to not make that change, as long as we don't force the UA to set the mimeType prior to starting the recording. See PR, I hope this will make both sides happy? Primarily I want to avoid a situation where we set the mimeType at different times depending on the UA's intentions (sync in start() if transcoding, vs async when start() later fires "start" when avoiding transcoding). Your PR achieves that. Secondarily I want to avoid shutting the door on something that would allow an application to dynamically handle track set changes (FWIW issue #4 covered this and is one of the most discussed issues on the spec, but was closed without resolution). Your PR does not achieve that. I could accept shutting this door if the WG discusses this and finds consensus for shutting it. I see two ways out that avoid both situations above: - Letting the UA start encoding data synchronously in start() although it won't fire "start" (or reveal its mimeType) yet. - Letting the UA guess (I imagine there's a bunch of heuristics the UA could use to guess right) mimeType synchronously in start() and avoiding transcoding iff the guessed codec and the actual codec match. I'll review the details of the PR if we can move forward with one of the three options mentioned above. -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/pull/190#issuecomment-542258055 using your GitHub account
Received on Tuesday, 15 October 2019 15:03:10 UTC