Back to Basics: Hardware Acceleration
Because CUDA is used to program Mercury Playback Engine, Adobe Media Encoder, and Elemental's Accelerator, the acceleration doesn't work on integrated Intel graphics or ATI graphics cards. Truth be told, as we'll discuss later, it doesn't work on all NVIDIA cards, at least not those more than 18 months old.
Bottom line on content creation and compression output: Read the fine print and buy the most recent top-of-the-line card you can find, unless you need a good excuse to take a several-hour break from editing and transcoding while your machine slowly renders the timeline or export file.
Playback
Perhaps the area rife with the most confusion, hardware-accelerated playback of content on desktop players—such as the Adobe Flash Player—use one or more "idle" components within the computer to allow a higher-quality playback experience.
With Flash Player 10.1, which has been in public beta for over seven months, the hardware acceleration uses the video or graphics card.
"Although Flash Player can display high-quality video and images by itself," a support document on Adobe's website states, "hardware-accelerated scaling uses the video or graphics card on your computer to display images and video more clearly and quickly than Flash Player can on its own."
What Flash Player is doing, especially on machines that have lower-speed or single-core processors, is allowing playback of content that otherwise would not play on the device (or would not play as well, depending on which semantic is used by those on either side of the Flash wars).
By default, Adobe enables hardware-accelerated scaling in the Flash Player 10.1 beta, in an attempt to guarantee that the majority of Flash Player users will be able to view full-screen playback of content without tweaking any bells or whistles within the Flash Player preferences.
So, you might ask, what is all the fuss about the Apple announcement of the Video Decode Acceleration framework that Jan Ozer covered yesterday? And how does it differ from the hardware-accelerated scaling that Flash Player 10.1's general beta release already covers?
In a word, optimization.
Adobe's Flash Player 10.1 beta covers both Macintosh and Windows platforms, using OpenGL for Apple's Mac OS X v10.2 or higher and DirectX 9 with VRAM 128MB for Windows.
Yet, Adobe notes, "there might be compatibility issues with older hardware and drivers." In other words, for those with older machines—a part of the market Flash Player 10.1 is supposed to address—there may be a problem with full-screen playback on some video or graphics cards.
This is typical of a generic hardware-software solution combination that is built to work across multiple operating systems and generations of hardware. But to keep the Flash Player user base happy, especially those on the Mac platform, Adobe needs to continue optimizing.
Apple's Video Decode Acceleration framework may provide this additional optimization.
"Now that the required APIs are available," Adobe representative Matt Rozen told Ozer, "we are working on an additional Flash Player release to follow shortly after Flash Player 10.1 to include this functionality for the hardware configurations supported by the new APIs."
Except this optimization will only be geared toward H.264 decoding on very specific GPUs, "such as the NVIDIA GeForce 9400M, GeForce 320M or GeForce GT 330M." If you recognize the latter two as the graphics cards that ship with the brand new i5- or i7-processor equipped MacBookPro line, give yourself bonus points.
Apple is indeed limiting the optimization potential to the newest grouping of GPUs on machines that are built with the latest processors. In other words, on machines whose CPUs may be able to handle full-screen playback without GPU acceleration.
While the intent to limit OS-level acceleration APIs to the most recent NVIDIA processors is a profitable decision on Apple's part, it rather defeats the purpose of providing full-screen hardware acceleration for late-model desktops and laptops. A bright spot, however, may be Adobe's ability to use a C programming language to allow the Mercury Playback Engine to access the mobile GPUs for its first foray into non-CUDA-based GPU programming.