x264 presets, profiles, and tuning system

[Dark Shikari]

Presets will be used as follows:

--preset name

and apply before all other options. In other words, they override the x264 defaults, which, with the default changes (http://forum.doom9.org/showthread.php?t=148148), will be:

--subme 7 --bframes 3 --weightb --8x8dct --ref 3 --mixed-refs --trellis 1 --crf 23 --threads auto

As such, all options that you set will act on top of the preset you choose, regardless of the option order.

ultrafast:

--ref 1 --scenecut 0 --nf --no-cabac --bframes 0 --partitions none --no-8x8dct --me dia --subme 0 --aq-mode 0

veryfast:

--partitions i8x8,i4x4 --subme 1 --me dia --ref 1 --trellis 0

fast:

--mixed-refs 0 --ref 2 --subme 5

medium:

<defaults>

slow:

--me umh --subme 8 --ref 5 --b-adapt 2 --direct auto

slower:

--me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2

placebo:

--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16

For all encodes, regardless of preset or not, using --pass 1 will automatically trigger "turbo" settings, which are as follows and override all commandline options:

--trellis 0 --no-8x8dct --partitions none --me dia --ref 1 --subme MIN(2, previous subme)

This can be disabled using --slow-firstpass.

For all encodes, if you don't set your own --ref option and instead use the default or a preset, x264 will automatically lower --ref if the --level you set conflicts with it. If you set --ref explicitly, it will not override what you set.

Profiles will be used as follows:

--profile name

The options will be baseline, main, and high, which do what you think they do. Note that these override all other options no matter what, with two exceptions.. Because interlaced and lossless coding are options with very explicit meanings, the encoder will terminate with an error if you attempt to use them with an incompatible profile.

Tunings will be used as follows:

--tune name

The options will be "film" and "animation", and will tweak AQ strength, psy-rd/trellis strength, deblock, refs, and so forth:

film:

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

animation:

--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5

All of this is subject to change before final release, and suggestions are welcome.

If you don't use any of the new presets, the only changes for you will be the new defaults, and the automatic fast first pass.

[Kurtnoise]

That's cool...:)

May I suggest to add several devices presets (basically for PMPs & SAPs) ?

[Dark Shikari]

That's cool...:)

May I suggest to add several devices presets (basically for PMPs & SAPs) ?Maybe later.

[juGGaKNot]

Presets will be used as follows:

--me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2

placebo:

--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16

Slower should have merange 24, placebo 32.

Profiles will be used as follows:

--tune name

The options will be "film" and "animation", and will tweak AQ strength, psy-rd/trellis strength, deblock, refs, and so forth:

film:

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

animation:

--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5

The film tune looks actually better to me for animation ( cs 1.6 )

I will not be able to tweek psy-rd and vaq/autovaq on my own ?

These new option seem k for gui but not for cmd users.

[Kurtnoise]

Slower should have merange 24, placebo 32.
:rolleyes:

These new option seem k for gui but not for cmd users.
cmd users use more or less all switches, not presets. Period...

[juGGaKNot]

cmd users use more or less all switches, not presets. Period...

Ahh i was thinking that all cvars will be replaced, than good, so lets go.

[Selur]

Thanks for the update. :)
Little question regarding, profile:
Note that these override all other options no matter what, ...
with what ?

[juGGaKNot]

Thanks for the update. :)
Little question regarding, profile:

with what ?

"x264.exe --profile placebo --tune film" replaces any following cvar with "--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16 --deblock -1:-1 --psy-rd 1.0:0.15" i guess.

[Dark Shikari]

Thanks for the update. :)
Little question regarding, profile:

with what ?profile baseline will disable CABAC, B-frames, CQMs, 8x8dct no matter what. It will error out on interlaced video.

profile main will disable 8x8dct and CQMs no matter what.

profile high will do nothing as that's default.

All will error out on lossless.

[LoRd_MuldeR]

For all encodes, regardless of preset or not, using --pass 1 will automatically trigger "turbo" settings, which are as follows and override all commandline options:

--trellis 0 --no-8x8dct --partitions none --me dia --ref 1 --subme MIN(2, previous subme)

Is this done in the CLI interface or will it be enforced in the library?

I hope for the latter...

[Dark Shikari]

Is this done in the CLI interface or will it be enforced in the library?

I hope for the latter...Former.

[LoRd_MuldeR]

Former.

d'oh! (http://upload.wikimedia.org/wikipedia/en/3/3d/Homer_D'oh.png)

[roozhou]

animation:

--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5

IMHO default 0:0 should be OK.

[Selur]

Why does '--presets' will only change the defaults?
Will '--tune' also only change the defaults?
Wouldn't it be better to replace all the settings which are defined through the preset with the preset?

Cu Selur

Ps.: Sorry, but personally I don't like the idea to have 'presets&tune' in the cl interface, but I think that is mainly because the cl interface for me is something that's far more connected to the library itself, for me they belong into a gui.

[Audionut]

for me they belong into a gui.

I agree. However, I tend to see a lot of people thinking that megui is x264.

And so these same people complain to the x264 devs when megui does something stupid in a profile.

I see this as the x264 devs trying to minimize time wasted.

[LoRd_MuldeR]

Wouldn't it be better to replace all the settings which are defined through the preset with the preset?

I don't think so. The way it is planned you can easily pick a preset as your basic configuration and still adjust a few settings here and there.

If the preset would overwrite your custom options, you couldn't make use of presets anymore, as soon as you need to adjust one single parameter!

Also it would be very confusing to have parameters in the command-line that are valid, but will be ignored by x264...

[Keiyakusha]

--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5IMHO default 0:0 should be OK.

Deblock 1:1 usually better for anime than 0:0 but IMHO psy-rd should be 0.0:0 and no AQ until AutoVAQ patch will be added...

[Selur]

Also it would be very confusing to have parameters in the command-line that are valid, but will be ignored by x264...
Like when you would use '--profile' ?
Also when the options just override the defaults it's always a pain to look up the presets to know which of my options would not be changed.
I would prefer them to override not just the defaults and throw an error if some one added a parameter which tries to change them. This would also notify one if one presets changes in a manner that it covers a new variable.

Cu Selur

[LoRd_MuldeR]

Also when the options just override the defaults it's always a pain to look up the presets to know which of my options would not be changed.

The opposite is the case: With your suggestion, we would have a mixture of command-line parameter that are effective and parameters that will be ignored (because of the preset).

With the method that is planned, all command-line parameters that a specified explicitly will work as expected. Only parameters that are left out will default to the selected preset/profile.

Why should it be possible to specify valid parameters that will be ignored? Why should it be forbidden to select a preset and adjust single parameters ???

[Selur]

Did you miss:
"I would prefer them to override not just the defaults and throw an error if some one added a parameter which tries to change them. This would also notify one if one presets changes in a manner that it covers a new variable."
or did you ignore it on purpose?

Only parameters that are left out will default to the selected preset/profile.
did you miss:
Profiles will be used as follows:.... Note that these override all other options no matter what,...

Why should it be forbidden to select a preset and adjust single parameters ???
I my option:
- I think it is a bad idea to have 'changing' defaults.
- I think such syntactic sugar should not be included in the cl interface

Cu Selur

[Audionut]

- I think it is a bad idea to have 'changing' defaults.

There's a difference between changing defaults. ie: being changed on a regular basis, and, changed, ie: being changed after how many years?

Logic behind this change: x264 should be by default High Profile and generate relatively high quality, but not entirely max itself out; it should be a reasonable speed/quality tradeoff.

[Selur]

with 'changing' defaults like when you would use the presets to just overwrite the defaults, which would be possible on a regular basis; think you misunderstood me there, or I'm not getting you here :)

[LoRd_MuldeR]

Did you miss:
"I would prefer them to override not just the defaults and throw an error if some one added a parameter which tries to change them. This would also notify one if one presets changes in a manner that it covers a new variable."
or did you ignore it on purpose?

I think I made quite clear that it should be possible to select a preset and still customize single parameters.

Whether x264 simply ignores all parameters that are already covered by the preset or whether it throws an error when I try to explicitly change a parameter that is already covered by the preset, I just don't like the idea that the preset doesn't allow me to customize any parameters. It would lead to the situation where I would like to use preset X, but there's one parameter I need to adjust. Then I would have to completely drop the preset and specify ALL parameters explicitly. That's really not very convenient...

I my option:
- I think it is a bad idea to have 'changing' defaults.
- I think such syntactic sugar should not be included in the cl interface

I you like it better, you can think of it the following way:

First of all we start with the x264 defaults (always). Then we apply a preset (optionally). Finally we apply all custom parameters.

That's basically how any x264 GUI works. For example: In MeGUI you can select a preset first and then you can adjust single options in the configuration window ;)

So we basically don't change the default, but we provide "shortcuts" for popular parameter combination. You can call it however you like.

Still we should give the user the opportunity to change single parameters when needed, even when a preset was selected...

[Selur]

That's basically how any x264 GUI works.
and that's probably why I don't like it in a CL(I)

So we basically don't change the default, but we provide "shortcuts" for popular parameter combination. You can call it however you like.
I leave that job to you. :)

I think I made quite clear that it should be possible to select a preset and still customize single parameters.
No, you just made clear that you like it to be possible and like I mentioned int the part that you didn't take into account was that I don't. :)

I wanted to suggest that, in my opinion, --presets should like --profiles "override all other options no matter what,.." and/or complain then one changes an option that is already specified by the preset.
I got it that you don't share that opinion and we both have different ways we think about it, plain and simple. :D

Cu Selur

[elguaxo]

How about a "slowest" preset? Something between slower and placebo. Thanks :)

[tph]

How about a "slowest" preset? Something between slower and placebo. Thanks :)

"Slowest" would imply the slowest settings possible, i.e. even worse than placebo, otherwise it wouldn't be slowest.

[popper]

Quote:
Originally Posted by Kurtnoise
That's cool...

May I suggest to add several devices presets (basically for PMPs & SAPs) ?


Maybe later.

that being the case, can we finally have a 360 device preset ASAP too?.

that currently stands at, and plays without stutter is a max of 10Mbit/s H@L4.1, ref 3 for 1920×1080 at 30 fps (confirmed as the max for 25fps PAL 360 playability too, 11Mbit,ref3 was bad on beetlejuice dvd , as was 10Mbit,ref4) in a generic mp4 container.

