x264 tuneing of "normal" settings

[gigah72]

i see alot of efford in getting x264 tuned in the "insane" area of encoding, where you usually run your encode during night, but for me (and maybe others, too?!) it's simply not the working case.
i use settings like this: --crf 20 --ref 3 --bframes 3 --b-pyramid --weightb --bime --direct temporal --filter -2:-1 --analyse p8x8,b8x8,i8x8 --8x8dct --no-fast-pskip --subme 2 --mixed-refs --progress --threads auto --no-dct-decimate --level 4 --aq-strength 0.5 --aq-sensitivity 5 --ipratio 1.1 --pbratio 1.1 --cqmfile prestige.cqm
they give me what i want in a reasonable encodingtime. electricity is not for free, atleast not where i live.
are the normal routines in x264 for far at the limit what is possible to optimize for speed/quality, or is it just not interesting to spend time in getting them faster or better in same time?

[Dark Shikari]

i see alot of efford in getting x264 tuned in the "insane" area of encoding, where you usually run your encode during night, but for me (and maybe others, too?!) it's simply not the working case.
i use settings like this: --crf 20 --ref 3 --bframes 3 --b-pyramid --weightb --bime --direct temporal --filter -2:-1 --analyse p8x8,b8x8,i8x8 --8x8dct --no-fast-pskip --subme 2 --mixed-refs --progress --threads auto --no-dct-decimate --level 4 --aq-strength 0.5 --aq-sensitivity 5 --ipratio 1.1 --pbratio 1.1 --cqmfile prestige.cqm
they give me what i want in a reasonable encodingtime. electricity is not for free, atleast not where i live.
are the normal routines in x264 for far at the limit what is possible to optimize for speed/quality, or is it just not interesting to spend time in getting them faster or better in same time?
--crf 20 --ref 3 --bframes 3 --b-pyramid --weightb --bime --direct temporal --filter -2:-1 --analyse p8x8,b8x8,i8x8 --8x8dct --no-fast-pskip --subme 2 --mixed-refs --progress --threads auto --no-dct-decimate --level 4 --aq-strength 0.5 --aq-sensitivity 5 --ipratio 1.1 --pbratio 1.1 --cqmfile prestige.cqm
You're combining some high-end low-speed options (no-fast-pskip) with some really low-end options (--subme 2 and no --analyse i4x4).

Prestige has a habit of screwing things up too.

My personal "balance of speed/quality" settings:

--ref 3 --bframes 16 --b-pyramid --weightb --bime --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 6 --mixed-refs --me hex --trellis 1
(add whatever other flags you need to it, like AQ, threads, CRF, deblocking, etc)

A bit faster:

--ref 2 --bframes 16 --b-pyramid --weightb --bime --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 5 --mixed-refs --me hex --trellis 1

Still faster:

--bframes 16 --weightb --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 4 --me hex --trellis 1

Also note that lower CRF/higher bitrate values result in considerably slower encoding.

[Atak_Snajpera]

Why do you use prestige.cqm along with AQ. AQ is enough.

[gigah72]

thank you guys for comments and suggestions to my settings, but my posting was not ment to be about them in particular, but as a general question about future optimazions going on to x264, not to the anyway time consuming options, but if there is room for further speed/quality gain to the "lower" settings like "subme 2", "me hex", etc. or if there something in the work e.g. to get "me hex" replaced by something with same quality, but much fast, or much better at same speed. i hope, i explaind this time better. :)

[ggf31416]

but if there is room for further speed/quality gain to the "lower" settings like "subme 2", "me hex", etc. or if there something in the work e.g. to get "me hex" replaced by something with same quality, but much fast, or much better at same speed. i hope, i explaind this time better. :)

I think some options are already very optimized, for example see this post http://forum.doom9.org/showpost.php?p=1044455&postcount=19

And no, there is no such thing as too many hexagons. Its pretty much the optimal search shape for speed and quality in my (limited) experience.

[Dark Shikari]

Yeah, many of the lower settings are already pretty heavily optimized.

--subme might get faster, --me hex most certainly isn't unless I can invent some magical algorithm :p

If --subme 2 --me hex isn't fast enough, I think you need a new CPU :cool:

I will try to work on some speedups though; one possibility is an improved early termination algorithm for multiple reference frames; currently it just skips the subpixel refine, not the main motion search, so slower motion search algorithms like --me umh are even slower with tons of reference frames.