Closed Bug 956614 Opened 7 years ago Closed 7 years ago

Missing (transparent) frames with video tag

Categories

(Core :: Audio/Video, defect)

x86
macOS
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox28 --- unaffected
firefox29 --- affected

People

(Reporter: ekr, Unassigned)

References

Details

(Keywords: regression)

Attachments

(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
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)
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 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?
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)
Indeed...
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.