flicker on html5/webm video




6 years ago
6 years ago


(Reporter: jmspeex, Assigned: kinetik)



8 Branch

Firefox Tracking Flags

(firefox8- affected, firefox9- fixed)


(Whiteboard: [qa!] [verified-beta] [verified-aurora], URL)


(1 attachment)



6 years ago
When viewing the following video on Youtube in *HTML5* mode, I'm getting a black flicker at the bottom of the video:


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.
status-firefox8: --- → affected
status-firefox9: --- → affected
tracking-firefox8: --- → ?
tracking-firefox9: --- → ?
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Karl, Matthew, can you reproduce this?
Keywords: regression, regressionwindow-wanted

Comment 2

6 years ago
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.

Comment 3

6 years ago
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?

Comment 5

6 years ago
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>

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.

Comment 6

6 years ago
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.
Depends on: 640074

Comment 7

6 years ago
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.
Assignee: nobody → kinetik
Attachment #571245 - Flags: review?(roc)


6 years ago
Blocks: 630835
No longer depends on: 640074
Keywords: regressionwindow-wanted


6 years ago
Duplicate of this bug: 640074
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!
Attachment #571245 - Flags: review?(roc) → review+
Attachment #571245 - Flags: approval-mozilla-beta?
Attachment #571245 - Flags: approval-mozilla-aurora?

Comment 10

6 years ago
Target Milestone: --- → mozilla10
Last Resolved: 6 years ago
Resolution: --- → FIXED
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.
Attachment #571245 - Flags: approval-mozilla-beta?
Attachment #571245 - Flags: approval-mozilla-beta-
Attachment #571245 - Flags: approval-mozilla-aurora?
Attachment #571245 - Flags: approval-mozilla-aurora+

This could affect non-Linux platforms in theory. Not sure why it hasn't come up elsewhere.
status-firefox9: affected → fixed


6 years ago
OS: Linux → All
Hardware: x86 → All
Duplicate of this bug: 690356
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.
Whiteboard: [qa!] [verified-beta] [verified-aurora]


6 years ago
tracking-firefox8: ? → -
tracking-firefox9: ? → -
You need to log in before you can comment on or make changes to this bug.