Still waiting for Flash

Those of us who were using Linux full-time around the turn of the century will remember that the state of web browsing on Linux was a little scary then. The only real option available was the binary-only Netscape 4 client; it was buggy and old. It really seemed like the web was going to move forward without Linux, and that there was not a whole lot we could do about it.

Things have improved somewhat on that front; we now have a few top-quality web browsers to choose between. At the same time, though, one might be forgiven for thinking that we are heading back into a similar situation, but involving Flash this time around. For all practical purposes, there is only one viable option for Flash on Linux: the binary-only plugin provided by Adobe. But that plugin is not just proprietary software; it also is somewhat old and buggy, and there is nothing we can do to fix it. For an increasing part of the web experience, we still have a second-rate, proprietary platform.

When one thinks of Flash, naturally, one thinks of video sites like YouTube. But there is more to the Flash experience than silly videos and obnoxious advertising. Some parts of Google are heavily into flash, as can be seen from that company's finance sites or analytics offerings. Your editor's children will attest that there's no end of game sites which require Flash, and for which the Linux plugin fails to work properly. Looking for any way to reduce the total amount of time spent in airplane seats, your editor recently investigated "around the world" tickets; that search ended up at this travel planning site which, of course, requires Flash. And so on. Like it or not, Flash is the language in which an increasing number of interactive sites are being coded, and Linux does not have proper support for it.

With this in mind, your editor decided to give the recently-announced Gnash 0.8.2 release a try. This release was billed as the first beta version of Gnash, so there was reason to hope that it would be something close to a true solution to the Flash problem. In reality, Gnash is a step in the right direction, but the Flash issue will be with us for some time yet.

For now, the acid test for a Flash player would appear to be YouTube, so that is the first place your editor went. The experience there was mixed. It is, in fact, possible to watch YouTube videos using the Gnash Firefox plugin. Hearing them is another matter, though; they all played silently. It would not be surprising to learn that getting audio is a matter of filling in a missing codec - but would sure be nice if the software were to say something to that effect. Pausing and playing the video worked, but skipping around in it did not. Playing videos from other sites was uniformly unsuccessful.

The "around the world" calculator appeared to load properly, but then took off as if somebody were punching all of its buttons at once. Charts on Google sites are uniformly blank. Some flash games mostly worked, others showed more input-related confusion. Few of them were truly playable. On the other hand, Flash "intros" and advertisements mostly work as intended - just what your editor wanted.

So Gnash is not really there yet. In truth, this software is not in a condition where the use of the term "beta" makes sense; there is a lot of work yet to be done. There are few of us clamoring for support for more obnoxious advertising - especially among the LWN readership, as your plentiful emails over the last couple of months have made clear. What we want is working support for the useful Flash applications out there - and there are a few of those at this point. Gnash does not, currently, provide that support. (Your editor also tried out Swfdec 0.6.0, with generally worse results).

That said, it is clear that a lot of work has been done to get Gnash to this point. Your editor has no real way to judge how much more is required to get full support for even Flash version 7; chances are it is not a small job. Needless to say, support for newer versions of Flash will require even more work. But there now appears to be a solid platform upon which that work can be done, and that is an important start. Gnash has the look of a project which has overcome some of the biggest initial hurdles and is now setting a pace to finish the job. With luck, it will have reached the point where the fact that it almost works will inspire new developers to come in and fill in the remaining pieces.

Adobe has the ability to make this job a lot easier. Your editor has heard, informally, that the company has taken a less hostile position toward the Gnash developers than it had in the past, but it certainly is still not helping them. The Flash specifications are not available to anybody trying to create a Flash player, and, unsurprisingly, the Flash EULA forbids any sort of reverse engineering. That EULA, incidentally, also forbids running Adobe's player on any "non-PC device," including tablets and phones. That restriction suggests that Adobe sees business opportunities in the lack of a free Flash player for such systems and intends to ensure that this scarcity continues. So, despite the occasionally friendly noises Adobe has been making toward the Linux community, we should not expect a great deal of help from that direction.

Someday, people will figure out that closed standards (like Flash) are best avoided. Meanwhile, Flash is a fact of life that we will need to deal with. It appears that we are getting closer to being able to deal with it - but we are not there yet.

---

to post comments

So from what you report it sounds like the free flash player would play YouTube videos about
as well as Adobe's plugin does on my machines.  I.e. silently.

Ok, I do get sound now... after a lot of google action and manually building libflashsupport
to make it support OSS, etc even though I do have ALSA running (xmms is playing via ALSA as I
type this) on one of the two machines.  So if you count sound playing over a second out of
sync with the video I have sound with the Adobe plugin.

