Interesting times for Linux Flash support

Although many proponents of free software and an open web don't like Flash, the multimedia platform has become so ubiquitous that it is difficult to imagine the web without it. However, Flash support has always been a challenge for Linux distributions. Adobe has had a proprietary Linux release of its Flash player software for years now, but only for the x86 processor architecture. Meanwhile, open source projects trying to recreate Flash functionality are lagging behind and struggling with lack of manpower. Luckily, there are also some interesting new technical developments in the open source Flash world. One that sparked our interest recently is Lightspark, which was written from scratch based on the SWF documentation Adobe published in June 2009 as part of the Open Screen Project.

The official Flash player

For years, Adobe treated Linux as a second-class citizen. As recently as 2007, Linux users had to wait six months after the Windows release for their version of Adobe Flash 9. At the end of 2008, that changed: with the release of Flash Player 10, Adobe released versions for Windows, MacOS X and Linux on the same day. However, that's not to say there are no problems with the proprietary Flash player. 64-bit support is still a sore point: although it's possible to use Adobe Flash player on a x86_64 Linux system using a 32-bit emulation layer such as nspluginwrapper, native 64-bit support is only available as an alpha version that was first released in November 2008.

In hindsight, it's ironic that, as late as it may come to the party, Linux is the first platform that gets a peek at a 64-bit Adobe Flash player. In its FAQ for the 64-bit prerelease, Adobe writes:

Open source approaches to Flash

But x86 and preliminary x86_64 support for Flash obviously isn't enough in the open source world. Granted, Adobe is or has been working with some mobile phone manufacturers to offer a version for ARM (for example on MeeGo or Android), but people running a Linux desktop system on a non-Intel processor are left in the cold. Until last year, your author was in exactly this position, running Debian on a PowerMac G5. If non-Intel users want to run the official Flash player they have to use ugly solutions such as running Flash in an x86 emulator.

Luckily there are some open source programs recreating Flash functionality, of which the most well-known is Gnash ("GNU Flash"), which also runs on PowerPC, ARM and MIPS processors. It's not even limited to Linux: Gnash also supports FreeBSD, NetBSD, and OpenBSD, so it pleases a lot of people that don't want to run proprietary software on their open source operating system but have to be able to see Flash content. In March we looked at the current state of affairs of Gnash when project lead Rob Savoye talked about the project at SCALE 8x.

Although Gnash has been progressing well, the nature of the project means that it will always be chasing Adobe. Moreover, Gnash is facing some manpower challenges. The Open Media Now! foundation was started in 2008 to fund Gnash development, but, because of the economic crisis, the four full-time developers were cut back to zero, Gnash developer Bastiaan Jacques said last year. Recently, another issue appeared: a growing disagreement between the two top contributors Benjamin Wolsey and Sandro Santilli on the one hand, and Rob Savoye on the other hand.

Different development styles

It all started with a message by Benjamin Wolsey to the Gnash-dev mailing list on Friday 21 May:

At the end of his message, Benjamin announced that he would start his own stable branch of Gnash if another commit of this sort appeared, implicitly threatening a fork. Benjamin's accusations seemed to be primarily aimed at Rob, who answered that the usual policy of free software projects is that frequent checkins are good. However, Sandro Santilli added that this policy would only work if the checkins are small and do not break the test suite. Then the discussion became somewhat nasty with general accusations thrown back and forth, but Rob soon pinpointed the central point of disagreement:

Rob also defended himself against the accusation that he doesn't consider testing important: "Remember, I wrote the majority of our testsuite, so I think it's fair to say I consider testing important." But he also wants to focus on new features and he has the impression that this doesn't work when the "stable branch" has to remain stable all the time:

John Gilmore tried to get the two parties back together behind their common cause ("We need each other, guys"), and Sandro suggested to use an experimental branch for code that breaks things.

However, because Benjamin reverted one of Rob's commits and threatened to do it again in the future, Rob removed Benjamin's commit rights to the Savannah repository for Gnash, because he doesn't want to "allow a power-hungry developer to continue to reverting my changes." In the meantime, Sandro worked on some improvements and asked where he should commit the code: to the Gnash trunk where Benjamin couldn't review it and Rob maybe wouldn't accept the changes, or to a fork, which would make the project diverge? Sandro obviously still cares for the Gnash project and rightly fears that a fork will not be good for the common cause.

