- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Aug 2019 15:05:52 +0000
- To: public-webrtc-logs@w3.org
@alvestrand Am asking for clarification as to the mechanism which dispatches `unmute` event at a `MediaStreamTrack` of `kind` `"video"`. Why does the process take up to 3 minutes? Is that question considered an implementation detail? Is there a canonical procedure defined by the specification to estimate or determine the length of time that is required for `unmute` to be dispatched? Without any guidance from the specification could have simply refreshed the tab without ever reaching `unmute` event being dispatched due to the length of time that it takes for the track to reach the `unmute` state. Though because the code is based on testing waited. If the code was deployment at large it would be helpful for the developer and users that are waiting on the `MediaStreamTrack` to reach `unmute` state to have some form of standardized timeline for the process. A user might wait 10 to 15 seconds for a procedure to potentially change state, though some users might not wait 3 minutes for `unmute` as there is no certainty that media will ever be unmuted. How would they technically know? `chrome://webrtc-internals` does provide some statistics, though it is not clear how to extrapolate an estimation of when `unmute` will be dispatched. > The muted/unmuted state of a track reflects whether the source provides any media at this moment. > Muted is out of control for the application, but can be observed by the application by reading the muted attribute and listening to the associated events mute and unmute. 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. In this case frames are constantly being drawn onto a captured `canvas`. `replaceTrack()` replaces the canvas track with a track from a video capture. Therefore the expectation is that there should not be a span of 30 seconds to 3 minutes where either the canvas track or the video track are muted. Though that is the case. Am asking how to determine when the track will be unmuted given those criteria. Not sure how the specification question as to `unmute` timing is a Chrome bug? Filed the issue because considered 30 to 60 seconds being a substantial amount of time to await `unmute` event when no server is involved. If the inquiry, in your view, is not related to the specification, can simply close this issue, leaving the matter of how to determine how to estimate when a track is unmuted unanswered. -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/614#issuecomment-523946153 using your GitHub account
Received on Thursday, 22 August 2019 15:05:54 UTC