In addition to learning that
Intel's UXA acceleration architecture will live on in its current form, there were a few other interesting bits of news reported as well during the X.Org talks at FOSDEM 2009. During Eric Anholt's talk some video playback/decoding improvements were discussed.
For its
xf86-video-intel driver, Intel is still working on adding support for more codecs to
XvMC along with possible support for offloading VLD to the GPU during MPEG-2 decoding. Extending XvMC was
first talked about a year ago at FOSDEM and then again during the X Developers' Summit, but as of yet no code has been publicly committed.
In addition to support for offloading more codecs / operations, Intel is also working on migrating the X-Video Motion Compensation code to using their
Graphics Execution Manager for the (in-kernel) memory management needs.
Perhaps what was most interesting, however, was confirmation that Intel is also exploring other possible video frameworks beyond XvMC. Intel has mentioned that they are looking at
VA-API and
VDPAU in particular. From their cursory examination, the API to VDPAU looks nice. Our
VDPAU benchmarks on NVIDIA hardware has been very positive and allows
HD video playback on very cheap hardware.
NVIDIA's proprietary Linux driver is the only X.Org driver right now implementing the Video Decode and Presentation API for Unix. Among the media applications supporting VDPAU are
MPlayer,
FFmpeg,
MythTV,
Xine, and
VLC Media Player. There is also a
VDPAU back-end for VA-API.
When it comes to
VA-API, this video acceleration API is actually being developed by Intel for mobile devices. VA-API support can be found for
MPlayer and FFmpeg support, but currently the only driver implementing this API is the Intel Pouslbo driver found on a few select netbooks/nettops. The Poulsbo driver though
is a bloody mess.
Seeing Intel's open-source driver implement VDPAU support would be a great addition. Intel isn't too interested in
Gallium3D video decoding or any
universal video decoding that uses the GPU's shaders. The trouble with a hardware-independent decoding method is that it will not be tuned for power optimization compared to a hardware-specific design.