http://support.xbox.com/support/en/us/xbox360/gamesandmedia/movies/videofaq/viewvideoplaybackfaq.aspx
"...
Q: What does the Xbox 360 console support for H.264?
A: The Xbox 360 console supports the following for H.264:

File extensions: .mp4, .m4v, mp4v, .mov, .avi
Containers: MPEG-4, QuickTime
Video profiles: Baseline, main, and high (up to level 4.1)
Video bit rate: 10 Mbps with resolutions of 1920 × 1080 at 30 fps. See the question about max bit rate, resolution, and frames per second.
Audio profiles: AAC, 2-channel, Low Complexity
Audio max bit rate: No restrictions. See the question about max bit rate, resolution, and frames per second.
..."

[Selur]

here's a suggestion for
ultrafast:
--ref 1 --scenecut 0 --partitions none --me dia --mvrange 64 --merange 4 --subme 0 --no-mixed-refs --no-chroma-me --no-8x8dct --aq-mode 0 --trellis 0 --threads auto --no-cabac --no-deblock --no-psnr --no-ssim --non-deterministic

[buzzqw]

X264;1;Ultra Fast;--keyint 250 --bframes 1 --trellis 0 --ref 1 --deblock 0,0 --subme 2 --direct spatial --me hex --no-ssim --merange 8 --b-adapt 0 --no-chroma-me --aud

X264;2;Very Fast;--keyint 250 --bframes 2 --trellis 0 --ref 2 --deblock 0,0 --subme 3 --direct spatial --me hex --no-ssim --merange 10 --b-adapt 0 --no-chroma-me --aud

X264;3;Fast;--keyint 250 --bframes 3 --trellis 0 --ref 3 --deblock -1,-1 --subme 4 --direct auto --me hex --no-ssim --merange 12 --weightb --b-adapt 2 --b-pyramid --partitions p8x8,i8x8 --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.0:0.0

X264;4;High Performance;--keyint 250 --bframes 3 --trellis 0 --ref 3 --deblock -1,-1 --subme 5 --direct auto --me dia --no-ssim --merange 14 --weightb --b-adapt 2 --b-pyramid --partitions p8x8,i8x8 --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.0:0.0

X264;5;Balanced;--keyint 250 --bframes 3 --trellis 0 --ref 3 --deblock -1,-1 --subme 5 --direct auto --me dia --no-ssim --weightb --b-adapt 1 --partitions p8x8,b8x8,i8x8 --8x8dct --aud --aq-mode 0 --aq-strength 0

X264;6;Better Quality;--keyint 250 --bframes 5 --mixed-refs --trellis 1 --ref 4 --deblock -1,-1 --subme 6 --direct auto --me umh --no-ssim --weightb --b-adapt 2 --b-pyramid --partitions p8x8,b8x8,i8x8 --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.0:0.0

X264;7;Extreme Quality;--keyint 250 --bframes 4 --mixed-refs --trellis 0 --ref 4 --deblock -1,-1 --subme 9 --direct auto --me umh --no-ssim --weightb --b-adapt 2 --no-chroma-me --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.1:0.0

X264;8;Insane Quality;--keyint 250 --bframes 6 --mixed-refs --trellis 2 --ref 6 --deblock -1,-1 --subme 7 --direct auto --me umh --no-ssim --merange 20 --weightb --b-adapt 2 --b-pyramid --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.0:1.0

X264;9;Slug;--keyint 250 --bframes 8 --mixed-refs --trellis 2 --ref 8 --deblock -2,-1 --subme 8 --direct auto --me esa --no-ssim --merange 24 --weightb --b-adapt 2 --b-pyramid --partitions p8x8,b8x8,i4x4,i8x8,p4x4 --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.1:1.0

X264;10;Placebo;--keyint 250 --bframes 16 --mixed-refs --trellis 2 --ref 16 --deblock -2,-1 --subme 9 --direct auto --me tesa --no-ssim --merange 24 --weightb --b-adapt 2 --b-pyramid --partitions all --8x8dct --aud --aq-mode 1 --aq-strength 1 --psy-rd 1.1:1.0

that's my 0.02€

BHH

[kumi]

Thanks Dark Shikari.

How about a new DV preset? In most of the prosumer camera footage I've seen, --deblock -1:-1 is too weak (0:0 works better for me). That makes me wonder if the other film preset parameters such as psy-rd are also in need of adjustment for DV. I'm no expert, so I can't say.

[nakTT]

slower:

--me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2

placebo:

--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16
Forgive me for this noob question,

Is that mean for "Slower" profile I should turn the "merange" from 24 (as in Placebo profile) to 0 (Zero) ?

:thanks:

[kemuri-_9]

Is that mean for "Slower" profile I should turn the "merange" from 24 (as in Placebo profile) to 0 (Zero) ?

No, if the preset doesn't mention the particular parameter, then it remains the default, in merange's case that is 16

[nakTT]

No, if the preset doesn't mention the particular parameter, then it remains the default, in merange's case that is 16
Many thanks for clear things up.

:thanks:

[10L23r]

cool, this sounds great

i think we should do something similar to msu's x264 preset comparison thing to find optimal combinations of options

@buzzqw- "high performance" is kinda ambiguous... and why does the 7th preset have subme9??

i think threads=1 should be added to the placebo preset

[Forteen88]

Slower should have merange 24, placebo 32.I think that x264 should set recommended merange automatically (but it should be possible to change), the higher resolution the higher merange. Around merange 28 for 1080p video.

[Yoshiyuki Blade]

I'm curious about the absence of b-pyramid anywhere in the settings. Is it insignificant, or problematic?

[Audionut]

I'm curious about the absence of b-pyramid anywhere in the settings. Is it insignificant, or problematic?

B-pyramid has a small enough benefit and large enough number of problems with some hardware devices that I don't want to deal with the bug reports.

http://forum.doom9.org/showthread.php?p=1301846#post1301846

[Yoshiyuki Blade]

http://forum.doom9.org/showthread.php?p=1301846#post1301846

D'oh! I can't believe I missed that. Thanks :)

[juGGaKNot]

I think that x264 should set recommended merange automatically (but it should be possible to change), the higher resolution the higher merange. Around merange 28 for 1080p video.

What about

64 for slow
128 for placebo

at 1920.

24 for slow
32 for placebo

at 720p.

LE : what about auto --keyint and --min-keyint aproximated for the fps ?

Now i use ffmpeg to get the fps and this script for 24-60 FPS :

set kint=240
set mint=24
if %myfps% GEQ 25 GOTO A1
:A1
if %myfps% LEQ 26 GOTO set1
if %myfps% GEQ 29 GOTO A2
:A2
if %myfps% LEQ 31 GOTO set2
if %myfps% GEQ 34 GOTO A3
:A3
if %myfps% LEQ 36 GOTO set3
if %myfps% GEQ 39 GOTO A4
:A4
if %myfps% LEQ 41 GOTO set4
if %myfps% GEQ 44 GOTO A5
:A5
if %myfps% LEQ 46 GOTO set5
if %myfps% GEQ 49 GOTO A6
:A6
if %myfps% LEQ 51 GOTO set6
if %myfps% GEQ 54 GOTO A7
:A7
if %myfps% LEQ 56 GOTO set7
if %myfps% GEQ 59 GOTO A8
:A8
if %myfps% LEQ 61 GOTO set8
:set1
set kint=250
set mint=25
GOTO END
:set2
set kint=300
set mint=30
GOTO END
:set3
set kint=350
set mint=35
GOTO END
:set4
set kint=400
set mint=40
GOTO END
:set5
set kint=450
set mint=45
GOTO END
:set6
set kint=500
set mint=50
GOTO END
:set7
set kint=550
set mint=55
GOTO END
:set8
set kint=600
set mint=60
GOTO END
:END
x264.exe --keyint %kint% --min-keyint %mint% blah blah blah

[Forteen88]

What about
64 for slow
128 for placebo

at 1920.What I've read, there's no reason/gain to have a merange over ~32 for 1080p, and IIRC, having a too high merange-value can be bad.

[juGGaKNot]

What I've read, there's no reason/gain to have a merange over ~32 for 1080p, and IIRC, having a too high merange-value can be bad.

ds sais "in theory full hd needs 128 merange" in theory ....

[burfadel]

Full HD needs a higher merange simply because the same spatial image is represented by a higher number of pixels, such that the higher the resolution the more pixels a block transverses between frames.

[Dark Shikari]

merange is the distance to search from the best predictor, not the maximum motion vector range.

Despite HD video having longer motion vectors, it also generally has smoother motion fields due to objects being of larger size, so it isn't necessarily guaranteed that you "need more merange" on an HD video.

[juGGaKNot]

merange is the distance to search from the best predictor, not the maximum motion vector range.

Despite HD video having longer motion vectors, it also generally has smoother motion fields due to objects being of larger size, so it isn't necessarily guaranteed that you "need more merange" on an HD video.

I see

what about the

--keyint and --min-keyint aproximated for the fps ?


Stuff ? this should be automated to the fps right ? if someone needs lower values ( like for blu-ray ) thay can overwrite it but the default should be fps x 10 / fps

But now its the 250/25 default.

[Manao]

Despite HD video having longer motion vectors, it also generally has smoother motion fields due to objects being of larger size, so it isn't necessarily guaranteed that you "need more merange" on an HD videoMotion vectors are larger, so whenever motion vectors differ, the difference is larger too. Motion vectors field isn't smooth on edges, and indeed the proportion of edges in HD (relatively to the number of macroblock) is lower, but on those edges, a higher ME range may make the difference.

[Selur]

Any news when the new options are going to be available, at least the default changes and the '--profile' was 'okay' for everyone. (aside from the point if bool/int values for the parameters would be better than parameter names with no-... at the beginning);)

[Dark Shikari]

Any news when the new options are going to be available, at least the default changes and the '--profile' was 'okay' for everyone. (aside from the point if bool/int values for the parameters would be better than parameter names with no-... at the beginning);)Assuming no new objections by akupenguin, I will commit the new defaults, and the profile/tune/preset system on Monday. Since the profile/tune/preset system is completely optional, GUIs don't need to update to use them just yet; they can do so at their leisure. The only thing that they will need to adapt to now is the new defaults.

