codepaths for ATI Stream, Intel Quick Sync, and NVIDIA CUDA

[svx2005]

Is it in the works that future versions of HandBrake will include codepaths for ATI Stream, Intel Quick Sync, and NVIDIA CUDA? I would like these options available so I can pick which one I want to use. I would enjoy taking advantage of these technologies to transcoding my blue-rays a lot faster. Espicially the new Intel Quick Sync on sandy bridge... that thing is FAST! Can you use Intel’s Media SDK 2.0 which is publicly available? Intel says that any developer can get access to and use it.

Currently Intel’s Quick Sync transcode is only supported by two applications: Cyberlink’s Media Espresso 6 and Arcsoft’s Media Converter 7. Both of these applications are video to go applications targeted at users who want to take high resolution/high bitrate content and transcode it to more compact formats for use on smartphones, tablets, media streamers and gaming consoles. The intended market is not users who are attempting to make high quality archives of Blu-ray content... but they work, and they encode much faster using the GPU than the CPU... so it must be possible...

And yes, both programs output 2-channel MP3 or AAC audio and main profile of H.264 for video.

Intel's Quick Sync was twice as fast at the transcode than the AMD Phenom II x6 1100T CPU, and the Sandy Bridge i5 2500K CPU
(as seen on Anandtech's The Sandy Bridge Review: Intel Core i7-2600K, i5-2500K and Core i3-2100 Tested)

[mduell]

As has been repeated many times when this comes up:

1) Usage of that hardware would be the responsibility of the underlying encoding libraries (x264, etc).

2) The quick hardware encoders are lousy in terms of quality per bit. Assuming relatively even matched hardware (not a Core Duo and a GTX580), you can get the same speed on your CPU alone using faster x264 settings and achieve approximately the same quality per bit.

[thompson]

As has been repeated many times when this comes up:

1) Usage of that hardware would be the responsibility of the underlying encoding libraries (x264, etc).

2) The quick hardware encoders are lousy in terms of quality per bit. Assuming relatively even matched hardware (not a Core Duo and a GTX580), you can get the same speed on your CPU alone using faster x264 settings and achieve approximately the same quality per bit.

But ZZZZzzzzOMG I saw on techblogsawesome.com that CUDA is 883899% faster!

/Seriously, I think this request should go on the "Top things that simply wouldn't do what you expect them to do" list.

[svx2005]

Wow just a suggestion.
It's confusing then why Intel spends all that money on R&D to include a new hardware H.264 encoder in their new core architecture when the x86 hardware could do the same thing just as fast. OR... perhaps it's the 3rd party software developers that don't yet know how to take advantage of it? Maybe Intel just needs to write the software for it.

I think someone needs do a benchmark... use the same settings on both x86 and Quick Path and see which one's faster.

[thompson]

Did you really not read anything that was said? This isn't simply a matter of speed. Yes, CUDA and similar technologies can provide a speed increase. However, that increase comes at a large and unreasonable drop in quality with regard to the encoded video. You can get similar speeds at that quality simply by changing your x264 encode settings.

x264, the underlying library that handbrake uses, is one of those freaks of nature—it really is "just that good". It's just damn well hard to beat it.

[TedJ]

x264 has won the last four or five H.264 encoder shoot outs in a row, as conducted by the MSU Graphics and Media Lab.

http://compression.ru/video/codec_comparison/h264_2010/

It's so highly regarded that the Criterion Collection sponsored x264's final compliance testing for use as a Blu-ray encoder.

http://x264dev.multimedia.cx/archives/328

Most of these hardware accelerated encoders are tuned for speed at the expense of quality, speeds that can be matched (with similar losses) by a good CPU based encoder.

[EuhicS]

It's right, CUDA technology is fast for encoding video but the quality output is terrible comparing to x86 quality. Simply because algorithm aren't the same on a GPU (lots of parallel process) and a CPU (few parallel process). But ATI Stream has an output quality very close to a x86 output, but is not very usefull since its algorithm isn't faster than a CPU (and actually seems to use the CPU while encoding O_o ???).
But Quick Sync technology from Intel is really different, it's much faster than any technology used now and output quality seems to be very close of a x86 output ! The lost of quality is worth the gain of speed.

You should have a quick read : http://www.anandtech.com/show/4083/the- ... 0-tested/9

Actually I'd like to buy a Sandy Bridge (for my future htpc) especially for this functionality, but only if I can backup my blu-rays with it :-/ (otherwise I'll keep encoding my movies with my desktop computer..).

