The attached image shows a WebRTC call with webrtc-landing pc.html. The lower-left square is supposed to be a composition of the remote video (the big picture of me) and the local video (the PIP in the upper-left-hand corner). The PIP should be a solid square about the color of the big square in the upper-right-hand corner, which shows the remote video on the other end of the WebRTC call (it's offset by about 100ms). And it generally is, but on recent calls (with trunk) I see a momentary flash of a single frame or so that is instead transparent and shows what you see here. Note that the PIP is *not* coming from WebRTC. It's just gUM plumbed into a video tag. We do see this also on the remote video, but this was easier to capture. One more note: On a recent WebRTC call with cpearce I saw my own PIP replicated onto his face, so you just saw me in both the main screen and PIP. Again, it was a brief flash. This sorta points to MSG. I can provide a copy of that if needed.

I was able to reproduce the problem with a local build from today on my MacBook Pro.

Not reproducible on FF27 Not reproducible on FF28.0a2 (2014-01-14) Reproducible on FF29.0a1 (2014-01-14)

From what I have seen in manual testing the problem can occur in any of the four video renderer. Unfortunately I failed so far to find a way to trigger the problem. So far only a couple of "calls" of a few minutes length help to verify if the problem exists.

The bug got introduce to mozilla-central with this commit: Revision: 160359 Changeset:8b2552ae775c1406a003af5b507517959293061e[8b2552ae775c] Parents: 160347, 160358 Author: Ryan VanderMeulen <ryanvm@gmail.com> Date: December 13, 2013 at 12:39:51 PM PST Merge fx-team to m-c.

Please dis-regard my comment #5. Falls alarm.

Now I'm pretty sure I have found the commit to m-c which is causing the problem: Revision: 160034 Changeset: 46586f01b86da44c671331527fe7d4fb1314d2e0 [46586f01b86d] Parents: 160033, 160032 Author: John Daggett <jdaggett@mozilla.com> Date: December 11, 2013 at 5:50:57 PM PST merge Unfortunately this is one big merge back with 23 changes all in the gfx sub-directory. I have not identified which on these 23 changes is causing the problem.

Normally I'd suggest bisecting on inbound, not m-c, to narrow the range. You at least now know the end-points for the bisect; likely it's only a 5 or 6 builds max (but considering that most of the commits in that range are a 17 part patch.... Probably it can't be broken apart, though, so further bisect likely is useless.) Note that I see something that doesn't match what you have above for that changeset: https://hg.mozilla.org/mozilla-central/pushloghtml?changeset=46586f01b86d hg log however seems to match your info above, and better match the symptoms. Odd. This looks the likely cause: 17-part patch for bug 897452 to the compositor. The other patches in the merge seem from the comments to be likely not involved. CC-ing the people involved in bug 897452 (code or review)

What's the STR?

(In reply to Milan Sreckovic [:milan] from comment #9) > What's the STR? Let me expand - is there anything beyond going to http://mozilla.github.io/webrtc-landing/pc_test.html and pressing start?

Exactly you go the URL, press "start", allow your camera and mic to be shared. Then you have to wait. Usually it happens within a minute in one of the four video renderers (a short blink - which if you look at it frame by frame is the transparent picture mentioned above). Unfortunately I have not found a trigger to reproduce it within that webrtc call. So if it does not happen within the first minute I click "stop", reload the page and try again.

I'm getting this issue pretty badly when running nightly on my big 27" monitor (two instances talking to each other). On a good day, my MacBook Pro 13" struggles to render anything at a reasonable speed (even a mouse pointer), so I'm not surprised to see this happening more clearly. Again, it does stabilize after a short while.

I was able to close down the window of commits causing the problem to m-c between 160014:969cfcbb1c9c and 160023:a283c87bafd1. I'm not able to compile any of the revisions in between. I'm not able to back-out these 9 commits, so that would leave us with manually removing the code of these 9 commits from current m-c to find out which exact commit caused this. But I'm not longer to reproduce the problem with m-c 165403:9ab72e2ec5e4. Although I can still reproduce the problem for example with 160030:fd0594ff74ce. Martin, can you check if you are still able to reproduce with latest m-c?

I tested this on my version of nightly, several times. No flicker any more.

EKR, is this fixed for you? If so we can close it WORKSFORME.

Yes, though I wish I knew what fixed it.

Indeed...