Interview With Linux Flash Player's Lead Engineer

An anonymous reader writes, "Ryan Stewart of ZDNet has an interview with Mike Melanson, the lead engineer behind Adobe's upcoming Flash Player 9 for Linux. It covers what the plans are for the player, what kinds of things won't be in the Linux player that are in the other players, and ways to give Adobe input on the Linux player."

Re:no hard questions asked....

[damiangerous]

That's not a comparable situation. The PDF format specifications are freely available for anyone to use. Not so with Flash. The specifications are available, sure, but the license to get them includes a provision about not creating a player. Therefore the only way Open Source players can exist is through reverse engineering. Some do exist though, like GNUFlash, but it's not an easy task.

Allow me to rain on your parade...

[Qbertino]

... but one of the reasons Flash is so successfull is that it's considered the securest plugin (tm) in existance. Flash allways has been extremely picky about security - that's one of the reasons why it's the easiest cross-plattform VM to deploy in corporate enviroments.

Open source player.

[phoebe]

It does not sound like he has heard of Gnash:

Gnash is a GNU Flash movie player. Till now it has only been possible to play flash movies with proprietary software. While there are a few other free flash players, none supports anything higher than SWF v4 at best. Gnash is based on GameSWF, and supports many SWF v7 features.

Features

1. Runs standalone: Gnash can run standalone to play flash movies.
2. Firefox plugin: Gnash can also run as a plugin from within Firefox.
3. SWF v7 compliant: Gnash can play many current flash movies.
4. XML Message server: Gnash also supports an XML based message system as is documented in the Flash Format specification.
5. High Quality Output: Gnash uses OpenGL for rendering the graphics.
6. Free Software: Gnash is 100% free software.

Re:no hard questions asked....

[Anonymous Coward]

> Nothing is stopping "the community" from writing an open source Flash player just like people did with the xpdf reader for PDF documents

Errr, yes there is: The flash documentation is explicitly not allowing you to write a player based on it.

Re:Allow me to rain on this parade...

[Sancho]

You can get in-sync audio by using alsa-oss. I'm sure if you Google around, you'll find the solution to your problem.

The out-of-sync sound on Linux annoyed me to no end until I installed Ubuntu on a notebook to see what all the fuss was about. I was having problems getting Flash sound to play /at/all/ and hit the forums--sure enough, there was a solution to that /and/ the sync issue. I was ecstatic!

The sound synchronization

[Rik Sweeney]

The only problem I have with the current Linux Flash is that the sound is out of sync with the picture. This makes using Google Video or You Tube a bit a hassle. So my question is

Has the sound synchronization problem been fixed?

On a side note, if you don't like flash ads with screaming sound, just install Flash Block [mozdev.org].

But install Firefox first [mozilla.com]

Keyboard

[protomala]

