579676 - Flash video corruption with alpha recovery (e.g. fixed backgrounds)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Matthew Turnbull [Bluefang]]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100717 Minefield/4.0b2pre Firefox/4.0
Build Identifier: 

When [some?] flash videos are scrolled off screen, they get blocky white rendering artifacts. I only noticed this because the landing of retained layers (or another landing at the same time) caused the corruption to be always present.

With IPC disabled, the corruption is not present.

Running Gentoo x86_64 and Flash 10.0 r45

As best as I can tell, the regression range [of the original problem] is 07/01/2010 - 07/02/2010
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=82edf5bd1abe&tochange=c173731c9d90

The regression range for being always present is 07/15/2010 - 07/16/2010
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7


Reproducible: Always

Comment 1

[Matthew Turnbull [Bluefang]]

Attachment: corruption example

Comment 2

[Felipe Barriga Richards]

Attachment: Screenshot of the bug when playing embedded youtube video.

Comment 3

[Felipe Barriga Richards]

Attachment: Page get corrupted when playing an embedded youtube video and scrolling (fast) the page.

Comment 4

[Felipe Barriga Richards]

Comment on attachment 458242 [details]
Screenshot of the bug when playing embedded youtube video.

Browser:
Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100717 Ubuntu/10.04 (lucid) MozillaDeveloperPreview/4.0b2pre

Adobe Flash plugin: Shockwave Flash 10.1 r53

Extensions:
Ubuntu Firefox Modifications 0.9rc2
Adblock Plus1.2.1
Adblock Plus: Element Hiding Helper1.0.6
RAMBack1.0
TubeStop1.4
Firebug1.9.1
Download YouTube Videos as MP4 and FLV0.73

Comment 5

[Matthew Turnbull [Bluefang]]

