So far, this is a Debian move. But that may influence other distributions. From reading various sources and bug trackers, it looks like more distributions are evaluating the idea (or perhaps just fielding questions from users who are not up to speed on the issues but who have read the headlines).

There are already enough challenges in trying to produce a single binary that runs across as many Linux distributions as possible. But who knows? Maybe this will whole episode blow over like so many audio APIs.

Pictured: the next big thing-- an 80-bit CPU; but 64 bits will have to do for now

So we have this x86-64 version of the Linux Flash Player available for those Linux users who have moved on to fully 64-bit computing environments. Go get it now on Labs. Be advised that this is pre-release quality. We hope to receive useful feedback about what areas need to be improved. You can help. You can report bugs at the Flash Player bug tracker. Hey, it gets results-- the 64-bit issue is approaching resolution. Or you can try the customary drive-by bug report in the comments section ("I tried it on XYZ distro and it didn't work!") which is almost guaranteed to help no one.

I feel a bit sentimental about it all. It's weird, but I think I'm going to miss the hundreds of comments on every post gently requesting a 64-bit version. So don't be afraid to pop in with a "64-BIT NOW!!!1!!" comment every so often, you know, just for old time's sake.

• SWF spec
• FLV spec

Here are some of the things added, changed, or corrected:

• new DefineBitsJPEG4 tag (90), with deblocking filter


• new DefineFont4 tag (91)


• described how to embed Speex into SWF and FLV


• described how to embed XMP metadata in FLV


• new flags in the FileAttributes tag describe whether a SWF requires the new 'gpu' or 'direct' WMODEs (only useful when running a SWF in a standalone player where there is no encompassing HTML to specify WMODE)


• new flag in DefineShape4 describes whether the shape uses fill winding rule


• rearranged some chapters to (hopefully) make the SWF spec flow better