[tlindgren]

But Quick Sync technology from Intel is really different, it's much faster than any technology used now and output quality seems to be very close of a x86 output ! The lost of quality is worth the gain of speed.
You should have a quick read : http://www.anandtech.com/show/4083/the- ... 0-tested/9

Note that they did NOT compare it to x264 or anything based on it, they used "Media Converter 7" because it allowed them to use one program for all code paths. Nor did they try to tune to either similar speed or similar quality.

That's two EPIC fails that makes all their testing utterly useless. I know at least some of their editors know better, it's a pity either someone had a total brain melt, it was assigned to a HACK or they got paid of by Intel for this.

Quick Sync looks possibly interesting, but the fact that someone likely felt the need for a hack job that bad makes me suspicious enough that I want to see someone actually do a proper test before I trust it.

Even without it Sandy Bridge looks like a mostly good HTPC platform, though the inability to output 23.976 fps video correctly (IE without judder!) on the built-in graphics card is a big problem for many people (because 99% of films are in 23.976...). It's a silly omission, shared by their older hardware and will only be fixed on the next major revision (2012 IIRC).

[Deleted User 11865]

It's right, CUDA technology is fast for encoding video but the quality output is terrible comparing to x86 quality.

[…]

But Quick Sync technology from Intel is really different, it's much faster than any technology used now and output quality seems to be very close of a x86 output ! The lost of quality is worth the gain of speed.

