Closed Bug 862422 Opened 12 years ago Closed 12 years ago

`external` flash video flickers

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
20 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: galtgendo, Unassigned)

Details

(Keywords: steps-wanted)

User Agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 Build ID: 20130406172344 Steps to reproduce: I'm seeing an odd inconsistency with how some of flash video elements are rendered depending on how are they displayed and if they're are local on the site or not. Actual results: http://www.upworthy.com/9-out-of-10-americans-are-completely-wrong-about-this-mind-blowing-fact-2 has a single flash youtube element pointing at http://www.youtube.com/watch?v=QPKKQnijnsM&feature=player_embedded#! If I watch it on youtube, it's rendered correctly, it's also rendered correctly if I watch it on the site, but fullscreen. However, if I choose to watch it without switching to fullscreen, it - for the lack of a better term - flickers. By "flickers", I mean that random portions of the embedded player turn black, both video and the interface, most of the times it's almost the whole embedded area. The sound is still OK. This is not the only flash video I've seen with that behavior, just the most easily accessible. firefox 19 was the first version, that I'm sure was affected, but it could be older.
Component: Untriaged → Video/Audio
Product: Firefox → Core
Flash video bugs go in the plugin component. Video/Audio is for HTML5 video.
Component: Video/Audio → Plug-ins
I assume that is with the latest version of Flash for Linux? I'm not seeing this with Fx 20 & Flash 11.2.202.280. Could be worth testing if it does it still happen with Flash hardware acceleration off. You might need to resort to those work-arounds for disabling it: http://superuser.com/questions/434762/disable-hardware-acceleration-for-flash-player-in-linux
Flags: needinfo?(galtgendo)
It's 10.3.183.75 actually - old Athlon means no 11.2 possible. But I've just tested it with 1.2 on an amd64 machine with 11.2.202.280 and the difference was that it's solid black instead of flickering. Also, just about any flash video I've tried on upworthy.com has this problem. x86 machine has an r200, amd64 has intel.
Flags: needinfo?(galtgendo)
Have you tried switching the hardware acceleration on/off?
(In reply to Georg Fritzsche [:gfritzsche] from comment #4) > Have you tried switching the hardware acceleration on/off? In Flash Player ? Doesn't seem to make a difference. On a funny note though, if I switch youtube to HTML5 (as this clip seems to be available in this version too), things work just fine.
Could you try to find out if this worked before, and if it did what the regression window is? http://mozilla.github.io/mozregression/ As is, with this apparently not being reproducable everywhere, i don't think we can do much here. HTML5 video is working very differently, so it working is to be expected.
Flags: needinfo?(galtgendo)
Keywords: steps-wanted
The regression is introduces by Gentoo, it is due to the fact we have patched in support to support building against system-cairo. I will give the user(s) a way to make the choice downstream, bug does not belong to upstream.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Well, if bug 627699 should get anywhere (once it's fully fixed), bug 722975 still needs to be properly fixed, even if there was no activity there in awhile. As such, perhaps this shouldn't be closed, but marked as blocking that bug instead ?
Status: RESOLVED → UNCONFIRMED
Flags: needinfo?(galtgendo)
Resolution: INVALID → ---
I'm not sure what comment 8 is about. This is not a bug in mozilla.org Firefox, and so we're not going to track it in mozilla.org bugzilla. It appears to be specific to Gentoo.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → INVALID
(In reply to Benjamin Smedberg [:bsmedberg] from comment #9) > I'm not sure what comment 8 is about. It's about the comments in the bug about system cairo, saying that if firefox is to work with gtk3 properly, it will *need* to work with system cairo. Also, don't you think that to trigger this problem you need to meet very specific conditions ? There might be a chance, that this path just happens to work with your copy of cairo, not that is should by design.
That may be true, but it's irrelevant to the *current* situation where we use a builtin cairo on purpose because the system cairo is in general in pretty terrible shape. Maybe we can just stop using cairo altogether by then.
> where we use a builtin cairo on purpose because the system cairo is in general in pretty terrible shape ...and we're doing....about it I might be exaggerating a bit, but recently I've read yet another article about nvidia vs kernel developers and can't help to notice similarities. The above might not be constructive (and chrome might be even worse about this), but still... bug 722975 comment 24 sounds pretty similar to yours and it's dated 2012-04-18 15:19:30 PDT
There's a similar issue in Fedora when browser is build with system cairo. It would be useful to identify the needed patches and propagate them downstream to distros.
So, given bug 982694 has pretty much done, what I've expected in the earlier comments, is it OK to reopen this now ?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.