• revised DefineBitsJPEG2 and DefineBitsJPEG3 to mention how they can be used to store GIF and PNG data as well as JPEG (as can the new DefineBitsJPEG4 tag; yes, the tag names are a bit misleading, but they're a bit too entrenched to be changed now)


• revised description of the Flash Screen Video v2 codec format


• in F4V, several signed values were incorrectly marked as unsigned


• fixed description of Flash ADPCM (initial predictors are signed, not unsigned; block size was off by 1)


• both documents now thoroughly describe which parameters (channels, bit resolution, sample rate) are fixed or flexible depending on the audio codec


• the FileAttributes tag came about in SWF 8 rather than SWF 1


• fixed the FileAttributes tag, which specifies a Metadata data structure -- not a SymbolClass -- with the hasMetadata flag


• in ButtonRecord and PlaceObject3, list the correct codes for the difference, add, and subtract blend modes


• PlaceObject3 tag description was missing a bitmap caching byte (should have been there since SWF 8 spec)


• in FillStyle, a GradientMatrix is also present for fill style 0x13


• SWF spec now uses "opacity" instead of "transparency" in many places in order to more accurately describe blending behavior


• clarified the maximum length of a SWF file


• fixed several examples


• fixed numerous inconsistencies in the Actions chapter

Thanks to Michael, Baptiste, both Benjamins, Bobby, Amol, Cody, Matthew, Romi, and anyone else I might have missed who also offered corrections and suggestions for improvements.

Well, that's really all I have to say at the moment. Release announcements for final Player versions are always a tad anticlimactic since we have already been doing beta and prerelease work for months. Though it should be noted that the Linux download page now hosts .deb packages in addition to .tar.gz and .rpm.

Also, I neglected to mention that a new Flash Player release candidate (designated 10.0.12.10) is available for download. You shouldn't notice much difference with this RC vs. the previous RC. Of course, I expect there will be users for whom this RC changes everything, whether for better or worse. That's just how it is in this Linux game.

Links:

• Flash Player Release Candidate (10.0.12.10)


• Mozilla.com -- download the Firefox 3.0.2 Linux browser for your preferred language

We started using cURL during the Flash Player 9 development cycle. At the time, we did not assess that cURL was widespread enough to link to it dynamically. So we included it in the binary, as permitted by the cURL license.

During the Flash Player 10 development cycle, we decided to make cURL the end user's responsibility, i.e., dynamically link to cURL, just as we do with a number of other libraries. In doing so, it's one less thing for us to manage internally. Plus, end users can manage cURL-related updates and bug fixes themselves. But wouldn't you know, there are problems with this approach. There are 2 versions of libcurl.so floating about in the wild: libcurl.so.3 (corresponding to cURL < 7.16) and libcurl.so.4 (corresponding to cURL >= 7.16). Most modern distributions come with the latter. But a few stragglers (that we are still committed to support) are still using the former.

A few possible solutions:

1. Build and distribute 2 separate binaries, one for libcurl.so.3 and one for libcurl.so.4, thus doubling our own internal testing efforts. Heh, naw, I don't think so.
2. Place a hard requirement in the binary to link to libcurl.so.3. Many distros that have libcurl.so.4 have a symlink from libcurl.so.3.
3. Place a hard requirement in the binary to link to libcurl.so.4, thereby freezing out any distros that still use libcurl.so.3.
4. Manually load the required cURL functions at runtime.
5. Sprinkle magic open source pixie dust on the Flash Player (solves all problems, don't ya know). Can you say "nonstarter"?

For the most recent release candidate of Flash Player 10, we opted for choice 2. This seemed to work for most distros except, most notably, Fedora systems which did not feature the symlink from .so.3 -> .so.4. Apparently, there's another reason not to rely on this method, though. The cURL functions are reportedly version-checked so that if the Flash Player links to libcurl.so.3, we are not certain we will actually be getting the most recent code present in libcurl.so.4.

The next thing we are going to try is option 4-- manually load the library, the same as we already do with ALSA and OpenGL. We will use dlopen() and dlsym() to load required functions from libcurl.so.4. If that library is not there, fall back to libcurl.so.3. Look for this behavior in the next release. If that library is not there... why not? Oh, and refuse to load the Flash Player in that circumstance.

I know many users are frustrated that we seem to be spending time on what might be perceived as minor issues when there are certain "bigger picture" items that are a little more visible. Believe me, we share that sentiment. Maybe one day, more of these little items will be standardized so we don't have to use so much developer time making sure 1% of the Flash feature set works correctly on Linux.

1. mm.cfg: user-local configuration file; lives in user's home directory on Unix systems and is largely only useful when using content debugger versions of the Player
2. mms.cfg: system-wide configuration file, designed to allow administrators to set policy for all users on a system; lives in /etc/adobe on Unix systems

There is a lengthy guide available that describes all of the various administration features and what the mms.cfg can do for you.

The reason I bring this up is that there is a new option in mms.cfg that will be of use to Linux users: "OverrideGPUValidation". Pursuant to the need to have such stringent rules for validating whether the Linux Flash Player can use the GPU. If you wish to force the Flash Player to bypass its GPU validity checks, add "OverrideGPUValidation=true" (without the quotes) to your mms.cfg.

But please don't expect the option to be a magical speed boost option for the Flash Player as a whole. Reread the original post on the matter to understand where GPU acceleration helps and where it doesn't. And if you are planning to ask about Xv support, read the post again until the message clicks.

• Camera input works a whole lot better (V4L1 and V4L2 cameras both work; V4L2 cameras don't peg the CPU anymore)
• Software fullscreen performance is vastly improved
• Faster, more stable windowless mode (but be sure to use very recent browser builds)
• SSL now handled through NSS instead of flashsupport-OpenSSL alliance
• White speckles are gone from video playback
• Important stability fixes (fewer crashes)
• Still not 64-bit native, just to get that out of the way

We tested the new NSS stuff on various popular [32-bit] Linux distributions and found that all the necessary libraries are present. If the NSS and cURL libraries are not present (as described in the previous post), Flash Player will refuse to load.

• cURL
• Mozilla's Network Security Services (NSS)
• Further, glibc >= 2.4

To what end? Most notably, the Linux Flash Player binary will no longer need to rely on a separate module called flashsupport in order to support secure connections. Supporting OpenSSL was the original motivation for creating the flashsupport library. We are moving to Mozilla's NSS which ought to be installed alongside Mozilla.

Will libflashsupport continue to be supported? Partially. Flash Player 10 will no longer care what libflashsupport.so has to say about SSL. However, it will still pay attention to the sound output functions (fpx_soundoutput_*) so that end users can continue to implement support for an ever-growing number of Linux audio APIs. The camera input functions (fpx_videoinput_*) were never implemented and that will not change now. Hopefully, the revised Video4Linux camera support in Flash Player 10 will solve many Linux camera problems (V4L1 will be supported in the final and V4L2 will no longer chew up all the CPU time).

Thanks to the many people who reported camera information in my last blog post. I guess YUYV is the most important colorspace out there. Here's another end user query: What glibc version do you have on your current Linux system(s)? And what distro is it? And how on earth did you figure out what glibc version you have? For such an important part of the system, it sure is hard to find a consistent method to query this information. A little searching has revealed these 2 methods:

• DEB-based systems: 'dpkg -l | grep libc6'
• RPM-based systems: 'rpm -q glibc'

Coworkers passing by are beginning to think I'm somewhat vain. Don't ask about that sumo camera. Just... nevermind.

Anyway, the second beta of Flash Player 10/Astro includes native support for cameras conforming to the Video4Linux v2 API (V4L2). The support is not complete, however, owing to the fact that there are dozens of different colorspaces that a V4L2 camera can provide to a user application. I suspect that this is a manifestation of the do-it-yourself spirit of Linux, i.e., if you need support for a particular format, you need to code it yourself.

So the first pass at V4L2 support in the Linux Flash Player contains handlers for quite a few different pixel formats. Only 2 of them have been tested so far. (I should point out that, of all the cameras in the picture above, only 2 work in V4L2 and also output a usable format.) The rest of the formats were just implemented blindly.

So I'm hoping to get your help in testing these formats.

My corporate masters have authorized me to release the source code for a small utility to gather basic data about a V4L2 camera:

• Source code, build instructions included; or if you're not comfortable with building...
• Pre-compiled x86_32 binary

An example run:

$ ./v4l2-formats /dev/video0

/dev/video0 is a V4L2 device named 'VF0410 Live! Cam Video IM Pro'

/dev/video0 is capable of video capture

/dev/video0 is capable of streaming capture

/dev/video0 supports 'YUV 4:2:2 (YUYV)' (raw format, V4L2_PIX_FMT_YUYV)

/dev/video0 supports 'MJPEG' (compressed format, V4L2_PIX_FMT_MJPEG)

Please download the utility and run it on each /dev/videoN device you have on your system. You will ideally have one such device for each camera attached to your system: /dev/video0, /dev/video1, etc. Then, go ahead and post the results in a comment below.

Also, it would help if you could test out the V4L2 capabilities of the current Flash Player 10 beta and let me know, along with the foregoing technical data, whether or not your camera gives you a picture through Flash, without crashing, and if it looks correct. Check out this snowfall SWF for a good example.

One more thing: If you include your email address in the form's email field (not in the actual message content), and you report that your camera does not work correctly, I may contact you directly if I deem that you could be useful for collecting more data.

Technical notes: The official documentation recommends VIDIOC_TRY_FMT in order to determine camera capabilities. In my experience, VIDIOC_TRY_FMT lies. I have a camera that claims to support every format in V4L2. I found VIDIOC_ENUM_FMT to be more reliable.

Great news: Thanks to the Firefox team, this issue has been solved. The fix has made its way into the Firefox nightly builds. You can download them at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/.

The first build I know of that contains the fix is for 2008-07-08. So start with that one or later, until the next formal Firefox release. Ideally, wmode-related crashes should now be entirely Flash's fault. But please, before reporting such crashes, be sure (using the About Firefox dialog) that you actually are using one of the very recent builds. And it wouldn't hurt to be certain that you're using the latest beta of the Flash Player by checking the "about:plugins" URL in the browser.

I'd like to give a shout out to my Turkish open source pal, İsmail. We didn't forget about you!

Windowless Mode

Oh yeah, this beta also introduces some other features that may be of interest to some people. There's this thing called windowless mode, a.k.a. wmode, a.k.a. transparency, a.k.a. proper stacking order, a.k.a. DHTML/JS menus unroll over a SWF vs. under, such as on the main Adobe website:

A.k.a. fullscreen Flash overlay ads! Yes! They're on Linux now. Let me tell you, I have never been so happy to see one as when I first got one to work in Linux. I suspect the novelty will wear off rather soon.

To be clear, there are 3 major modes for SWFs embedded in webpages: 1) Windowed mode, which is the only one supported by the Linux Flash Player up to this point; 2) windowless/transparent mode; 3) windowless/opaque mode. CommunityMX has this great, simple page that illustrates the differences between the 3 modes. (There are also 2 new wmodes introduced in Astro -- direct and gpu -- that are already supported in Linux where allowed by hardware.)

