Mac OS X 10.14.6 on a MacBook (Retina, 12-inch, 2017, 1.4 GHz Intel Core i7, 16 GB 1867 MHz LPDDR3, Intel HD Graphics 615 1536 MB)

Firefoxes tried:

• Nightly: 72.0a1 (2019-10-31) (64-bit)
• Release: 70.0.1 (64-bit)

Works in Chrome Canary and release. Tested on Android in Firefox Nightly and Firefox Preview Nightly, works fine. Others reported testcase working fine across various Windows and Linux versions/distros.

Testcase:

<video id="video" autoplay loop muted></video>

<script>

document.addEventListener('DOMContentLoaded', () => {
  let videoElement = document.querySelector('#video');

  navigator.mediaDevices.getUserMedia({video: true}).then(function(stream) {

    videoElement.srcObject = stream;

    // never fires on Firefox desktop on Mac OS X 10.14.6
    videoElement.onloadedmetadata = function(e) {
      alert('onloadedmetadata');
      videoElement.play();
    };
    
    // used to work fine on Firefox, without waiting for onloadedmetadata
    // still works on Chrome in that scenario
    videoElement.play();

  }, function(err) {
    console.error(err);
  });
})

</script>

Thanks for filing! I assume you're using the internal camera? Does it fail with https://jsfiddle.net/jib1/r60bzmrs/ ? With what error? Have you tried rebooting?

Also, please double-check in System Preferences / Security & Privacy / Privacy / Camera that Firefox is ☑

Actually, you said on twitter the red light came on. Getting logs on this would help us out.

To enable logs, set

export MOZ_LOG_MODULES=timestamp,MediaStreamGraph:5,MediaStream:5,MediaManager:5,GetUserMedia:5
export MOZ_LOG_FILE=/tmp/ff.log

before you start Firefox from the command line. Will look tomorrow for someone still on 10.14 to repro.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #1)

Thanks for filing! I assume you're using the internal camera? Does it fail with https://jsfiddle.net/jib1/r60bzmrs/ ? With what error?

Same - blank white screen, no errors in console (or browser console), camera hardware green light is on, and red camera icon in location bar is throbbing.

Have you tried rebooting?

Not yet, because that might "fix" it... will get log first.

Also, please double-check in System Preferences / Security & Privacy / Privacy / Camera that Firefox is ☑

It is. I don't think we'd get to green hardware light stage if that wasn't checked.

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #2)

Actually, you said on twitter the red light came on. Getting logs on this would help us out.

Yeh, sorry:

• green hardware light is on
• red throbbing camera icon in location bar is lit

By all accounts, this should be working - the same code has worked for years. I noticed this regression some time ago (weeks?) and just hadn't followed up.

Will look tomorrow for someone still on 10.14 to repro.

Someone on Twitter in the thread said 10.14.4 worked for them. I asked in #nightly for others repro and nobody had a Mac.

Log attached.

I just tried it on Nightly 72.0a1 (2019-11-01) (64-bit) w/ MacBookPro (15-inch, 2018) running 10.14.6 and I see a working video preview. I also tried it in 70 and worked for me. Just a couple more data points. If you need logging to compare, let me know.

Dietrich, thanks and apologies I gave you the wrong string for Nightly, where "MediaStreamGraph" has been completely refactored and renamed "MediaTrackGraph"! - I forgot this affected the log monikers as well 😕 If you wouldn't mind re-running instead with:

MOZ_LOG_MODULES=timestamp,sync,MediaTrackGraph:5,MediaStream:5,MediaManager:5,GetUserMedia:5

...I'd appreciate it! Note that the logs will grow rapidly now, so closing the tab immediately after you've verified the video isn't coming, should reduce the upload size.

After that, I'd look at determining the scope of this problem. On older MBPs I've sometimes seen the camera driver get stuck, and had to reset it either by typing:

sudo killall VDCAssistant

or rebooting the machine. If that doesn't fix it, we need to escalate this bug and look for someone else with your exact hardware.

Updated log w/ new modules

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #7)

