x264 presets, profiles, and tuning system

[juGGaKNot]

--preset placebo --tune animation --pass 1 --level %mylevel% --bframes 5 --keyint %kint% --min-keyint %mint% --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 24000 --vbv-maxrate 24000

=

Writing library : x264 core 68 r1181M 49bf767
Encoding settings : cabac=1 / ref=11 / deblock=1:1:1 / analyse=0x3:0x133 / me=tesa / subme=9 / psy_rd=0.4:0.0 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-2 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=5 / b_pyramid=0 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=300 / keyint_min=30 / scenecut=40 / rc=2pass / bitrate=4500 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=24000 / vbv_bufsize=24000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.60

cmd :

Encoding X264 First Pass :

avis [info]: 1136x656 @ 30.00 fps (756 frames)
x264 [info]: using SAR=1/1
x264 [warning]: VBV bitrate (24000) > level limit (20000)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
x264 [info]: slice I:12 Avg QP:20.32 size: 32605
x264 [info]: slice P:299 Avg QP:22.35 size: 28404
x264 [info]: slice B:445 Avg QP:26.03 size: 15156
x264 [info]: consecutive B-frames: 4.6% 43.3% 23.4% 14.0% 6.7% 8.1%
x264 [info]: mb I I16..4: 57.2% 0.0% 42.8%
x264 [info]: mb P I16..4: 40.7% 0.0% 0.0% P16..4: 54.1% 0.0% 0.0% 0.0% 0
.0% skip: 5.2%
x264 [info]: mb B I16..4: 12.6% 0.0% 0.0% B16..8: 43.5% 0.0% 0.0% direct:
18.5% skip:25.3% L0:36.3% L1:45.4% BI:18.3%
x264 [info]: final ratefactor: 22.60
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra:53.2% 54.2% 21.2% inter:34.0% 29.7% 1.7%
x264 [info]: kb/s:4961.5

encoded 756 frames, 6.83 fps, 4961.69 kb/s

Encoding X264 Second Pass :