[Selur]

Thanks for the info :)

[juGGaKNot]

Assuming no new objections by akupenguin, I will commit the new defaults, and the profile/tune/preset system on Monday. Since the profile/tune/preset system is completely optional, GUIs don't need to update to use them just yet; they can do so at their leisure. The only thing that they will need to adapt to now is the new defaults.

How about a way for the user to write custom profiles

--setting > xxx.profile

x264.exe xxx.profile.

Useless?

and the



--keyint and --min-keyint aproximated for the fps ?

Stuff ? this should be automated to the fps right ? if someone needs lower values ( like for blu-ray ) thay can overwrite it but the default should be fps x 10 / fps

But now its the 250/25 default.

Or the 250/25 is k for all range of fps values ?

[Kurtnoise]

How about a way for the user to write custom profiles

--setting > xxx.profile

x264.exe xxx.profile.

Useless?

yes...:rolleyes:

1/ you should first try to understand presets vs profiles meaning.
2/ if you want to customize something, use the current switches instead.

[Dark Shikari]

And it's in (http://git.videolan.org/?p=x264.git;a=commit;h=af2a4ecd7bcefc97c8aa83913c9a2980206f9cd0). Have fun everyone.

[Kurtnoise]

--tune touhou \0/

[smok3]

so it will be like:

a.
x264 --preset CRFfast --tune 'custom commands that will overwrite the preset' --profile 'that will overwrite whatever is 'wrong' in the preset, including bitrate'
or
b. ?

[Dark Shikari]

so it will be like:

a.
x264 --preset CRFfast --tune 'custom commands that will overwrite the preset' --profile 'that will overwrite whatever is 'wrong' in the preset, including bitrate'
or
b. ?No...

--preset <speed> --tune <content type> --profile <profile> --bitrate/--crf/--qp <whatever>

profile has no effect on bitrate. Order of commands doesn't matter for preset/tune/profile.

[buzzqw]

what about threads ?

is now --threads auto automatic ?

BHH

[Kurtnoise]

@DS:

