A short conversational Q&A from a July 26, 2024 video by Tsahi Levent-Levi discussing how to mute video in WebRTC. Speakers explain two main approaches: disabling the video track (setting enabled=false) which sends black frames at reduced bitrate but keeps the camera active (camera light stays on), or calling stop() on the media stream track to release the camera (turning camera light off) but requiring reacquisition via getUserMedia and replaceTrack on the peer connection. They note audio differs because keeping the microphone open is often preferable for application reasons (e.g., voice activity detection).
Chapters
Another question similar to the previous one. How do you mute video in WebRTC?
So the question, the answer is slightly different from audio because we have basically two ways to go about it. First is like, for audio, you set the tracks enabled attributed false, which will cause sending black frames. And since these frames are all black, the bitrate is pretty low.
But we're still sending video frames and I'm still receiving video. I'm just receiving black video.
Yes.
Okay.
Bit rate and packet rate will be reduced, but you still get 30 frames per second.
Yep.
And the main problem is that the camera light stays on, which you don't have that often for audio, but for video, users will notice it. They're like, but I muted access to the camera. Why is the camera light still on?
Why are you watching me?
Why are you watching me? Yes. So the way to go about that, which you will eventually need to do is to call stop on the media stream track, which releases the camera and should stop the camera light. Problem is you then need to call GetuserMedia again to reacquire the camera, which might fail. It rarely does, but sometimes it can happen. And then you need to use replace direct to replace the track on the peer connection.
Okay, so now you got me confused. Because if I need to go to all of this effort and work for video, why not do it for audio as well?
Good question. I think the main difference is that for audio it makes more sense to keep it around. So you have speaking when you use the detection, which makes the second alternative to just call replacetrack and deattacher from the connection much more attractive.
What you're saying is that for audio there are actually compelling reasons for me as an application and for you as a user, to keep the microphone open while not sending audio, whereas in video it's almost the opposite.
