Re: [mediacapture-main] what is the default channelCount (#775)

> 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]( 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 2 March 2021 23:55:37 UTC