- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Dec 2023 18:57:47 +0000
- To: public-webrtc-logs@w3.org
> > For video, MediaStreamTrack stats is hopefully sufficient to detect these malfunctioning cases. For audio, it is unclear whether MediaStreamTrack stats is enough, maybe this should get fixed. > > When the `mute` event is fired and the app observes it and turns to handle it, what stats are available to it that would definitively, non-heuristically inform it that the track is muted due to an upstream entity such as the OS or UA? What is _"an upstream entity such as the OS or UA"_ distinct from, when all muting is "UA" by definition? This seems to be the definition problem we're having. Turning the question around: When the `mute` event is fired in Chrome and the app observes it and turns to handle it, what stats are available to it that would inform it that the track is malfunctioning? In other browsers, apps could detect this (e.g. using stats once implemented): - lack of frames in stats + !track.[muted](https://w3c.github.io/mediacapture-main/#dom-mediastreamtrack-muted) = malfunction In Chromium, apps cannot, because Chromium circularly masks the symptom, making malfunction indistinguishable from _"OS or UA"_ mute. This problem seems unique to Chromium, as does the need for a new mute-reason API to resolve it. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/982#issuecomment-1864985520 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 December 2023 18:57:49 UTC