The major problem I got with Flash for Linux is that keyboard simply don't work! There are a lot of mini-games out there that use keyboard for controlling the character, but I get nothing trying all the keys. Maybe it's because I'm using a pt-BR (ABNT2) keyboard, but it dosen't seem to be a problem for Flash Player in Windows :-(

Re:Allow me to rain on this parade...

[Rik Sweeney]

You can get in-sync audio by using alsa-oss. I'm sure if you Google around, you'll find the solution to your problem.

In case anyone is interested, or just too lazy to look themselves, here's the link

http://www.ubuntuforums.org/showthread.php?t=18659 4 [ubuntuforums.org]

Re:64 bits please...

[tomstdenis]

Assuming you're not trolling...

You can't call 32-bit code [that is, code compiled with 32-bit pointers and registers in mind] directly from a 64-bit application. Even if you don't use 4GB of memory you still have 64-bit pointers [well 48-bit on AMD64]. Then you have registers. The ABI [application binary interface] for x86_64 specifies that you pass a certain # of arguments as registers and not on the stack, etc.

You need a "thunking" layer to call 32-bit code [like WoW ... er Windows on Windows when 16-bit device drivers were the norm].

Assuming Flash isn't all spaghetti code it should really be a matter of just rebuilding with a 64-bit compiler against 64-bit libraries.

Tom

Re:no hard questions asked....

[doti]

Is this GNUFlash the same as Gnash [gnu.org]?

Why won't they support Gstreamer?

[Anonymous Coward]

The current (but outdated) Flash player 7 for Linux has big problems with audio/video synchronization. They are hoping to solve this by getting rid of OSS support and using ALSA exclusively. This is a good move. But I also see that they do not plan to support the current version of Video For Linux (V4L2), although the older V4L is being phased out of the kernel. And in that engineer's blog, I saw a brief statement about the fact that the Flash player will not use Gstreamer. This is bad.

Why don't they use Gstreamer? This would solve the synchronization issues (the current gstreamer-0.10 is very good at keeping everything in sync, unlike other multimedia frameworks) and it would also provide good support for both V4L and V4L2. In addition, it would provide a good cross-desktop integration, because Gstreamer will be supported in KDE4 (through Phonon) and in GNOME.

Currently, Gstreamer allows me to configure multiple sound cards correctly and decide in one place which one is the default one. If the new Linux Flash player ignores Gstreamer and codes for ALSA and V4L directly, then I bet that it will have problems picking the right sound card automatically. And it will probably ignore my gstreamer filters as well, which is a pity. Not to mention that it would force me to keep the obsolete V4L code in my kernel instead of using V4L2 (gstreamer would do the switch transparently), just like Flash Player 7 forces me to keep the OSS API (alsa-oss) while all other programs have moved to a more mature interface (ALSA).

By the way, I have read some comments in the blog saying that Gstreamer should not be used because its API or ABI is not stable. I say: bullshit. There were some incompatibilities while moving from gstreamer-0.8 to gstreamer-0.10, but this was a long time ago and the interfaces have been stable since then. If I remember correctly, the Gstreamer developers stated that they intend to keep the interfaces stable now. So those who reject Gstreamer for that reason are just spreading FUD.

Re:An obscure database known as MySQL

[the unbeliever]

Score -1, Joke Flew Over Head

It's a Futurama reference.

Re:Mike Melanson?

[sconest]

From the article:
I started doing some homework and began contributing to, and occasionally leading, various multimedia-related open source projects and efforts, such as xine, FFmpeg, and MPlayer.
So I'll say yes (at least for FFmpeg)

Re:64 bits please...

[gmack]

Except that the difference in bytesize is not the only differnece between x86 and x86_64. X86_64 also fixes the register starvation issues that have plagued x86 since the XT days. Less register swapping often means more efficianct use of the rest of the CPU.

The reason why 64-bit Flash is not available yet

[Wesley Felter]

Flash Player 9 is not just a C program any more. It now has a JIT, and so they have to write a separate JIT backend for every architecture they want to support (although an interpreter might be a good stopgap). They haven't written the x86-64 JIT yet, and it's going to take time for them to do it. Sure, it might have been better if they delayed the release of Flash Player 9 until after they developed x86-64, PPC, ARM, IA-64, MIPS, and Alpha JITs, but it's too late now.

Re:Why won't they support Gstreamer?

[Anonymous Coward]

Why are they fleeing gstreamer like plague? I see at least three reasons:

1. Because gstreamer's performance sucks; there is absolutely no excuse for using ten times more resources than mplayer/xine for decoding a MP3;
2. Because after 7 years (yes, the project started even before Windows XP and OS X were released!), it still is brittle (look yourself at the serious bugs fixed two weeks ago [freedesktop.org]);
3. Because no serious video player uses it (there must be a reason...); and even in simple audio apps, see point 1. Why would Adobe be a testbed for a library that didn't prove to be reliable video-wise?

you know not what you speak of

[r00t]

You're clueless, and you just let everybody know it.

64-bit code does indeed run faster. The data may be bigger, but the code (.text segment) is actually smaller. There are more registers. The calling convention for 64-bit Linux can pass up to 6 integers in registers. Stack accesses are greatly reduced. This is enough to be noticable to casual observation.

A typical modern Linux has only a handful of 32-bit binaries, certainly not including the web browser. OpenOffice.org is even 64-bit now. Some systems don't even include the 32-bit libraries anymore, thus being unable to run 32-bit apps.

Running 32-bit stuff is gross. It's like running 680x0 code on a Mac, or 16-bit DOS apps on Windows. Normal people hate that.