avis [info]: 1136x656 @ 30.00 fps (756 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
x264 [info]: slice I:12 Avg QP:18.77 size: 33160
x264 [info]: slice P:299 Avg QP:23.25 size: 23088
x264 [info]: slice B:445 Avg QP:26.78 size: 14818
x264 [info]: consecutive B-frames: 4.6% 43.3% 23.4% 14.0% 6.7% 8.1%
x264 [info]: mb I I16..4: 22.6% 72.0% 5.4%
x264 [info]: mb P I16..4: 5.5% 23.4% 1.2% P16..4: 39.0% 13.8% 5.1% 0.2% 0
.1% skip:11.8%
x264 [info]: mb B I16..4: 1.4% 5.9% 0.5% B16..8: 46.3% 3.0% 2.6% direct:
10.7% skip:29.5% L0:47.8% L1:45.7% BI: 6.5%
x264 [info]: 8x8 transform intra:76.9% inter:89.1%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra:67.1% 64.9% 22.3% inter:35.2% 30.8% 1.6%
x264 [info]: ref P L0 66.2% 12.6% 7.6% 3.7% 2.9% 2.2% 1.6% 0.9% 0.7% 0.
8% 0.7%
x264 [info]: ref B L0 67.3% 12.5% 7.2% 3.7% 2.8% 2.1% 1.4% 1.1% 1.0% 0.
9%
x264 [info]: kb/s:4411.2

encoded 756 frames, 0.41 fps, 4411.24 kb/s


Main 4.0 has a vbv limit of 20000, i use 24000, problem ? should i go with 4.1 for ps3/xbox/etc ?

[nurbs]

The --longhelp of x264 seems to indicate that --qp 23 is the default. Typo I guess.

[Dark Shikari]

The --longhelp of x264 seems to indicate that --qp 23 is the default. Typo I guess.No, 23 is the default QP if you use select QP mode in the library but don't set a QP. CRF is still the default encoding mode.

I should probably modify it to print the default CRF as well.

[akupenguin]

But --longhelp is for x264cli, and only incidentally documents the library's defaults too.

[nurbs]

I'm talking about the cli. When I look at it as it is now with --bitrate, --qp and --crf listed and only --qp has a default value next to it it gives me the impression that this is also the default mode.

[Dark Shikari]

I'm talking about the cli. When I look at it as it is now with --bitrate, --qp and --crf listed and only --qp has a default value next to it it gives me the impression that this is also the default mode.Yes, this is fixed locally.

[Kurtnoise]

At most --device settings should perform like --profile. Disable certain options (like b-pyramid, cabac, etc) and limit other options like bframes and references to a certain maximum number.
2nd attempt (http://pastebin.com/f66945224), is it better ?

[rack04]

In a two pass encode will there be any noticeable quality loss using fast first pass vs slow first pass?

[buzzqw]

no noticeable. i loss is present, but usually is imperceptible

BHH

[Kurtnoise]

2nd attempt (http://pastebin.com/f66945224), is it better ?
so, any comments ? is it the right way or not ?

[Dark Shikari]

1. You haven't set VBV settings for PS3/Xbox360.

2. The reference frame numbers seem too low in most cases, and a --device setting should never raise --ref, ever.

3. The VBV settings seem completely arbitrary.

4. The Apple TV is definitely not limited to SD Level 3.0.

... and so forth. This is why I don't really like the idea of a device preset, because everything is going to be wrong.

[GodofaGap]

--weightb (-w) replaced with --no-weightb (default is now on)
--8x8dct (-8) replaced with --no-8x8dct (default is now on)
--no-psnr replaced with --psnr (default is now off)
--no-ssim replaced with --ssim (default is now off)
--mixed-refs replaced with --no-mixed-refs (default is now on)
--progress replaced with --no-progress (default is now on)

Is there any reason why these options haven't become a boolean? For example '--8x8dct true' or '--8x8dct false'.

I don't expect defaults to change anytime soon again, but it would make user custom settings or GUI frontends more future proof. You can simply put out the recommendation to GUI developers to always enforce the setting instead of relying on the default.

[Ulf]

The whole concept of presets, profiles and tunings is great.
If I want do use any combination of preset/tuning and still produce a Blu-ray compliant output, will the following command line options do the trick?


--preset <any> --tune <any> --level 4.1 --bframes 3 --keyint 24 --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 38000 --mvrange 511 --aud --nal-hrd

[Dark Shikari]

The whole concept of presets, profiles and tunings is great.
If I want do use any combination of preset/tuning and still produce a Blu-ray compliant output, will the following command line options do the trick?


--preset <any> --tune <any> --level 4.1 --bframes 3 --keyint 24 --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 38000 --mvrange 511 --aud --nal-hrd
Yup. --mvrange 511 is pointless though.

[Ulf]

Dark,

Would it be too much to ask for a --blu-ray option that sets:


--level 4.1 --bframes 3 --keyint ROUND(input framerate) --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 38000 --aud --nal-hrd


Coding for Blu-ray would then be as simple as:


--preset <any> --tune <any> --blu-ray


apart from selecting a proper bitrate.

[LoRd_MuldeR]

Adding one switch per target device would clutter the interface. If at all "--device bluray" would be added, along with other target devices.

We already have a patch suggestion for adding a "--device" parameter:
http://forum.doom9.org/showpost.php?p=1305004&postcount=107

Also keep in mind that the "--nal-hrd" parameter isn't available in official x264 ;)

[Ulf]

Adding one switch per target device would clutter the interface. If at all "--device bluray" would be added, along with other target devices.

We already have a patch suggestion for adding a "--device" parameter:
http://forum.doom9.org/showpost.php?p=1305004&postcount=107

Also keep in mind that the "--nal-hrd" parameter isn't available in official x264 ;)

OK. I didn't think of Blu-ray as a device, but rather as a specification with some specific restrictions and demands. A "--device bluray" parameter would be nice though - I didn't find it in the post you referred to.

By the way, why isn't the "--nal-hrd" parameter included in the official x264?

[LoRd_MuldeR]

A "--device bluray" parameter would be nice though - I didn't find it in the post you referred to.

But it would be easy to add to a "--device" system, like suggested by that (http://pastebin.com/f66945224) patch.

By the way, why isn't the "--nal-hrd" parameter included in the official x264?

...because it's part of the experimental "x264_hrd_pulldown" patch.

[akupenguin]

Is there any reason why these options haven't become a boolean? For example '--8x8dct true' or '--8x8dct false'.
Unix convention.

[rack04]

Dark,

Would it be too much to ask for a --blu-ray option that sets:


--level 4.1 --bframes 3 --keyint ROUND(input framerate) --min-keyint 1 --vbv-bufsize 30000 --vbv-maxrate 38000 --aud --nal-hrd


Coding for Blu-ray would then be as simple as:


--preset <any> --tune <any> --blu-ray


apart from selecting a proper bitrate.

Is Blu-ray limited to --ref 3? Also, --bframes 3 is default. Is --tune film needed in the first pass if using fast first pass?

[LoRd_MuldeR]

Max decoded picture buffer size (MaxDPB) for Level 4.1 is 12.288.000 Bytes. This allows a maximum of 3 references for 1920x1080 video.

[rack04]

Max decoded picture buffer size (MaxDPB) for Level 4.1 is 12.288.000 Bytes. This allows a maximum of 3 references for 1920x1080 video.

So even though --preset slow sets the --ref 5 x264 will automatically lower to --ref 3 if the --level 4.1 is specified?

[Dark Shikari]

Max decoded picture buffer size (MaxDPB) for Level 4.1 is 12.288.000 Bytes. This allows a maximum of 3 references for 1920x1080 video.No, it allows a maximum of 4 references.

[LoRd_MuldeR]

So even though --preset slow sets the --ref 5 x264 will automatically lower to --ref 3 if the --level 4.1 is specified?

Nope, x264 displays a warning and continues anyway in that case ;)

No, it allows a maximum of 4 references.

My bad. My calculation came out at 3.9, so I took the floor. But I see the mistake now :o

(MaxDPB is specified in KByte and a KByte has 1024 bytes, so the MaxDPB for Level 4.1 is 12.582.912 bytes, not 12.288.000)

But why do all "Blu Ray" presets (e.g. in MeGUI) use 3 references then?

[kemuri-_9]

Nope, x264 displays a warning and continues anyway in that case ;)

no, if you specify a level with --level, x264 will decrease the ref count to comply with that level.

Edit:
this happens unless you specify --ref yourself...

[GodofaGap]

Unix convention.
Not really the answer I'd hoped for, but I guess it's a reason.

[Kurtnoise]

This is why I don't really like the idea of a device preset, because everything is going to be wrong.
from my own tests (only with ipod/iphone though), that worked fine.

Maybe we should ask to users to test different encoding files to see the real limits of each devices ? I'm sure that some people have such devices as described above and that way you can tweak each presets. What do you think ?

[Selur]

about the whole device preset: Don't like the idea, but if it will, such a preset should set some default values and !enforce! known min/max settings. ;)

[microchip8]

Not really the answer I'd hoped for, but I guess it's a reason.

yeah, and why not have
--8x8dct enable or --8x8dct disable
or
--8x8dct lightson or --8x8dct lightsoff
or
--8x8dct positive or --8x8dct negative
or
--8x8dct switchon or --8x8dct switchoff

The thing is that there's no need to change the current way of enabling/disabling an option. It works and people understand and are used to it for a very long time. Also as said, UNIX convention

[Selur]

then how about using an integer? 0=disabled, 1=enabled, 2+ whatever you need, afaik unix conventions shouldn't have any problems with it, alternatively keeping e.g. --fast-pskip and --no-fast-pskip instead of just the one that's not currentliy covered by the default? ;)

[ACoolie]

alternatively keeping e.g. --fast-pskip and --no-fast-pskip instead of just the one that's not currentliy covered by the default? ;)

Just because it isn't in --long-help doesn't mean --fast-pskip doesn't work (hint: it does work).

[Snowknight26]

(MaxDPB is specified in KByte and a KByte has 1024 bytes, so the MaxDPB for Level 4.1 is 12.582.912 bytes, not 12.288.000)

Wouldn't you have to take padding into consideration, so refs=floor(8*(2^20)/((width+(width%16))*(height+(height%16))))?

[LoRd_MuldeR]

wouldn't you have to take padding into consideration, so refs=floor(8*(2^20)/((width+(width%16))*(height+(height%16))))?

Makes no difference in this case: 1920 % 16 = 0, 1088 % 16 = 0

[Snowknight26]

Makes no difference in this case: 1920 % 16 = 0, 1088 % 16 = 0

Right, in this case it doesn't, but I'm looking for it more in terms of a general rule.

[flebber]

For presets and tuning options is there a way to have the x264 cli tell us what options are contained within, so print out their command line output.

so for example.

> x264 print preset --medium
>x264 subme6 --umh etc

So that we can clearly see what options are contained and will be used before encoding? Like a cli help option

[kolak]

Is Blu-ray limited to --ref 3? Also, --bframes 3 is default. Is --tune film needed in the first pass if using fast first pass?

Blu-ray is 4 ref frames, but if you use 3 B frames than GOP should be <=28 frames (for 60i). With 2 B frames is <=30 frames. Also if you use 3 B frames with Pyramid codding than number of reference frames changes to 3 max.
This is according to one of the pro encoders.


Andrew

[Audionut]

2 quick questions.

I thought deadzones didn't work with trellis. Has this changed? If not, why does --tune grain adjust deadzone with trellis enabled? Is this incase one uses --tune grain --trellis 0?

Also, why was --thread-input left out of the defaults?

[Kurtnoise]

Also, why was --thread-input left out of the defaults?
probably because some OSs don't use avisynth...

[Audionut]

probably because some OSs don't use avisynth...

--tune windoze
--tune linux

:devil:

[Dark Shikari]

2 quick questions.

I thought deadzones didn't work with trellis. Has this changed? If not, why does --tune grain adjust deadzone with trellis enabled? Is this incase one uses --tune grain --trellis 0?

Also, why was --thread-input left out of the defaults?--threads auto implies --thread-input.

Deadzones still affect mode decision if trellis=1. And what if a user uses --tune grain and then uses a faster preset that disables trellis?

[kemuri-_9]

probably because some OSs don't use avisynth...

avisynth has nothing to do with thread-input,
thread-input means it takes whatever the input file it is (avisynth, y4m, or yuv/stdin) and has it read data into x264cli with its own thread.


#ifdef HAVE_PTHREAD
if( b_thread_input || param->i_threads > 1
|| (param->i_threads == X264_THREADS_AUTO && x264_cpu_num_processors() > 1) )
{
if( open_file_thread( NULL, &opt->hin, param ) )
...
#endif


which says that if any of
1. thread-input is flagged
2. threads > 1
3. threads = auto and processor count > 1
it will run the input within its own thread as long as there is threading support.

[shambles]

film:

--deblock -1:-1 --psy-rd 1.0:0.15

do both psy-rdo and psy-trellis allow values with 2 digits? they get written in the header with just 1 digit..

[LoRd_MuldeR]

do both psy-rdo and psy-trellis allow values with 2 digits? they get written in the header with just 1 digit..

They are floats, consequently their number of digits is only limited by the precision of single-precision (http://en.wikipedia.org/wiki/Single_precision) IEEE 754 ;)

However the param2string() function does only print out one digit:

s += sprintf( s, " psy_rd=%.1f:%.1f", p->analyse.f_psy_rd, p->analyse.f_psy_trellis );

[shambles]

They are floats

ah, thanks! :)

[Selur]

Any addition infos about "fastdecode" other than "It does what it says it does." anyone?

Cu Selur

[J_Darnley]

http://forum.doom9.org/showthread.php?t=130364&page=103#post1309302

[LoRd_MuldeR]

Any addition infos about "fastdecode" other than "It does what it says it does." anyone?

GIT is your friend ;)
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=d6eed014d0af8f87045d6d5daf3376c486efdea7

In short: Inloop-Deblocking, CABAC and Weighted B-Frame Prediction are disabled.

[Wishbringer]

@Dark Shikari:

because subme 10 was introduced after preset system,
why not change "--preset placebo" to include "--subme 10"?

edit: found, sorry, overlooked change in x264.c. I should really scroll down diffs to the very end.

[juGGaKNot]

@Dark Shikari:

because subme 10 was introduced after preset system,
why not change "--preset placebo" to include "--subme 10"?

it is.

[kemuri-_9]

the very bottom:
http://git.videolan.org/gitweb.cgi?p=x264.git;a=commitdiff;h=7733721e410acb96fdf740ca95d2a394b2a2b713#patch9