Firefox and OS X cannot share Camera access with Chrome, Photo Booth or another Firefox Tab




2 years ago
2 years ago


(Reporter: james, Unassigned)



50 Branch

Firefox Tracking Flags

(firefox50 wontfix, firefox51 wontfix, firefox52 fix-optional, firefox53 fix-optional)




2 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36

Steps to reproduce:

We are using our platform for Firefox webrtc video communication. However, we are seeing Firefox or OS X camera stopped acquiring when having another Chrome, Firefox or Photo Booth Session. We think the first Firefox camera permission got revoked when a new session acquired the camera.

Steps to reproduce:
1. Launch Firefox Hello or a similar webrtc video chat room In Firefox that acquires camera.
2. Launch another Chrome/Firefox or launch Photo Booth to get a new camera permission acquired.

Actual results:

We are seeing the first Camera stopped working in Firefox right after the second camera got access. It is frozen.

Expected results:

Both Firefox session and the new acquired session should work.


2 years ago
Component: Untriaged → WebRTC
Product: Firefox → Core
I remember this working on OSX before, and can confirm that it is broken now.

Acquiring the camera in Firefox first (I used and then another process (Chrome on, FaceTime) is ok. Acquiring in Firefox when another app is already using it results in a ghost (acquire ok, but no frames).

Sharing the camera between processes on Windows and Linux has never worked though, IIRC. So I'm not sure of the priority here. I'll make it a P2 for now, maybe jib or Munro would like to revise this.
Rank: 25
Component: WebRTC → WebRTC: Audio/Video
Ever confirmed: true
Keywords: regression
Priority: -- → P2
See Also: → bug 1322188
This issue should be different from bug 1322188 but duplicated to bug 1297029 and bug 1323775.
I can reproduce the problem in chrome with below page

When the issue occurs, we keep receiving the didDropSampleBuffer callback from avfoundation.

I try to find out the frame drop reason as the spec ( describes,unfortunately all kCMSampleBufferAttachmentKey_* are not defined in Mac. So it is still a mist why avfoundation drop the frame in this case.
(In reply to Munro Mengjue Chiang [:mchiang] from comment #2)
> unfortunately all
> kCMSampleBufferAttachmentKey_* are not defined in Mac. So it is still a mist
> why avfoundation drop the frame in this case.
Not all of kCMSampleBufferAttachmentKey_*, but the one kCMSampleBufferAttachmentKey_DroppedFrameReason we need is not defined on mac.
Do we have any idea what caused this regression?
status-firefox50: --- → wontfix
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
This is a regression caused by avfoundation framework, which replaces the deprecated framework QTkit.
Qtkit has been deprecated in OS X v10.9 and removed in OS X v10.12 (Sierra).

avfoundation always configures the camera hardware per the latest camera request.

If the previous camera constraint conflicts with the current setting, it will try to post process the frames to fulfill the constraint. For example, avfoundation support down-scale. However, it doesn't support up-scale.

If the previous camera request frame size, e.g., set gUM constraint video to 1280x720, is larger than the latest request, e.g., Photo booth uses 640x360, avfoundation cannot up-scale the frame to 1280x720. So it will choose to drop.

I did some experiments by removing the snippet we configure the width & height.

Then the issue is gone, the tradeoff is constraint doesn't work because we stop setting it.

I believe all Mac application which uses avfoundation should have the same problem.
If there is no concern, I will set the status to WONTFIX.
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1297029
No plan to have dot release for 51. Mark 51 won't fix.
status-firefox51: affected → wontfix
Not sure if this is resolved but marking fix-optional to get this out of triage. We can track it in the duplicate.
status-firefox52: affected → fix-optional
status-firefox53: affected → fix-optional
You need to log in before you can comment on or make changes to this bug.