Bugs can be reported and tracked here.

The combination of NVIDIA GPUs and Adobe Flash Player 10.1 enables device manufacturers to deliver uncompromised Web browsing of rich applications, interactive content and HD video with substantially decreased power consumption. With the support of the NVIDIA GeForce®, NVIDIA ION™ and Tegra™ products users will be able to enjoy a much smoother viewing experience when accessing rich content built with the Flash Platform including HD and SD video from popular sites like Hulu.com or YouTube.

In answer to any other questions regarding this feature: The above is what the press release says so that's what I'm allowed to pass along.

See the sidebar for download locations.

In other news, as you can imagine, today's xkcd comic made the rounds in the office. That's good stuff; there are layers of meaning behind those pithy stick figures. I guess this would be a good time to link back to my post about hardware acceleration in Flash on Linux and invite another round of questions that are already clearly answered in that post.

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.