802397 - If I try to get access to my USB camera with a USB camera and built-in camera plugged in, I end up getting the built-in camera instead

Status: VERIFIED FIXED

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

Description

[Jason Smith [:jsmith]]

Steps:

1. Call gUM with video with an integrated camera and USB camera on your device
2. When the permission prompt appears, select the USB camera

Expected:

The USB camera should start streaming and be shown in the video tag using the media stream from gUM.

Actual:

The integrated camera starts streaming and is shown in the video tag using the media stream from gUM.

Comment 1

[Dão Gottwald [:dao]]

Sounds like bug 797796 isn't working as expected, unless the front-end is sending bogus data to the back-end.

Comment 2

[Jason Smith [:jsmith]]

Spoke with Anant about this today - this is more likely a core webrtc bug.

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

jsmith, can you retest with today's nightly or a fresh build?

Comment 4

[Jason Smith [:jsmith]]

(In reply to Randell Jesup [:jesup] from comment #3)
> jsmith, can you retest with today's nightly or a fresh build?

Yup, retested. I can still reproduce this bug.

Comment 5

[Justin Dolske [:Dolske]]

This is easy for me to reproduce on OSX, current nightly:

* Plug in USB camera to MacBook
* Load http://timtaubert.de/demos/green-screen/
* Give it permission for the USB cam

Instead of video from the USB cam, I get the built-in camera.

Comment 6

[Justin Dolske [:Dolske]]

Attachment: Uhh, what?

So, from some debugging I found that the frontend code was passing the wrong device to the MediaManager observer.

This patch adds logging and makes it work, but I don't understand what's going on... The logging prints:

Allow: FaceTime HD Camera (Built-in) for callID {de506c63-8a26-9e42-a914-0aeaefc1352e}
Allow: USB 2.0 PC Cam for callID {de506c63-8a26-9e42-a914-0aeaefc1352e}

So ddd != device, and indeed passing |ddd| to .notifyObservers fixes things.

But AFAIK there should be a closure over |device| here, so the code _should_ work as-is. Ergo, JS engine bug. Or am I missing something?

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

I see the same thing; it *appears* as if device remains a reference to an outer context.  Odd.

BTW, I see this on Linux and windows as well; I doubt it's OS-related.

We should probably do a minimal testcase to verify.

Comment 8

[Justin Dolske [:Dolske]]

The fine folks in #jsapi say this is bug 449811.

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

// standalone testcase that's now irrelevant deleted....

Sheesh.  4-year old bug, with a 9-month-old r+'d patch....
Let's land ttaubert's fix (minus dumps) with a comment that it's that bug, and point them in that bug to fix the js code when they land that engine fix.

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Work around JS engine bug 449811 to select correct mic/camera

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/mozilla-central/rev/58c8080a1a7c

Comment 12

[Jason Smith [:jsmith]]

Verified on 10/26 build.

Comment 13

[Jason Smith [:jsmith]]

If we could fake the devices, we might be able to automate this. Although as it stands in the current framework, we don't have this ability. Putting in-testsuite- for now, although if device faking becomes possible at some point, then we should re-evaluate this one for a test.