Penguin.SWF

Thanks, I appreciate the timely security updates, but the Flash player has been sigsegving on me after the update on pages such as The Daily Show front page. At least the gdb backtrace blamed the flash player. Too bad it didn't have debug symbols or I could have given you a better analysis.

Hi, I appreciate the work you did to add gpu support to flash player. It doesn't change the fact that I get roughly double framerates in Windows on my old machine (so the difference is watchable/not watchable)

In your linked post of May 30, 2008, I see mention of three sticking points regarding gpu acceleration (apologies if I mis-characterise any of them):

* Sniffing the client glx vendor string (and accepting false negatives in open drivers) because other, "more robust", methods for identifying software rendering were crashy.

* "Compiz and GPU-accelerated Flash on Linux do not mix."

* Flash GPU acceleration is incompatible with Xv acceleration because the data formats are different and because flash would like to preserve the ability to draw on top of the video.

Could you say a few words about how these issues stand now (with current open and/or proprietary drivers)? And how you anticipate things changing in the near future (with projected advances in the open drivers).

for the other people like me with 64bit systems like me, get the new version here: http://labs.adobe.com/downloads/flashplayer10.html

Or for a 64-bit yum repo for flash-plugin, here:

http://forums.fedoraforum.org/showthread.php?t=205642

Adobe should add the 64-bit version to its own repo so it isn't necessary to have yet another one enabled (or trust another GPG key).

I wonder if there are any improvements undergoing regasrding sound.

I can't get flash sound via HDMI even after applying as lot of alsa options...

I didn't really hear the news... where can I find the changelog?

http://arstechnica.com/software/news/2008/10/benchmarking-flash-player-10.ars

If I read carefully, you are getting half the performance of Windows Vista, and you are beating Mac OS X hard. I know one of your bottlenecks is X. Are there any other bottleneck? Can you point OSS developers into the right direction to locate and destroy those bottlenecks? This should be done, for the advancement of free software AND your goals as a proprietary company. Consider this. It's about adding developers, not even about opening code.

Sounds like a pretty bitter post. Things not going too well with the whole flash-on-linux thing then?

Anyway, I too would like to know what exactly the compiz problems are. Any bugreports you could link to?

Naive assumption: The Compiz problem is probably the same one Google Earth has; that you can't use a 3D application in a composited desktop without kernel mode-setting. If you try, it's constantly flickering--you end up having two things competing to render directly on the hardware. Or something.

At least we have no viruses! XD

And thats b/c no one in there right mind would waste time writing viri for 1% (woo hoo) of the market.

The compiz problems where never present on systems supporting redirected direct rendering.

The nvidia binary driver always did this, the open source radeon and intel driver support this for a while now (DRI2). And fglrx also has redirected direct rendering nowdays. So there is no reason not to use opengl with compiz.

Without RDR you get artifacts when running opengl apps in compiz, but as all major drivers now support it its a thing of the past.

Mike, please remove this limitation.

Why not use OpenGL just on the final video scaling step for older OpenGL versions without shader programs?

This would help on a vast number of Linux powered 945GM based netbooks.

I am disappointed by this version:
No progress in improving the bad camera support in the Linux version of FP 10. A lot of cameras that used to work under version 9 still do not work with the latest version. The fact that bug FP-775 was changed from a bug into a feature request does not solve the problem. And I do not understand why "Linux microphone" is still the one and only option for sound input. Please implement PROPER V4L and ALSA support.

Vedran, this already works fine, at least for me. You need to force Flash to use the GPU, but after that, fullscreen videos are mostly smooth on my slow netbook.

Mike, I'm not sure how much you are involved in that, but is the 64-bit plugin going to have OpenGL acceleration any soon?

@default, how do you force it to use the GPU? only one trick I use is to actually use the mplayer on the .flv file in /tmp that is created when playing flash videos

I have an AMD Athlon 64+ 3500 and all 64 bits Flash versions immediately make Firefox crash: "Illegal instruction". It's disappointed to see that Adobe is publishing a 64 bit plug-in which does not even support all 64 bit CPUs.

@Vedran, this was described on this blog a few posts earlier. See http://blogs.adobe.com/penguin.swf/2008/08/secrets_of_the_mmscfg_file_1.html

If gnash has xvideo support, why can't flash player?

I can't watch HD videos on YouTube with Linux flash. They're slow as molasses. The Windows version works fine.

What's wrong?

ffmpeg has no issues playing back .flv files in fullscreen while compiz is the window manager.

Perhaps the ffmpeg folks will waiver the stricter LGPL requirements out of pity for you guys.

And even if they don't. Just take it and run with it. No-one has to know. It'll be our little secret ;)

Using 64-bit 10.0.32.18 on Fedora 11 64-bit, just tried cnn.com ... the live video locks up after just a couple seconds of the "your video will start in x seconds"... the archived videos also lock up after a few seconds.

Youtube works great, though!

@default, doesn't work on 945GM, but thanks anyway. I didn't know about mms.cfg.

@realnc, are you joking? Mike (Penguin.SWF author) works for ffmpeg project. Check out "Multimedia Mike" blog. He's a great guy, but maintaining a complex piece of code such as flash player on a non major platform is a demanding task.

Though I have a feeling that a implemenation that is more easy on lame OpenGL hardware/drivers could benefit both Mac and Linux versions, using the same underlying code.