After a few nights of sleep, Benjamin, Sandro, and Rob seem to acknowledge that they have different development, project management, and communication styles, that they all made mistakes, and were too rude in their responses at some times. At the time of this writing, they were still on speaking terms on the #gnash irc channel on Freenode and were actively trying to reach a consensus and drafting some new commit rules (including "Commits shall not be reverted except as a last resort." and "No code shall be committed that causes failures in existing tests."), so this whole crisis may well result in a better development process for the project.

The death of Swfdec

Another Flash decoder, Swfdec, has silently stopped development a while ago. The last stable release, 0.8.4, is from December 2008, and the last commits are from December 2009. Swfdec has been primarily run by one person, Benjamin Otte, but he seems to have lost interest, although he is still occasionally answering questions on the Swfdec mailing list. In response to a question by Puppy Linux developer Barry Kauler in January of this year, Benjamin announced the death of his project in one sentence:

The fact that Benjamin started a new job in Red Hat's desktop team in January of this year is surely no coincidence: it should remind us that a project with just one core developer always has a fragile future because big changes in the developer's life can result in less time to work on the project.

A new open source Flash player

Development of Gnash and Swfdec was done using reverse engineering because Adobe only offered the SWF specification with a license that forbids the use of the specification to create programs that play Flash files. In June 2009, Adobe launched the Open Screen Project which made the SWF specification available without these restrictions. This made it possible for Alessandro Pignotti to work on a new open source Flash player, entirely based on this official SWF documentation. A part of this project is based on his bachelor's thesis at the university of Pisa, called An efficient ActionScript 3.0 Just-In-Time compiler implementation [PDF].

The result is Lightspark, which includes OpenGL-based rendering, a mostly complete implementation of Adobe's ActionScript 3.0 using the LLVM compiler, and a Mozilla-compatible browser plug-in. Because Lightspark has been designed and written from scratch based on Adobe's documentation, it promises a clean code base optimized for modern hardware.

By using OpenGL instead of XVideo, Lightspark allows for hardware-accelerated rendering using OpenGL shaders. Moreover, this opens the path for supporting blur and other effects that are implemented by efficient shaders. Another possibility is using OpenGL textures to display video frames, which is less efficient than XVideo but more flexible. For example, it makes it possible to implement the overlay and transformation effects that Flash supports.

For ActionScript 3.0 (introduced in Flash 9), Lightspark has both an interpreter and a JIT compiler that uses LLVM to compile ActionScript to native x86 code. However, because the previous ActionScript versions run on a completely different virtual machine, Alessandro has decided to not support them. This means that currently it's not really possible to compare the performance of Lightspark with that of Gnash: while Lightspark only supports ActionScript 3.0, Gnash only supports previous versions of the scripting language.

For people that want to try Lightspark in their browser, Alessandro has released a Mozilla-compatible plug-in. When encountering an unsupported Flash file, the plug-in should fail gracefully. For now, there's only a PPA (Personal Package Archive) for Ubuntu users, but packages are being created for Arch Linux and Debian. In this alpha phase of development, the current release is more of a technological demo. Alessandro is currently the only developer, although some external contributions have started trickling in.

After the first wave of testing, Alessandro published some information on the plan for the next releases. A stability release with no new features is planned for the first week of June, while release 0.5.0 will be focused on YouTube support. He also clarified that his current implementation only works on x86/x86_64 because of some assembly code, but he welcomes ports to other architectures:

The Gnash developers have been talking with Alessandro about joining their efforts, but he decided to work on Lightspark because it was very difficult to include an optimizing JIT compiler into the existing Gnash architecture. That said, code sharing or even a closer collaboration between the two projects certainly seems possible. Alessandro has already said that Lightspark's code could be integrated with Gnash in time when it's good enough, and Rob would like to add support for using Lightspark in Gnash to handle AVM2, the ActionScript virtual machine that Adobe introduced in Flash 9. If this idea is implemented, Gnash could essentially hand off all ActionScript 3 functionality to Lightspark.

Conclusion

Although most free and open source proponents agree that Flash is a bad thing and that it should be replaced by open web technologies such as HTML 5, the transition to an open web will happen slowly as all evolutions in the computer world do. Moreover, we are stuck with a lot of existing Flash content that should remain accessible. Therefore, open source Flash projects like Gnash and Lightspark will remain important for many Linux users for years. There is hope that the Gnash developers will reach a consensus on their development model and hopefully Lightspark will not face the same fate as Swfdec. For something as critical as Flash is to many users, more developers for both projects could certainly help.