There's no such thing as "x86 quality". Anandtech is comparing the CUDA/Stream/QuickSync to some CPU-based encoder. We don't know which (and it seems like Anandtech couldn't care less). Some CPU-based encoders are crappy too.

2. Pick a bitrate that’s way too high. This is staggeringly common mistake: pick a bitrate so high that all of the resulting encodes look absolutely perfect. The claim is then made that “there’s no significant difference” between any of the encoders tested. This is surprisingly easy to do inadvertently on sources like Big Buck Bunny, which looks transparent at relatively low bitrates. An equally common but similar mistake is to test at a bitrate that isn’t so high that the videos look perfect, but high enough that they all look very good. The claim is then made that “the difference between these encoders is small”. Well, of course, if you give everything tons of bitrate, the difference between encoders is small.

The first transcode involves taking the original Casino Royale Blu-ray, stripping it of its DRM using AnyDVD HD, and feeding that into MC7 as a source. The output in this case was a custom profile: 15Mbps 1080p main profile H.264.

IMO, any encoder that can't achieve good results over 200,000 frames given 15 Mbps to play with really, really sucks (it's not like Casinon Royale is as difficult as Planet Earth's birds scene looping for 200,000 frames).

Comparing the shots above the only real outlier is NVIDIA’s GeForce GTX 460. The CUDA path clearly errs on the side of performance vs. quality and produces a far noisier image. The ATI Stream codepath produces an image that’s very close to the standard x86 and Quick Sync output. In fact, everything but the GTX 460 does well here.

So, CUDA sucks, and the bitrate is so high that the other encoders more or less tie. Big surprise here.

The next test uses an already transcoded 15Mbps 1080p x264 rip of Quantum of Solace Blu-ray disc. For many this is likely what you’ll have stored on your movie server rather than a full 50GB Blu-ray rip. Our destination this time is the iPhone 4. The settings are as follows: 4Mbps 720p H.264.

[…]

The image quality story is about the same for AMD’s GPUs and the x86 path, however Quick Sync delivers a noticeably worse quality image. It’s no where near as bad as the GTX 460, but it’s just not as sharp as what you get from the software or ATI Stream codepaths.

For our final test we’ve got a 12Mbps 1080p x264 rip of The Dark Knight. Our target this time is a 640x480, 1.5Mbps iPod Touch compatible format.

[…]

Quick Sync maintains color fidelity but loses the sharpness of the x86 path, similar to what we saw in the previous test. In this case the loss of sharpness does help smooth out some aliasing in the paint on the police car but otherwise is undesirable.

With more reasonable settings, Quick Sync is beaten by some CPU-based H.264 encoder. Maybe it's a good one, or maybe MediaEspresso's CPU encoder is bad to begin with.

And Quick Sync is 2-3x faster than the CPU encoder on a Core i5 2500K. But how fast is that CPU encoder? Is it the same speed as x264's ultrafast preset? Is it closer to medium? It's not that difficult to make x264 2-3x faster than its default settings (assuming you don't bottleneck on decoding, which is clearly not the case there), while still beating quite a few CPU-based H.264 encoders in compression efficiency.

[mduell]

Sandy Bridge is a great CPU for doing BR ripping using HB/x264. Use a preset fast enough to satisfy your speed desires.

It's confusing then why Intel spends all that money on R&D to include a new hardware H.264 encoder in their new core architecture when the x86 hardware could do the same thing just as fast.

Marketing.

OR... perhaps it's the 3rd party software developers that don't yet know how to take advantage of it? Maybe Intel just needs to write the software for it.

A senior Intel guy stopped by the x264 forum and IRC... and produced nothing useful.
IIRC nVidia developers even wrote some code... that did nothing useful.

[8steve8]

Yes some "hardware" encoding sacrifices quality (nvidia, ati)... that doesn't mean all must.

The one data point we have from anand shows at least the quality being miles ahead of nvidia and ati, at a much faster speed.

The cpu encoder might not have been the best, so instead of bashing, give us a data!

show that quick sync is worse than a cpu encoder at the same quality of output.

Don't tell us, show us.

[TedJ]

Pardon?

Why is the onus on the developers to prove to you that hardware accelerated encoding is of dubious use? As has already been stated ad infinitum, it's not up to the developers of Handbrake in any case, Quick Sync would have to be implemented at the encoder level. In this case this would be the people working on libx264, people who are arguably some of the most accomplished people in the field of video compression. I'm going to take their word over that of a tech journalist or a random blow in with an overweening sense of entitlement.

If you think I'm being needlessly harsh, then take your suggestion and your demands for "the data" over to #x264 on freenode and I'm sure that they will be more than happy to set you straight.

[thompson]

If you think I'm being needlessly harsh, then take your suggestion and your demands for "the data" over to #x264 on freenode and I'm sure that they will be more than happy to set you straight.

I'll bring the popcorn.

[mduell]

Yes some "hardware" encoding sacrifices quality (nvidia, ati)... that doesn't mean all must.

The one data point we have from anand shows at least the quality being miles ahead of nvidia and ati, at a much faster speed.

The cpu encoder might not have been the best, so instead of bashing, give us a data!

show that quick sync is worse than a cpu encoder at the same quality of output.

Don't tell us, show us.

Start here.

Continue here.

[8steve8]

Yes some "hardware" encoding sacrifices quality (nvidia, ati)... that doesn't mean all must.

The one data point we have from anand shows at least the quality being miles ahead of nvidia and ati, at a much faster speed.

The cpu encoder might not have been the best, so instead of bashing, give us a data!

show that quick sync is worse than a cpu encoder at the same quality of output.

Don't tell us, show us.

Start here.

Continue here.

well that was a big waste of time, everyone claiming this and that, give me a link to someone showing that sandy bridge accellerated encoding is worse quality, at the same speed, or slower at the same quality.

Don't give me a link to people just claiming such things.

[rogue23]

well that was a big waste of time, everyone claiming this and that, give me a link to someone showing that sandy bridge accellerated encoding is worse quality, at the same speed, or slower at the same quality.

Don't give me a link to people just claiming such things.

Provide a link with hard facts that proves SB accelerated encoding is equal to or better than x264 all else being equal.

[8steve8]

well that was a big waste of time, everyone claiming this and that, give me a link to someone showing that sandy bridge accellerated encoding is worse quality, at the same speed, or slower at the same quality.

Don't give me a link to people just claiming such things.

Provide a link with hard facts that proves SB accelerated encoding is equal to or better than x264 all else being equal.

well the one piece of evidence that attempts to do an apples to apples comparison is anandtech, may not be perfect, but definitely points towards quick sync being faster and at the same time better quality than the cpu encoder they used..

so unless you have evidence that shows otherwise....

I'm not attempting to say for sure it's better or worse, How could I know without testing... but the little evidence we have would have us guess it's better than a software encoder like x264 as-is. I'd love to be proved wrong by actual data... not using gpu encoders, but using quick-sync.

[Deleted User 11865]

well the one piece of evidence that attempts to do an apples to apples comparison is anandtech, may not be perfect, but definitely points towards quick sync being faster and at the same time better quality than the cpu encoder they used..

Faster, yes. But unless I missed something, they never say the quality is better with Quick Sync than with the CPU-based encoder. Sometimes equivalent, sometimes worse.

I'm not attempting to say for sure it's better or worse, How could I know without testing... but the little evidence we have would have us guess it's better than a software encoder like x264 as-is.

Faster? Maybe. Better (as in better compression efficiency*) than the world's best software H.264 encoder? Unlikely.

Plus, Quick sync is apparently optimized for PSNR…



Which frame do you think looks better? The first one (nopsy2.png) has the better PSNR. Put another way, I doubt Quick Sync can even come close to x264's slower settings.

The other interesting question, i.e. how compression efficiency compares once you match their speeds (e.g. by configuring x264 for better speed) depends on the CPU.

* i.e. better quality at the same bitrate or same quality at a lower bitrate

[8steve8]

Faster, yes. But unless I missed something, they never say the quality is better with Quick Sync than with the CPU-based encoder. Sometimes equivalent, sometimes worse.

well if you look at the samples they have comparing the different rendering paths, quick sync does indeed look better than software for many of the scenes, an on-par on the rest.

I am not saying that is definitive, as im sure they didn't use the best software path/settings, but it's the only comparison I've found, everyone else just seems to guess it's worse, without actually trying.

Faster? Maybe. Better (as in better compression efficiency*) than the world's best software H.264 encoder? Unlikely.

Plus, Quick sync is apparently optimized for PSNR…



Which frame do you think looks better? The first one (nopsy2.png) has the better PSNR. Put another way, I doubt Quick Sync can even come close to x264's slower settings.

The other interesting question, i.e. how compression efficiency compares once you match their speeds (e.g. by configuring x264 for better speed) depends on the CPU.

* i.e. better quality at the same bitrate or same quality at a lower bitrate

the latter frame looks better, as a single frame, but as part of a movie, I could only guess...

Again, you doubt quick sync can come close to x264... instead of guessing and doubting, lets look at the evidence.

Right now there is only a tiny bit of evidence... Maybe not definitive... but points to quick sync being faster and better at the same time...

If someone thinks that software will dominate quick sync, they need to step up and do some tests, show us that they are right. Words are cheap.

[thompson]

Again, you doubt quick sync can come close to x264... instead of guessing and doubting, lets look at the evidence.

Right now there is only a tiny bit of evidence... Maybe not definitive... but points to quick sync being faster and better at the same time...

If someone thinks that software will dominate quick sync, they need to step up and do some tests, show us that they are right. Words are cheap.

1) You've offered no evidence that quicksync beats x264 in speed or quality, just some third-party encoder.
2) x264 is the gold standard, it is the status quo. It is incumbent on YOU and others who are claiming that quick sync are better to provide evidence that it beats x264, not on the x264 developers to prove that it does not. That's like saying we have to prove ghosts exist. No, the burden is on those trying to find spirits from another world and/or show the quality/speed of hardware-accelerated encoders to provide the evidence.

