Here it is, at last. Gnash 0.8.1 no longer segfaults on FreeBSD, I've solved all configure problems, all dependencies are checked, all test builds completed successfully. Behold, native Flash player for FreeBSD.
It seems like I'm the first to try it, so why not do some tests while the port is being committed? I wonder, can I play flash games now? Can I be see those shiny flash banners? Can I watch YouTube videos at last?
First, I have to say that I hate flash. It's closed proprietary format, and it's heavily abused on the web. It's known mostly for annoying flash banners, absolutely unusable navigation, stupid simple games and useless video players (seriously, why not use video player plugin to play video in browser? why the hell use flash here?!). Yet, I cannot deny that there really are some pieces of art made entirely in flash, so GNU Flash Player is definitely a good thing. Let flash abuse be a problem of no-good web designers, and let's see how well we can experience those rare pieces of art without using proprietary players.
Gnash lets you choose between 3 renderers: AGG (Anti-Grain Geometry), OpenGL and Cairo. OpenGL was default (and the only) renderer in earlier versions of Gnash, AGG is recommended for better quality and Cairo support is experimental for now. For the sake of comleteness, in addition to default OpenGL settings, I've tried turning on 8x anti-aliasing (via nvidia-settings utility), which significantly improved image quality, and also software OpenGL rendering.
Let's start with (more or less) simple flash cartoons. There's not much (if any) ActionScript here, so no advanced features are required from the player.
I've chosen famous "Happy Tree Friends" episode #4: Crazy Antics.
As you can see, AGG outputs the best image. Anti-aliasing is great, yet the small features remain sharp. Also I didn't notice any image artifacts with AGG.
OpenGL without anti-aliasing is terrible, but after turning it on, it looked comparable to other renderers.
Cairo showed many artifacts when viewing clips, but I guess that's what you expect from experimental feature. OpenGL has some glitches too, but those were less visible.
Okay, we have good looking picture. But, will the render be able to render it fast enough for realtime watching? That's the question.
Well, after watching Happy Tree Friends I can declare that on my machine (old good Pentium-4 1.8, GeForce3) the only usable renderer is OpenGL. Cairo is very, VERY slow, and AGG is almost fast enough, but still not enough for realtime. The main problem is that Gnash can't skip frames and that sound is not synchronized with rendering in any way. Thus, if it can't render frames in realtime, audio and video will come out of sync => not much pleasure from watching.
So, OpenGL beats others to dust in terms of speed. Hardware acceleration is still a serious argument.. The good thing is that turning anti-aliasing on doesn't affect CPU usage, so you can still have decent image quality. The bad thing is that, though CPU usage stays around 13% the whole clip, if there still are any complex frames (for example, I have 100% CPU usage for 1-2 sec in the beginning of Happy Tree Friends episode), sound will inevitably come ahead of visuals.
You must be interested in some numbers. Hopefully, gnash supports -1 option that makes it exit after the clip finishes, and nvidia-settings can be used from command line, so I made simple benchmarking script. Here are the results (each benchmark was repeated 3 times and median taken):
|Renderer||User time||System time||CPU usage||Total time|
`None' renderer is just what it means: no renderer at all. Just reading and decoding flash clip takes place (see -r gnash option). As you can see, this episode of Happy Tree Friends lasts 1 minute 11 seconds. And every time Gnash ran more than 1:11 means that realtime rendering was not possible. Each second above 1:11 adds to difference between what you see and what you hear.
Note low CPU times and processor usage of software OpenGL. That's because rendering work was done by the X server and not by Gnash process. This is not good, as overloaded X server shows significant lag in updating other windows. With hardware accelerated GL, X server seem to not eat more than ~5% CPU (even with antialiasing and Gnash window maximized).
Now let's conclude rendering stuff.
OpenGL works excellent, but only if you have hardware acceleration. It this case rendering doesn't eat much CPU, and it won't eat (much) more CPU if you decide to turn on anti-aliasing for better quality or maximize player to fullscreen. But without acceleration, OpenGL is just no good.
AGG gives you the best image quality, but it is somewhat slow for low-to-mid end machines or heavy clips. Still it's your choice if you have no 3D acceleration. Also I would recommend this renderer if you intend to mostly view static flash (like charts).
Cairo is just too slow, and has too many artifacts. BUT!!! Here's where I remembered that Cairo can be built with hardware acceleration (glitz)! I've rebuilt it, but no luck - benchmarks were the same. Please mail me if you have any ideas on how to use hardware acceleration with cairo - I'm really interested on how well it performs. Maybe gnash lacks support for glitz - still a thing to investigate.
Update: strk of Gnash development team suggested me to benchmark OpenGL performance without hardware acceleration (done 19.09.2007, see above), and also to try some knobs (--enable-mit-shm configure option and NDEBUG define), which may improve Gnash performance. I'll make results of benchmarks available as soon as I get them (done 21.09.2007, not much gain from both knobs).
Now, to games. Games usually require much more ActionScript code, draw many smaller sprites and require user interaction.
I didn't try previous versions of Gnash on games (but I've collected few dozens of v5-v8 flash games specially for this case), so let this part of article be just a reference point to compare future releases of gnash to. I'll just point some things that don't work in 0.8.1.
And for now, unfortunately, almost nothing works. Some games are stuck infinitely in preloading loop, in some buttons don't work, some sprites aren't rotated and placed correctly etc. So of 50 games, only 3 were actually playable.
"Big fish eat little fish"
works pretty well
"Bowman 2" works, except for
some displaced sprites
Most flash v8 games look
Flash in web is something in-between simple animation and games in terms of complexity. Let's test some sites that heavily use flash, and see if gnash make them usable.
Well, actually, there can be no such sites worth visiting, and even on sites where there is flash, I won't see it because of FlashBlock and AdBlock Firefox extensions. Still I'll do my best and find at least couple of worthy flash-using sites.
http://www.starcraft2.com - sites oriented to gamers often use flash. Well, large logo on the top doesn't work, navigational menu below it doesn't work. But, videos for new units and buildings work pretty well, and as it was what I came to that side for, gnash receives +1 here.
http://www.ixbt.com - popular Russian hardware site. They don't use flash for navigation, but use it for some charts instead. Unfortunately, Gnash couldn't handle these (abort with assertion failed). But this was fixed almost immediately after I've reported the error to Gnash developers, so another +1.
http://www.uncontrol.com - interesting site with flash visualization. And seems like a perfect test for gnash. Unfortunately, navigation flash don't work, so I couldn't continue.
http://finance.google.com - flash is used to show scrollable/scalable graphs on Google Finance. Gnash just eat 100% CPU and show black rectangle.
http://www.tombraider.com - I've ran out of ideas, so here's another game site. Unlike starcraft, this whole site is one .swf. Well, it should be rather complex, so it's not strange gnash can't handle it at all.
Now, we're getting closer to, I think, the most awaited feature in gnash 0.8.0: streamed video support.
As with renderers, Gnash lets you choose between several media handlers: FFmpeg, GStreamer and MAD. FFmpeg is a library that supports great number of codecs and video formats, and is used, for instance, in mplayer. GStreamer is freedesktop's framework that supports multimedia input, processing and output and MAD is MPEG Audio Decoder library. While GStreamer has built in support for audio output, FFmpeg and MAD rely on SDL library for that purpose.
In short, all three media handlers work, i.e. you'll get sound in Happy Tree Friends. But under the hood, there are, of course, huge differences:
MAD, as you would expect from `MPEG Audio Decoder' only supports decoding of mp3 audio embedded into flash movies. It does it's work quite well, but it just is not enough if you need to play streaming video or if you happen to encounter flash clip with ogg audio.
FFmpeg can do much more than MAD. It supports huge set of codes, and of course, yes, Gnash compiled with FFmpeg media handler does play YouTube video! It's still not as good as proprietary flash player, as there are some glitches in player interface and the video is pixelized (see screenshot), but I guess both those problems will be fixed in future Gnash releases. YouTube works well for AGG and OpenGL renderers, though you won't see video if the renderer fails to update frames in realtime. No A-V desyncing happens in this case, as both audio and video are extracted from one stream, you just won't see video updates. So choose your renderer carefully.
Like FFmpeg, GStreamer also support many codecs. It's advantage is intelligent plugin architecture, so to add support for another codec, you'll only need to install a plugin. On some Linux distros plugins are installed automatically, but on FreeBSD this turns a downside of GStreamer, as you'll need to install required plugins yourself. Those are: multimedia/gstreamer-plugins-good (for OSS sound output), audio/gstreamer-plugins-mp3 (for audio) and multimedia/gstreamer-ffmpeg (for video decoding). Actually, the right video decoder for YouTube is multimedia/gstreamer-plugins-x264, but it's unsupported in Gnash 0.8.1 and FFmpeg is used instead. What's for playback, Gnash compiled with GStreamer behaves absolutely similar to FFmpeg, except for slightly higher (2-3%) CPU usage.
Gnash supports both Firefox and Konqueror. I have no KDE installed, so neither I could test Konqueror plugin not add proper support for it to the port (so if you happen to use KDE of FreeBSD and would like Konqueror plugin, please mail me (amdmi3 at amdmi3 dot ru)). Firefox plugin works very well. The advantage of Gnash is that you can close an instance of flash player completely from context menu (with Adobe plugin, you can only stop the playback). The plugin should also work for Opera, but for me it didn't. It was listed in the list of plugins found by Opera, but just grey rectangles instead of flash clips.
Customizability was always a strong side of free software. Gnash is not an exception, as it offers many tunables (see Gnash documentation). For example, you can setup your ~/.gnashrc so all flash clips will start in stopped state (StartStopped variable). Thus flash ads won't annoy you (and playback can be started anytime through right-click menu). Another useful feature is blacklist and whitelist of domain names, which allows you to skip loading of unwanted flash clips completely.
As of version 0.8.1, Gnash is still far from being as usable as closed source Adobe flash player. But the progress is definitely being made, and YouTube support introduced in 0.8.x confirms it. So, as development continues steadily, I'm sure Gnash will soon catch up to it's closed source competitor, thus removing need in one more proprietary application and bringing flash support to operating systems and architectures Adobe doesn't bother to support. Keep up the good work!
If you are interested in more info on Gnash, please visit http://www.gnashdev.org.