- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Sat, 28 Mar 2020 16:29:04 +0000
- To: public-webrtc-logs@w3.org
> That's out of scope of this spec. Take it up with the manufacturer. Agree. That is what you should do. However, in this case the device appears to be doing what you expect it to do. Thus, you are still using the device instead of a device that does not do that. That is a choice. *nix does not do that. If it did would start a shell and command the machine to not do that. > Here's the full text: "There can be several reasons for a MediaStreamTrack to be muted: the user pushing a physical mute button on the microphone, the user toggling a control in the operating system, the user clicking a mute button in the browser chrome, the User Agent (on behalf of the user) mutes, etc. None of that language articulates that the stream should stop because a laptop lid is closed or a user put their "smart" phone in their pocket and continued performing activities knowing full well a button could be pressed while the device is in their pocket. > If you're concerned about laptop lid detection, I recommend looking at w3c/webrtc-pc#2489 and https://bugs.chromium.org/p/chromium/issues/detail?id=1060547. No, am not concerned about that case, nor the wiles of "smart" phone functionality. Am stating this specification should not be concerned with those matters either. Pick a device that does what you want it to do. As you apparently have. That does not mean just because you expect a stream to stop when the laptop lid is closed, or whatever device you happen to be used mutes a track for some reason, others expect the same output. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/670#issuecomment-605482439 using your GitHub account
Received on Saturday, 28 March 2020 16:29:06 UTC