[nawoa]

x264 is the best available encoder quality-wise, period. When compared with other encoders in terms of speed alone, hardware or otherwise, a similar or faster result can be had by simply reducing the x264 settings to be of similar quality. It's not an exaggeration to say that this is the case virtually 100% of the time unless you have a retardedly unbalanced comparison like a pair of 580s versus a Pentium 4 or something.

Produce some results not based on marketing or hyperbole and the developers might pay attention.

[B166ER]

Hi guys. I'm asking only because I want to be schooled in this matter. Anandtechs review left me confused, and you guys kinda confused me as well, but the debate here seems to be that using the x264 'version' of H.264 is the best encoder. Ok, I understand that. But in Anands review, the software used, Media Converter 7 uses a 'generic' h.264 encoder, but thats not the actual encoder, thats just a name. What is the underlying codec of H.264 used by (and others) MC 7 when using the different hardware as the engine?

I've been searching through the forums but cant make heads or tails of this issue. Is the x.264 encoder limited only to an x86 engine, or is it supported by Nvidia or ATi or Quick Sync? Or is it that They are the encoding engines that use their specific implemetation of H.264? All encoding software I've seen just says they use H.264, but what version? Reading from WikiP, there are QT, Nero, LEAD, x264, MainConcept, DivX, Elecard, TSE, VSofts, ProCoder, Avivo, Elemental, and IPP 'versions' of H.264, but is there a such thing as an H.264 'generic' version?
I agree that x264 brings the best video out, but is it engine agnostic?

Sorry for being ignorant on this issue but if I don't ask questions I wont know answers!

[JohnAStebbins]

"h.264" is a specification. It is a piece of paper that spells out the format and some of the techniques used for generating a bitstream compliant with the spec. There is no such thing as a "generic" version of h.264. But there is a reference implementation of the h.264 codec. http://iphome.hhi.de/suehring/tml/ This reference implementation is not particularly efficient or fast.

