When viewing the following video on Youtube in *HTML5* mode, I'm getting a black flicker at the bottom of the video: http://www.youtube.com/watch?v=JzhlfbWBuQ8 Steps to reproduce: 1) Go to http://www.youtube.com/html5/ and enable HTML5 trial 2) Go to http://www.youtube.com/watch?v=JzhlfbWBuQ8 3) Black flicker at the bottom of the video The problem does not happen with Firefox 7.0.1, but it does happen with the latest Beta of FF 8, as well as with Aurora (FF 9). In Aurora, the "Full screen" button also does not work. The flicker problem does not happen on most other videos I watched and I don't know what's special about this one. My machine is a Thinkpad W520 (Intel i7), 4 GB RAM, running Debian testing (amd64) with the Intel video driver. I'm running the standard 32-bit FF builds.
Karl, Matthew, can you reproduce this?
I can reproduce this with the linked video, and I have seen it before on other YouTube hosted WebM videos. Changing the background colour of the video-container div (which contains the video element) to red changes the colour of the flickr flickering box to red also. When hovering over the scrubber bar, you can also see a similar flicker around the bubble popup.
I'm also seeing this in the Firefox 7.0.1 release, but it's much worse in the nightlies.
I assume GL layers are still disabled by default for Linux? Sounds like the flicker does not cover the entire video? Try dumping the GetClipExtents in force when we draw the BasicImageLayer to see if the image is being incorrectly clipped or something?
It's not enabled for me, about:support reports 0/1 accelerated windows. Minimal testcase (as linked): <div style="background:#f0f;height:360px"> <video src="sync240.webm" height="100%"></video> </div> Right click the video, select play, then click elsewhere in the document to defocus the video. If the video is left focused, the bug doesn't occur. If the video is started via autoplay or the controls, the bug doesn't occur. The video also seems to need to be scaled up for this to occur. The size of the flickering box doesn't seem to increase with scaling, and given the size and positioning it's probably related to the hidden default controls.
doublec pointed me to bug 640074 (which I can no longer reproduce locally), but I can't reproduce this bug with prescale always false in gfxUtils::GetYCbCrToRGBDestFormatAndSize, so it does appear to be related.
Created attachment 571245 [details] [diff] [review] patch v0 Bug 630835 introduced this change: http://hg.mozilla.org/mozilla-central/diff/b8194445b364/layout/generic/nsVideoFrame.cpp If I understand this correctly, it should be using frameSize rather than videoSize.
Comment on attachment 571245 [details] [diff] [review] patch v0 Review of attachment 571245 [details] [diff] [review]: ----------------------------------------------------------------- Right, we need to set the pre-transform size as the visible region. Great! Let's get this into aurora and (if possible) beta!
Comment on attachment 571245 [details] [diff] [review] patch v0 [Triage Comment] * We won't re-roll beta for this - only affects webm on Linux * Approving for Aurora since we should have time to identify regressions as it progresses through the channels Please land on Aurora today to make it in before the merge day tomorrow.
https://hg.mozilla.org/releases/mozilla-aurora/rev/a0834921de1e This could affect non-Linux platforms in theory. Not sure why it hasn't come up elsewhere.
Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Windows NT 6.1; rv:10.0a2) Gecko/20111116 Firefox/10.0a2 Mozilla/5.0 (Windows NT 6.1; rv:11.0a1) Gecko/20111116 Firefox/11.0a1 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111116 Firefox/10.0a2 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0a1) Gecko/20111117 Firefox/11.0a1 Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (X11; Linux x86_64; rv:10.0a2) Gecko/20111117 Firefox/10.0a2 Mozilla/5.0 (X11; Linux x86_64; rv:11.0a1) Gecko/20111117 Firefox/11.0a1 Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0 Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111110 Firefox/10.0a2 Mozilla/5.0 (Windows NT 5.1; rv:11.0a1) Gecko/20111110 Firefox/11.0a1 Verified the fix on the above builds: described issue is no longer reproducible.