WebRTC/getUserMedia: How to properly mute local video?

Question

I\'m trying to implement the functionality for muting the local video MediaStreamTrack in my WebRTC application. Here\'s how I\'m approaching this:

Answer 1

I think you can make two requests for getuser media : http://codepen.io/anon/pen/gjtpu . Then you can really stop a stream. You will also have to use mutiple peer connection between user since renegociation (adding or removing stream during to an existing peer connection) is not supported by firefox

Answer 2

Today

track.stop() works just fine in Firefox. Chrome's behind. Spec way to end a track (https fiddle):

navigator.mediaDevices.getUserMedia({video: true, audio: true})
  .then(stream => video.srcObject = stream)
  .catch(e => log(e.name + ": "+ e.message));

let stop = k => video.srcObject.getTracks().map(t => t.kind == k && t.stop());

<video id="video" width="160" height="120" autoplay></video><br>
<button onclick="stop('video')">Stop Video</button>
<button onclick="stop('audio')">Stop Audio</button>

This gives you a way to turn off video while keeping audio, without permission re-prompt in Firefox. You still get prompted when turning video back on, so it's not perfect, but 50% better.

Until Chrome catches up, your other answer (drop and re-gUM each time) should work there, since they never re-prompt.

By browser-detecting and combining these answers, it should be possible to come up with something that works well in more than one browser, until browsers catch up.

Long term

The spec has recently addressed this by allowing browsers to turn off the camera light during temporal mute (e.g. track.enabled == false), provided a camera access indicator remains on:

"The User Agent is encouraged to provide ongoing indication of the current state of anyAccessible.

The User Agent is encouraged to provide ongoing indication of the current state of anyLive and to make any generic hardware device indicator light match."

Stronger language precedes these statements in the spec, making indicators a requirement.

Currently, browsers do not implement this correctly. Chrome is close, with a tiny camera access indicator inside the url bar on the right after recent access, but it fails to appear on page load to warn that persistent access was granted on a previous visit; the site can turn the camera on at any time.

Answer 3

We solved this by tearing down the local media stream and creating it anew without the video track. Doing it mid-call requires either re-establishing the peer connection or performing renegotiation (triggered by sending a new offer).