Any time a review uses a "generic" encoder in the comparison, that should be a warning sign. If you don't know the specifics about the encoder, you can't make a valid comparison.

x264 is an open source software encoder that generates a bitstream compliant with the h.264 spec. It is considered one of the best available. Since it is software, it is not limited only to x86. For speed, it has many functions that have been optimized in assembly language. These optimizations are architecture specific, so x264 will be faster on some CPUs than others.

ATi and Nvidia have encoders that leverage the parallel computing capabilities of their graphics cards to encode. Since many of the better algorthims used in video encoding can not be parallelized, these encoders have limitations that exhibit as poor quality output.

QuickSync is an encoder that leverages hardware in new Sandy Bridge chips that was specifically designed for video encoding. Not much is known about how this hardware works yet, so it is yet to be seen how it will compare in speed and quality to a good software encoder.

I'm not quite sure what you are trying to describe when you call something an "engine". My guess is you mean the underlying encoder that is used to generate the h.264 bitstream. In this case, x264 *is* an engine. Likewise QuickSync, ATi AVIVO, etc. I couldn't tell you which encoding engine all the software you listed uses. In some cases, I'm sure they have options for multiple encoders.

[B166ER]

Hey John, thanks for the reply. I apologize for not being accurate with my terms but by engine I meant the hardware that drives the software. By example the engine for x264 would be any x86 processor, and as i don't know much about coding, that may or may not be limited by the developers of the software. I understand the specifics for the most part of x264 I just didnt understand if encoders, all or just x264, were limited by certain hardware, meaning could Quick Sync (or the underlying engine, Intels 2000 and 3000 series gpus) use x264 as an encoder, or would that have to be implemented by the x264 developers? That make sense?
As it seems, anytime a better or more efficient engine (hardware) is used, the end result seems to always be [Censored]. GPUs are crazy parallel in processing terms, which means awesome speed but the end result is just ass. From what I can gather this isn't because using a gpu as an encoding engine is worthless, its the software or h.264 encoder Avivo or CUDA uses. Being a lurker around the forums and seeing the dander the guys get into when one mentions Nvidia or Avivo, it seemed to infer that the fellas just hated the more efficient process. But I can see now the efficient process wasn't the issue, it was the poor implementation of the software (their versions of h.264 spec encoding.) This is what had me confused.
So let me ask you this: if CUDA or AVIVO based encoding got significantly better, to the point of rivaling x264, would it then be considered for Handbrake inclusion?

[Deleted User 11865]

Hey John, thanks for the reply. I apologize for not being accurate with my terms but by engine I meant the hardware that drives the software. By example the engine for x264 would be any x86 processor, and as i don't know much about coding, that may or may not be limited by the developers of the software. I understand the specifics for the most part of x264 I just didnt understand if encoders, all or just x264, were limited by certain hardware, meaning could Quick Sync (or the underlying engine, Intels 2000 and 3000 series gpus) use x264 as an encoder, or would that have to be implemented by the x264 developers? That make sense?

IIRC, Quick Sync is an ASIC and is completely separate from the GPU.

As it seems, anytime a better or more efficient engine (hardware) is used, the end result seems to always be [Censored]. GPUs are crazy parallel in processing terms, which means awesome speed but the end result is just ass. From what I can gather this isn't because using a gpu as an encoding engine is worthless, its the software or h.264 encoder Avivo or CUDA uses.

The software used by these encoders is heavily parallelized because if it weren't, it would be slow (each of a GPU's "cores" is rather slow; a GPU is only fast because there are so many of them). But it's the same parallelization that causes these encoders' quality to be lower than a good CPU-based encoder. So, in this case, the limitation is that of the hardware, not the software.

Being a lurker around the forums and seeing the dander the guys get into when one mentions Nvidia or Avivo, it seemed to infer that the fellas just hated the more efficient process. But I can see now the efficient process wasn't the issue, it was the poor implementation of the software (their versions of h.264 spec encoding.) This is what had me confused.
So let me ask you this: if CUDA or AVIVO based encoding got significantly better, to the point of rivaling x264, would it then be considered for Handbrake inclusion?

No. Because if it became that good it would be slower than x264.

There are no plans to include any H.264 encoder other than x264. If x264 includes code to use the GPU or dedicated hardware like Quick Sync (more likely), they will make their way into HandBrake, however. It may be possible to port some of x264's algorithms to Quick Sync, for example; but that won't happen overnight.