diff --git a/x264.c b/x264.c
index e79f9ac..06d5b99 100644
--- a/x264.c
+++ b/x264.c
@@ -622,7 +622,7 @@ static int Parse( int argc, char **argv,
param->i_deblocking_filter_beta = 1;
param->analyse.f_psy_rd = 0.4;
param->rc.f_aq_strength = 0.6;
- param->i_bframe += 2;
+ param->i_bframe = param->i_bframe > 15 ? param->i_bframe : +2;
}
else if( !strcasecmp( optarg, "grain" ) )
{


that's maybe more accurate ?

[LoRd_MuldeR]

what about threads ?

is now --threads auto automatic ?

BHH

Yes.

index d7d45d3..9260c64 100644 (file)
--- a/common/common.c
+++ b/common/common.c
@@ -43,7 +43,7 @@ void x264_param_default( x264_param_t *param )
/* CPU autodetect */
param->cpu = x264_cpu_detect();
- param->i_threads = 1;
+ param->i_threads = X264_THREADS_AUTO;

[buzzqw]

thanks LoRd_MuldeR!

BHH

[smok3]

No...

--preset <speed> --tune <content type> --profile <profile> --bitrate/--crf/--qp <whatever>

profile has no effect on bitrate. Order of commands doesn't matter for preset/tune/profile.

thanks, so one can do something like;

--preset medium --tune animation --deblock -1:-1 --crf 22 --sar 16:11 --level high

to say encode ice age DVD for WD TV (i mean, is this a valid example)?

p.s. i don't know how i missed the 1st post before :/...

[akupenguin]

param->i_bframe = param->i_bframe > 15 ? param->i_bframe : +2;
that's maybe more accurate ?
No. Option ranges are clipped by libx264, no need to duplicate that code.

[Kurtnoise]

ok...

Here is a 1st attempt (http://pastebin.com/f2074a4cf) to create several tunings for some devices.

Any comments ?

[Dark Shikari]

Devices should not be under --tune. There's no reason I can't use --tune film --device ipod.

[MatMaul]

and you seem to override speed settings like --me which has nothing to do with devices compatibility.

[Kurtnoise]

Devices should not be under --tune. There's no reason I can't use --tune film --device ipod.
mmmh...right.

and you seem to override speed settings like --me which has nothing to do with devices compatibility.
it's because I would like override some default settings...but you can tweak this. :)

[ACoolie]

mmmh...right.

it's because I would like override some default settings...but you can tweak this. :)

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.

[Dark Shikari]

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.Exactly; device settings should, like profile, guarantee a certain output by overriding all other settings.

[Chengbin]

x264.nl finally updated.

I can't encode anymore. What was different with this build than before? I don't think a change in defaults change the format of the command line.

[kemuri-_9]

the change in defaults also affected some of the command line options to take reverse forms of what they were previously...
i.e.:

--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)


so if you were using any of the options on the left, you need to remove them from your new command line

[lcx]

^^Also notice the slow-firstpass parameter.
It wasn't clear to me why my 'ref' and some other settings were being ignored in 1st pass until I check looked at x264.c changes :D

[juGGaKNot]

The refs and level are now automated/resolution right ?

start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune animation --pass 1 --level %mylevel% --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 24000 --vbv-maxrate 24000 --output NUL %myavs%
start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune animation --pass 2 --level %mylevel% --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 24000 --vbv-maxrate 24000 --output "%mypath%\%mpath%\T1\%mymovie%.264" %myavs%

Questions :

The profile is MAIN and not high, how do i force high ?
Is --keyint and --min-keyint needed ? there rounder at fps x 10 / fps in my script

[J_Darnley]

juGGaKNot: The default settings give you a high profile video. If you don't disable the 8x8dct or set main or baseline profiles then it will remain as high profile. If you want a slow first pass then you had better set --slow-firstpass

Chengbin: If you still have problems and want help then you will have to post your command line.

[juGGaKNot]

juGGaKNot: The default settings give you a high profile video. If you don't disable the 8x8dct or set main or baseline profiles then it will remain as high profile. If you want a slow first pass then you had better set --slow-firstpass

Chengbin: If you still have problems and want help then you will have to post your command line.

File encoded with those settings :

Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 16 frames
Duration : 25s 200ms
Bit rate mode : Variable
Bit rate : 4 406 Kbps
Nominal bit rate : 4 500 Kbps
Maximum bit rate : 7 507 Kbps
Width : 1 148 pixels
Height : 666 pixels
Frame rate : 30.000 fps
Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=0.4:0.0 / mixed_ref=1 / me_range=16 / 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=20000 / vbv_bufsize=20000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.60

Encoding X264 First Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 4.0
x264 [info]: slice I:13 Avg QP:19.67 size: 32273
x264 [info]: slice P:293 Avg QP:22.62 size: 28497
x264 [info]: slice B:450 Avg QP:26.24 size: 15198
x264 [info]: consecutive B-frames: 4.6% 40.1% 23.8% 16.2% 8.1% 7.3%
x264 [info]: mb I I16..4: 58.9% 0.0% 41.1%
x264 [info]: mb P I16..4: 36.6% 0.0% 0.0% P16..4: 51.8% 0.0% 0.0% 0.0% 0
.0% skip:11.6%
x264 [info]: mb B I16..4: 13.1% 0.0% 0.0% B16..8: 43.0% 0.0% 0.0% direct:
17.9% skip:26.1% L0:36.8% L1:45.9% BI:17.3%
x264 [info]: final ratefactor: 22.81
x264 [info]: direct mvs spatial:99.6% temporal:0.4%
x264 [info]: coded y,uvDC,uvAC intra:56.1% 57.5% 21.8% inter:32.0% 28.1% 1.5%
x264 [info]: kb/s:4954.9

encoded 756 frames, 6.42 fps, 4955.04 kb/s

Encoding X264 Second Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [warning]: DPB size (16 frames, 18579456 bytes) > level limit (10 frames, 1
2582912 bytes)
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
[12.7%] 96/756 frames, 1.67 fps, 1583.70 kb/s, eta 0:06:36

So first pass is main fast, k.

What about the ref ? it did not work



For all encodes, if you don't set your own --ref option and instead use the default or a preset, x264 will automatically lower --ref if the --level you set conflicts with it. If you set --ref explicitly, it will not override what you set.


If i remove --level

Encoding X264 Second Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 5.0
[27.0%] 204/756 frames, 1.17 fps, 2143.48 kb/s, eta 0:07:50

LE :

--tune film works fine, animations does not

Encoding X264 First Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile Main, level 3.2
x264 [info]: slice I:13 Avg QP:18.35 size: 33820
x264 [info]: slice P:310 Avg QP:22.61 size: 27635
x264 [info]: slice B:433 Avg QP:25.91 size: 14609
x264 [info]: consecutive B-frames: 5.1% 42.3% 27.9% 24.8%
x264 [info]: mb I I16..4: 55.0% 0.0% 45.0%
x264 [info]: mb P I16..4: 37.0% 0.0% 0.0% P16..4: 53.1% 0.0% 0.0% 0.0% 0
.0% skip:10.0%
x264 [info]: mb B I16..4: 14.4% 0.0% 0.0% B16..8: 42.8% 0.0% 0.0% direct:
19.1% skip:23.6% L0:35.5% L1:44.7% BI:19.9%
x264 [info]: final ratefactor: 23.09
x264 [info]: direct mvs spatial:99.5% temporal:0.5%
x264 [info]: coded y,uvDC,uvAC intra:59.9% 60.3% 23.1% inter:31.6% 28.8% 1.2%
x264 [info]: kb/s:4867.3

encoded 756 frames, 8.79 fps, 4867.43 kb/s

Encoding X264 Second Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
x264 [info]: slice I:13 Avg QP:18.66 size: 34852
x264 [info]: slice P:310 Avg QP:23.90 size: 23569
x264 [info]: slice B:433 Avg QP:27.19 size: 14211
x264 [info]: consecutive B-frames: 5.1% 42.3% 27.9% 24.8%
x264 [info]: mb I I16..4: 24.4% 70.0% 5.6%
x264 [info]: mb P I16..4: 3.7% 20.3% 1.2% P16..4: 40.4% 13.8% 6.9% 0.1% 0
.0% skip:13.6%
x264 [info]: mb B I16..4: 0.9% 3.9% 0.2% B16..8: 49.5% 2.4% 2.8% direct:
13.4% skip:26.9% L0:47.7% L1:45.8% BI: 6.5%
x264 [info]: 8x8 transform intra:78.9% inter:83.9%
x264 [info]: direct mvs spatial:99.3% temporal:0.7%
x264 [info]: coded y,uvDC,uvAC intra:69.8% 69.9% 25.4% inter:36.4% 35.3% 1.5%
x264 [info]: ref P L0 65.1% 13.7% 7.8% 4.0% 3.3% 2.9% 2.0% 1.3%
x264 [info]: ref B L0 67.1% 13.5% 7.4% 4.3% 3.1% 2.6% 1.9%
x264 [info]: kb/s:4416.8

Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.2 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / 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=20000 / vbv_bufsize=20000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

echo Encoding X264 First Pass :
echo.
start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune film --pass 1 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000 --output NUL %myavs%
echo.
echo Encoding X264 Second Pass :
echo.
start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune film --pass 2 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000 --output "%mypath%\%mpath%\T1\%mymovie%.264" %myavs%

[nurbs]

You didn't bother to post your command line so I can't say for sure, but from the Mediainfo text it looks to me as if you used your own settings and not one of the presets or defaults. Your first pass only works because the refs are automatically lowered there anyway, and of course it's main profile since 8x8dct is on of the settings that gets dropped in first pass.

[juGGaKNot]

i did, see 70 and 72

start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune animation --pass 1 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 24000 --vbv-maxrate 24000 --output NUL %myavs%
start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune animation --pass 2 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 24000 --vbv-maxrate 24000 --output "%mypath%\%mpath%\T1\%mymovie%.264" %myavs%

And refs are 16, x264 [warning]: DPB size (16 frames, 18579456 bytes) > level limit (10 frames, 12582912 bytes)

echo Encoding X264 First Pass :
echo.
start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune film --pass 1 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000 --output NUL %myavs%
echo.
echo Encoding X264 Second Pass :
echo.
start "encode" /b /low /wait "%mypath%\bin\x264n.exe" --preset slower --tune film --pass 2 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000 --output "%mypath%\%mpath%\T1\%mymovie%.264" %myavs%

tune film and it is k

[nurbs]

You shouldn't have 16 refs then because --preset slower only uses 8. Also the mediainfo of your first encode shows plenty of settings different from --preset slower and different from the command line you posted.

[MasterNobody]

You shouldn't have 16 refs then because --preset slower only uses 8. Also the mediainfo of your first encode shows plenty of settings different from --preset slower and different from the command line you posted.
He should because --tune animation:
else if( !strcasecmp( optarg, "animation" ) )
{
param->i_frame_reference = param->i_frame_reference > 1 ? param->i_frame_reference*2 : 1;
param->i_deblocking_filter_alphac0 = 1;
param->i_deblocking_filter_beta = 1;
param->analyse.f_psy_rd = 0.4;
param->rc.f_aq_strength = 0.6;
param->i_bframe += 2;
}

P.S. But it should be reduced if he doesn't specify --ref manualy.

[J_Darnley]

P.S. But it should be reduced if he doesn't specify --ref manualy.
But it isn't. I think there is a problem with the automatic ref reduction. The code block enters but doesn't run the reduction because mbs = 0 for the videos I've tried.
[EDIT] This is because the input file has not been opened yet so the width and height are 0.
[EDIT2] Quick patch: http://pastebin.com/d5259ba1a Moves the code block to after the files are opened.

[juGGaKNot]

From the top, new encodes :

film :

--preset slower --tune film --pass 1 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000
--preset slower --tune film --pass 2 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000

CMD :

Encoding X264 Second Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 4.0
[51.5%] 389/756 frames, 1.75 fps, 3339.88 kb/s, eta 0:03:29

Output :

Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=1.0:0.2 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-3 / threads=3 / nr=0 / decimate=1 / mbaff=0 / bframes=3 / 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=20000 / vbv_bufsize=20000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

Animation :

--preset slower --tune animation --pass 1 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000
--preset slower --tune animation --pass 2 --keyint %kint% --min-keyint %mint% --stats "%mypath%\%mpath%\T1\%mymovie%.stats" --bitrate %btratex264% --sar 1:1 --aud --nal-hrd --vbv-bufsize 20000 --vbv-maxrate 20000

CMD :

Encoding X264 Second Pass :

avis [info]: 1148x666 @ 30.00 fps (756 frames)
x264 [warning]: width or height not divisible by 16 (1148x666), compression will
suffer.
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: profile High, level 5.0
[31.7%] 240/756 frames, 1.04 fps, 2234.92 kb/s, eta 0:08:15

Output :

Writing library : x264 core 68 r1179M 96e2229
Encoding settings : cabac=1 / ref=16 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy_rd=0.4:0.0 / mixed_ref=1 / me_range=16 / 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=20000 / vbv_bufsize=20000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.60

LE :

But it isn't. I think there is a problem with the automatic ref reduction. The code block enters but doesn't run the reduction because mbs = 0 for the videos I've tried.
[EDIT] This is because the input file has not been opened yet so the width and height are 0.
[EDIT2] Quick patch: http://pastebin.com/d5259ba1a Moves the code block to after the files are opened.

So when i force level 4.0 it will adjust the refs auto now not to break the level limit right ?

[Dark Shikari]

But it isn't. I think there is a problem with the automatic ref reduction. The code block enters but doesn't run the reduction because mbs = 0 for the videos I've tried.
[EDIT] This is because the input file has not been opened yet so the width and height are 0.
[EDIT2] Quick patch: http://pastebin.com/d5259ba1a Moves the code block to after the files are opened.Ah, good point. Will fix.

[me7]

slower:

--me umh --subme 9 --ref 8 --b-adapt 2 --direct auto --partitions all --trellis 2

placebo:

--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16


You suggest to keep 3 B-frames up to the 'slower' setting and raise the number only for 'placebo'. Are more then 3 B-frames really that useless?

[stax76]

StaxRip supports the stuff since version 1.1.1.2 beta.

http://img268.imageshack.us/img268/7379/x264.th.png (http://img268.imageshack.us/i/x264.png/)

[juGGaKNot]

placebo:

--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16

animation:

--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5

--profile : Note that these override all other options no matter what

Will the tune --animation work with placebo ?

[akupenguin]

Will the --tune animation work with placebo ?
Yes. It calls libx264 with --ref 32 --bframes 18, but libx264 clips all options to their valid range, including those.

[juGGaKNot]

placebo:

--me tesa --subme 9 --merange 24 --ref 16 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --bframes 16

animation:

--ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5

--profile : Note that these override all other options no matter what

Will the tune --animation work with placebo ?

Yes. It calls libx264 with --ref 32 --bframes 18, but libx264 clips all options to their valid range, including those.

So --preset placebo --tune animation =

--me tesa --subme 9 --merange 24 --b-adapt 2 --direct auto --partitions all --no-fast-pskip --trellis 2 --ref (previousref==1?1:MIN(previousref*2,16)) --deblock 1:1 --psy-rd 0.4:0 --aq-strength 0.6 --bframes 5 ?

Doesn't the --profile override the --tune settings ?

[LoRd_MuldeR]

Doesn't the --profile override the --tune settings ?

First of all the preset is applied. Next the tuning is applied. Then all explicit options are applied (and may overwrite what has been done so far). Finally the profile is enforced.

[juGGaKNot]

Finally the profile is enforced.

So the refs and b-frames must be removed from --profile placebo for the tune to actually work right ?

[LoRd_MuldeR]

So the refs and b-frames must be removed from --profile placebo for the tune to actually work right ?

Why? The "placebo" preset will set both, refs and b-frames, to 16. Then the "animation" tune will raise ref to 32 and b-frames to 18 - temporarily. They'll be clipped back to 16 anyway ;)

So I really cannot see a problem here. Except that there's not much to do for the tune option when starting with "placebo" settings. Well, it'll still adjust Filter, AQ and Psy-RD...

[Adub]

There is no --profile placebo. There is a --preset placebo, but no --profile.

[Lorax2161]

As it relates to tuning, would sports captured OTA in DV and encoded w/x264 be most likely to benefit from:

- general purpose (no specific tuning, raise preset/lower CRF as needed)
- film tuning
- as a classification, warrant it's own tuning like animation & film

This would predominantly involve field sports (football/soccer) and motor sports.

Thanks

[j8ee]

/.../
For all encodes, regardless of preset or not, using --pass 1 will automatically trigger "turbo" settings, which are as follows and override all commandline options:

--trellis 0 --no-8x8dct --partitions none --me dia --ref 1 --subme MIN(2, previous subme)

This can be disabled using --slow-firstpass.
/.../

I don't understand what the subme value will be. Could someone please explain how it's read - "--subme MIN(2, previous subme)"?

[smok3]

There is no --profile placebo. There is a --preset placebo, but no --profile.

there is gonna be bunch of useless questions concerning --preset and --profile i believe, is there another word for 'preset'? (like --shortcut, --default, --pref, --init, --setting, --behave ...)

[Dark Shikari]

I don't understand what the subme value will be. Could someone please explain how it's read - "--subme MIN(2, previous subme)"?MIN(x,y) means the minimum of x and y.

[j8ee]

Thanks, that what was I thought, but where does "previous subme" come from? Why "previous" - is it a subme value I provide and that's only read if it's used in the commandline before the --pass 1 switch, but disregarded if used after, or?


edit: Thanks again! Now I got it - "applied last" - the full commandline and all values are actually used, except those six switches substituted by the "--pass 1/turbo/fast first pass" settings. I got a little confused with that it would "override all commandline options".

[Dark Shikari]

Thanks, that what was I thought, but where does "previous subme" come from? Why "previous" - is it a subme value I provide and that's only read if it's used in the commandline before the --pass 1 switch, but disregarded if used after, or?"Previous"; the one that was set before the "fast first pass" was applied. "fast first pass" is applied last.

[LoRd_MuldeR]

In other words: Whatever Subme you have specified (either explicitly or via preset), for the first pass it won't be higher than 2.

If x264 detects a first pass and Subme is higher than 2, then Subme will be lowered to 2. Unless you specify "--slow-firstpass", of course.

[kemuri-_9]

seems someone updated the megui wiki for this, maybe it'll help clarify things
http://mewiki.project357.com/wiki/X264_Settings#Quick_Run_Support

[woah!]

would having a txt file with say bluray compatible settings in it, like a custom matrix file option: --preset placebo --tune film --profile "bluray.txt" then anyone can have txt files for different things... as it stands now, i cant "make" a profile unless i can code one into a certain build of x264 myself, or is that not the case?

you have "film" "animation" "grain" "psnr" but they dont help me for what i want to do to make sure of bluray forced compatible settings..

[juGGaKNot]

Why? The "placebo" preset will set both, refs and b-frames, to 16. Then the "animation" tune will raise ref to 32 and b-frames to 18 - temporarily. They'll be clipped back to 16 anyway ;)

So I really cannot see a problem here. Except that there's not much to do for the tune option when starting with "placebo" settings. Well, it'll still adjust Filter, AQ and Psy-RD...

The placebo will set them at 16/16
The tune will set them at max refs/level ( if i force 4.o it will use 7-8 for 1280x720 right ? ) and bframes to 5

i want the placebo but with 5 bframes and the automated refs.

The tune animation will clip bframes at 5and refs/level, thats what i'm asking.

[kemuri-_9]

--preset placebo --tune animation --level 4.0 --bframes 5

would be ideally what you seem to be looking for, but as the automated ref reduction is having problems you should also add --ref 9 to that
so it becomes:
--preset placebo --tune animation --level 4.0 --ref 9 --bframes 5

[Dark Shikari]

--preset placebo --tune animation --level 4.0 --bframes 5

would be ideally what you seem to be looking for, but as the automated ref reduction is having problemsnot anymore

[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. ;)

[froggy1]

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

[juGGaKNot]

@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.

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

I have edited the wiki page (http://mewiki.project357.com/wiki/X264_Settings) to avoid confusion.

[jwdaigle]

Hello x264 experts -

I am trying to come up with "best for me" settings that work well on mostly hi def sources, mostly action movies. My priorities are in quality, while keeping the total encode time below 12 hours (ie, runs overnight). On my i7-920 OC'd to 3.5GhZ, the following 2 pass encode usually finishes between 10 and 12 hours, depending on # of frames.

Could someone please critique my settings? Im using the CLI x264, and its hard to line up the options with what is in the presets. Like dct-decimate - should that be on or off? mixed-refs : on or off? Are there any options I should add?

Thank you very much in advance -

Joe


x264.exe --pass 1 --bitrate %2 --level 5.1 --profile high --ref 16 --bframes 5 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --me umh --subme 9 --partitions none --no-fast-pskip --8x8dct --mixed-refs --no-dct-decimate --psnr --ssim --threads auto --thread-input --output NUL "movie.avs"

x264.exe --pass 2 --bitrate %2 --level 5.1 --profile high --ref 16 --bframes 5 --b-adapt 2 --b-pyramid --weightb --direct auto --deblock -1:-1 --me umh --subme 9 --partitions p8x8,b8x8,i8x8,i4x4 --no-fast-pskip --8x8dct --mixed-refs --no-dct-decimate --psnr --ssim --threads auto --thread-input --output "EncodedButNoSound.mkv" "movie.avs"

[juGGaKNot]

--level 4.1 refs 5,

--b-pyramid --no-fast-pskip --no-dct-decimate --psnr --ssim out

i guess

[LoRd_MuldeR]

1. You can use the same settings for first and second pass. x264 will lower/disable anything that isn't needed for the first pass (unless "--slow-firstpass" is used).

2. The following commands are superfluous, as they simply represent the default: --weightb, --8x8dct, --threads auto, --mixed-refs, --partitions p8x8,b8x8,i8x8,i4x4

3. Have a look at the "--preset" command, if you are looking for reasonable settings. I'd pick the slowest preset that still gives acceptable speed ;)


Probably all you need is:
x264.exe --pass 1 --preset slow --tune film --bitrate %2 --stats "movie.stat" --output NUL "movie.avs"
x264.exe --pass 2 --preset slow --tune film --bitrate %2 --stats "movie.stat" --output "output.mkv" "movie.avs"

(if that's too fast for you, try "--preset slower" instead)

[jwdaigle]

Thank you guys. 2 questions please? which gives "better" quality, no-dct-decimate or decimate? what about mixed-refs: off or on for better quality?

I really like the new preset system, but I am trying to learn how the more granular options affect speed and quality (the journey is as important as the destination :-)). This is why I prefer to use the CLI - it forces me to learn something about the options and algorithms used.

I have been encoding for about 8 months, sometimes doing multiple encodes to compare quality of output.

Thanks for your time,

Joe

1. You can use the same settings for first and second pass. x264 will lower/disable anything that isn't needed for the first pass (unless "--slow-firstpass" is used).

2. The following commands are superfluous, as they simply represent the default: --weightb, --8x8dct, --threads auto, --mixed-refs, --partitions p8x8,b8x8,i8x8,i4x4

3. Have a look at the "--preset" command, if you are looking for reasonable settings. I'd pick the slowest preset that still gives acceptable speed ;)


Probably all you need is:
x264.exe --pass 1 --preset slow --tune film --bitrate %2 --stats "movie.stat" --output NUL "movie.avs"
x264.exe --pass 2 --preset slow --tune film --bitrate %2 --stats "movie.stat" --output "output.mkv" "movie.avs"

(if that's too fast for you, try "--preset slower" instead)

[LoRd_MuldeR]

Thank you guys. 2 questions please? which gives "better" quality, no-dct-decimate or decimate? what about mixed-refs: off or on for better quality?

Mixed-refs give "better" quality when using more than one reference frame, because each block in the frame can choose it's own (optimal) reference frame. Keep that enabled!

DCT decimation saves bits and the visual effect usually is very small. So you should keep that enabled too, unless you have a reason to disable it (AFAIK in rare cases it can cause visual artifacts).

I have been encoding for about 8 months, sometimes doing multiple encodes to compare quality of output.

That's the way to go :D

[Dark Shikari]

Mixed-refs give "better" quality when using more than one reference frame, because each block in the frame can choose it's own (optimal) reference frame. Keep that enabled!No, it lets each partition of P macroblocks choose its own reference frame.DCT decimation saves bits and the visual effect usually is very small. So you should keep that enabled too, unless you have a reason to disable it (AFAIK in rare cases it can cause visual artifacts).It doesn't cause artifacts, it just might be counterproductive when trying for all-out grain retention or something.

[LoRd_MuldeR]

No, it lets each partition of P macroblocks choose its own reference frame.

It doesn't cause artifacts, it just might be counterproductive when trying for all-out grain retention or something.

You live and learn :D

[Firebird]

My priorities are in quality
Try CRF then.

On my i7-920 OC'd to 3.5GhZ, the following 2 pass encode usually finishes between 10 and 12 hours
That is very slow... You are using avisynth filters, right? You can do lossless pass first, that would save your time.

subme 9
You can try subme 10. (Actually i don't know how much better it is. Is it placebo?)

[Dark Shikari]

You can try subme 10. (Actually i don't know how much better it is. Is it placebo?)My testing suggested ~2%.

[m3mbran3]

I just did the same encode using --preset placebo and tune --film with / without --no-dct-decimate. The file with --no-dct-decimate was 514mb and without 501mb. To my eyes there was no noticable difference in output quality, although I'll run some more tests on it.

[Yoshiyuki Blade]

I just did the same encode using --preset placebo and tune --film with / without --no-dct-decimate. The file with --no-dct-decimate was 514mb and without 501mb. To my eyes there was no noticable difference in output quality, although I'll run some more tests on it.

The proper way to evaluate quality differences is by doing 2-pass bitrate encoding. That way, both files will run at almost the same bitrate for a fair comparison.

[RunningSkittle]

Any way we can get a two pass with first pass as CRF?

[Mr VacBob]

What's stopping you? It already works.

[RunningSkittle]

instead of --bitrate i can use --crf?

[DarkZell666]

instead of --bitrate i can use --crf?

Yes ?

x264 --pass 1 --crf 22 ... --stats wtf.stats
x264 --pass 2 --bitrate 1500 ... --stats wtf.stats

¬_¬

[rack04]

Should --direct auto be applied to the 1st pass when using a slow preset in the 2nd pass? The reason that I ask is I get a warning in the 2nd pass that --direct auto was not used in the 1st pass.

[Dark Shikari]

Should --direct auto be applied to the 1st pass when using a slow preset in the 2nd pass? The reason that I ask is I get a warning in the 2nd pass that --direct auto was not used in the 1st pass.Always use the same preset in both passes.

[JarrettH]

I didn't read the inbetween pages, but are these going to be profiles soon? It doesn't interest me to use the command line at all.
I just deleted all the old profiles since they are now outdated with recent x264 changes.

[Zachs]

I didn't read the inbetween pages, but are these going to be profiles soon?

Doesn't look like you've read any pages at all. If you have, you'd have probably realized this isn't the thread for ya...

It doesn't interest me to use the command line at all.

[JarrettH]

What was the point of that post?

They're presets, just like LAME has presets, but right now there's nothing to select them in MeGUI unless I overlooked something and the profiles are outdated.

[neuron2]

This isn't the right thread or forum for MEGUI discussion.

[Audionut]

I was playing with matrices and noticed this one was increasing SSIM.

You results may vary.

http://www.users.on.net/~audionut11/ssim.cfg

[Dark Shikari]

I was playing with matrices and noticed this one was increasing SSIM.

You results may vary.

http://www.users.on.net/~audionut11/ssim.cfgA matrix that completely trashes chroma helps SSIM, a metric which solely measures luma quality? A shocker ;)

[Audionut]

I've got 1 or 2 others that don't hate chroma. I need to run some quick tests again to remember what's what.
I should label them better while testing.

[Audionut]

Hmm, the one I was thinking of actually reduced SSIM by 0.00002.

This other one increased PSNR.

http://www.users.on.net/~audionut11/psnr2.cfg

edit: a variant of above that increases SSIM.

http://www.users.on.net/~audionut11/ssim1.cfg

[crasus]

the change in defaults also affected some of the command line options to take reverse forms of what they were previously...
i.e.:

--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)


so if you were using any of the options on the left, you need to remove them from your new command line

After some errors, I just noticed this post a few minutes ago, and while updating my script to reflect the defaults I saw that altough --progress is no longer recognized, weightb, 8x8dct and mixed-refs are still accepted.

[Dark Shikari]

After some errors, I just noticed this post a few minutes ago, and while updating my script to reflect the defaults I saw that altough --progress is no longer recognized, weightb, 8x8dct and mixed-refs are still accepted.Yes, this is because it must always be possible for the user to invert the effects of a preset. So if --preset veryfast turns off mixed-refs, the user still must be able to turn it back on if he wants.

[Kurtnoise]

What do you think about these default settings for the devices, guys ?

Target : Android G1
--profile baseline --level 3 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --deblock 1:0 --ref 1 --vbv-bufsize 2500 --vbv-maxrate 2500 --me umh --partitions p8x8,b8x8,i4x4 --output "output" "input"

Target : AppleTV
--profile main --level 3 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --no-cabac --b-pyramid --direct auto --me umh --partitions p8x8,b8x8,i4x4,p4x4 --output "output" "input"

Target : Archos 605
--profile baseline --level 4 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --ref 2 --me umh --partitions p8x8,b8x8,i4x4 --output "output" "input"

Target : iPhone
--profile baseline --level 3 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --ref 2 --vbv-maxrate 10000 --me umh --partitions p8x8,b8x8,i4x4,p4x4 --output "output" "input"

Target : iPod
--profile baseline --level 3 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --ref 1 --vbv-bufsize 10000 --vbv-maxrate 10000 --me umh --partitions p8x8,b8x8,i4x4,p4x4 --output "output" "input"

Target : PS3
--level 4.1 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --bframes 5 --b-pyramid --direct auto --me umh --partitions all --output "output" "input"

Target : PSP
--profile main --level 3 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --bframes 5 --b-pyramid --direct auto --me umh --partitions p8x8,b8x8,i4x4,p4x4 --output "output" "input"

Target : Xbox 360
--level 4.1 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --b-pyramid --direct auto --me umh --partitions all --output "output" "input"

Target : Zune
--profile baseline --level 3 --preset medium --pass 2 --bitrate xxx --stats ".stats" --thread-input --ref 1 --me umh --partitions p8x8,b8x8,i4x4,p4x4 --output "output" "input"

[me7]

I have an iPod classic that handles up to 5 reference frames. AFAIK the maximum allowed bitrate is 10 Mbit/sec so your vbv settings seem to restrictive.

[Chengbin]

The 605 can handle much higher settings as well. It is at the same level as the PSP.

[Audionut]

I have an iPod classic that handles up to 5 reference frames. AFAIK the maximum allowed bitrate is 10 Mbit/sec so your vbv settings seem to restrictive.

Wow, 10Mbit/sec for a 320x240 display.:eek:

[Kurtnoise]

I have an iPod classic that handles up to 5 reference frames.
5G or lower ?

The 605 can handle much higher settings as well.
such as ?

[Audionut]

This is the command line i'm using for a nokia 5800.

--profile baseline --pass 2 -B 400 --level 1.3 --ref 1 --aq-mode 2 --no-mixed-refs --trellis 2 --rc-lookahead 240 --scenecut 40 --partitions all --me umh --subme 10 --keyint 240 --min-keyint 24 --psy-rd 0.0:0.0 --vbv-bufsize 1000 --vbv-maxrate 768

[Kurtnoise]

240 for --rc-lookahead seems to be very high for me...and subme 10 for the 1st pass ?

my initial post was to suggest some default settings.

[Audionut]

240 for --rc-lookahead seems to be very high for me...and subme 10 for the 1st pass ?.

Overridden by auto fast first pass. And lookahead is only so high because of low res (320x240).

[Chengbin]

For the 605/5 (max playable settings)

--keyint 250 --bframes 5 --no-fast-pskip --trellis 2 --ref 8 --deblock 0,0 --subme 10 --direct auto --me umh --rc-lookahead 250 --merange 32 --b-adapt 2 --vbv-maxrate 5000 --vbv-bufsize 5000 --partitions all --no-8x8dct --psy-rd 1.0:0.2 --aq-mode 2 --aq-strength 1

[popper]

cant several of these devices do --profile High perfectly fine and playback smoothly!

and i know my 360 internal codec can do --profile High --level 4.1 --ref 3 --bframes 3 1080P25 to 10Mbit/s inside an mp4 playback smoothly...

I have an iPod classic that handles up to 5 reference frames. AFAIK the maximum allowed bitrate is 10 Mbit/sec so your vbv settings seem to restrictive.

OC generally speaking using more than ref=3 isnt really needed or required for anything other than perhaps HD manga animation quality smooth playback wise it seems..., so why use more in a preset/profile for a given tested device, the main thing id imagine is getting to, and making sure to use a --profile High were ever a device can be shown to play that smoothly in the real world, upto a given level its internal codec etc can manage..

[Kurtnoise]

and i know my 360 internal codec can do --profile High --level 4.1 --ref 3 --bframes 3 1080P25 to 10Mbit/s inside an mp4 playback smoothly...
High Profile is the default one from x264, that's why it's not mentioned for PS3 & Xbox 360...

[popper]

High Profile is the default one from x264, that's why it's not mentioned for PS3 & Xbox 360...
yeah i know, but that ref=3 and related info is the best iv ever managed to get smooth playback from the 360/PMS, and noones linked higher encoded samples iv tryed are smooth for me so far.....so thats my max proven smooth settings for 360 above until someone gives me a better option that actually works for me ,or MS Finally refacture and update their antiquated codecs/containers 360 firmware for the better OC.

also it seems several of the other mentioned devices should be able to do high profile ref=3 etc, someone with a named device should try and report back perhaps.

i thought your list could serve as a tryed tested base reference that most generic encodes would work to for the given device.

as more and more PMPs and High profile capable SOC devices are begining to hit the markets soon, we could need a good current and near future reference and perhaps even a wiki to use as our generic codec/container max smooth playback guide...

[me7]

Wow, 10Mbit/sec for a 320x240 display.:eek:
It can output resolutions up to 720x576 to a TV and I've encountered some fast-edited music videos that end up with >3 Mbit/sec [EDIT: and peak bitrate of 7325 kbps] at CRF 22 (especially since baseline profile is less efficient then your usual encodes).
I didn't ask him to default to 10 MBit/sec, I just wanted to say that it can handle a lot more then he assumed.
Raising the vbv restrictions would not change anything for your low-bitrate 320x240 encodes but if someone wants to encode PAL/NTSC material with too tight restrictions he might run into trouble.

5G or lower ?

iPod classic 6G (http://en.wikipedia.org/wiki/IPod_classic) (released in September 2007)

OC generally speaking using more than ref=3 isnt really needed or required for anything other than perhaps HD manga animation quality smooth playback wise it seems..., so why use more in a preset/profile for a given tested device, the main thing id imagine is getting to, and making sure to use a --profile High were ever a device can be shown to play that smoothly in the real world, upto a given level its internal codec etc can manage..
Again, I didn't tell him to use 5 reference frames. He assumed that the iPod can handle only 1 and I wanted him to know that it can up to 5. Now it's up to him to decide which number between 1 and 5 is efficient (but I am sure that 1 is not efficient, if this was the case then h.264 wouldn't need to support more then 1 reference frame in the first place :) )

[Chengbin]

as more and more PMPs and High profile capable SOC devices are begining to hit the markets soon, we could need a good current and near future reference and perhaps even a wiki to use as our generic codec/container max smooth playback guide...

There is only 1 right now (and will stay that way for a year) capable of high profile that is available in North America and Europe, and that is the Archos 5 Android.

When high profile capable devices start to roll in (unlikely because Apple never change, and Zune won't get an upgrade anytime soon), you wouldn't need profiles, just watch for VBV and number of b/ref frames.

[Kurtnoise]

I'd say that for devices, a good start would be to concentrate on restriction like Profile & Level + vbv + slices in the case of BD...The rest can be tweak afterwards. Maybe I should start an other thread to extend discussion (or any moderator can split the last posts...yeah, I'm lazy)

[Snowknight26]

Your Zune command line options could use a little work. The Zune HD supports up to 3.1 @ 14Mbps with b-frames, so judging by what you wrote, you are targetting the previous generation.

[me7]

@Kurtnoise: Regarding iPod compatibility, you might find this list from the HandBrake forum interesting: http://forum.handbrake.fr/viewtopic.php?f=7&t=3859

[Kurtnoise]

Your Zune command line options could use a little work. The Zune HD supports up to 3.1 @ 14Mbps with b-frames, so judging by what you wrote, you are targetting the previous generation.
well, yes...It seems that it supports only Baseline/Main Profiles, right ?

I'll create a spreadsheet and update some infos.


@Kurtnoise: Regarding iPod compatibility, you might find this list from the HandBrake forum interesting: http://forum.handbrake.fr/viewtopic.php?f=7&t=3859
great...thanks.

[Raptus]

OP needs update considering mb-tree and --preset veryslow.

[benwaggoner]

well, yes...It seems that it supports only Baseline/Main Profiles, right ?
Well, really only the Baseline + B-frames subset of Main. So no CABAC.

IIRC, it's pretty much the same subset as AppleTV, except with a 14 Mbps peak instead of 5 Mbps peak. I could believe there's other AppleTV caveats that might not apply to Zune HD, in the same way Zune 2 was a superset of iPod (allowing 720x576p25 @ 3 Mbps).

I shake my head at the AppleTV. Sad that a similarly priced handheld device can play back higher bitrate video than an AC-powered STB.

[benwaggoner]

@Kurtnoise: Regarding iPod compatibility, you might find this list from the HandBrake forum interesting: http://forum.handbrake.fr/viewtopic.php?f=7&t=3859
Wow, has that been verified?

The iPhone 3GS really supports Main Profile? If so, it's one of the first handheld devices with MP support.

And unfortunately breaks my hope/prediction that devices are going to be either Baseline or High, without any new Main-only products being introduced. Bummer. Seems like we're getting FOUR categories of devices in terms of profile support:

Baseline
Baseline + B-frames (Main subset)
Main
High

[Dark Shikari]

Wow, has that been verified?

The iPhone 3GS really supports Main Profile?I'm pretty sure it supports High just fine.

[Chengbin]

Wow, has that been verified?

The iPhone 3GS really supports Main Profile? If so, it's one of the first handheld devices with MP support.

And unfortunately breaks my hope/prediction that devices are going to be either Baseline or High, without any new Main-only products being introduced. Bummer. Seems like we're getting FOUR categories of devices in terms of profile support:

Baseline
Baseline + B-frames (Main subset)
Main
High

Umm, there are multiple devices that support main profile, released years ago. PSP, Archos and Cowon's PMP comes to mind.

The iPhone 3GS seems to be able to play high profile if you can bypass iTunes.

The new Archos 5 Android can play 720p high profile to a reasonably high bitrate (>10000Kbps peaks)

[benwaggoner]

Umm, there are multiple devices that support main profile, released years ago. PSP, Archos and Cowon's PMP comes to mind.
Sure. I'm just hoping we don't see new Main-but-not-High devices introduced, so we can let Main start its slow fade into history.

[Ice Dragon]

Does the preset veryslow contain --no-fast-pskip or do i have to manually add it ?

Thanks

[Dark Shikari]

Does the preset veryslow contain --no-fast-pskip or do i have to manually add it ?

ThanksWhy do you "need" no-fast-pskip? Did the fast pskipper eat your family or something?

[Ice Dragon]

Why do you "need" no-fast-pskip? Did the fast pskipper eat your family or something?
Hahaha luckily no :p

Any way this is what i read

no-fast-pskip
Default: Not Set
Disables early skip detection on P-frames. Fast skip detection increases speed but may cause slight blockiness in areas of solid color or slight gradients such as dark scenes or sky.
Recommendation: Enabled

So was just asking whether its enabled or not in veryslow, to keep the code short :)

[Dark Shikari]

Hahaha luckily no :p

Any way this is what i read

no-fast-pskip
Default: Not Set
Disables early skip detection on P-frames. Fast skip detection increases speed but may cause slight blockiness in areas of solid color or slight gradients such as dark scenes or sky.
Recommendation: Enabled That's very outdated; AQ fixed the blockiness-related issues far better than turning off fast pskip ever did.

[Ice Dragon]

That's very outdated; AQ fixed the blockiness-related issues far better than turning off fast pskip ever did.
Ok thanks for the info :thanks:

[jethro]

That's very outdated; AQ fixed the blockiness-related issues far better than turning off fast pskip ever did.

Is there a reason to use it then and do deadzones influence p-skip?

[Dark Shikari]

Is there a reason to use it then and do deadzones influence p-skip?A reason to use it? It sometimes marginally improves quality (thus why it's in placebo). And yes deadzones affect P-skip.

[Chainmax]

I recently bought some DVDs of a cartoon series and would like to see how compressible they might be. For that effect, I intend to encode the first episode with as little compression as possible and see how big it gets. These are the settings to be used:

Unrestricted 1pass Const. Quality Anime plus:

* Weighted prediction for b-frames
* Adaptive b-frames 2
* Adaptive quantization on: variance mode, strength 0.5
* Subpixel refinement 6
* Trellis 1
* No dct decimation
* No fast p-skip
* 16 reference frames
* ME range 32

The filterchain included dithering, which I assume nothing short of lossless will conserve, but that's allright.
What I would like to ask is whether you guys think these settings are ok for their intended purpose (checking compressibility, keeping the result if filesize is not excessive) or if they are incoherent/overkill. Any and all feedback will be appreciated.

[dstln]

merange 32 is almost certainly overkill
so is 16 ref frames, although then you could check the error output and see exactly how many are being used on average (and then lower it accordingly for the real encodes)

[Forteen88]

* Subpixel refinement 6
* ME range 32I'd set subme 10 and merange 24 (if HD-res). 3 bframes are quite good, and should be compatible with much hardware. b-adapt 2 and trellis 2 maybe.

[Chainmax]

When last I did an encode, the highest SubME was 7, and if I recall correctly for grain/detail conserving encodes it was not recommended. Have all SubMEs improved overall or are the recent recently addded ones (8, 9, etc) better at preserving detail?

[J_Darnley]

When last I did an encode, the highest SubME was 7, and if I recall correctly for grain/detail conserving encodes it was not recommended. Have all SubMEs improved overall or are the recent recently addded ones (8, 9, etc) better at preserving detail?

Some other settings were removed and the features were integrated into subme.

bime was merged and is on with subme >= 5
otherwise 1-6 remain the same

b-rdo was removed and merged like as follows
new subme 7 = old subme 6 and b-rdo
new subme 8 = old subme 7 and b-rdo
new subme 9 is new, it added rd refinement on B-frames

subme 10 is even newer, it does: QP-RD - requires trellis=2, aq-mode>0

I don't remember any other commits that specifically targeted subme and improved its compression.

[DarkZell666]

When last I did an encode, the highest SubME was 7, and if I recall correctly for grain/detail conserving encodes it was not recommended. Have all SubMEs improved overall or are the recent recently addded ones (8, 9, etc) better at preserving detail?

There have been other massive improvements that actually have more impact on quality than those sole subme improvements. I'm talking about rc-lookahead and mb-tree, though the latter is most effective in two-pass mode, and doesn't always benefit to CRF mode, depending on the source. You might have found the testing thread already : http://forum.doom9.org/showthread.php?t=148686

Slight OT : It's true I hadn't seen you around for a while ! ^^ I had a good laugh reading your comment as well : "When last I did an encode, the highest SubME was 7" :D Nice to see you're still in business anyway ;)

[Dark Shikari]

When last I did an encode, the highest SubME was 7, and if I recall correctly for grain/detail conserving encodes it was not recommended. Have all SubMEs improved overall or are the recent recently addded ones (8, 9, etc) better at preserving detail?It's the opposite. Higher subme means more psy-RD, which means more detail preservation.

[Chainmax]

DarkZell666: it's good to be back on the scene, however small my current experimentations might be. I had indeed started to read that thread, thanks for the welcoming and for the explanations http://img524.imageshack.us/img524/6030/xyxthumbs.gif.

Dark Shikari: cool, more stuff to make my puny CPU suffer with, thanks for clarifying my doubt :).

[ACrowley]

Can x264 use "Trellis- 2 always" with the Tune Grain Settings, (deadzones) ?

[Dark Shikari]

Can x264 use "Trellis- 2 always" with the Tune Grain Settings, (deadzones) ?The deadzones are just set in case you don't use trellis 2.

[ACrowley]

The deadzones are just set in case you don't use trellis 2.

The Preset very slow use Trellis 2. So the Tune Grain Option overwrites it to use deadzones ?

[Dark Shikari]

The Preset very slow use Trellis 2. So the Tune Grain Option overwrites it to use deadzones ?I don't see a "trellis=0" in --tune grain, do you?

[ACrowley]

I don't see a "trellis=0" in --tune grain, do you?

why do i have the Feeling that youre feeling bugged by me ?

-You told me that Trellis cant be used with Deadzones,right ?
-Tune Grain use deadzones, correct ?:)
-So i assume that "Tune Grain" disables the Trellis 2 from preset very high, otherwise deadzones Settings wont work ?

I know my English is very bad sometimes...but i think im understandable

[LoRd_MuldeR]

Uhm, no. Tunings are applied after Presets, so potentially they could overwrite any setting that the Preset has already set.

But from what I can see, the"--tune grain" preset does not touch Trellis at all, it just adjusts Psy-Trellis strength:

else if( !strcasecmp( optarg, "grain" ) )
{
param->i_deblocking_filter_alphac0 = -2;
param->i_deblocking_filter_beta = -2;
param->analyse.f_psy_trellis = 0.25;
param->analyse.b_dct_decimate = 0;
param->rc.f_pb_factor = 1.1;
param->rc.f_ip_factor = 1.1;
param->rc.f_aq_strength = 0.5;
param->analyse.i_luma_deadzone[0] = 6;
param->analyse.i_luma_deadzone[1] = 6;
param->rc.f_qcompress = 0.8;
}

So with "--preset veryslow" combined with "--tune grain" you will definitely get Trellis enabled (Trellis=2). Which means Dead Zones aren't used.

And no, I don't think "--tune grain" should disable Trellis, as you'd loose Psy-Trellis! It adjusts the Deadzone values, yes. That's probably for the case you use "--tune grain" without Trellis.

But who said that this should be the only case to use the "grain" tuning? Apparently "--tune grain" is written in a way to work with and without Trellis. And also with Trellis=1 mode.

[ACrowley]

Thank you :)

[Audionut]

http://forum.doom9.org/showthread.php?p=1307463#post1307463

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?

[Alf Bundy]

Hi, Could someone post parameters for each tuning (film, grain, ...) ?
The first post of this thread lists all tunings, but doesn't tell what they do exactly.

That information was available in the x264 wiki, but it was deleted :(

http://mewiki.project357.com/wiki/X264_Settings.

[J_Darnley]

Check the history! http://mewiki.project357.com/index.php?title=X264_Settings&oldid=3718
[EDIT] FTFY

[neuron2]

But why was it deleted?

[stax76]

I guess because it does some calculation, maybe my code helps a bit:


Select Case profileTunePreset.Tune.Value
Case x264TuneMode.Film
defaults.DeblockAlpha.Value = -1
defaults.DeblockBeta.Value = -1
defaults.PsyTrellis.Value = 0.15
Case x264TuneMode.Animation
defaults.RefFrames.Value = If(defaults.RefFrames.Value > 1, Math.Min(defaults.RefFrames.Value * 2, 16), 1)
defaults.DeblockAlpha.Value = 1
defaults.DeblockBeta.Value = 1
defaults.PsyRD.Value = 0.4
defaults.AQStrengthV2.Value = 0.6
defaults.BFrames.Value = Math.Min(defaults.BFrames.Value + 2, 16)
Case x264TuneMode.Grain
defaults.DeblockAlpha.Value = -2
defaults.DeblockBeta.Value = -2
defaults.PsyTrellis.Value = 0.25
defaults.DctDecimate.Value = False
defaults.PBRatio.Value = 1.1
defaults.IPRatio.Value = 1.1
defaults.AQStrengthV2.Value = 0.5
'param->analyse.i_luma_deadzone[0] = 6;
'param->analyse.i_luma_deadzone[1] = 6;
defaults.QComp.Value = 0.8
Case x264TuneMode.Psnr
defaults.AQMode.Value = x264AQMode.Disabled
defaults.Psy.Value = False
Case x264TuneMode.Ssim
defaults.AQMode.Value = x264AQMode.AutoVariance
defaults.Psy.Value = False
Case x264TuneMode.Fastdecode
defaults.Deblock.Value = False
defaults.CABAC.Value = False
defaults.BFramesWeightb.Value = False
defaults.Trellis.Value = x264TrellisMode.Disabled
Case x264TuneMode.Touhou
defaults.RefFrames.Value = If(defaults.RefFrames.Value > 1, Math.Min(defaults.RefFrames.Value * 2, 16), 1)
defaults.DeblockAlpha.Value = -1
defaults.DeblockBeta.Value = -1
defaults.PsyTrellis.Value = 0.2
defaults.AQStrengthV2.Value = 1.3

If defaults.PartitionP8x8.Value Then
defaults.PartitionP4x4.Value = True
End If
End Select

[J_Darnley]

But why was it deleted?
It looked like spam.

[Fr4nz]

I have a question: how presets are affected by the new weight-p functionality?

[LoRd_MuldeR]

The presets have been updated for Weight-P.

By default x264 will use the "Smart" Weight-P mode. However the "ultrafast" and "veryfast" presets will disable Weight-P, the "faster" preset will use "Blind" Weight-P mode.

All other presets don't touch Weight-P, so they use the default. Note that the "fatsdecode" tuning as well as the "baseline" profile will disable Weight-P.

Lats but not least, "--interlaced" doesn't work with Weight-P yet. So if you use "--interlaced", then a warning message will be printed and Weight-P will be disabled.

[Fr4nz]

The presets have been updated for Weight-P.

By default x264 will use the "Smart" Weight-P mode. However the "ultrafast" and "veryfast" presets will disable Weight-P, the "faster" preset will use "Blind" Weight-P mode.

All other presets don't touch Weight-P, so they use the default. Note that the "fatsdecode" tuning as well as the "baseline" profile will disable Weight-P.

Lats but not least, "--interlaced" doesn't work with Weight-P yet. So if you use "--interlaced", then a warning message will be printed and Weight-P will be disabled.

Got it, thanks for your answer. Another question I have is: how much is the speed penalty given by weight-p?

[LoRd_MuldeR]

Got it, thanks for your answer. Another question I have is: how much is the speed penalty given by weight-p?

See:
http://forum.doom9.org/showthread.php?p=1342501#post1342501

[Selur]

Backround:
I want to use the following 1pass command line:
x264 --pass 1 --bitrate 1500 --level 4.1 --ref 1 --keyint 250 --min-keyint 25 --scenecut 40 --bframes 0 --cplxblur 20 --qcomp 0.6 --mbtree --rc-lookahead 40 --qblur 0.5 --qpmin 1 --qpmax 51 --qpstep 4 --ipratio 1.4 --pbratio 1.3 --chroma-qp-offset 0 --partitions none --no-8x8dct --me dia --mvrange -1 --subme 2 --sync-lookahead 250 --no-mixed-refs --trellis 0 --weightp 1 --aq-mode 0 --nr 0 --deadzone-inter 21 --deadzone-intra 11 --threads auto --no-cabac --sar 1:1 --deblock 0:0 --no-psnr --no-ssim --stats "PATH TO THE .stats FILE" --progress
removing all default values and using the ultrafast preset the whole thing would shrink to:
x264 --preset ultrafast --pass 1 --bitrate 1500 --level 4.1 --qpmin 1 --subme 2 --sync-lookahead 250 --weightp 1 --stats "PATH TO THE .stats FILE" --progress
which would be nice, problem is ultrafast implies --no-cabac and looking at the x264 --fullhelp output there seems to be no way to enable cabac.

Question:
Is there still a way to 'enable cabac' explicitly ? (through a not in the 'fullhelp' documented option?)

If not it might be a good idea to make sure all options can be explicitly dis-/enabled, since similar things could probably happen to other options which can't be explicitly be turned on/off and are coverd by a preset.

Cu Selur

[Snowknight26]

Yes, --cabac, according to line 439 (http://git.videolan.org/?p=x264.git;a=blob;f=x264.c;h=6bf75e05fe1227642f4d4cf98509c2fb54d700fe;hb=e8501efbd235b1b5321adda8926e7a859beafd3c).

[Selur]

Thanks!! Totally overlooked that. :D

[Sharc]

Not sure if this is the right thread, but I was wondering about the sensitivity of file size vs crf in a recent test.
I encoded the same source with the same x264 version r1352 from x264.nl with exact the same encoder settings (--preset medium, --film, --me umh) for various --crf values:
1) --crf 20 file size 3'661'503 kB (100%, reference)
2) --crf 20.1 file size 2'871'120 kB ( 78.4%)
3) --crf 21 file size 2'836'541 kB ( 77.5%)

I am surprised about the big change in file size between 2) and 1) with only 0.1 difference in --crf, and almost no change between 3) and 2) with 0.9 difference in --crf.
Does this make sense? I am aware that there exists no linear dependency, but I would expect a 'somehow logarithmic' dependency .... but maybe I am totally wrong .....
For confirmation I read the crf values and other parameters back using MediaInfo.

