STR: 1) Visit http://people.mozilla.com/~anarayanan/webrtc/pc_test.html 2) Click Start, let the camera be accessed 3) Click Stop 4) Close the tab 5) Start Skype 6) Visit Skype's preferences and select Audio/Video Actual Results: => Camera cannot be accessed unless I close Firefox Expected Results: => Firefox has completely stopped using the camera and should have released the camera back to the OS.

Just tried this test. Had no problem accessing the camera from Skype.

I just retried this with my Macbook Pro running OS X 10.8 with no external cameras/microphones attached, and I was able to reproduce still in the 2012-12-23 nightly build.

tentatively making system-specific since it WFM on Windows

I've just tried this too on OS X 10.8. I can reproduce with the steps given in comment 0. Interestingly, this bug seems to only block Skype. Vidyo can access the camera. I was surprised to see that if I close a webrtc call, then start a vidyo call and close the vidyo call, Skype can access the camera. So closing a vidyo call seems to release whatever wasn't released after closing a webrtc call.

Verified problem exists with Skype on Mac (with all my latest to-be-landed patches) I also found that the problem does *not* affect the other video apps on Mac I tried (Facetime and Photobooth); so far it appears to be just Skype (though perhaps some other video apps might have this problem). Could even be a bug in Skype. Blocking still because we want to fix this for release, but I would not block preffing the feature on by default in m-c.

We need a serious mac person to help with this. I'm not sure where to start with figuring out what it is Skype is upset about. Anyone have a suggestion as to who could help? CC-ing a bunch of people to try to find a good suggestion. An interesting test would be to do the same with Chrome Canary...

Tested - Chrome Canary has the exact same problem, which perhaps isn't that surprising. Making blocking-. I'll file an issue at webrtc.org upstream. It still would be nice to find someone who knows enough about this layer of the mac to track it down.

(In reply to Randell Jesup [:jesup] from comment #7) > Tested - Chrome Canary has the exact same problem, which perhaps isn't that > surprising. Making blocking-. I'll file an issue at webrtc.org upstream. > > It still would be nice to find someone who knows enough about this layer of > the mac to track it down. Robert - Do you know anyone from your team who could help us track down this mac-specific issue with getUserMedia and Skype?

Upstream issue at webrtc.org 1351

Steven might be able to help us when it comes to OS X specific code and APIs.

I don't know anything off the top of my head that could help here (including anything about how OS X accesses the camera). So I'd have to start from scratch with this bug. I'm very good at debugging problems on OS X -- particularly ones that (potentially) involve reverse-engineering (of the OS or other apps). But that takes time, and currently all my time is eaten up by more urgent bugs. Suggestions: Look up this problem in the Chrome bug base to see if they're working on it. Also build Chromium to see if the problem happens there (the Chrome and Chromium code bases are very close, but not identical).

Comment on attachment 714692 [details] [diff] [review] imported patch from webrtc issue 1351 This works!

Timothy, could you please have a look at the patch? It's waiting nearly a month to be reviewed by your person. It's kinda blocking me from dogfooding Webrtc on Skype. Thanks.

Comment on attachment 714692 [details] [diff] [review] imported patch from webrtc issue 1351 Review of attachment 714692 [details] [diff] [review]: ----------------------------------------------------------------- r- for bitrot, but it should be pretty simple to fix. ::: media/webrtc/trunk/webrtc/modules/video_capture/mac/qtkit/video_capture_qtkit_objc.h @@ -60,5 @@ > NSString* _captureQuality; > - > - // other > - NSAutoreleasePool* _pool; > - This appears to have been obsoleted by bug 837539. ::: media/webrtc/trunk/webrtc/modules/video_capture/mac/qtkit/video_capture_qtkit_objc.mm @@ +46,5 @@ > /// ***** Objective-C. Similar to C++ destructor > /// ***** Returns nothing > - (void)dealloc { > if(_captureSession) > + [_captureSession stopRunning]; This probably needs a fix similar to that in bug 837539 (dispatching stopRunning to the QTKit main thread). That bug added an async dispatch, but since you release the object below, I you either need a sync one here, or you need to proxy the release. @@ +56,3 @@ > { > + if([[_captureVideoDeviceInput device] isOpen]) > + [[_captureVideoDeviceInput device] close]; _captureVideoDeviceInput can also be released in setCaptureDeviceById(). You probably need this same logic there, as well. You may also need to remove it from the session, e.g., [_captureSession removeInput:_captureVideoDeviceInput].

I consistently run into this bug in Firefox 22. I have 100+ tabs open so I don't know what the offending one is currently. Only quitting Firefox will release the camera to Skype (after a restart). OS X 10.8.4

Fixed in the 3.30 landing

So this is fixed in Nightly?

yes, it should be - please give it a try

Works great with Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 ID:20130812004004 CSet: 4d652113720b Randell, I assume it's too late for a fix for Firefox 24?