Stopping tracks in one WebRTC stream also stops tracks in other streams
Reported by
skadb...@cyviz.com,
Nov 24 2017
|
|||||||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Steps to reproduce the problem:
1. Start a WebRTC stream (using chrome.desktopCapture.chooseDesktopMedia).
2. Start a second WebRTC stream using the same source, resulting in the same label `stream1.getTracks()[].label == stream2.getTracks()[].label`.
3. Run `stream2.getTracks().forEach(function(track){track.stop();})` on the second stream
What is the expected behavior?
All other streams persists when stopping the one of the stream, even when they have the same track label.
What went wrong?
Running `track.stop()` as explained in step 3 also results in killing the first stream tracks, observable with `stream1.getTracks()[].enabled == false`.
Did this work before? N/A
Does this work in other browsers? N/A
Chrome version: 62.0.3202.89 or earlier Channel: stable
OS Version: 10.0
Flash Version: N/A
Ending the first stream before the second stream results in the expected behavior. Ending any stream using the "Stop sharing" button from the multiple screen sharing dialogs also results in expected behavior.
,
Nov 27 2017
skadberg@ - Thanks for filing the issue...!! Could you please provide a sample test file to test the issue from TE-end. This will help us in triaging the issue further. Thanks...!!
,
Nov 27 2017
The attached example should illustrate the issue, but won't run without modifications, since the required extension is not included. I also tested using a regular web camera (webkitGetUserMedia), which resulted in expected good behavior.
,
Nov 27 2017
Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 21 2017
,
Jan 18 2018
Ping for triaging.
,
Jan 18 2018
I'll take a look soon.
,
Jan 19 2018
,
Jan 25 2018
guidou@, this is not a desktop_capture specific issue, but a general MediaStreamManager problem. Please have a look and triage appropriately. Here are some findings: When app requests gUM twice with same device id, 2 streams, with each MediaStreamVideoSource, will be created accordingly. But there is only one MediaStreamManager instance, which maintains a request list which contain the device list. When the stream 2 is to be stopped, MediaStreamVideoSource::RemoveTrack is called to the right MediaStreamVideoSource instance. And later it will call to MediaStreamManager::StopStreamDevice, https://cs.chromium.org/chromium/src/content/browser/renderer_host/media/media_stream_manager.cc?l=662. Here because the two streams share same render_process_id/render_frame_id/device_id, MediaStreamManager can't figure out which device to be stopped. So it will stop the first matched device in its devices list, which corresponding to stream 1. Then the device of stream 1 will stop capture and this will trigger its running state change, which will go to MediaStreamVideoCapturerSource::OnRunStateChanged eventually, https://cs.chromium.org/chromium/src/content/renderer/media/media_stream_video_capturer_source.cc?l=279. Here it will try to StopSource again. This time in MediaStreamManager::StopStreamDevice, it can only find the device of stream 2. So as a consequence, device of stream 2 will be stopped too. The end. I guess MediaStreamManage should also maintain the relationship of each track and corresponding capture-session.
,
Jan 25 2018
,
Feb 1 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/24acfac5aa663111412b1c845789390f8d43399e commit 24acfac5aa663111412b1c845789390f8d43399e Author: Guido Urdaneta <guidou@chromium.org> Date: Thu Feb 01 22:12:28 2018 Use session_id to find devices to stop in MediaStreamManager In screen capture it is possible to have multiple sessions associated to the same device in the same renderer process. Prior to this CL, MSM::StopStreamDevice() received only the device ID, which sometimes resulted in the wrong screen-capture tracks being stopped on the renderer side. This CL adds the session ID to the StopStreamDevice() so that only the correct track is stopped. Bug: 788400 Change-Id: If759af86fa9819e4c3574b2bc840ad45c3c924b7 Reviewed-on: https://chromium-review.googlesource.com/892859 Reviewed-by: Henrik Boström <hbos@chromium.org> Reviewed-by: Tom Sepez <tsepez@chromium.org> Commit-Queue: Guido Urdaneta <guidou@chromium.org> Cr-Commit-Position: refs/heads/master@{#533828} [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/browser/renderer_host/media/media_stream_dispatcher_host.cc [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/browser/renderer_host/media/media_stream_dispatcher_host.h [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/browser/renderer_host/media/media_stream_dispatcher_host_unittest.cc [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/browser/renderer_host/media/media_stream_manager.cc [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/browser/renderer_host/media/media_stream_manager.h [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/common/media/media_stream.mojom [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/renderer/media/mock_mojo_media_stream_dispatcher_host.cc [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/renderer/media/mock_mojo_media_stream_dispatcher_host.h [modify] https://crrev.com/24acfac5aa663111412b1c845789390f8d43399e/content/renderer/media/user_media_processor.cc
,
Mar 19 2018
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by guidou@chromium.org
, Nov 24 2017