[AiDz0r]

Oke fist of all, im really new into this x264 encoding, i've researched and looked at the history a little, but this is really getting complicated for me. Is this x264.exe stable? and can juGGaKNot please give the perfect BEST quality cmds in order for the perfect extreme quality for the game "Counter-Strike" I want to lock the fps to 30, and a CRF bitrate around 4500? Is it possible if so can someone do it thanks

[Inspector.Gadget]

Oke fist of all, im really new into this x264 encoding, i've researched and looked at the history a little, but this is really getting complicated for me. Is this x264.exe stable? and can juGGaKNot please give the perfect BEST quality cmds in order for the perfect extreme quality for the game "Counter-Strike" I want to lock the fps to 30, and a CRF bitrate around 4500? Is it possible if so can someone do it thanks

We don't do "best" around here (read the rather conspicuous link at the top of each page). Second, you've already opened a thread where you can catalogue your total refusal to do any of your own research beyond asking the same question repeatedly and refusing to take the advice given to you: you don't need to then cross-post about it.

[AiDz0r]

well sorry about that, its just frustrating now because its been like a year im trying to find the best codec and tweak, so 1 year of wasting time of finding is a little overboard. Well what can i do, simply information given is not enough for people who recently started and are begginer. Take a little perspective look from our eyes.

