- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 Mar 2023 17:38:24 +0000
- To: public-webrtc-logs@w3.org
> If track1 and track2 share the same source, WebKit would probably fail both of them,
When you say "fail" here, you mean WebKit would [end](https://w3c.github.io/mediacapture-main/#track-ended) active tracks because another call to getUserMedia was made?
Even so, track [ended](https://w3c.github.io/mediacapture-main/#track-ended) doesn't rely on source [stopped](https://w3c.github.io/mediacapture-main/#source-stopped). It's the other way around.
Firefox would instead fail creation of `track3` FWIW. But these seem like UA decisions independent of where `source` is defined. IOW, I'd expect the same behavior from the following code (becase constraints are per-track, not per-source):
```js
const track1 = navigator.mediaDevices.getUserMedia({video: {facingMode: 'environment', width:640});
const track2 = track1.clone(); await track2.applyConstraints({video: {width:1280}});
const track3 = navigator.mediaDevices.getUserMedia({video: {facingMode: 'user', width:640});
```
This seems like POLA, an invariant worth clarifying in the spec, so implementations don't implement side effects that affect API usage.
> If the source granularity was the top page, [[devicesLiveMap]] would also start to be out of sync as well.
True, but this seems trivially avoided by using a `rawDeviceId` instead of the awkward reference to MediaDeviceInfo's [deviceId](https://w3c.github.io/mediacapture-main/#dom-mediadeviceinfo-deviceid), which is what I believe implementations do in practice already.
> Can we settle on source granularity being the JS realm then?
Can we eliminate option 1 first? I'd like to discuss between option 2 and 3, but wanted to simplify first.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/940#issuecomment-1476666602 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 20 March 2023 17:38:29 UTC