The article you linked is not very good.
Normally, single pass bitrate encodings convert your bitrate into a RF
value with a maximum bitrate limit and takes it from there.
x264's one-pass ABR ratecontrol is not implemented as CRF + limit. He's right that 2pass is by far the best way to hit a target bitrate, though.
And he apparently doesn't realize that he could start x264 with threads=3 or something, to leave some CPU time free for other tasks. Or set x264's priority to verylow, so it only gets CPU time that no other task wants.
He also mixes up threads=1 with using CUDA, or something. No wonder you have questions, because that article has a TERRIBLE explanation. The whole article basically boils down to: use x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv
, or maybe use some light filtering with an input AviSynth script. He actually recommends "placebo". That's hilarious. I've never seen a pirated file encoded with placebo. (you can tell from me=esa
or me=tesa
, instead of me=umh
for all the good quality presets, right up to veryslow
.
He also doesn't mention using 10bit color depth. Slower to encode and decode, but even after downconverting back to 8bit, you get better 8-bit SSIM. Having more precision for motion vectors apparently helps. Also, not having to round off to exactly a whole 8 bit value helps. You can think of 8-bit per component as a speed-hack; quantizing in the frequency-domain and then compressing that with CABAC means that higher bit-depth coefficients don't have to take more space.
(BTW, h.265 gets less benefit from 10-bit encodes for 8-bit video because it already has more precision for motion vectors. If there is a benefit to using 10-bit x265 for 8-bit video inputs, it's smaller than with x264. So it's less likely that the speed penalty will be worth it.)
To answer your actual question:
edit: doom9 is up again now, so I'll tidy up the link. Go to it for proper quoting of who said what.
http://forum.doom9.org/showthread.php?p=1135399#post1135399
google only caches the stupid print version which doesn't properly show the quoting. I'm not quite sure which parts of these messages are quotes, and which are attributed to the person themselves.
Highly irregular branching patterns (skip modes) and bit manipulation (quantization/entropy coding) don't suit present GPUs. IMO the only really good application at the moment are full search ME algorithms, in the end though accelerated full search is still slow even if it's faster than on the CPU.
-- MfA
Actually, basically everything can be reasonably done on the GPU except CABAC (which could be done, it just couldn't be parallelized).
x264 CUDA will implement a fullpel and subpel ME algorithm initially; later on we could do something like RDO with a bit-cost approximation instead of CABAC.
Because it has to do everything at single precision floating point
-- MfA
Wrong, CUDA supports integer math.
-- Dark Shikari
Dark Shikari is the x264 maintainer, and developer of most of the features since 2007 or so.
AFAIK, this CUDA project didn't pan out. There is support for using OpenCL to offload some work from the lookahead thread (quick I/P/B decision, not a high quality final encode of the frame).
My understanding is that the search space for video encoding is SO big that smart heuristics for early-termination of search paths on CPUs beat the brute-force GPUs bring to the table, at least for high quality encoding. It's only compared to -preset ultrafast
where you might reasonably choose HW encoding over x264, esp. if you have a slow CPU (like laptop with dual core and no hyperthreading). On a fast CPU (i7 quad core with hyperthreading), x264 superfast
is probably going to be as fast, and look better (at the same bitrate).
If you're making an encode where rate-distortion (quality per file size) matters at all, you should use x264 -preset medium
or slower. If you're archiving something, spending a bit more CPU time now will save bytes for as long as you're keeping that file around.
side note, if you ever see messages from deadrats on a video forum, it's not going to be helpful. He's been wrong about most stuff he's talking about in every thread I've ever seen. His posts turned up in a couple threads I googled about x264 GPU encoding. Apparently he doesn't understand why it isn't easy, and has posted several times to tell the x264 developers why they're dumb...