Closed Bug 579676 Opened 10 years ago Closed 9 years ago

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

Categories

(Core :: Graphics, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b4
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: sparky, Assigned: karlt)

References

()

Details

Attachments

(5 files)

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
Attached image corruption example
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
(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.
Blocks: 564991
(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 ?
Not sure, but probably we need layer-plugins implementation bug 556487
Felipe, I think you are seeing bug 579736.

Matthew, what video driver are you using?
I think this will be resolved by bug 576143.
Depends on: 576143
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)
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)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(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?
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.
Blocks: 574583
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
blocking2.0: --- → ?
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.
Assignee: nobody → karlt
Summary: Flash video corruption when scrolled partially off screen → Flash video corruption with alpha recovery (e.g. when scrolled partially off screen)
Duplicate of this bug: 581122
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 ?
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.
Attachment #461145 - Flags: review?(roc)
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.)
Attachment #461146 - Flags: review?(roc)
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?
Attachment #461145 - Flags: review?(roc) → review+
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"
Attachment #461146 - Flags: review?(roc) → review+
(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.
Summary: Flash video corruption with alpha recovery (e.g. when scrolled partially off screen) → Flash video corruption with alpha recovery (e.g. fixed backgrounds)
Blocks: 583621
No longer blocks: 583621
Component: IPC → Graphics
QA Contact: ipc → thebes
blocking2.0: ? → betaN+
http://hg.mozilla.org/mozilla-central/rev/ef549d1ee3d3
http://hg.mozilla.org/mozilla-central/rev/ff1fdbad6e20
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
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.
(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).
This bug is not linux specific. And it's still present for me even in the latest trunk.
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.
Depends on: 687634
You need to log in before you can comment on or make changes to this bug.