how to close mediastream after multiple remote peers attached?
I am creating multiple webrtc peer connections and creating a single mediastream using
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
audio: true,
video: true
}).then(function (stream) {
mediaStream = stream;
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}).catch(function (err) {
console.log("get user media " + err.name + ": " + err.message);
});
} else {
console.log("using the existing local stream");
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}
Everything works perfectly until the last peer connection is closed and I want to close the mediastream.
if (mediaStream != undefined) {
if (mediaStream.active) {
mediaStream.getTracks().forEach(function (track) {
track.stop();
});
mediaStream = null;
}
}
If only 1 peer connection has been used then everything shuts down as planned. If more than 1 peer connection has used the MediaStream then the MediaStream becomes null , but the camera indicator on the browser and the camera light both stay on.
What am I missing?
javascript webrtc mediastream rtcpeerconnection
edited Nov 22 '18 at 13:40
mkUltra
764922
asked Nov 22 '18 at 12:31
CroftieCroftie
83
add a comment |
I am creating multiple webrtc peer connections and creating a single mediastream using
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
audio: true,
video: true
}).then(function (stream) {
mediaStream = stream;
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}).catch(function (err) {
console.log("get user media " + err.name + ": " + err.message);
});
} else {
console.log("using the existing local stream");
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}
Everything works perfectly until the last peer connection is closed and I want to close the mediastream.
if (mediaStream != undefined) {
if (mediaStream.active) {
mediaStream.getTracks().forEach(function (track) {
track.stop();
});
mediaStream = null;
}
}
If only 1 peer connection has been used then everything shuts down as planned. If more than 1 peer connection has used the MediaStream then the MediaStream becomes null , but the camera indicator on the browser and the camera light both stay on.
What am I missing?
javascript webrtc mediastream rtcpeerconnection
edited Nov 22 '18 at 13:40
mkUltra
764922
asked Nov 22 '18 at 12:31
CroftieCroftie
83
refactored the code and now embarrassingly It works. In the full code there were 2 places where the mediastream could be called depending on whether the client was the offeror or the offeree. One of them was calling a new media stream and that was the problem. Thanks to Kaiido for perseverance
– Croftie
Nov 25 '18 at 10:59
add a comment |
I am creating multiple webrtc peer connections and creating a single mediastream using
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
audio: true,
video: true
}).then(function (stream) {
mediaStream = stream;
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}).catch(function (err) {
console.log("get user media " + err.name + ": " + err.message);
});
} else {
console.log("using the existing local stream");
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}
Everything works perfectly until the last peer connection is closed and I want to close the mediastream.
if (mediaStream != undefined) {
if (mediaStream.active) {
mediaStream.getTracks().forEach(function (track) {
track.stop();
});
mediaStream = null;
}
}
If only 1 peer connection has been used then everything shuts down as planned. If more than 1 peer connection has used the MediaStream then the MediaStream becomes null , but the camera indicator on the browser and the camera light both stay on.
What am I missing?
javascript webrtc mediastream rtcpeerconnection
edited Nov 22 '18 at 13:40
mkUltra
764922
asked Nov 22 '18 at 12:31
CroftieCroftie
83
I am creating multiple webrtc peer connections and creating a single mediastream using
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
audio: true,
video: true
}).then(function (stream) {
mediaStream = stream;
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}).catch(function (err) {
console.log("get user media " + err.name + ": " + err.message);
});
} else {
console.log("using the existing local stream");
mediaStream.getTracks().forEach(function (track) {
rtcPeerConns[userName].addTrack(track, mediaStream);
});
}
Everything works perfectly until the last peer connection is closed and I want to close the mediastream.
if (mediaStream != undefined) {
if (mediaStream.active) {
mediaStream.getTracks().forEach(function (track) {
track.stop();
});
mediaStream = null;
}
}
If only 1 peer connection has been used then everything shuts down as planned. If more than 1 peer connection has used the MediaStream then the MediaStream becomes null , but the camera indicator on the browser and the camera light both stay on.
What am I missing?
javascript webrtc mediastream rtcpeerconnection
javascript webrtc mediastream rtcpeerconnection
edited Nov 22 '18 at 13:40
mkUltra
764922
asked Nov 22 '18 at 12:31
CroftieCroftie
83
edited Nov 22 '18 at 13:40
mkUltra
764922
asked Nov 22 '18 at 12:31
CroftieCroftie
83
edited Nov 22 '18 at 13:40
mkUltra
764922
edited Nov 22 '18 at 13:40
mkUltra
764922
edited Nov 22 '18 at 13:40
mkUltra
764922
764922
asked Nov 22 '18 at 12:31
CroftieCroftie
83
asked Nov 22 '18 at 12:31
CroftieCroftie
83
asked Nov 22 '18 at 12:31
CroftieCroftie
83
83
refactored the code and now embarrassingly It works. In the full code there were 2 places where the mediastream could be called depending on whether the client was the offeror or the offeree. One of them was calling a new media stream and that was the problem. Thanks to Kaiido for perseverance
– Croftie
Nov 25 '18 at 10:59
add a comment |
refactored the code and now embarrassingly It works. In the full code there were 2 places where the mediastream could be called depending on whether the client was the offeror or the offeree. One of them was calling a new media stream and that was the problem. Thanks to Kaiido for perseverance
– Croftie
Nov 25 '18 at 10:59
refactored the code and now embarrassingly It works. In the full code there were 2 places where the mediastream could be called depending on whether the client was the offeror or the offeree. One of them was calling a new media stream and that was the problem. Thanks to Kaiido for perseverance
– Croftie
Nov 25 '18 at 10:59
refactored the code and now embarrassingly It works. In the full code there were 2 places where the mediastream could be called depending on whether the client was the offeror or the offeree. One of them was calling a new media stream and that was the problem. Thanks to Kaiido for perseverance
– Croftie
Nov 25 '18 at 10:59
add a comment |
1 Answer
1
active
oldest
votes
That's a bit of a guess, but seems like the most possible reason, so while having more code would help...
If you do enter that first code block
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
...
again before the first Promise returned by getUserMedia gets resolved, then you will have actually multiple different MediaStreams coming from your device.
The global variable mediaStream will only represent the last MediaStream got from getUserMedia, and all the previous ones while inaccessible from your code, will still lock your device.
Here is an MCVE
In other words, you need to refactor your code.
You need to keep better track of when a request to get the MediaStream has been made, so to make the less changes in your code, I can propose you to actually store the Promise that gets returned by getUserMedia [instead of / along with] storing the MediaStream.
This way, next calls will just have to then() this Promise, in order to access the same MediaStream.
// outer scope
var stream_request = null;
// [...]
function requestStream() {
if(!stream_request) {
stream_request = navigator.mediaDevices.getUserMedia(options);
}
return stream_request
.then(doSomethingWithTheMediaStream);
}
// and to kill it
function kill_stream() {
return stream_request.then(stream => {
stream.getTracks().forEach(t => t.stop());
}
}
live example
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracksidat getting and when you stop them. If they do differ, you have multiple streams from the same device.
– Kaiido
Nov 24 '18 at 5:38
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53431093%2fhow-to-close-mediastream-after-multiple-remote-peers-attached%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
That's a bit of a guess, but seems like the most possible reason, so while having more code would help...
If you do enter that first code block
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
...
again before the first Promise returned by getUserMedia gets resolved, then you will have actually multiple different MediaStreams coming from your device.
The global variable mediaStream will only represent the last MediaStream got from getUserMedia, and all the previous ones while inaccessible from your code, will still lock your device.
Here is an MCVE
In other words, you need to refactor your code.
You need to keep better track of when a request to get the MediaStream has been made, so to make the less changes in your code, I can propose you to actually store the Promise that gets returned by getUserMedia [instead of / along with] storing the MediaStream.
This way, next calls will just have to then() this Promise, in order to access the same MediaStream.
// outer scope
var stream_request = null;
// [...]
function requestStream() {
if(!stream_request) {
stream_request = navigator.mediaDevices.getUserMedia(options);
}
return stream_request
.then(doSomethingWithTheMediaStream);
}
// and to kill it
function kill_stream() {
return stream_request.then(stream => {
stream.getTracks().forEach(t => t.stop());
}
}
live example
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracksidat getting and when you stop them. If they do differ, you have multiple streams from the same device.
– Kaiido
Nov 24 '18 at 5:38
add a comment |
That's a bit of a guess, but seems like the most possible reason, so while having more code would help...
If you do enter that first code block
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
...
again before the first Promise returned by getUserMedia gets resolved, then you will have actually multiple different MediaStreams coming from your device.
The global variable mediaStream will only represent the last MediaStream got from getUserMedia, and all the previous ones while inaccessible from your code, will still lock your device.
Here is an MCVE
In other words, you need to refactor your code.
You need to keep better track of when a request to get the MediaStream has been made, so to make the less changes in your code, I can propose you to actually store the Promise that gets returned by getUserMedia [instead of / along with] storing the MediaStream.
This way, next calls will just have to then() this Promise, in order to access the same MediaStream.
// outer scope
var stream_request = null;
// [...]
function requestStream() {
if(!stream_request) {
stream_request = navigator.mediaDevices.getUserMedia(options);
}
return stream_request
.then(doSomethingWithTheMediaStream);
}
// and to kill it
function kill_stream() {
return stream_request.then(stream => {
stream.getTracks().forEach(t => t.stop());
}
}
live example
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracksidat getting and when you stop them. If they do differ, you have multiple streams from the same device.
– Kaiido
Nov 24 '18 at 5:38
add a comment |
That's a bit of a guess, but seems like the most possible reason, so while having more code would help...
If you do enter that first code block
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
...
again before the first Promise returned by getUserMedia gets resolved, then you will have actually multiple different MediaStreams coming from your device.
The global variable mediaStream will only represent the last MediaStream got from getUserMedia, and all the previous ones while inaccessible from your code, will still lock your device.
Here is an MCVE
In other words, you need to refactor your code.
You need to keep better track of when a request to get the MediaStream has been made, so to make the less changes in your code, I can propose you to actually store the Promise that gets returned by getUserMedia [instead of / along with] storing the MediaStream.
This way, next calls will just have to then() this Promise, in order to access the same MediaStream.
// outer scope
var stream_request = null;
// [...]
function requestStream() {
if(!stream_request) {
stream_request = navigator.mediaDevices.getUserMedia(options);
}
return stream_request
.then(doSomethingWithTheMediaStream);
}
// and to kill it
function kill_stream() {
return stream_request.then(stream => {
stream.getTracks().forEach(t => t.stop());
}
}
live example
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
That's a bit of a guess, but seems like the most possible reason, so while having more code would help...
If you do enter that first code block
if (mediaStream == undefined) {
navigator.mediaDevices.getUserMedia({
...
again before the first Promise returned by getUserMedia gets resolved, then you will have actually multiple different MediaStreams coming from your device.
The global variable mediaStream will only represent the last MediaStream got from getUserMedia, and all the previous ones while inaccessible from your code, will still lock your device.
Here is an MCVE
In other words, you need to refactor your code.
You need to keep better track of when a request to get the MediaStream has been made, so to make the less changes in your code, I can propose you to actually store the Promise that gets returned by getUserMedia [instead of / along with] storing the MediaStream.
This way, next calls will just have to then() this Promise, in order to access the same MediaStream.
// outer scope
var stream_request = null;
// [...]
function requestStream() {
if(!stream_request) {
stream_request = navigator.mediaDevices.getUserMedia(options);
}
return stream_request
.then(doSomethingWithTheMediaStream);
}
// and to kill it
function kill_stream() {
return stream_request.then(stream => {
stream.getTracks().forEach(t => t.stop());
}
}
live example
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
answered Nov 23 '18 at 4:41
KaiidoKaiido
43.2k464104
43.2k464104
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracksidat getting and when you stop them. If they do differ, you have multiple streams from the same device.
– Kaiido
Nov 24 '18 at 5:38
add a comment |
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracksidat getting and when you stop them. If they do differ, you have multiple streams from the same device.
– Kaiido
Nov 24 '18 at 5:38
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
I have tried setting the mediastream first and then adding it to the peerConnections. There is no way that more than one mediaStream is being created. It seems to be the act of adding the mediastream to multiple peers that is the problem that breaks the link between the mediastream reference and the media.
– Croftie
Nov 23 '18 at 18:45
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracks
id at getting and when you stop them. If they do differ, you have multiple streams from the same device.– Kaiido
Nov 24 '18 at 5:38
@Croftie as I said in my answer, to be 100% sure of what happens we would need more details about your setup, that you should add as an edit to your original question. But once again, this is the most plausible reason. Whatever you do with this MediaStream afterward should have no incidence on its tracks, and on how they do lock the device. As a debugging step, you can log the mediaStream tracks
id at getting and when you stop them. If they do differ, you have multiple streams from the same device.– Kaiido
Nov 24 '18 at 5:38
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53431093%2fhow-to-close-mediastream-after-multiple-remote-peers-attached%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
refactored the code and now embarrassingly It works. In the full code there were 2 places where the mediastream could be called depending on whether the client was the offeror or the offeree. One of them was calling a new media stream and that was the problem. Thanks to Kaiido for perseverance
– Croftie
Nov 25 '18 at 10:59