I'm seeing repeated freezes of both local and remote video on WebRTC calls with apprtc with current m-i and my patch from https://bugzilla.mozilla.org/show_bug.cgi?id=904598 Things look good in the local view and then when you make a call, you sometimes get no remote video or frozen remote video. The distinguishing factor here is that the *local* video is also frozen. I've done a bit of diagnosis and I don't see any direct evidence that this is networking related, but it might be and I just missed it. However, you wouldn't ordinarily expect the local video to be frozen. Other notes: 1. turning on MSG debugging seems to make the situation 2. tokbox seems OK.

"1. turning on MSG debugging seems to make the situation" ... better

This seems to be reliably reproducible using the current tip of m-i by performing a self-call on https://apprtc.webrtc.org/ I did see one strange run where the local view was frozen, while the media was being sent just fine. In other words, in a self-call (two browsers), I had three images moving just fine, and one frozen. The frozen image was the inlaid self-view.

My guess is that this is a gfx/layers issue.

To clarify comment 2: I'm running two different processes to repro the issue, not multiple tabs/windows within the same process.

I've seen it in two tabs on the same browser as well as separate machines.

I didn't see it in two tabs on MacOs 10.7 with nightly. I did see it 3/4 times roughly with two separate processes. Interestingly, I do NOT see it using nightly-gupshup on two processes (10 attempts). And it didn't ahppen for me on Linux

More info: Trying several times with two Aurora processes (8/15 build) I could not make it happen. So this would point at a regression between Aurora/25 and Nightly/26 (which I retested and still fails 50+% of the time). Less likely (given the regression range) would be some timing change affecting how the Mac video drivers interact and interact with the two browser Mainthreads. (previously discussed on IRC): Combined with the fact that this doesn't happen on several non-apprtc sites (herokuapp, webrtcme, etc) implies it might be related to media element manipulation done by apprtc that the others don't do.

WFM Nightly 8/6

WFM 8/9 Fail 8/11

Fail 8/10, so checkins between e33c2011643e and c5946a8bcd5b

retest of 8/9 fails, extending down. Good to double-check!

ok, a bunch more tests, and the regression range is 8/6 to 8/7 (9 tests without fail on 8/6) a0dd80f800e2:79b5c74ef97b There are a bunch of MediaStream/MediaStreamGraph changes in this range

ok, bisection appears to finger 95ffea3d6908: Bug 879717. Delay entering HAVE_CURRENT_DATA state until a video frame has been stored in the image container. I'm trying a backout of the patch on inbound, but inbound won't build currently on Mac or Linux. It's possible but unlikely that it's a patch near this one; the "good" patch right before it worked 12 times in a row, the bad one failed the first time (though sometimes it would take 5-6 times for a "bad" one to fail. Roc: can you think of how this would affect things? Right now this appears to be a media element (or graph) issue, not a webrtc issue (from the bisect and from it working on sites that don't do fancy things with media element positioning).

I just built this locally with the following results - 4 clean runs w/ this patch - first run w/o patch froze It's super-laggy, but I suspect that's just that it's really hard the CPU of my little Air

Try: https://tbpl.mozilla.org/?tree=Try&rev=d84c6c6e1dc2 Tried it 10 times (opt) with 100% success (with the backout patch). Sounds like we have a winner... Over to you roc

backout of bug 879717 pushed per roc: https://hg.mozilla.org/integration/mozilla-inbound/rev/bbf749ee2af7

(In reply to Randell Jesup [:jesup] from comment #16) > backout of bug 879717 pushed per roc: > https://hg.mozilla.org/integration/mozilla-inbound/rev/bbf749ee2af7 https://hg.mozilla.org/mozilla-central/rev/bbf749ee2af7