Re: [mediacapture-main] Relinquish device when all tracks are muted or disabled. (#662)

> Screenshare has no observable device HW light, so I no reason to relinquish anything there.

I might be missing something, but a device HW light does not seem like a good criteria.
Any OS level/user agent icon seems in scope to me.
Microphone seems in scope as well although there is often no HW light, at least for built-in mics.

> This has no impact on the track's [muted](https://w3c.github.io/mediacapture-main/getusermedia.html#track-muted) state which is _"out of control for the application"_.

It has impact on the track's muted state.
An application can actually change the muted state if it is capturing and not having focus by doing enabled=false/enabled=true.

IIRC, the spec currently does not mandate the user agent to mutate the muted state of a capture track. This PR breaks the assumption that the capture muted state is in full control of the user agent.

> Having web sites go through new APIs specifically for Safari would be a mistake IMHO.

This is not only about Safari, this PR tries to minimise the amount of changes to the existing API at the expense of convenience and backward compatibility.

If we add a user activation requirement for this, which I think we should do in this PR and not as a follow-up, we will use a pattern of setting an attribute based on user activation, but this requirement might only apply for a subset of all MediaStreamTrack objects. This seems like a new pattern.

If we add activation requirement, this API does not allow to tell whether the task was rejected because of lack of user activation or something else. Or we will add something like an exception, which might not be very backward compatible. Usually we try to provide this information, see for instance video.play() or device orientation requestPermission.

Setting this attribute might trigger a prompt, which might be a new pattern.
To know whether this async-by-nature task is completed, a web page might have to combine the information given by two event listeners. This also seems like a new pattern.

Web sites will have to adapt whatever the API we choose.
If a web page uses track cloning or requests several media stream tracks, the page will need to make sure to disable all tracks related to a given device to actually get the desired effect. Ditto for enable, potentially in the same runloop if we add the user activation requirement.
This seems error prone and not very web developer friendly.

Given the fact that the target of this PR is specifically about capture sources and MediaStreamTrack can have non-capture sources, I am even wondering whether MediaStreamTrack is the right place for this API.
From a model point of view, it seems this feature is something like 'mute that device' which is closer to MediaDeviceInfo for instance.

> The consensus at the [virtual interim](https://www.w3.org/2011/04/webrtc/wiki/February_27_2020) last Thursday was to merge this PR.

I was planning to attend but unfortunately had to miss it.
I guess I would have expressed the points stated above.
I hope they can be taken into consideration.

-- 
GitHub Notification of comment by youennf
Please view or discuss this issue at https://github.com/w3c/mediacapture-main/pull/662#issuecomment-594008148 using your GitHub account

Received on Tuesday, 3 March 2020 15:25:49 UTC