AbortError ("Starting video failed") when calling getUserMedia second time
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
People
(Reporter: armen.michaeli, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
- Call
navigator.mediaDevices.getUserMedia({ video: true, audio: true}) - Call
stream.getTracks().forEach(track => track.stop())withstreambeing the MediaStream object promised by thegetUserMediacall above. - Repeat the
getUserMediacall as per step 1
Actual results:
Calling navigator.mediaDevices.getUserMedia({ video: true, audio: true}) a second time (step 3) [in the same browsing context (application)], with or without stopping the previously obtained stream's tracks with stream.getTracks().forEach(track => track.stop()) (step 2), even waiting a considerable amount of time (seconds) after the latter, results in an AbortError with the message "Starting video failed".
After refreshing the page, calls to getUserMedia as per step 1 do not cause any errors but the displayed stream is "faulty" -- although a video and an audio track are evidently present and are "live", when rendered in a video element, there is neither image nor sound.
Situation persists until the entire browser process is restarted -- closing the tab and retrying in another browsing context has no redeeming effect.
Expected results:
Expected to see video rendering the camera image and microphone feedback sound as obtained through the getUserMedia call, capturing from my default devices.
Comment 1•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•5 years ago
|
||
Thank you for the bug report! I'm not able to reproduce this on either Windows or Linux, but I might not be following your steps correctly. Could you please put together a small test file that reproduces the problem and attach it to this bug? It would also be useful to know what kind of camera you are using in case there is something hardware specific going on here. Thank you!
Comment 3•5 years ago
|
||
Unfortunately, without more information this bug is not actionable.
Description
•