Closed Bug 1663913 Opened 5 years ago Closed 5 years ago

AbortError ("Starting video failed") when calling getUserMedia second time

Categories

(Core :: WebRTC: Audio/Video, defect)

79 Branch
defect

Tracking

()

RESOLVED INCOMPLETE

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:

  1. Call navigator.mediaDevices.getUserMedia({ video: true, audio: true})
  2. Call stream.getTracks().forEach(track => track.stop()) with stream being the MediaStream object promised by the getUserMedia call above.
  3. Repeat the getUserMedia call 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.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

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!

Flags: needinfo?(armen.michaeli)

Unfortunately, without more information this bug is not actionable.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(armen.michaeli)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.