Closed Bug 1338124 Opened 7 years ago Closed 7 years ago

Unable to get video stream in two different browsers on Windows

Categories

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

51 Branch
x86_64
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: karl, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

Steps to reproduce:

1) open https://mozilla.github.io/webrtc-landing/gum_test.html in Chrome
2) click Video, accept permissions
3) video feed appears
4) open https://mozilla.github.io/webrtc-landing/gum_test.html in Firefox
5) click Video, accept permissions
6) an error is displayed "NotReadableError: Failed to allocate videosource"

Note that I'm running this on Windows 10 (64-bit) inside Virtualbox on a Mac. The webcam access was provided by "VBoxManage controlvm "windows-10" webcam attach .1" which attaches the default Macbook webcam to the Windows virtual machine. Having said that, one of our customers is also reporting the same behaviour on both a Dell laptop and a Lenovo one, both running Windows 10 Pro. Our front-end error tracking reported the same error when they tried to record a video ("NotReadableError: Failed to allocate videosource").

Also note, the same thing happens when you first open Firefox and then Chrome, although Chrome does not report any errors, just fails silently.

Thirdly, that this does not seem to happen in any capacity on a Mac.


Actual results:

Video feed appeared in Chrome when the Video button is clicked, but not in Firefox when the same button is clicked there. Firefox reports an error "NotReadableError: Failed to allocate videosource" upon clicking the button.


Expected results:

Video feed should have appeared in both Chrome and Firefox upon clicking Video button in both browsers.
Component: Untriaged → WebRTC: Audio/Video
OS: Unspecified → Windows 10
Product: Firefox → Core
This depends on OS platform APIs on the respective platforms. On Mac OS this has traditionally worked, but with our update to use the AVFoundation backend rather than the deprecated Qtkit one, I have seen the same behavior also there.

If it works to have the same camera open in two other applications at the same time, say Chrome and Skype, we could keep this bug around. Otherwise I'm inclined to close it as WONTFIX. karl, could you test for this?
Flags: needinfo?(karl)
(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #1)
> karl, could you test for this?

Yes, will test ASAP and report back.

I'm not familiar with AVFoundation -- is there a fundamental reason why two browsers seemingly cannot use the camera at the same time?
See bug 1297029 and its linked bugs for the issue on OSX.

Optimization reasons I guess. If two processes request captures with different settings you'd have to configure the device with settings that are compliant for both of them and do the rest in software.
Just to clarify, the issue outlined in my original bug report does not appear when I'm using OSX. If I perform the relevant steps on OSX, everything works fine. But on Windows, whichever browser tries to capture an already open video feed fails.
Hardware: Unspecified → x86_64
Andreas,

I've tested with Skype and Firefox on Windows 10. It seems that if either application is already using the camera, the other cannot get access.

I don't know how to attach images to the comment, but here are some screenshots.
On Windows:
Get camera access in Firefox, then in Skype - http://d.pr/i/80UG.
Get camera access in Skype, then in Firefox - http://d.pr/i/THdr

On Mac:
Get camera access in either application, then in the other, works both ways - http://d.pr/i/NKZP

Does this mean that there isn't anything inherently wrong with Firefox or Chrome or Skype, but with Windows/its drivers and how it manages access to shared resources?
(In reply to karl from comment #5)
> Does this mean that there isn't anything inherently wrong with Firefox or
> Chrome or Skype, but with Windows/its drivers and how it manages access to
> shared resources?

I'm sure they have reasons for it (as opposed to it being "inherently wrong"), but yes, that's my understanding.
Yes, sorry -- "inherently wrong" was supposed to mean a bug. :-)

Hm.. In that case, I'm not sure what else there is to do. I think with Firefox we can catch the NotReadableError exception and notify the user. However, Chrome does not seem to raise any exceptions and will happily even record a video which will not contain the video stream, only audio.
Yeah, that's a bug on Chrome's part. I believe there's one on file in their tracker too.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Flags: needinfo?(karl)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: