I am creating an audio/video and chat application using webRTC and Node.js. I need to mute and unmute the camera device.
Presently, I am able to disconnect and the other party is not able to see me, but the problem I see is that it doesn't disconnect the camera. It still remains active and connected as I see the camera flash still on.
I need help how to disconnect when muted and connect it back when unmuted. I want the same feature as we see in skype video call.
It varies a bit between Firefox and Chrome. These steps, in this order, work for me.
1) Set the src property on your video element to empty string ''.
2) Make sure the stop method exists before calling it as a function. Firefox doesn't have it, and if you try to run it, your code will throw an error.
if (localStream && localStream.stop) {
localStream.stop();
}
3) After you call cameraStream.stop() (or not), set localStream = null. (Maybe not actually necessary, but it couldn't hurt to let the object get garbage-collected. And when the user asks to start the camera up again, you can check against the variable to see if you need to clean up after the previous stream before starting a new one.)
When you are getting your media, in your success callback function you have to keep your localstream in a variable. Then, when you want to stop your stream, you can do localstream.stop();
To start again, you can repeat to call your getUserMedia() method again.
Related
My question is similar to this
In my web-app, I call replaceTrack() to switch between webcam and screen share content. Everything works fine till replaceTrack() isn't called but when its called some camera reference is still there due to which even after stopping the medaistreams the webcam led is still on. It seems the localstream is still on but no luck even after manually stopping it
I'm working on a p2p webtrc video call between HoloLens2 and PC. I also need to support the capturing of photos(and send photos to the server). Now the video and photo can be supported with a resolution of 2272x1278, but I need the photo resolution of 3904x2196(the highest value that HoloLens2 provides).
The problem is when I am trying to change the resolutions, I found I had no limit when the call continues.
I use MediaCapture to take a photo. And the WebcamSource based on MixedReality-WebRTC running on the SharedReadOnly mode. I thought of one way to solve this: shut the call down when taking a photo, and restart it after capturing finished. But the problem is
How can I set the mode to exclusive WebcamSource when just capturing the photo?
Can I make sure when the call had been shut down, the WebcamSource is released?
Or if there is another way to use different resolutions for the video call and the photo capture? Thanks a lot.
How can I set the mode to exclusive WebcamSource when just capturing the photo?
No, SharingMode has hardcoded in the UwpUtils and does not expose any API to access.
Can I make sure when the call had been shut down, the WebcamSource is released?
To make sure dispose of audio and video tracks and media sources last, please reference the following code:
localAudioTrack?.Dispose();
localVideoTrack?.Dispose();
microphoneSource?.Dispose();
webcamSource?.Dispose();
Im facing with an issue on desktop Safari 13.1 version. If I open the console in the web inspector (with a regular macbook which has webcam and mic) and execute this command on any kind of website:
navigator.mediaDevices.enumerateDevices()
First time it will return in the Promise result with a videoinput and an audioinput.
Second time it will return only 2 audioinput. Videoinput is disappear.
Unfortunately I call this method several times while checking the available devices on my solution.
Any idea why does it happen and how could I get the accurate information about the devices even If I call it more than once?
See the results here
I've found the same issue, also on my iPad running iOS 13.
It seems you need to request camera access first in order to see the correct device list.
navigator.mediaDevices.getUserMedia({ video: true })
This will prompt you for access to the camera (you need to be on HTTPS or localhost).
Grant permission, then run this again and you should see the videoinput device(s) listed in the returned promise:
navigator.mediaDevices.enumerateDevices()
I guess this makes sense as a privacy feature that a website cannot check if a camera exists without first asking your permission.
Currently, the video mute functionality in webrtc is achieved by setting the enabled property of a video track to false
stream.getVideoTracks().forEach(function (track) {
track.enabled = false;
});
But the above code would not only mute the outgoing video, but the local self-view which is rendered using that local stream, also gets black frames.
Is there a way, to ONLY mute the outgoing video frames, but still be able to show a local self-view?
There's no easy way yet. Once MediaStreamTrack.clone() is supported by browsers, you could clone the video track to get a second instance of it with a separately controllable mute property, and send one track to your self-view and the other to the peerConnection. This would let you turn off video locally and remotely independently.
Today, the only workarounds I know of would be to call getUserMedia twice on Chrome (should work on https at least, where permissions will be persisted so the user won't be prompted twice) which would get you two tracks you could video-mute independently, or on Firefox you could use RTCRtpSender.replaceTrack() with a second "fake" video stream from getUserMedia using the non-standard { video: true, fake: true } constraint like this.
We are playing videos from a server. We attach an 'ontimeupdate' event which fires periodically, as the video plays. For slow connections, we can compare where the video currently IS, to where it SHOULD be. Then we can do some other things we need to do, if it is lagging. Everything works fine in Chrome, FF, IE. In Safari, when the connection is slow, the event only fires twice. Why does it get removed? Is there a way to add the event again, inside of the handler for the event? Thanks
The HTML5 audio/video element is still less than perfect. The biggest issues I've noticed is that it doesn't always behave the same way in every browser. I do not know why the timeupdate event stops firing in Safari, but one option you have is to monitor whether the video is playing or not and verifying the information independently. Example,
$(video).bind('play', function() {
playing = true;
}).bind('pause', function() {
playing = false;
}).bind('ended', function() {
playing = false;
})
function yourCheck() {
if (playing) {
if (video.currentTime != timeItShouldBe) {
//do something
}
} else {
return;
}
setTimeout( yourCheck(), 100);
}
Something to that effect. Its not perfect, but neither is the current HTML5 audio/video element. Good luck.
The event will not fire if the currentTime does not change, so it may not be firing if the video has stopped playing to buffer. However, there are other events you can listen for:
1) "stalled" - browser is trying to load the video file, but it's not getting anything from the network.
2) "waiting" - playback has stopped because you ran out of buffered data, but it will probably pick up again once more data comes in from the network. This is probably the most useful one for you.
3) "playing" - playback has resumed. Not to be confused with "play" which just means it's "trying" to play. This event fires when the video is actually playing.
4) "progress" - browser got more data from the network. Sometimes just fires every so often, but it can also fire after it recovers from the "stalled" state.
See the spec for reference.
I've heard some people say that these events can be unreliable in some browsers, but they seem to be working just fine here: http://www.w3.org/2010/05/video/mediaevents.html
If you want to be extra cautious, you can also poll periodically (with a timeout as tpdietz wrote) and check the state of the video. The readyState property will tell you whether you have enough data to show the current frame ( >= 2 ), enough to keep playing at least a little bit into the future ( >= 3 ) or enough to play all the way to the end (probably). You can also use the buffered property to see how much of the video has actually been buffered ahead of where you're playing, so you can roughly estimate the data rate (if you know how big the file is).
MDN has a great reference on all these properties and events.