[Wishbringer]

It's not that ppl don't want to help you.
But asking for a subjective solution (and term "best" is subjectiv) would lead to thousands different answers.

You have to do a little bit research by your self to find a way that best suits to you.
Others can only give some hints.

Hint is:
- start with defaults
- raise, lower crf depending if result is transparent for you or not good enough
- use presets to raise/lower encoding time and decrease/increase filesize for given crf
- use tune to adjust settings to content
- use other settings to tweak for playback device

thats called learning-by-doing and leads you to "your best results".

[stax76]

Maybe you are not patient enough, did you read some guides and tutorials?

[olapanekala]

It's not that ppl don't want to help you.
But asking for a subjective solution (and term "best" is subjectiv) would lead to thousands different answers.

You have to do a little bit research by your self to find a way that best suits to you.
Others can only give some hints.

Hint is:
- start with defaults
- raise, lower crf depending if result is transparent for you or not good enough
- use presets to raise/lower encoding time and decrease/increase filesize for given crf
- use tune to adjust settings to content
- use other settings to tweak for playback device

thats called learning-by-doing and leads you to "your best results".

I still beleive 2pass encoding gives better results in certain filesize.

[Wishbringer]

I still beleive 2pass encoding gives better results in certain filesize.

Question is, what do you want?!
If you want a fixed resulting filesize, go for 2-pass.
If you want a overall quality level regardless of filesize, go for crf.
Mixed settings are possible too:
first pass at crf xx then 2nd pass with that determined bitrate.

