Adobe Flash Player For Linux
- x86 32-bit Plugin Version: Flash Player 10.1 (10,1,53,64) (.tar.gz, .rpm, .deb, APT and YUM available); x86_32 only
- x86 32-bit Debugger/Standalone: Flash Player 10.1 (10,1,53,64) (.tar.gz file contains debugger version of plugin and both release and debugger version of the GTK standalone player); x86_32 only
x86 64-bit Linux Plugin, Alpha "Better than Nothing" Version: Flash Player 10 (10,0,42,34) (.tar.gz file contains x86_64 only)
- September 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- August 2009
- May 2009
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- May 2008
- April 2008
- December 2007
- October 2007
- August 2007
- June 2007
- May 2007
- April 2007
- March 2007
- January 2007
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
Archive for August, 2008
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:
- 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.
- 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.
- Place a hard requirement in the binary to link to libcurl.so.4, thereby freezing out any distros that still use libcurl.so.3.
- Manually load the required cURL functions at runtime.
- 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.
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).
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:
- 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
- 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.
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.
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’