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."

It seems even this article has a few fictions.

To begin with, x264 blows the water out of Badaboom in terms of speed when similar settings are used. Badaboom appears to use the rough equivalent of --aq-mode 0 --subme 1 --scenecut -1 --no-cabac --partitions i4x4 --no-dct-decimate in terms of x264 commandline... its no wonder its "fast" when they compare it to x264 on far slower settings!

GPU encoders won't be able to compete with CPU encoders until they either get a lot faster (in which case they'll compete in the "high performance" market) or they get much better quality, since at sane settings x264 unsurprisingly blows Badaboom out of the water quality-wise, too. Until then, the product is not only completely proprietary but furthermore simply inferior, and they're going to have a very hard time marketing it.

Re:It seems even this article has a few fictions.

To begin with, x264 blows the water out of Badaboom in terms of speed when similar settings are used.

If you'd RTFA, you'd see this disparity is repeatedly mentioned, and they attempted to make a fair comparison.

In a direct comparison, using as close to the same visual quality settings as we could, Handbrake's circa February 2008 X264 codec actually beat the Elemental encoder by almost a minute. Image quality was roughly the same; we've included several stills below so you can directly compare the results.

Re:

Yet that line brings up yet another problem--they're using the absolute latest software from Elemental, but are using a 7-month-old version of x264 that is lacking an enormous number of recent improvements. Its anything but a fair test.

Obvious

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.

They're not encoding, they're transcoding

They're not encoding video. They're transcoding it. They're starting from one compressed representation and outputting another compressed representation. (Now, with twice the artifacts!)

The good test for this is football. The players, ball, and field are all moving in different directions. If the motion compensation gets that right, it's doing a very good job.

Re:makes sense to me

All MPEG formats (including H.264) are lossy; if you want lossless, use HuffYUV, Lagarith, or FFV1 (or one of a countless variety of similar proprietary formats, such as Sheer YUV). Of course, this will give far larger file sizes, for obvious reasons.

Re:makes sense to me

And it seems that I made a slight oversight here also; --qp 0 in x264 (in the standard as qpprime_y_zero_transform_bypass_flag) is set, H.264 can indeed be a lossless format too, making it the only MPEG video format with a lossless mode.

Re:

I was referring to the idea of encoding a lossy format in another lossy format, resulting in further losses. Not necessarily just the loss of the original lossless-to-lossy. Sorry if I was unclear.

Seriously, why encode twice? And why rate performance on how fast you can lose bits?

Re:

Since Badaboom is a baseline-only encoder, I would guess one of its main markets would be to backup movies in a format that can be played by iPods or similar.

Re:makes sense to me

All MPEG formats (including H.264) are lossy;

H.264/AVC includes lossless compression as well as lossy. The same is true for the wavelet based "snow" codec. Still, I'd recommend FFV1 for best compression, as long as you don't need the video to be playable by all the standard H.264 decoders out there.

if you want lossless, use HuffYUV, Lagarith, or FFV1 (or one of a countless variety of similar proprietary formats, such as Sheer YUV). Of course, this will give far larger file sizes, for obvious reasons.

This test is about reencoding from a DVD to H.264/AVC. If you want lossless quality, you need only copy the MPEG-2 stream... Reencoding to a lossless format will dramatically increase the file size, without any quality improvement.

Re:makes sense to me

What are you talking about?!?! I do the audio equivalent all the time! I download 64kbps MP3 files, and reencode them to 320kbps to regain the quality! Screw information theory! I'm an audiophile, I can tell the difference!

Re:

HuffYUV supports RGB and YUY2, and the ffmpeg extension (FFVHUFF) supports YV12 too.

Re:makes sense to me

Wouldn't archival-quality backups be actual MPEG instead of H.2 or whatever?

You may have a point, or you might not. Depends on the definition of "archival", and your specific purpose for doing so. I imagine most historians who deal with digital data would scoff at your conflating the terms used to describe their work, with some home user who just wants to back-up their DVDs...

There's certainly going to be loss, when encoding from MPEG-2 DVDs to H.264. But considering how ridiculously large DVD video is for the relatively small amount of data it contains, I'd say a tiny drop in quality is generally acceptable in exchange for reducing the storage space required for near-as-high-quality backups of your DVDs in (eg.) 1/10th the space.

Don't quote me on that, though, it's just a hypothetical example. I just recently finished explaining, here, why H.264 isn't all that much more effective than MPEG-2 where indistinguishable/high-quality (rather than just "watchable") is desired: http://slashdot.org/comments.pl?sid=956141&cid=24940379 [slashdot.org]
In fact, you could probably re-compress a DVD with MPEG-2 (instead of H.264) and get equivalent quality at almost equally low data-rates, simply because the DVD producer's MPEG-2 encoders are terrible, and the settings they use (GOP size, fixed resolution/black borders, high frequency noise, etc.) waste a LOT of the bitrate on things which really don't improve visual quality.

