- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Mar 2023 23:59:58 +0000
- To: public-webrtc-logs@w3.org
> I do not think the spec works well with source as a singleton. > For instance, it is useful to be able to have all tracks of a document tracks being muted while tracks of another document tracks are not muted, even if they both are using the same camera. Safari is using this for instance to have only one tab capturing at a time. If the source was a singleton, it would not be possible. As you say, _tracks_ are [muted](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastreamtrack-muted), not sources, so I don't immediately see what's not possible. But let's dig in: [§ 4.3.1.2 Media Flow](https://w3c.github.io/mediacapture-main/getusermedia.html#media-flow) begins with _"[Muted](https://w3c.github.io/mediacapture-main/getusermedia.html#track-muted) refers to the input to the [MediaStreamTrack](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastreamtrack)."_, BUT this ultimately just describes the [track's muted state](https://w3c.github.io/mediacapture-main/getusermedia.html#set-track-muted), and when the UA should update it, which it accomplishes (almost!) without mentioning "source". The section has just two mentions of "source" near the end: 1. _"media from the source only flows when a [MediaStreamTrack](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastreamtrack) object is both unmuted and enabled."_, which is fine 2. _"For a newly created [MediaStreamTrack](https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediastreamtrack) object, the following applies: the track is always enabled unless stated otherwise (for example when cloned) and the muted state reflects the state of the source at the time the track is created."_ The second one does mention _"the muted state reflects the state of the source"_, which seems a tacit admission that the source has some (unnamed) state. But I think s/source/input/ here would have been more self-consistent with the rest of this section. I think what happened here was that all the user agent examples we could think of at the time were global to the user agent (_"the user pushing a physical mute button on the microphone, the user closing a laptop lid with an embedded camera, the user toggling a control in the operating system"_), and we wanted to express the invariant that creation of new tracks shouldn't sidestep those user-directed privacy measures, so we had no choice but to tacitly refer to some state outside of the track.¹ I think the challenge here is how to express this invariant while at the same time allowing a user agent to mute all tracks in some contexts and not others. — But I don't think defining multiple instances of _source_ is the answer, because having an instance live inside a single (per realm) global object seems too limiting, because in my view, the idea that gUM for the same camera from a page and from an iframe in that page (see my example [above](https://github.com/w3c/mediacapture-main/pull/939#issuecomment-1458870504)) refers to distinct source objects seems confusing for little benefit. At least in Firefox, privacy indicators act as if this is the same source (yes I gave up fixing that section in the spec). > AIUI, the main (only) requirement is that cloned tracks have to share the same source. This is the minimum granularity that all UAs adhere to and this is what we can use as a basis. [Transferred](https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack) tracks also share the same [[Source]] of their [detached](https://html.spec.whatwg.org/multipage/structured-data.html#detached) counterpart. Such tracks may be transferred not just to workers but to other documents, in which case their relevant global object (which will be in the destination realm) won't have it in its [[[mediaStreamTrackSources]]](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-mediastreamtracksources). This, iframes, and the way privacy indicators have been implemented in all browsers, I think suggest the minimal granularity is a page. E.g. if an iframe calls gUM, transfers the resulting video track up to the document containing it, and then the iframe navigates, does the the video track end? If so, why should it? The permissions were delegated to the iframe in the first place, so why can capture not continue? So perhaps the source should live in the top-level document? Or maybe we can write algorithms that don't depend on where sources are defined? > > This fails to: > > > > 1. queue a task > > We should dig into this, stopping the sources happen when the document gets unloaded, it is not clear whether queueing a task at this time will ensure the task will be executed. Good point. I can remove that. > It works as follows: > > * the source has tracks in different global objects > > * only one global object will trigger stopping the source when global object gets unloaded > > * all tracks that are not in the source global object will get ended after the source is stopped (with an ended event). My problem with this and the current text is it only works correctly if we ASSUME sources are different per global object, which at best isn't obvious and at worst seems to lack support in the spec, which means when I read this (thinking sources are singletons) it reads to me as doing the WRONG thing (stopping other concurrent sources). In contrast, I hope my PR does not rely on that assumption (since it was written without it). --- <sub>1. There's also the more recent: _"[[[Muted]]](https://w3c.github.io/mediacapture-main/getusermedia.html#dfn-muted), initialized to true if source is [muted](https://w3c.github.io/mediacapture-main/getusermedia.html#track-muted)"_, which I think erroneously refers to the track muted state.</sub> -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/pull/939#issuecomment-1461053818 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 March 2023 00:00:00 UTC