Slashdot Mirror
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."
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.
... 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.
We suffer more in our imagination than in reality. - Seneca
> 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.
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.
/at/all/ and hit the forums--sure enough, there was a solution to that /and/ the sync issue. I was ecstatic!
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
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.
But install Firefox first
Summation 2
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 :-(
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.
9 4
In case anyone is interested, or just too lazy to look themselves, here's the link
http://www.ubuntuforums.org/showthread.php?t=1865
Summation 2
Assuming you're not trolling...
... er Windows on Windows when 16-bit device drivers were the norm].
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
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
Someday, I'll have a real sig.
Is this GNUFlash the same as Gnash?
factor 966971: 966971
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.
Score -1, Joke Flew Over Head
It's a Futurama reference.
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)
Guvf vf abg n EBG zrffntr
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.
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.
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.