And both computers' Firefox became extra unstable after installing Flash.  One would almost
get the impression the whole idea was to make sure we have a bad experience unless we run IE
on Windows.

And you just know that by the time we finally have a working free flash player the hip
websites will be on to some new closed tech.  Feh.

>So from what you report it sounds like the free flash player would play YouTube videos about
as well as Adobe's plugin does on my machines.  I.e. silently.

Probably a permission issue.

But anyway, you do not need crappy browser plugins to play YouTube (thank god!), but
youtube-dl and mplayer do a better job at it, including (surprise) double-speed playing,
eating much less CPU, thanks to Xvideo, SSE-optimized decoding, and the "cleanliness"¹ of free
software projects' code.

¹Well, not every project. But given AdobeFlash and mplayer, I take a stance that the latter
would win. Closed corporate code can be really ugly actually.

http://home.gna.org/clive/

clive annihilates youtube-dl in all tests I've put it through. You might want to check it out.
Beyond that, I've had rather better luck with the VLC Multimedia plugin than the mplayer
plugin, despite using mplayer for my primary video viewing. YMMV.

> Someday, people will figure out that closed standards (like Flash) are best avoided.

I doubt it.  I expect the current general lack of awareness in this area is a long-term trend.

The ten-year trend is toward more awareness and more openness.  However, the slope is shallow.
Check back in ten more years.

