Now Supporting 16 Exabytes

We are pleased to announce that there is now a version of the Flash Player for Linux that supports 16 theoretical exabytes of physical memory. This technological feat is accomplished using a bleeding edge type of processor known as a 64-bit CPU.

Zilog_Z80.jpg

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 And FLV 10 Specs

The version 10 updates of both the SWF and FLV specs are available for your inspection:

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 0×13
  • 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.

Flash Player 10 Is Live

The release version of Flash Player 10 is out there and available for download. Hopefully, it will soon be available from your favorite automated update repository since such package management should resolve the new dependencies needed for Flash Player 10.

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.

Firefox 3.0.2: The Wmode Fix

Firefox 3.0.2 is now out. Lots of security fixes. But for Linux users, the most interesting item that slipped through is “the wmode fix”– Firefox 3.0.2 fixes the problem of instant, repeatable crashes on a number of windowless-enabled websites. Upgrade quickly, at least for that reason. It’s probably most readily available through your package manager.

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:

Random Blog Post

I found this random blog post just now. What has my coworker Tinic been up to?

cURL Tradeoffs

Sometimes, the Flash Player needs to do HTTP stuff. Most of the time, it’s enough for the Flash Player to use plugin/browser functions (NPAPI) to achieve this. However, it is occasionally necessary to go above and beyond what NPAPI provides. While the Windows and Mac versions have standard platform APIs to call upon for that little something extra in the HTTP department, the closest thing that Linux has to a standard is the longstanding cURL library.

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). 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.

Windowless Mode Fix

As a reminder, Firefox 3.0.1 has a known crash problem with a wide variety of windowless mode SWFs. This has already been fixed in the Mozilla code tree and alpha builds are available for download. However, if you would prefer to wait until a new official Firefox release, you may wish to disable windowless mode in the Flash Player. You can do this (on any platform) by setting WindowlessDisable=true in the mms.cfg (which lives in /etc/adobe on Unix platforms).

Secrets Of The mms.cfg File

Did you know that the Adobe Flash Player honors a few configuration files on the user’s local file system? There are 2 such files:

  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.

10rc

Adobe Flash Player version 10rc (designated build 569) is live. Go get it. Items to observe about this build:

  • 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.

Library Expansion

Be forewarned: Flash Player 10 for Linux will have more external library dependencies. These are very new requirements that were not required in either of the 2 released FP10 beta builds publicly released so far.

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’