Slashdot Mirror
Facts and Fiction of GPU-Based H.264 Encoding
notthatwillsmith writes "We've all heard a lot of big promises about how general-purpose GPU computing can greatly accelerate common tasks that are slow on the CPU — like H.264 video encoding. Maximum PC compared the GPU-accelerated Badaboom app to Handbrake, a popular CPU-based encoder. After testing a variety of workloads ranging from archival-quality DVD rips to transcodes suitable for play on the iPhone, Maximum PC found that while Badaboom is significantly faster than X264-powered Handbrake in a few tests that require video resizing, it simply can't compare to the X264-powered Handbrake for archival-quality DVD backups."
This is the most obvious and boring insight they could possibly offer... Everyone with the slightest interest knows this already.
The low quality of hardware-based video encoder cards is a very well-known fact, and those MPEG encoders cards are just ASICs on a PCI card, almost exactly the same hardware as your video card.
The point of offering up APIs for GPUs, and AMD's attempt to integrate the GPU ASIC with the CPU via HyperTransport, is aimed at improving things, however.
x264 does a good job because it's an open source project, with several skilled and interested individuals continually tweaking the code to improve quality and performance. Once hardware-based video encoding routines aren't hidden in closed-source firmware on a dedicated card, the same development effort can step up and improve HARDWARE encoding now, exactly as they have with software.
Not only can quality be significantly improved, you can expect performance to improve significantly as well, even with greater quality. The initial implementation of any codec is always relatively poor performing, and low quality, so this wouldn't even be an insightful observation if it was comparing x264 with any other software based encoder... The only difference is that a new software h.264/AVC encoder would be SLOWER than x264, as well as being much lower quality.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
This isn't 1990 anymore; CPUs have SIMD just as graphics cards do. A modern CPU doing even a brute-force exhaustive motion search can come out on par with a GPU in terms of performance. And if you use sequential elimination instead of a brute-force search (which gives a mathematically equivalent output), a single Core 2 Quad can outperform a quad-SLI set of top-end graphics cards. Sequential elimination, however, despite being SIMD-able, is not well-suited to the threading model of CUDA and similar APIs, and so probably cannot be implemented reasonably on a GPU.
This concept applies to many algorithms--the brute-force method is easily implementable on a GPU, but a faster and algorithmically smarter method is not well-suited to such an architecture.
LGPL vs GPL is not actually a very big issue in my experience. I spent the summer working at Avail Media, a company that uses x264 for real-time 1080i/720p broadcast encoding for IPTV and cable television (and also funds a large portion of x264 development). They use x264 in their encoding boxes--yet their main application is proprietary! This is done by having an extremely simple open-source wrapper which is statically linked to x264; the raw frames to be encoded are passed to it over a pipe by the main program. This completely bypasses the limitations of the GPL without violating the spirit of it, since anyone who wants to can still read the source code of the wrapper, modify it, and recompile it as necessary and still use it with the main application.