And to be a bit pedantic... H.264 is, in fact "MPEG". It's MPEG-4 AVC (Part10), while DVDs use MPEG-2.

Re:makes sense to me

I don't know what your source is, but MPEG-2 can't even APPROACH MPEG-4 AVC quality at the same bitrate (at low bitrate), and MPEG-4 AVC can produce a much more compact file for a specified quality (such as where DVD-quality or better). On the other hand, MPEG-4 is much more recent, and takes an order of magnitude more processing power to encode and decode. MPEG-4 uses much improved intraframe compression, variable-size macroblocks, and more advanced descriptions of block motion. Even if we drop the issue of MPEG-2 support for B-frames and limits on P/B frames per GOP (limited by the MPEG-2 profiles, which could be ignored), MPEG-4 is much more efficient at removing redundant information. Finally, MPEG-4 adds more advanced entropy coding for the final lossless compression of coefficients, etc after lossy compression is performed -- the CAVLC coding is an improvement on MPEG-2's standard variable-length coding. CABAC's arithmetic coding is even more efficient than CAVLC.

MPEG-4/AVC was intended to deliver comparable quality to MPEG-2 at half of the bitrate, and certainly succeeds at low bitrates. At higher bitrates (near-perfect picture quality), you certainly would have been right about the Advanced Simple Profile for MPEG-4 (used in Divx, Xvid, etc), but AVC should still be more efficient.

Incidentally, the MPEG-2 profile allowed in DVDs was picked to ease the work of the decoding hardware (savings on cost for consumers), at the cost of compactness. The fixed resolutions, bit rate limitations (both max and min bitrates), and GOP limits make it much easier to create a compatible hardware decoder. Yes, they can sometimes significantly decrease compression, but they made early DVD players marketable. Within these significant limitations, the studio-grade encoding software and technicians are PHENOMENAL at delivering maximum quality. If you're used to consumer grade MPEG-2 encoding, something like the pro version of Cinema Craft Encoder is a revelation (an expensive one though -- nearly $2K). See if you can sniff up a trial or demo, and compare the output quality to premiere.

Re:

In my experience HCEnc, a freeware encoder (not open-source though), tends to beat CCE quality-wise. Most of Doom9 seems to agree, though I don't think the differences were too dramatic.

Re:Compression isn't really parallel

Uh...you space multiplex rather than time multiplex to parallelize encoding. Motion estimation, e.g., is quite parallelizable.

Re:Compression isn't really parallel

uh huh, tens of thousands of lines of asm....

~/x264-snapshot-20080812-2245/common/x86$ wc -l *.asm
      165 cabac-a.asm
        91 cpu-32.asm
        51 cpu-64.asm
      437 dct-32.asm
      223 dct-64.asm
      316 dct-a.asm
      874 deblock-a.asm
      659 mc-a2.asm
      933 mc-a.asm
      428 pixel-32.asm
    1615 pixel-a.asm
      600 predict-a.asm
      383 quant-a.asm
      968 sad-a.asm
      519 x86inc.asm
      124 x86util.asm
    8386 total

Re:

So if you had tried Handbrake before posting you would see you don't need to first rip the dvd's. You wouldn't have to buy slysoft. You furthermore would be able to choose ipod, psp, etc as a setting for output.

Re:Clone DVD Mobile

So you paid money for a GUI that selects command-line options?

I'm in the wrong line of work.

Re:Apples and Oranges

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.

Re:

Yes, Core2 seems to have much better SSE units than the AMD chips, but this only really manifests itself when running code optimized to use SSE... And that's usually hand optimized assembly, as compilers aren't generally good at generating SSE code yet.

John the ripper SSE2 mode on a core2 is 2-3 times faster than the generic compile...
John the ripper SSE2 mode on an AMD (tested on a quad core phenom and dual core opterons) is slightly slower than the generic compile with gcc 4.3 and -O3.

The core2 beats a si

Re:

but if a solution already existed as you seem to imply, Intel, AMD, Microsoft and the others would not be spending tens of millions of dollars a year to find a solution. The parallel programming problem is not just a problem. It is a crisis.

You seem to not understand the difference (or that there is a difference) between multi-threaded programming, and SIMD data processing.

The former requires dividing a single application up into independent parts (threads), where no one part needs to wait for the output of

Re:Not a valid comparison

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.

Re:

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.

Moreso, that is exactly how proprietary software is supposed to interact with GPL software. See Mere Aggregation [gnu.org], especially the last paragraph:

By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs.

Re:

Their wrapper is required to be GPL ; but since they don't distribute it, the source distribution clauses are not in effect.

Their commercial software pipelines frames into their wrapper ; they are separate processes, not linked, and thus their use does not violate GPL.

Otherwise you could argue that because you opened a Word document in OOo, that Word was now required to be GPL because it had emitted data that was now being consumed by a GPL application.