I yet have to try the new gnash, but for my only use of Flash (yes, it's youtube!) swfdec
works fine. In contrast to gnash < 0.8.2. Other stuff might not work, but I believe that
owners of Flash-based sites do not want me to visit them anyway. Adobe is not an option
anyway, because they do not provide source code (nor a binary for my platform != i386).

Flash is anything but barrier-free (“accessibility”), so the sooner you forget about it in
websites that could perfectly do without it, the better for everyone. I agree that some
browser games require it, but many a  webpages just use it in places where it just is not
welcome. Have a wireframe of your new product? Well, that's ok, but that does not mean the
goddamn entire page/domain has to be a multimegabyte flash blob.

I get the impression that many sites use Flash specifically to make it difficult (if not
effectively impossible) to scrape their content.  They can also prevent you from using my
preferred browsing mode: open every interesting link in a new tab, and flip between them as
needed.  This prevents sites from collecting "marketing data" such as how long you viewed a
page before hitting the "back" button, not that that's why I browse that way.

For what it's worth, Adobe's flash plugin has excellent accessibility support on Windows, and
lets you use screen readers etc. to read flash files. AFAIK the Linux version still doesn't
have any accessibility features, unfortunately; but then again, neither does Gnash.

"Someday, people will figure out that closed standards (like Flash) are best avoided."

Not before Silverlight grabs a significant toe-hold.  :-(
In fact, Netflix subscribers might say that's already happened.

> Not before Silverlight grabs a significant toe-hold.  :-(

Leaving the politics to one side, the short-term odds of seeing a functional and compatible
free software implementation of Silverlight are better than for Flash.

Even if there was no Silverlight content on the web, Moonlight would be a useful platform for
developing certain kinds of desktop applications (Games, Educational and more) in its own
right.

Much as some of us may loath its abuses, Flash solves a need.  It provides an easy way to put
together graphically rich interactive media which is convenient to distribute.  If someone
asked for an alternative libre tool which could do the same thing, until recently I'm not sure
what I could point them to.  

"Leaving the politics to one side, the short-term odds of seeing a functional and 
compatible free software implementation of Silverlight are better than for Flash."

True for a limited definition of "free software". I'm much more willing to leave the 
anti-Microsoft politics aside than I am to leave patent law aside, and there's no way 
anyone but Microsoft and Novell will be able to legally distribute Moonlight without paying 
patent royalties to Microsoft.  That's not free or open-source software.

Hum? Software patents doesn't apply in the whole world. So saying that «nobody» can do it is
false. I'll distribute Monolight legally with no problem.

Actually it is perfectly legal in most of the world (outside USA and Japan).

I'm not quite sure if the LWN report about the CeBit inicident is correct. The police raided
the booth for *devices*, not for software. None of the pure software shops have been addressed
so far.

I don't want to adress here if it's sensible to have patents on hardware implementations of
algorithms; simply want to state that this is the case in Europe. And that seems to be the
legal background for the CeBit incident, not any software patent.

For what it's worth, Gnash works fine with sound here.  It's likely an issue of your specific
audio setup.  The sooner the Linux world finally freaking standardizes on a single
application-level audio interface (e.g. PulseAudio) the better.

Here too. Gnash 8.1 (Ubuntu 7.10) plays youtube (and similar site) videos fine, except that it
pegs the CPU at 100%.

I have also found that most simple (aka "annoying") flash animations play fine. Unfortunately,
I don't think I have yet found a useful flash tool that works. Perhaps that has improved in
8.2, which I will presumably have in about a month when I upgrade to the next Ubuntu release.

Please, no. Not another sound daemon. They suck, introduce unneccessary latency and generally
bogs down performance. OSS4 works fine, has extremely low latency, *is standard* on every
other UNIX system but Linux and is released under BSD license; what more could one possibly
want? Except the death of ALSA of course...

Your saying that PulseAudio sucks pretty much guarantees that you haven't 
tried it.

PulseAudio is brilliant.  I love being able to send music to my headphones and still have the
phone ring over my speakers.  And being able to use my Bluetooth headset for Ekiga.  And being
able to have my music quiet but my IM notifications at a regular volume.

OK, truth be told, I don't quite love it yet...  There are still some warts to smooth out.
But I'll go out on a limb and predict that in a year you'll wonder how you ever got by without
PA.  It's just that useful.

(this is coming from a guy who would immediately turn off esd and arts first thing after
installing any new system)

Come to think of it, PA's flexible support for sane APIs could help ALSA to the exit over the
next few years.  That would be sweet.

Hang on, so OSS4 provides network-transparent audio, RTSP streaming, 
up/downsampling and format conversion, per-application 
automatically-preserved volume levels and audio source/sink bindings, and 
a command-line interface and plugin infrastructure safely extensible by 
arbitrary users without any special privileges?

If it does, this is an excellent example of how to do *way* too much 
inside the kernel.

If it doesn't, this is not equivalent to PulseAudio.

>>Hang on, so OSS4 provides network-transparent audio, RTSP streaming,

Nope, these two are a special case, and are the only reason I can see a sound server for. When
you want to send out a network sound stream. Then again, mpd seems to do a perfect job of
this.

>>up/downsampling and format conversion, per-application automatically-preserved volume levels
and audio source/sink bindings

Volume levels yes (as long as the vmix API is used, like you're supposed to), and channel
levels as well. I'll have to get back to you on all the other stuff, but chances are good it's
supported.

>>Shell

No, why should it? Again, the only conceivable reason I can see for a sound server is when you
want to stream stuff over a network. Else, it just introduces more lag, which is the thing I'm
opposed to (I'm an amateur musician btw, so I need that low-latency).

So, er, why should it need to be extensible? I note the absence of a 
replacement for the PulseAudio plugin system in that list as well.

I guess if you want an all-in-kernel unextensible replacement for part of 
PulseAudio then OSS4 provides you with that.

(Oh, and mpd isn't a sufficient replacement either. Thanks to the ALSA 
PulseAudio plugin, *every* app you use can get its output routed via 
PulseAudio, which is very useful on remote systems. mpd, while nifty, does 
nothing of the kind, nor should it.)

So you have listed one benefit which cannot be achieved by OSS4. Should you by some reason run
a thin-client based solution ala LTSP and you need sound, OSS4 is not quite up to the task.
Fair enough.

As for extensibility; Why would you ever want that for sound? What exactly is it that you need
scripting for? If you need to redirect the streams like PulseAudio does, then yes, PulseAudio
*IS* the way to go. But most *doesn't* need this, most need/wants what we have today+reliable
software mixing+per-app volume controls. That's it, and OSS4 provides for that. I don't see
any advantage at all to go with PulseAudio over OSS4 as default, given the increase in
latency.

Again, prove me wrong and I'm happy to admit to my ignorance. But right now PulseAudio sounds
like yet another soundserver hack, which doesn't help the situation at all...

Finally, read this page, it explains my feelings on why OSS4 is the way to go:
http://insanecoding.blogspot.com/2007/05/sorry-state-of-s...

If you can't figure out why people might want runtime modification of 
behaviour in ways unanticipated at kernel-build time (!) then there's not 
much I can do to convince you, although it might help to point out that 
there are an *awful* lot of people with e.g. service contracts that 
*forbid* recompiling kernels. (Also, hacking the kernel to add some new 
feature is a hell of a lot more risky than adding a new plugin, an 
unprivileged userspace shared library.)

I'm questioning why it has to be default. PulseAudio seems to have it's uses, yes, but the way
I see it;

"Oh crap! We have twenty different incompatible APIs in the Linux sound arena! It's a friggen
mess!"
"... Darnit! Wait, let's create a twentyfirst incompatible API which can wrap around all other
APIs! That'll solve everything!"
"... BRILLIANT!!!"

... Isn't that the kind of think that got us into this mess in the first place? Isn't it
better to deprecate *ALL* other APIs but three (OSS4, OpenAL and PulseAudio), and take it from
there? OSS4 because it's the best API available today for most apps, and is portable to most
other UNIXes (sans OSX). OpenAL because it works on Win+MacOSX+Linux, making it the best
cross-platform API today. And finally, PulseAudio for those who would need it. It'd solve
quite a few headaches on that arena. 'Nuff said.

Actually the PulseAudio API is going to be superseded, by, wait for it, a 
twenty-second incompatible API, in the form of the libsydney library, 
which can talk to all the others! (Note the inspired naming after the city 
where the design was done: that'll make it easy for people to remember 
what it is!)

The nicest thing about PA for me is that (with the aid of, wait for it, 
*loadable modules*) it can emulate almost every other sound server and 
talk to almost every lowlevel API out there. I didn't need to recompile 
any of my programs when I started using PA: they still think they're 
talking to esd for the most part, or arts.

The proprietory flash is old and buggy? True last year perhaps but the latest 9.0 v115 release
is the same as that for Windows and OS X. I'm not sure how much newer you'd like it to be. As
for the buggy bit, well there YMMV a bit more.

The core point that it's closed source so it can't be fixed by anyone other than Adobe is a
fine one though. I wise Gnash and Swfdec every bit of luck.

And it only works in Gecko-based browsers.

I have used it in an Opera 9.5 snapshot. But My Mileage Has Varied so significantly from
machine to machine and snapshot to snapshot that I wouldn't recommend it to anyone else.

Proprietary flash has been working extremely well on my boxen for the last year and a half. I
honestly haven't stumbled on a major bug with the exception of losing sound in UT2004 after
going to a flash website. Full screen on youtube even works, which is pleasantly surprising. 

One way or another, it does not sit well with me to be using a closed-source app frequently.
This article has encouraged me to give Gnash a shot :). 

> Some flash games mostly worked, others showed more input-related confusion. Few of them were
truly playable. On the other hand, Flash "intros" and advertisements mostly work as intended -
just what your editor wanted.

I love you, Jon Corbet.

So how do Gnash and swfdec compare to Adobe Flash speedwise?  My main desktop machine is
rather slow for modern day standards and could benefit from a (much) more efficient Flash
implementation...

I've found that the acid test for flash is Comedy Central's "Motherload".  It's a full-screen
flash app that displays video, catalogs episodes of the show you're currently watching
(usually The Daily show), you iteract with it to select things and queue up the next episodes
for it to show when it's done with this one...

And of course they keep changing it.  It used to work with the proprietary adobe plugin, but
what set of bugs you had changed week by week, then it stopped working at all...

Is there anything it *does* work with, or is it just irredeemably buggy? 
(i.e., can you distinguish bugs in the flash app from bugs in the flash 
implementation?)

I haven't really had any problems with it, except for the crashes being reported here, and (as
a developer) problems with uploads and downloads on secured sites, related to Flash not
getting session and HTTP credentials when transferring files (why in the world the player is
doing the transfer of files itself, instead of using the browser as it does for all other
comm, is beyond me...).

Oh, and a few font size differences when using system fonts instead of embedded fonts, but
that is almost unavoidable, given the differences in the system's rendering (Which both
Windows and Linux sucks at, but that is a completely other subject).

A couple of things that might help make Gnash more popular.  They may not be realistic though
:)

1) Make it either play files successfully or fail cleanly.
2) Campaign to encourage important sites that use flash to test with gnash.

The first requires technical skills, but probably less than making gnash work perfectly(!)
The second is somewhat dependant on the first, but does not require technical skills.

It's been out there for years. It's called SVG + XHTML + JavaScript + CSS.

However, few know how this could be put together in a coherent fashion, and there's no dev
tool to create an SVG animation that even remotely mirrors the ease-of-use Adobe Flash CS3
gives. And it has a bunch of other problems as well.

The pieces are there. Might need a bit work on the rough edges, but until someone genuinely
*tries* to create something with it, until support for SVG is available in *all* major
browsers (either as a plugin or natively in the browsers) and until there's a killer feature
for it, adoption won't happen.

Well, I'm a fan of the Go-Go genre of Funk from Washington DC.

All these bands use Myspace for information, samples, links, updates, etc.

The ONLY way I've found to use the Myspace pages I need under Linux is...

... Wine, Windows Firefox, Windows Flash plugin.

Except for some of the fonts not "just working", it works pretty well, certainly WAY better
than Adobe's Linux plugin, which crashes ALL THE TIME, and gnash or the other one, which just
don't work and render garbage.

Benefit: I can leave Gnash as the Linux Firefox plugin, and ONLY use the Wine one when I'm
trying to use a site that uses much flash...