Thanks to both the Firefox and Opera teams for their support in implementing wmode. That's right-- this feature will work on both Firefox and Opera on Linux. For Firefox, you must have version 3. For Opera (as of this writing), you will need the latest beta of 9.50 Opera 9.50 release. Thanks also to Swfdec for implementing this feature concurrently, helping to attack wmode from many angles and bring Linux web browsing up to ~2002 standards.

Be advised that there are still some wmode-related problems, most notably this crash issue. Please report any other consistently crashing URLs.

Updated Camera Support (V4L2)

There is still some work to do on V4L2 and I will need some help with it. You might be able to help me with it, too. Details to come in a separate post.

Bonus! You can finally select from among multiple cameras installed on the system:

Oh hey, the dialog is localized in another new language: Swedish. Which brings me to...

Extended Language Support

Speed and Stability

Go. Get testing.

Starting in version 9.0.115.0, the Flash Player was able to display fullscreen content with GPU assistance. This is done via OpenGL facilities.

Starting in the most recent Astro Beta, Flash Player supports new GPU acceleration modes. This acceleration doesn't automatically speed up legacy content. Instead, new SWF content has to be authored specifically to take advantage of this. Tinic Uro has an excellent overview of the capabilities and limitations of this new feature in his blog post, "What does GPU acceleration mean?"