But there are no general rules.
Or better said, there is one rule: try it yt your own to get results that best suits to you.

But you see, there are several opinions what ppl prefer.
And that is, what i tried to point out.

[AiDz0r]

Well, to be hoenst This is all I wan't:

*File size doenn't matter making sure that a 10 Minute video doenst pass 2 GB
*Fixing the Bitrate don't know what to use exactly, I want something that i can watch also something that can be watched over online stream such as YouTube.
*And im still complicated which one should i use?, CRF or ABR, 1st Pass or 2nd Pass. on CRF i see that the bitrate goes up to 14000...

And yeah i did a reasearch on way before. But im here to get some help. So far x264.exe thingy with the CMDS aint good for me. Well i think its because i got an AVI container i heard x264/H264 goes best with Mp4 ?

[nm]

*Fixing the Bitrate don't know what to use exactly, I want something that i can watch also something that can be watched over online stream such as YouTube.

YouTube re-encodes and uses their own bitrate targets anyway. You just need to make sure that the video that you upload has decent quality.

*And im still complicated which one should i use?, CRF or ABR, 1st Pass or 2nd Pass.

CRF is a good choice for encoding stuff that is loaded to YouTube. Some other video sites may support direct sharing of user-encoded videos, in which case 2-pass encoding with properly set VBV is also a good idea.

on CRF i see that the bitrate goes up to 14000...

Use a higher CRF value if you want lower bitrates at the cost of quality. I wouldn't go over CRF=20 for stuff that gets re-encoded.

And yeah i did a reasearch on way before. But im here to get some help. So far x264.exe thingy with the CMDS aint good for me. Well i think its because i got an AVI container i heard x264/H264 goes best with Mp4 ?

AVI is fine for lossless intermediates and feeding the video to x264, but are you still using it for storing H.264 streams? Why?

[me7]

Now that b-pyramid works with mb-tree, what b-pyramid setting does x264 default to?

[rack04]

Now that b-pyramid works with mb-tree, what b-pyramid setting does x264 default to?

b-pyramid is disabled by default.

[nakTT]

b-pyramid is disabled by default.
Its automatically disable when you use mbtree. But now they both can work together already.