x264 and Core i7 920

[rtjnyoface]

Using megui I set my cpu for 8 threads. I can use CQ and get a full cpu load of around 80%. I use 2 pass abr and get around 30% for both passes. Is there a way to get a full load with the 2 passes also? Just wondering as it would go faster (obviously) if I were able to have it use my cpu to its entire potential.

[jeffy]

Post your script! What profile? What source (DVD/something else, HD/SD)? What options selected?

[cogman]

What do you mean by "Getting the most out of my CPU." If you strickly want a fast encode, well, there are several threads on the subject of what options speed up encodes. If you have the setting you want to use, but are just wondering how you could go faster, then the most you can do (really) is adjust the number of threads x264 uses until you get the highest FPS.

One note. Don't judge speed or quality or anything really on the % of utilization your OS reports x264 is using. Judge it by FPS and what you think it looks like.

[Dark Shikari]

Note the fact that both --b-adapt (read the --longhelp!) and your input filter/decoding process serve as bottlenecks. Since these have constant cost, the faster your other encoding settings, the less x264 will be able to get done while waiting for these bottlenecks.

[rtjnyoface]

@jeffy: you sound like some of the mods at the divx forums. I understand you may get frustrated but there are users who don't really know squat about x264. I'm sure there many users who've chosen not to learn what the 40 or so intricacies of x264 do. I would also understand your frustration if I had said something like "there are line thingy's on the video when I play it. How do i fix this?" or " x264 won't run". BUT, I wasn't asking a question similar to those (not precisely anyways). Being a mod at the divx forums and a newby at one time still reminds me that I should have some common courtesy and that I was at that point at one time. Maybe I shouldn't be a jerk even though they are asking what seems to me to be a stupid question.

Source: SD DVD

#deinterlace
crop( 0, 0, 0, 0)
Lanczos4Resize(720,400) # Lanczos4 (Sharp)
#denoise

(very simple as you can see)

Settings for the unrestricted 2 pass HQ:

program --pass 2 --bitrate 868 --stats ".stats" --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --subme 7 --trellis 2 --partitions all --8x8dct --me umh --threads 8 --thread-input --progress --no-psnr --no-ssim --output "output" "input"

Settings for unrestricted 1 pass CQ HQ

program --crf 18 --ref 5 --mixed-refs --bframes 3 --b-adapt 2 --b-pyramid --weightb --deblock -1:-1 --trellis 2 --partitions all --8x8dct --me umh --threads 8 --thread-input --progress --no-psnr --no-ssim --output "output" "input"

Keep in mind I'm not talking about quality. It was my perception that encoding in general would have a high load. I thought it to be strange that while using a 2 pass the cpu would only be around 30% but when using a 1 pass CQ it would be around 80%. That's all I was wondering.

Thanks to those who tried helping.

Judge it by fps and what it looks like

I think the 2 pass was around 80fps. Can't remember what the 1 pass was (maybe 60???)

Since these have constant cost, the faster your other encoding settings, the less x264 will be able to get done while waiting for these bottlenecks.

Nice simple script I would assume would bottleneck it all that much.

Cogman may have my fix but I question the ability/responsibility of my cpu to do more than 8 threads. I'm sure you all may know about that.

[Esurnir]

b-adapt 2 will certainly be the bottleneck on the first pass, b-adapt being single threaded and every other task being done -after- it's decision, it'll certainly make your encode go bellow 50%.

Is the secondpass usage any better ? (b-adapt 2 shouldn't impact the second pass, the stats file deciding the slice types)

[rtjnyoface]

In all honesty, I can't remember as fact. I think it was pretty much the same.

[lexor]

set threads to auto, I forgot what the actual formula is for number of threads, but it's more than the actual number of threads you have (4/3*num of cores?) at least it is for actual physical cores. I dunno how how that plays with HyperThreading, but try --threads auto anyway.

[jeffy]

I was not frustrated. See this icon :script:; I hesitated whether I should put an exclamation mark at the end of the sentence – and I did. Since you expect a reasonable answer, you should give as much relevant information as possible. Then you can expect relevant help.

Unless something has changed, the b-adapt decision is not multithreaded. Dark Shikari, can you please confirm, is it still true?
http://forum.doom9.org/showthread.php?p=1215388

I requested the information for your own good, that's all :)

[rtjnyoface]

I know this may most likely not be fact but b-adapt is also on the CQ example I gave you. Does the bottlenecking not happen as significantly with the CQ example? I say most likely because I"m fairly sure that there are MANY other things to take into account. Just pondering.

[Dark Shikari]

Yes, the lookahead is still unthreaded.

[Esurnir]

I know this may most likely not be fact but b-adapt is also on the CQ example I gave you. Does the bottlenecking not happen as significantly with the CQ example? I say most likely because I"m fairly sure that there are MANY other things to take into account. Just pondering.

The difference between CQ and twopass is that in two pass you -may- (check your logs) use turbo mode for the first pass, in which case the first pass use really fast settings (subme 2, me dia etc.) the only time the cpu stretch his leg is when the single threaded bframe placement decision come in play.

CQ being single pass you use your maximum settings in that pass.