- From: Andreas Pehrson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 25 Feb 2020 21:10:08 +0000
- To: public-webrtc-logs@w3.org
The spec says: > 8. If the [[ConstrainedMimeType]] slot specifies a media type, container, or codec, then run the following sub steps: > > 8.1. Constrain the configuration of recorder to the media type, container, and codec specified in the [[ConstrainedMimeType]] slot. > > 8.2. For each track in tracks, if the User Agent cannot record the track using the current configuration, then throw a NotSupportedError DOMException and abort all steps. My intention when writing this was that a present codecs parameter locks the codecs in. As in, the vp8 codec is specified, thus the UA cannot add another. In the end, the vp8 codec alone can not record an audio track, thus we should throw. In my mind the main reason in favor of this behavior is that web developers may catch bugs early. Because they're specifying codecs they want exactly those codecs -- trying to record mismatched tracks is likely a bug on their part. On the other hand, if the UA is allowed to add codecs, would it be allowed to add a codec of the same type as the one already present? I'd argue no, because it is already specified. Applying the same logic to the entire codecs parameter reduces the corner cases and simplifies the logic, which seems like an improvement. Can we 'just' clarify the spec here? -- GitHub Notification of comment by Pehrsons Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/194#issuecomment-591070629 using your GitHub account
Received on Tuesday, 25 February 2020 21:10:09 UTC