956614 - Missing (transparent) frames with video tag

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Eric Rescorla (:ekr)]

Attachment: 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.

Comment 1

[Nils Ohlmeier [:drno]]

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

Comment 2

[Nils Ohlmeier [:drno]]

Attachment: Empty PIP on nightly on my MacBook Pro

Comment 3

[Nils Ohlmeier [:drno]]

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

Comment 4

[Nils Ohlmeier [:drno]]

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.

Comment 5

[Nils Ohlmeier [:drno]]

The bug got introduce to mozilla-central with this commit:

Revision: 160359
Changeset:8b2552ae775c1406a003af5b507517959293061e[8b2552ae775c]
Parents: 160347, 160358
Author: Ryan VanderMeulen <[e-mail]>
Date: December 13, 2013 at 12:39:51 PM PST

Merge fx-team to m-c.

Comment 6

[Nils Ohlmeier [:drno]]

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

Comment 7

[Nils Ohlmeier [:drno]]

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 <[e-mail]>
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.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

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)

Comment 9

[Milan Sreckovic [:milan] (needinfo for best results)]

What's the STR?

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

(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?

Comment 11

[Nils Ohlmeier [:drno]]

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.

Comment 12

[Martin Thomson [:mt:]]

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.

Comment 13

[Nils Ohlmeier [:drno]]

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?

Comment 14

[Martin Thomson [:mt:]]

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

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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

Comment 16

[Eric Rescorla (:ekr)]

Yes, though I wish I knew what fixed it.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Indeed...