Re: [webrtc-pc] Should the remote track mute in response to replaceTrack(null)? (#3077)

Whether this is strange or not strange depends on what you think the responsibility of the mute state is supposed to reflect, which has historically been up for interpretation. But if "unmuted" doesn't mean "media is flowing", it only means "UA is not preventing media from flowing", then I agree there is nothing strange about the current spec language.
- Based on the input here from @jan-ivar and @youennf and also from talking offline with @guidou, I'm under the impression that "Mute causes lack of frames. Lack of frames does not cause mute." is the majority opinion.

I'm not opposed to this definition assuming we can converge on it without backwards compat issues.

My concern with Chrome's current "mute when media hasn't flown in a while" is it makes assumptions that the frame rates will be relatively constant and is heuristic based, but there exists variable FPS sources or sources where not sending any frames for a while is "normal".

> Web apps can probably use stats instead so the benefit of doing this spec work might not be very high.

Yes, we have pc.getStats(). We don't have [track.stats](https://w3c.github.io/mediacapture-extensions/#mediastreamtrack-statistics) for remote tracks because that API is only defined for local tracks, but pc.getStats() would be more valuable here because in the case of audio you need to distinguish between real samples (real packets) and not synthesized samples (no packets = synthesized silence produced).

-- 
GitHub Notification of comment by henbos
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/3077#issuecomment-3351145998 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 30 September 2025 10:16:57 UTC