Dietrich, thanks and apologies I gave you the wrong string for Nightly, where "MediaStreamGraph" has been completely refactored and renamed "MediaTrackGraph"! - I forgot this affected the log monikers as well 😕 If you wouldn't mind re-running instead with:

MOZ_LOG_MODULES=timestamp,sync,MediaTrackGraph:5,MediaStream:5,MediaManager:5,GetUserMedia:5

attached

sudo killall VDCAssistant

"No matching processes were found"

Will reboot and see if still occurs.

Reboot did not fix. Good news, I think - means we have more opportunity to reproduce ;)

ni? jib for log analysis, guessing P3 for priority.

Let's go deeper on this.

Please follow this STR, preferably in a debug build, because then we get per-frame logs:
1 Start Firefox with MOZ_LOG=MediaManager:5,CamerasParent:5,VideoEngine:5,webrtc_trace:5
2 Go to about:webrtc
3 Click "Start Debug Mode"
4 Go to https://mozilla.github.io/webrtc-landing/gum_test.html
5 Click "Video"
6 Select the internal camera and approve
7 Quit

And upload the logs here.

I'm guessing we're not receiving any frames from the backend and this hopefully verifies that and highlights why.

Not sure P3 is right until we know how wide-spread this is.

I'm able to reproduce this on a MacBook (Retina, 12-inch, Early 2016) with 10.13.3.

[Tracking Requested - why for this release]: Camera does not appear to work on non-pro Macbooks since Firefox 64.

Regression range:

26:37.04 INFO: Last good revision: faf1cfd83dd5a3359edfd6d7e66a7123a84bb031
26:37.04 INFO: First bad revision: e83c311e5293902be4db4ecea17cff87c633f7cf
26:37.04 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=faf1cfd83dd5a3359edfd6d7e66a7123a84bb031&tochange=e83c311e5293902be4db4ecea17cff87c633f7cf

The branch 64 update resulted in switching to a newer implementation of the OS X video capture code (see comments in Bug 1515461, Bug 1439997). As far as I can tell, the only local changes to the upstream os x video capture code landed as part of the branch 64 update were to add pid_t as an argument to GetDeviceName in device_info.h and device_info.mm, so if this turns out to be a problem with the webrtc.org code, it seems likely this is a bug in upstream. That newer implementation has since been deprecated and removed upstream (see Bug 1451394). If we're lucky, this was fixed in between the branch 64 update and that code being deprecated. I'll have a look for any commits that seem promising.

[Parent 96962: IPDL Background]: D/CamerasParent Capability: 640 480 30 14 0

The 14 there maps to videoType kNV12, FWIW.

On specific Macbooks (no exact pattern, unfortunately),
video from an integrated camera is not captured.
Changed AVCaptureVideoDataOutput pixel format configuration
as in Chromium which solved the problem.
https://chromium.googlesource.com/chromium/src/media/+/master/capture/video/mac/video_capture_device_avfoundation_mac.mm
FourCharCode best_fourcc = kCVPixelFormatType_422YpCbCr8;

Tested with external cameras as well.

Bug: webrtc:8958

Verified fixed (on system from comment 14) with this patch (from upstream).

Dietrich, please check with this build or wait for Nightly (+1 day after patch lands) if you prefer, to verify this has been fixed.

It's unclear how many Macbooks are affected. Upstream patch says "specific Macbooks (no exact pattern, unfortunately),".

👍🏼 demo at https://economic-enquiry.glitch.me WFM with the test build, and onloadedmetadata fires correctly.

Thanks y'all for listening to the report and digging in to find the solution!

https://hg.mozilla.org/mozilla-central/rev/91b3fc6f5fa0

Since this isn't a recent regression (since Firefox 65), I'd like to let the fix ride with 72 or 71 rather than rush it to release 70.

Not a recent regression and not noticed until a few days ago, unless the fix is very isolated and can not cause any risk of regressions for other webcams (all OSes), I think it should ship in 72.

I'll go ahead and remove qe-verify+ from this issue since we are way past the milestone of this bug. For what is worth we did not encounter this issue on latest builds Fx 75.0 on two MacBooks with 10.15, 10.14 and 10.13.