Either way, we should be thankful to both Mike and Adobe, it's not like we pay them to do this.

@Vedran, yes I was joking. I thought the last sentence and the smiley was a clear give away :)

Look, I like Mike's cynicism as much as I liked the good old Linux Hater (sidenote: possibly one and the same person. Need to investigate further). However, the XKCD comic is right on the money here.

I don't buy the "Xv does YUV scaling so we can't use it to overlay our RGB stuff" argument. Guess what, Xv also does colorspace conversion. As evidenced by the fact that every frame displayed on your *RGB* monitor is in *gasp* RGB! Magic I say! Heresy even!

So what, right? Just add extra colorspace conversions so that you do your compositing in good old RGB---done and done! But what's that I hear?! Whispers of inefficiency! Au contraire kind sirs, what's inefficient is eating 100% CPU while ffmpeg "idles" at 5% in *fullscreen* mode on the *exact same* file and the *exact same* hardware.

Clearly there's enough incentive for Adobe to support flash on Linux. Just not enough to do a particularly good job at it. Kudos to Mike and the rest of the "penguin team" for proudly carrying the linux torch anyway;-bringing some of the internet's finest programming to the linux world with such shows as keyboard cat, gender confused teenagers, and an assortment of colorful videos that would make a blind person avert their eyes in horror.

@Alex,

When speaking about XV, you have two different things to think about: data source and output. Usually XV implementations support different YUV packings for the source part. The output is of course in the pixelformat of the X screen.

Use xvinfo command to check out what your XV implementation supports. I think I only saw nVidia expose RGB source formats.

However, OpenGL usually supports RGB scaling on most hardware with decent performance, so my feeling is that this could be used.

I guess the fastest fullscreen YouTube flash implementation would use native colorspace of the video stream, and just "damage" the regions of video that should be overlaid by RGB stuff and convert that to the native video color space and just push that to the OpenGL driver.

Of course, if most of the area was RGB, then it makes sense to use RGB in that case. And since those cases mostly have letterboxed video, then that should be fine performance wise.

Some kind of auto heuristics should provide for a best case.

Putting the ideal implementation aside, just as I've said, I think that just using the RGB scaler with OpenGL should be immensely helpful. I'm not sure how flash does YUV -> RGB, but that could probably be accelerated too with OpenGL, maybe even without shaders.

I dunno, haven't touched this things in years.

Mike will tell. Or not :)

Is there a page describing the details for logging and reporting a bug? I decided to try the 64-bit version and it segfaults the browser whenever I go to the website for the denver post...

I don't know about "opengl" and stuff. I can watch HD videos in mplayer without acceleration using X11 back-end; no XV, no overlay, no gl, no nothing. Who needs acceleration? For what? No, the problem is not acceleration it seems.

I'm also curious about the current state of accelerated GL stack detection. I hope it's improved since your last blog entry, since we (Intel Linux graphics developers) have been spending a lot of time improving our accelerated GL support, and hope you can take full advantage of it.

Lately I've been working on adding support for GLX extensions that should help with video playback and synchronization (e.g. SGI_video_sync, OML_sync_control, etc. see URL).

I'm curious if you have any particular needs on the Flash front that wouldn't be covered by the extensions listed (aside from those already mentioned in your other blog post of course). I'm particularly interested in any thoughts you have about composited environments. You mentioned some problems with compiz configurations, but didn't list specifics...

a web comic does not have to factually accurate.

funny is more than enough.

That comic is mostly funny BECAUSE it's accurate, and not just for intel cards either.

Anyway, a bigger problem for me is the absolutely terrible audio latency of flash in linux. I get a latency of between 0.5 and 1 second here in general (though it seems to be less at youtube for some reason), and yes, I'm using plain old ALSA. Windows firefox+flash in wine has no noticable audio latency, but has graphical glitches, so that's also unusable.

That said, I do appreciate the work you've done so far, Mike. Even with these major issues, today's Flash is still a massive improvement over what we used to have.

My problem turned out to be pulseaudio. Disabled pulseaudio and cnn.com started working.

Now need to figure out the video falling behind when running on the second display... seems to be a potential issue caused by the nvidia binary drivers.

Would be nice if there were some way to see if the flash player was actually using gl hw acceleration or ignoring the checkbox, which would help in debugging what's going on.

Also, does flash respect the GL sync to vblank option?

released but still some problems with 64bit platforms. sometimes I still have "Illegal instruction" while I'm using AMD 64

The OpenGL acceleration discussion is leading in the wrong direction. It is used ONLY for fullscreen playback.

However the real problem is that Flash is at least 3-5 times slower when playing at Normal size, compared to mplayer -vo x11 (x11 output is RGB only and software conversion is used).
I could only explain that with the lack of asm/SIMD/MMX optimizations.
Given that Mike is FFmpeg developer, it should be trivial for him to make Flash use libavcodec and libswscale as optional dynamic-loading plugins.
The DRM protected stuff could still be played only with the internal codecs.

Why not start harnessing the power of the crowd (us) without necessarily open sourcing the whole thing as the first step, by creating an abstraction layer of functions we can implement to achieve the things we have whined about, if it's so easy?

Is the fullscreen video on http://www.c-spanarchives.org working for folk (specifically using the 64-bit alpha)?

In-browser works fine, and this is the first page I've seen the fullscreen not work.