Tinic's post mentions the lofty GPU requirements for Windows: "You will need at least a DirectX 9 class card. We essentially have the exact same hardware requirements as Windows Vista with Aero Glass enabled." Obviously, the Linux version isn't going the DirectX route. It uses OpenGL and we require the following features before we consider honoring the new SWF GPU features:

• GL_ARB_multitexture
• GL_EXT_framebuffer_object
• GL_ARB_shader_objects
• GL_ARB_shading_language_100
• GL_ARB_fragment_shader

Also, for fullscreen OpenGL acceleration, the Flash Player requires that the client glx vendor string be something besides "SGI". Official drivers from, e.g., ATI and Nvidia hopefully do not have "SGI" in this field (check the 'glxinfo' command, for this string and for the extensions listed above). We have this logic in place to detect whether software rendering is in place and fall back on our own software fullscreen in that case. There are more robust ways to detect software rendering but we have seen crash problems on a number of distributions, possibly with outdated libraries.

Another important note: Compiz and GPU-accelerated Flash on Linux do not mix. The Flash Player still works if you have Compiz as your window manager; you just won't be able to make use of GPU-accelerated features. This is a shame since Compiz is coming with the basic installation of various Linux distributions. Unfortunately, things get unstable when trying to do GPU acceleration in SWFs running under Compiz.

• FAQ regarding hardware acceleration: Why doesn't the Flash Player on Linux user the X video extension (Xv)?
• Answer: Because Xv scales YUV data. Flash Player operates on RGB data.

For the uninitiated, many video codecs operate in a YUV colorspace. Unix/X11 has an extension called X video that allows hardware scaling of YUV images. This is a very mature system on Linux which has allowed seamless, low CPU usage, fullscreen video playback on Linux for many years. Unfortunately, the Flash Player can not easily make use of this since Sorenson, On2, or H.264 video data -- even though it is decoded as YUV -- has to be converted to RGB and possibly combined with other graphical elements. This is why RGB scaling via OpenGL is the future of Flash.

Except if Compiz is acting as window manager.