I\'m trying to implement the functionality for muting the local video MediaStreamTrack
in my WebRTC application. Here\'s how I\'m approaching this:
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());
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.
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.