View Full Version : What Are The Most CPU-Intensive x264 Options?
JPSiemer
10th July 2008, 13:24
Sorry if there is a thread like this... couldn't find anyhing after an extensive Google search so I came here...
I have been encoding for the Xbox running XBMC in the last couple of months. The Xbox is limited in terms of hardware, so I must be careful about the settings I choose or the video justs skips like crazy. So in order to improve what I am doing, I need a better understanding of which options are the most CPU-intensive on the *decoding* side... I would be nice to get an order from most intense to least intense, citing any additional knowledge you might have that would help me out.
I already know CABAC and Deblocking are at the top of the list, so what is next... ?
Dark Shikari
10th July 2008, 13:44
The only things that significantly affect decoding speed are CABAC, deblocking, bitrate, and resolution. Direct-8x8 inference could potentially give a very small speedup also, but that's on by default at any level higher than 3.0 or so.
cogman
10th July 2008, 14:31
The only things that significantly affect decoding speed are CABAC, deblocking, bitrate, and resolution. Direct-8x8 inference could potentially give a very small speedup also, but that's on by default at any level higher than 3.0 or so.
what about references? I thought higher numbers of reference frames required more decoding power.
Dark Shikari
10th July 2008, 14:34
what about references? I thought higher numbers of reference frames required more decoding power.Not really, maybe a tiny bit more cache usage but that's about it.. not significant from my tests.
JPSiemer
11th July 2008, 19:40
That doesn't make much sense... There has got to be something else making decoding difficult for the Xbox. I'll show you why...
Encode #1
program --pass 2 --bitrate 1150 --stats ".stats" --keyint 240 --min-keyint 24 --ref 5 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto --nf --subme 7 --trellis 2 --partitions all --8x8dct --ipratio 2.8 --pbratio 2.6 --vbv-bufsize 1500 --vbv-maxrate 5000 --ratetol 15 --me umh --merange 24 --threads auto --thread-input --cqmfile "C:\CQMs\EQM_AVC_HR.cfg" --progress --no-psnr --no-ssim --output "output" "input"
Encode #2
program --pass 2 --bitrate 1300 --stats ".stats" --level 4.1 --keyint 240 --min-keyint 24 --ref 5 --no-fast-pskip --bframes 6 --b-rdo --weightb --nf --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4 --ipratio 2.8 --pbratio 2.6 --ratetol 25.0 --me umh --merange 32 --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
Encode #1 is the default agreed-upon Xbox setting for 720x400 and under. Video is a bit skippy in high action scenes. If you go over a resolution of 720x400 you must turn CABAC off and drop the bitrate or it will skip like crazy. Encode #2 is some settings I stumbled upon that just work wonders. The encodes look just as good as #1, allow for an ~150 KBps more bitrate, and skip a lot less.
Obviously #1 is maxed out settings and #2 is conservative, but what is actually causing most of the damage? I would like to be able to max out what I can, and discard the CPU-intensive tasks while still preserving the same quality.
Any more suggestions?
Dark Shikari
11th July 2008, 20:01
--ipratio 2.8 --pbratio 2.6 What the hell? :eek::confused:
Comatose
12th July 2008, 00:03
Since you seem to be encoding at SD resolutions, dropping merange to 16 shouldn't hurt quality much and will make encoding much faster :3
JPSiemer
13th July 2008, 23:59
Since you seem to be encoding at SD resolutions, dropping merange to 16 shouldn't hurt quality much and will make encoding much faster :3
Thanks for the suggestion but I am not looking for faster encodes... I need max quality with as little decoding power as possible.
JPSiemer
14th July 2008, 00:01
What the hell? :eek::confused:
What is wrong with this?
Dark Shikari
14th July 2008, 00:55
What is wrong with this?Its a recipe for disaster, quality wise.
Stop touching those options unless you have a good reason.
akupenguin
14th July 2008, 02:11
Obviously #1 is maxed out settings and #2 is conservative, but what is actually causing most of the damage? I would like to be able to max out what I can, and discard the CPU-intensive tasks while still preserving the same quality.
There aren't many difference there that could conceivably have any effect, so I have to guess.
CQM might increase the number of nonzero blocks per bitrate (i.e. time spent in IDCT).
B-pyramid reduces the the amount of non-standard-compliant shortcuts possible with -lavdopts fast, but doesn't affect speed without that decoder option.
JPSiemer
15th July 2008, 07:02
B-pyramid reduces the the amount of non-standard-compliant shortcuts possible with -lavdopts fast, but doesn't affect speed without that decoder option.
I'm a confused as to what that means... My best guess at what you are saying is... If I edit my mplayer.conf and add:
lavdopts=fast
Any video encoded with B-Pyramid will decode faster? Is this right? Or am I completely wrong???
----
On another note, in my mplayer.conf I also have:
lavdopts=skiploopfilter=bidir
This disables deblocking to an extent... Are there any other commands like these that I can use that will help me out but not diminish the quality of playback?
Comatose
15th July 2008, 07:23
He said it reduces the amount of shortcuts, implying it slows down decoding with -lavdopts fast, but if you don't have it enabled then it doesn't affect speed.
LoRd_MuldeR
15th July 2008, 12:14
As far as I understand, "lavdopts=fast" will speed-up the "libavcodec" decoder a bit. But when you use B-Pyramid, then this speed-up is less efficient (that is: less speed-up).
Without "lavdopts=fast" the B-Pyramid has no effect on speed. Also other decoders than "libavcodec" are not effected at all (unless they offer a similar speed-up trick).
bitbit
21st July 2008, 07:27
How about qpels? Interpolation seems to require a lot of computation.:o
SilentTweak
22nd July 2008, 16:53
So to add to this conversation, currently in my anime encodes I use B-Frames 3 and Ref. 10. Would upping these to 16 each put a HUGE impact on the people who can decode it? And how significant is the decoding power difference from 400p to 720p?
LoRd_MuldeR
22nd July 2008, 16:58
I think it was said that more References do not increase the CPU usage much, they just require a bit more RAM to cache the references.
But keep in mind that hardware-decoders (standalone-players) usually are limited to a pretty low number of reference frames...
Shinigami-Sama
22nd July 2008, 21:22
So to add to this conversation, currently in my anime encodes I use B-Frames 3 and Ref. 10. Would upping these to 16 each put a HUGE impact on the people who can decode it? And how significant is the decoding power difference from 400p to 720p?
you just have to watch out for DXVA compatiblity with those references
and 720p I can decode on my laptop's 3500+ newcastle @ 2.2ghz with about 5-15% headroom with FFDShow
so most people should be able to watch it no problems
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.