- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Mar 2021 23:55:32 +0000
- To: public-webrtc-logs@w3.org
> The spec mentions platform defaults, but do not define them. Just like web audio doesn't define _"default output device"_. It's UA specific. > We can probably test it, by comparing WebAudio default sampleRate with getUserMedia default sample rate. This would test that the user agent is consistent with its own definition of _"default device"_. I agree with this level of testing. But that's different from mandating default device setting values (regardless of device?) must be the same across user agents, which would require a spec change. > For some constraints, the OS provides default values and we should use them, like web audio is doing. > For other constraints, the OS does not provide default values, say echoCancellation. Agreed.¹ I'd put `channelCount` and `sampleRate` in the first category. I appreciate the nuance that there are two questions: 1) whether we need to specify more around how UAs must deduce defaults, and 2) should those defaults be hard-coded values or be derived from platform/OS. I think this is going to be difficult, and is why the spec has stayed out of this so far, trusting user agents with defining this. I think disagree with the notion that code is not "interoperable" unless it gives the exact same values as other browsers for the same platform + device. The "unconstrained" API feature here is literally to ask for the user agent's defaults. As long as that user agent is consistent with itself, that might be enough. A hard part will be facing up to cases where we didn't go for the ideal (if not max) available quality say, like the conservative 640x480x30 + echoCancellation + noiseCancellation + audoGainControl. These decisions were clearly biased toward making sure the RTCPeerConnection sink didn't blow up. Also, Chrome's `resizeMode: "crop-and-scale"` approach basically morphs `getUserMedia` from a device discovery API into a resolution control-surface for RTCRtpSender. Ironically, the mediacapture spec still also has some [fairly liberal ideas](https://w3c.github.io/mediacapture-main/getusermedia.html#the-model-sources-sinks-constraints-and-settings) around what UAs are allowed to do to change unconstrained camera settings to adapt to sinks: *"A <video> element that displays media from a dynamic source can either perform scaling or it can feed back information along the media pipeline and have the source produce content more suitable for display."* — I don't think anyone has implemented anything like this. But it's something defining defaults would close the door on. --- <sub>1. though since an OS _could_ provide echoCancellation, the OS default is arguably false except on the Lenovos mentioned.</sub> -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/775#issuecomment-789310054 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 March 2021 23:55:37 UTC