(In reply to comment #3)
> Created attachment 458243 [details]
> Page get corrupted when playing an embedded youtube video and scrolling (fast)
> the page.

That's a different bug, I think.



Marked this bug as blocking Bug 564991. Not sure if that's correct, but it seems a likely place to start.

Comment 6

[Felipe Barriga Richards]

(In reply to comment #5)
> (In reply to comment #3)
> > Created attachment 458243 [details] [details]
> > Page get corrupted when playing an embedded youtube video and scrolling (fast)
> > the page.
> 
> That's a different bug, I think.
I think that you're right, it also happens in others pages without adobe flash (always with fast scrolling and (I'm not sure) it can happen with intensive cpu use). Maybe it's a problem involving somehow a timer o thread ?

Comment 7

[Oleg Romashin (:romaxa)]

Not sure, but probably we need layer-plugins implementation bug 556487

Comment 8

[Karl Tomlinson (:karlt)]

Felipe, I think you are seeing bug 579736.

Matthew, what video driver are you using?
I think this will be resolved by bug 576143.

Comment 9

[Matthew Turnbull [Bluefang]]

Gentoo Linux x86_64 non-multilib

Linux 2.6.34.1
xorg-server-1.8.1.902
mesa-7.8.2
libdrm-2.4.21
xf86-video-ati-6.13.1 (using KMS)

Comment 10

[Matthew Turnbull [Bluefang]]

Oh, sorry, I should also mention that the particular mesa/DRI/DRM driver I'm using is R600 for an ATI Mobility FireGL V5700 (a.k.a ATI Mobility Radeon HD 3650)

Comment 11

[Karl Tomlinson (:karlt)]

Thanks, can reproduce here with a similar system, but xorg-server 1.7.7 and older radeon card, though, on roosterteeth, i see the problem even before the video is scrolled offscreen.

(In reply to comment #8)
> I think this will be resolved by bug 576143.

No, it won't help on roosterteeth, here at least.  It looks like the
fallback drawing there is because the target surface has an alpha channel.
Don't know why that would be.

I don't think layer-plugins can solve this until flashplayer can draw to a
surface with alpha.

Comment 12

[Matthew Turnbull [Bluefang]]

(In reply to comment #11)
> Thanks, can reproduce here with a similar system, but xorg-server 1.7.7 and
> older radeon card, though, on roosterteeth, i see the problem even before the
> video is scrolled offscreen.

Yep, I did mention that in my first comment (second regression range)

I should also mention that RoosterTeeth has 2 different players, one for sponsor videos and one for regular and/or non-sponsor videos. When full-screening the video, the sponsors player is corruption free, whereas the non-sponsors player is broken. Not sure if this is related or not.

When you say the target surface has an alpha channel, do you mean as part of the flash media player implementation, or because it is in an HTML element with transparency?

Just to be clear, this looks to be a problem introduced by [retained] layers. Is this a problem that can be fixed on Mozilla's end, or is this something that Flash needs to be updated for?

Comment 13

[Karl Tomlinson (:karlt)]

OK, thanks.  First regression would be from bug 574583.  Bug 576143 covers that.

(In reply to comment #12)
> When you say the target surface has an alpha channel, do you mean as part of
> the flash media player implementation, or because it is in an HTML element with
> transparency?

I'm referring our internal layer surface that we use for drawing.  There are a few different situations where we choose to have layers with alpha channels.

> Just to be clear, this looks to be a problem introduced by [retained] layers.
> Is this a problem that can be fixed on Mozilla's end, or is this something that
> Flash needs to be updated for?

I think we can probably do something about it in Gecko.
Exactly how well we can fix it, I don't know until I find out exactly what the problem is.

Comment 14

[Felipe Barriga Richards]

I forgot to mention, here I'm using:
Linux 2.6.32-23-generic
xorg 1:7.5+6ubuntu1~xorgedgers3~lucid
libdrm-radeon1 2.4.21+git20100702.b803918f-0ubuntu0sarvatt~lucid
xserver-xorg-video-radeon 1:6.13.99+git20100716.cdeb1949-0ubuntu0sarvatt~lucid

VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400

Comment 15

[Karl Tomlinson (:karlt)]

I suspect this is due to our trying to guess an alpha value for the plugin rendering from two different renderings that are not the same, which causes our computation to overflow.

That should be easy enough to improve, though I think we should also think about minimizing the number of times we use COLOR_ALPHA layer surfaces.

Comment 17

[Felipe Barriga Richards]

Fixed for me (the problems with video corruption, didn't tried the fast page scroll) after the last release. I need to say that I've also updated X drivers so , There is anybody that have tested only updating Firefox ?

Comment 18

[Karl Tomlinson (:karlt)]

Attachment: part 1: use the same alpha recovery code for gfxWindowsNativeDrawing and gfxXlibNativeRenderer

This is mostly refactoring to share code.

There is a small change on the in that gfxWindowsNativeDrawing now sets the alpha on the black surface in-place, rather than creating a third image surface.

Comment 19

[Karl Tomlinson (:karlt)]

Attachment: part 2: detect overflow when black and white images differ

From the comments in the patch:
|diff| here is a measure of the transparency.  If both renderings are
from the same source image composited with OVER, then the color values
on white will always be greater than those on black, so |diff| would
not overflow.  However, overflow may happen, for example, when a plugin
plays a video and the image is rapidly changing.  If there is overflow,
then behave as if we limit to the difference to >= 0, which will make
the rendering opaque.  (Without this overflow will make the rendering
transparent.)

Comment 20

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

Comment on attachment 461145 [details] [diff] [review]
part 1: use the same alpha recovery code for gfxWindowsNativeDrawing and gfxXlibNativeRenderer

+        if (!gfxAlphaRecovery::RecoverAlpha(black, white)) {
+            NS_ERROR("Alpha recovery failure");
+            return;
+        }
         nsRefPtr<gfxImageSurface> alphaSurface =
-            gfxAlphaRecovery::RecoverAlpha(black, white, mTempSurfaceSize);
+            new gfxImageSurface(black->Data(), black->GetSize(),
+                                black->Stride(),
+                                gfxASurface::ImageFormatARGB32);

Why not just use 'black' instead of allocating a new alphaSurface?

Comment 21

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

Comment on attachment 461146 [details] [diff] [review]
part 2: detect overflow when black and white images differ

+    /* |diff| here is a measure of the transparency.  If both renderings are

I think more clear to say "|diff| here increases as the pixel is more transparent"

Comment 22

[Karl Tomlinson (:karlt)]

(In reply to comment #20)
> Why not just use 'black' instead of allocating a new alphaSurface?

|black| will treat the data as RGB24.
alphaSurface treats the same data as ARGB32.

Comment 23

[Karl Tomlinson (:karlt)]

http://hg.mozilla.org/mozilla-central/rev/ef549d1ee3d3
http://hg.mozilla.org/mozilla-central/rev/ff1fdbad6e20

Comment 24

[Matthew Turnbull [Bluefang]]

That seems to have fixed the rendering artifacts in attachment 458109 [details]. However, now there's 'compositing' artifacts around motion and scene cuts.

This is a good example
http://roosterteeth.com/archive/?id=1431

I should also mention that what ever changed to cause this problem (rendering to transparent surfaces?) also causes the browser to become nearly unresponsive. You have to stop the video before you can interact with the browser.

Comment 25

[Karl Tomlinson (:karlt)]

(In reply to comment #24)
> I should also mention that what ever changed to cause this problem (rendering
> to transparent surfaces?) also causes the browser to become nearly
> unresponsive. You have to stop the video before you can interact with the
> browser.

I filed Bug 586162 on that.

> However, now there's 'compositing' artifacts around motion and scene cuts.

I see a little of that, I think.
I suspect it's the same issue that alpha extraction is not working right when two images differ, only it now only shows as the video becoming partially transparent.

Oleg could be right that bug 556487 might help by ensuring that the two plugin paints occur without the plugin processing any other events (on that thread).

Comment 26

[sashafan2]

This bug is not linux specific. And it's still present for me even in the latest trunk.

Comment 27

[Karl Tomlinson (:karlt)]

sashafan2: Does http://roosterteeth.com/archive/?sid=rvb
still look like attachment 458109 [details]?

Would you mind filing a new bug please?
with your system details and steps to reproduce.