Closed Bug 956614 Opened 7 years ago Closed 7 years ago

Missing (transparent) frames with video tag


(Core :: Audio/Video, defect)

Not set



Tracking Status
firefox28 --- unaffected
firefox29 --- affected


(Reporter: ekr, Unassigned)



(Keywords: regression)


(2 files)

Attached image Example
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
Parents: 160347, 160358
Author: Ryan VanderMeulen <>
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 <>
Date: December 11, 2013 at 5:50:57 PM PST


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:

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)
Severity: normal → major
Depends on: PTexture
Keywords: regression
(In reply to Milan Sreckovic [:milan] from comment #9)
> What's the STR?

Let me expand - is there anything beyond going to 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?
Flags: needinfo?(martin.thomson)
I tested this on my version of nightly, several times.  No flicker any more.
Flags: needinfo?(martin.thomson)
EKR, is this fixed for you? If so we can close it WORKSFORME.
Flags: needinfo?(ekr)
Yes, though I wish I knew what fixed it.
Flags: needinfo?(ekr)
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.