`external` flash video flickers

RESOLVED INVALID

Status

()

RESOLVED INVALID
5 years ago
5 years ago

People

(Reporter: galtgendo, Unassigned)

Tracking

({steps-wanted})

20 Branch
x86
Linux
steps-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
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)
(Reporter)

Comment 3

5 years ago
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?
(Reporter)

Comment 5

5 years ago
(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

Comment 7

5 years ago
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
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 8

5 years ago
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 → ---

Comment 9

5 years ago
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
Last Resolved: 5 years ago5 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

5 years ago
(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.

Comment 11

5 years ago
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.
(Reporter)

Comment 12

5 years ago
> 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.
(Reporter)

Comment 14

5 years ago
So, given bug 982694 has pretty much done, what I've expected in the earlier comments, is it OK to reopen this now ?
You need to log in before you can comment on or make changes to this bug.