Log in

View Full Version : x264 placebo not using much CPU


DoomNlNE
28th December 2012, 19:55
My source is standard definition captured using camstudio lossless.
In virtualdub, it can be decoded at 1200 fps.

I have a quad core i7 server (win 2008 r2), which has hyper threading.
I use the latest x264 exe from the official website.

I currently use these settings to encode:
x264 --preset placebo --crf 0 -o out.mp4 in.avi
(adding --threads 8 makes no difference)

x264 only uses 20-35% of my CPU. Can this be increased?

Edit:
SOLVED: changing preset to SLOW and using crf 14 uses 90% of my CPU. I think that's enough. But interestingly it only doubles the fps speed.

Veryslow lossless would encode at 140fps and slow crf 14 encodes at 280fps. The only change is I added keyint 1 to the latter. Not sure if that makes any difference.

Selur
29th December 2012, 07:50
"Can this be increased? " -> ever tried to not use placebo? (it's only using x percent since some of the placebo settings are not, probably can't, be multi-threaded properly and thus slow down the whole thing,..)

x264 --preset placebo --crf 0 -o out.mp4 in.avi
Are yor aware that this will create a raw h.264 stream with an .avi extension and not an avi container, containing h.264 material?

Warpman
29th December 2012, 15:35
Also, crf 0 is lossless mode, i think some optimations are unavaible in lossless mode...


you sure you need lossless?

Blue_MiSfit
30th December 2012, 05:28
Yes, don't use placebo... dial it back to something sensible. You're doing CRF 0, so the difference in quality won't matter.

BTW - last I checked --crf 0 wasn't lossless, just stupidly high bitrate. This may have changed, but if you actually want lossless I'd use --qp 0.

Also, if your input is a camstudio lossless avi, how does x264 decode it? Possibly the built-in lavc decoder doesn't multithread? Try using AviSource in AviSynth.

DoomNlNE
30th December 2012, 07:20
"Can this be increased? " -> ever tried to not use placebo? (it's only using x percent since some of the placebo settings are not, probably can't, be multi-threaded properly and thus slow down the whole thing,..)


Are yor aware that this will create a raw h.264 stream with an .avi extension and not an avi container, containing h.264 material?
No. You are wrong about this. It creates an mp4, not an avi.

Different presets do not significantly increase CPU usage. The difference is around 5% (fast, slow, very slow, placebo).

I don't know what x264 uses to decode my video.

This video will not be watched in real time. It will be watched frame by frame, for analysis of its content. So I need every single frame intact with no weird blending or blurring. I'm scared of lossy because of this. Also, I would need every frame as a key frame (60 fps).

Can lossy use 100% of my CPU without destroying frames and keeping all key frames?
Please recommend a setting for this :)

J_Darnley
30th December 2012, 11:53
BTW - last I checked --crf 0 wasn't lossless, just stupidly high bitrate. This may have changed, but if you actually want lossless I'd use --qp 0.

FYI x264 will produce lossless when using --crf 0 but only with an 8-bit build. Yes the recommended way is now --qp 0 so that you get the same behaviour with every build.

I don't know what x264 uses to decode my video.
What does x264 say it is using? There should be a line printed before encoding saying what input module it is using.

This video will not be watched in real time. It will be watched frame by frame, for analysis of its content. So I need every single frame intact with no weird blending or blurring. I'm scared of lossy because of this. Also, I would need every frame as a key frame (60 fps).

Can lossy use 100% of my CPU without destroying frames and keeping all key frames?
Please recommend a setting for this :)
You are not getting a key frame for every frame at present. Lossless and how x264 places key frames are independent of each other. If you really want every frame to be a key frame you need --keyint 1

I think you should probably paste all the text that x264 prints during its run.

Blue_MiSfit
30th December 2012, 12:18
I'd be shocked if you see visible artifacts about something like --crf 14.

DoomNlNE
30th December 2012, 12:26
Cool! --keyint 1 is what I need. I will also try --crf 14.

Here is what I usually get with my original settings:

x264 --preset veryslow --qp 0 -o out.mp4 in.avi
ffms [info]: 320x240p 0:1 @ 60062/1001 fps (vfr)
resize [warning]: converting from bgr24 to yuv420p
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High 4:4:4 Predictive, level 2.2, 4:2:0 8-bit
x264 [info]: frame I:4440 Avg QP: 0.00 size: 39406
x264 [info]: frame P:806541 Avg QP: 0.00 size: 2354
x264 [info]: mb I I16..4..PCM: 34.6% 14.4% 51.0% 0.0%
x264 [info]: mb P I16..4..PCM: 0.7% 0.4% 0.4% 0.0% P16..4: 8.1% 1.7% 1.
9% 0.5% 0.4% skip:85.9%
x264 [info]: 8x8 transform intra:25.0% inter:28.7%
x264 [info]: coded y,uvDC,uvAC intra: 83.6% 79.7% 79.6% inter: 5.3% 8.3% 8.3%
x264 [info]: i16 v,h,dc,p: 50% 44% 6% 0%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 39% 53% 5% 1% 0% 0% 0% 0% 1%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 44% 6% 3% 2% 2% 2% 1% 3%
x264 [info]: i8c dc,h,v,p: 23% 47% 29% 1%
x264 [info]: Weighted P-Frames: Y:1.7% UV:1.3%
x264 [info]: ref P L0: 46.9% 3.2% 3.3% 17.7% 0.5% 11.2% 1.2% 5.0% 0.2% 3.
5% 0.2% 2.6% 0.5% 2.2% 0.2% 1.6%
x264 [info]: kb/s:1227.55

encoded 810981 frames, 143.51 fps, 1227.56 kb/s

DoomNlNE
30th December 2012, 14:07
WTF!!! Veryslow lossless file is 2GB while the slow crf14 is 10GB.

This doesn't make much sense does it? I'm losing quality and getting 5x the file size..... ?

sneaker_ger
30th December 2012, 15:11
Slow crf14 done with --keyint 1 and veryslow lossless not? Easily compressible content (lots of static blocks)?

LoRd_MuldeR
30th December 2012, 16:00
Yeah, "--keyint 1" is certainly going to hurt compression efficiency quite a lot, as every frame will be an IDR-Frame and inter-frame compression cannot be used at all.

Use this only if you really need every frame to be a key-frame...

(As far as I remember, the "lossless" mode will automatically disable B-Frames, but it will still use P-Frames, which is quite an advantage over "--keyint 1")