x264 defaults changing

[Dark Shikari]

A lot of patches are going to be pushed soon. And among other things, the x264 defaults are changing. We will also be adding presets to the CLI interface (but not the library interface).

New defaults (suggestions welcome):

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

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. UMH is probably a bit too costly speed-wise to set as the default.

Logic behind the CRF: x264 should, by default, encode with a reasonable quality that isn't overkill but isn't low quality. This means a user can generate a good encode simply by doing "x264 inputfile -o outputfile". Also, out of respect to goddess Eris of Discord.

The intention here is that you can simply use x264 with defaults and it will give Very Good Results that nobody can complain about.

I will announce quality/profile presets soon as well.

GUI designers: have fun ;)

[LoRd_MuldeR]

A lot of patches are going to be pushed soon.

Now I'm curious. What patches? ^^

New defaults (suggestions welcome):

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

Sounds like a great idea. But maybe CRF 23 is a bit too high. I'd prefer CRF 21 ;)

What about b-adapt 2? Still too slow at 3 b-frames? And what about b-pyramid?

[Dark Shikari]

What about b-adapt 2? Still too slow at 3 b-frames? And what about b-pyramid?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.

B-adapt 2 is too slow, it'll be in a slower preset (which will also use me=umh).

[elguaxo]

sounds like a great idea. But maybe crf 23 is a bit too high. i'd prefer crf 21 ;)

+1 :)

[Chengbin]

How about some partitions set as default?

[Sagekilla]

It's implied that the old defaults hold true still except where specified up there:


--partitions <string> Partitions to consider ["p8x8,b8x8,i8x8,i4x4"]
- p8x8, p4x4, b8x8, i8x8, i4x4
- none, all


The only thing disabled is p4x4, which is less useful than the other partitions. I wouldn't consider p4x4 for anything but one of slower profiles.

[linyx]

--ref 3
Maybe 4 or even possibly 5? Or would it not be worth the loss in speed (for defaults of course:D)?

[Manao]

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.Do note however that the problems lay in x264, not in the hardware devices.
Maybe 4 or even possibly 5? 4 would break level 4.1 for 1080p streams. So either the default ref number depends on resolution (and then the users will never understand how it is set), or it stay at 3.

[Dark Shikari]

Do note however that the problems lay in x264, not in the hardware devices.Unrelated; even before we lowered the dpb by 1, the problem still existed with some devices and players (perhaps not as many). This is probably due to the fact that b-pyramid requires a delay of 2 frames.

If the issue is ever fixed, I'll make it default.4 would break level 4.1 for 1080p streams. So either the default ref number depends on resolution (and then the users will never understand how it is set), or it stay at 3.x264 (with the changes announced in the presets thread) automatically changes ref to match level as long as you don't force --ref yourself.

[juGGaKNot]

K, so lets go.

Autovaq and open gop will be added ?

with the changes announced in the presets thread) automatically changes ref to match level as long as you don't force --ref yourself.

To match level ? not resolution ? so there will be no difference if i usa 800x600 or 1920x1080 at 4.0 ?

[Dark Shikari]

To match level ? not resolution ? so there will be no difference if i usa 800x600 or 1920x1080 at 4.0 ?"To match level" has an inherent, implicit dependence on resolution.

[juGGaKNot]

"To match level" has an inherent, implicit dependence on resolution.

Ah, so no more setting the level ?

So it will be 3.2 up to 1280, 4.0 up to 1920 ?

[Manao]

x264 (with the changes announced in the presets thread) automatically changes ref to match level as long as you don't force --ref yourself.I know that, but I don't think it's good that default settings on 1080p content would lead to a default level of 4.2 or 5.0 if --ref was bumped up.

[Dark Shikari]

I know that, but I don't think it's good that default settings on 1080p content would lead to a default level of 4.2 or 5.0 if --ref was bumped up.If someone wants level 4.1 they should specify it.

[Gabriel_Bouvigne]

Instead of --option/--no-option, what about "--option boolean", with boolean allowed to be 0/false/off-1/true/on ?

[greath]

I will announce quality/profile presets soon as well.



I was wondering if you could give quality profiles for both first pass and second pass encoding? I am always confisued about which settings have an effect on each pass and which you can specifiy values for that speed up the first pass encoding but have an effect on second pass. I think that first pass is just to determine the frame types, so I assume that settings that can affect this are ones that must be present in both passes, but things like estimating the motion vectors are not important in the first pass?

Thanks.

[buzzqw]

would by handy a "--turbo" switch that will disable/lower some values (subme/ref/...)
so users will be using a standard "slow" profile in two pass mode, BUT simply adding "--turbo" (and not removing other options) to first pass string , will got a huge first pass speed boost (as xvid option)

about preset: you surely know x264 better (and a lot!) then me, but you could take a look at HDConvertToX or MeGui profiles

in hdc i have build profiles based on your suggestions :)

last one: +1 for crf 21

BHH

[Atak_Snajpera]

I would suggest something like this:
--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim

[juGGaKNot]

would by handy a "--turbo" switch that will disable/lower some values (subme/ref/...)
so users will be using a standard "slow" profile in two pass mode, BUT simply adding "--turbo" (and not removing other options) to first pass string , will got a huge first pass speed boost (as xvid option)

about preset: you surely know x264 better (and a lot!) then me, but you could take a look at HDConvertToX or MeGui profiles

in hdc i have build profiles based on your suggestions :)

last one: +1 for crf 21

BHH

Well its turbo by default and only setting --slowetcetc makes it full

+1 for default profile 3 pass

--bframes 16 --b-adapt 2 --b-pyramid --weightb --direct auto --subme 9 --trellis 2 --psy-rd 1.5:1.5 --partitions all --8x8dct --me tesa --merange 128 --qcomp 1 --threads auto --aq-mode 1 --aq-strength 1.0

Kidding ofc.

Why is

--no-mixed-refs replaces --mixed-refs
--no-8x8dct replaces --8x8dct
--no-weightb replaces --weightb

Replaced ? enabled by default now ?

I would suggest something like this:
--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim

Doesn't that add huge encoding time vs default megui partitions ? with maximum 0.5% compression gain ?

[Atak_Snajpera]

Doesn't that add huge encoding time vs default megui partitions ? with maximum 0.5% compression gain ?
And who says that? The guy who uses crazy placebo settings :)

[juGGaKNot]

And who says that? The guy who uses crazy placebo settings :)

I use higher setting than placebo and partitions all, i was saying that megui presets are there because normal people tested them.

[roozhou]

I would suggest something like this:
--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim

Does p4x4 break dxva compatibility?

[Atak_Snajpera]

Does p4x4 break dxva compatibility?
No i does not

[roozhou]

No i does not

Why by default i4x4 is on but p4x4 is off? Any other compatibility issue?

[juGGaKNot]

Why by default i4x4 is on but p4x4 is off? Any other compatibility issue?

From what i've read more encoding time for 0.5% compression advantage and more decoding power needed.

[roozhou]

From what i've read more encoding time for 0.5% compression advantage and more decoding power needed.

A quick test on Big Buck Bunny 360P PNGs for 1000 frames.


--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh --threads auto
40.00fps

--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --8x8dct --me umh --threads auto
42.55fps

Much less impact on speed than hex->umh or subme 6 -> subme 7

[LoRd_MuldeR]

Why is

--no-mixed-refs replaces --mixed-refs
--no-8x8dct replaces --8x8dct
--no-weightb replaces --weightb

Replaced ? enabled by default now ?

Multiple-references are much more efficient, if "--mixed-refs" is enabled. Since the new default will be "--ref 3", it's only consequent to make "--mixed-refs" a default too.

About "--8x8dct": It's probably one of the most useful "High" profiles features. And it may even improve decoding performance, as you can get away with a lower bitrate.

[juGGaKNot]

A quick test on Big Buck Bunny 360P PNGs for 1000 frames.


--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --partitions all --8x8dct --me umh --threads auto
40.00fps

--crf 22 --aud --ref 3 --mixed-refs --bframes 3 --b-adapt 1 --weightb --direct auto --subme 7 --trellis 1 --8x8dct --me umh --threads auto
42.55fps

Much less impact on speed than hex->umh or subme 6 -> subme 7

I'm not sure its the x264 default ( since you get 3 fps less i guess it is ), its on most megui profiles ( non insane ones ).

You used crf, what was the size for the files ?

Multiple-references are much more efficient, if "--mixed-refs" is enabled. Since the new default will be "--ref 3", it's only consequent to make "--mixed-refs" a default too.

About "--8x8dct": It's probably one of the most useful "High" profiles features. And it may even improve decoding performance, as you can get away with a lower bitrate.

Yes i got it but should have been a "replaced with x because its on by default now and you need no-..... to turn it off"

old cvar was for turning on, new is for turning off so the naming is correct but why was not specified in the post near the new names.

[LoRd_MuldeR]

Yes i got it but should have been a "replaced with x because its on by default now and you need no-..... to turn it off"

old cvar was for turning on, new is for turning off so the naming is correct but why was not specified in the post near the new names.

I don't get your point. If some option is enabled by default, it only makes sense to have a "--no-someoption" parameter. Just in case people want to overwrite the default.

At the same time it makes absolutely no sense to still have "--someoption", because setting this parameter or not would make no difference (as it's the default anyway).

[juGGaKNot]

I don't get your point.

My only point at this moment is that he should have said "changed to no- because its on by default now"

Nothing else.

[J_Darnley]

He did. He said "New defaults [are x]. Logically, this results in the following changes in commandline options"

[Selur]

--subme 7 --bframes 3 --weightb --8x8dct --ref 3 --mixed-refs --trellis 1 --crf 23 --threads auto
with
--no-mixed-refs replaces --mixed-refs
--no-8x8dct replaces --8x8dct
--no-weightb replaces --weightb
shoudln't it be more like:
--subme 7 --bframes 3 --ref 3 --trellis 1 --crf 23 --threads auto
since --weightb, --8x8dct and --mixed-refs won't exist any more ;)

[LoRd_MuldeR]

I think first of all he explained how the "new" defaults would have looked using the "current" (old) CLI options.

Only then he explains why and how the CLI options will change...

[roozhou]

I'm not sure its the x264 default ( since you get 3 fps less i guess it is ), its on most megui profiles ( non insane ones ).

You used crf, what was the size for the files ?

~500kbps.
Roughly p4x4 gave 2% larger file.

[LoRd_MuldeR]

~500kbps.
Roughly p4x4 gave 2% larger file.

It has been explained more than enough that changing options at the same CRF and then checking how the filesize changed is useless!

For example: If the file is 2% larger with p4x4 enabled (at the same CRF), how do you decide whether the extra 2% are worth the quality improvement or not?

You simply can't expect that CRF mode still delivers identical quality (at the same CRF value) after changing other options...

[roozhou]

It has been explained more than enough that changing options at the same CRF and then checking how the filesize changed is useless!

For example: If the file is 2% larger with p4x4 enabled (at the same CRF), how do you decide whether the extra 2% are worth the quality improvement or not?

You simply can't expect that CRF mode still delivers identical quality (at the same CRF value) after changing other options...

I agree. But it seems you miss my point. I am comparing performance loss of p4x4 with hex->umh and m6 -> m7. If p4x4 always brings better quality, why not add it to the defaults?

[LoRd_MuldeR]

As far as I know, default partitions plus p4x4 (aka "--partitions all") isn't better than the default for most sources, but it is significant slower for all sources.

So it wouldn't be a very good idea to include p4x4 in the default partitions for obvious reasons.

And even if the speed loss for p4x4 is smaller than the speed loss for HEX -> UMH, this isn't really an argument. UMH isn't a default either ;)

(BTW: I think your test with the 360p version of Big Buck Bunny may be biased, because p4x4 is more helpful for "lower" resolution video, if helpful at all)

[Audionut]

^^^^
Agreed. And it's been explained on these very forums more than enough times.

[Selur]

another thin about:
--no-mixed-refs replaces --mixed-refs
--no-8x8dct replaces --8x8dct
--no-weightb replaces --weightb
and the replacing part,...
Will these option be switched back if the defaults change again?
Wouldn't it be better to use something like:
--mixed-refs=true/false
instead of changing the interface parameters whenever the defaults change?

[Audionut]

whenever the defaults change?

When was the last time the defaults were changed?

[Selur]

does it matter (probably with the last introduction of a new feature, where I think such a change isn't bad), I don't think so, my point is to keep option for the future without changing the interface.

[J_Darnley]

With B-frames to be on by default it makes sense to use subme 7 so that RD is performed on all frames. Plus Dark Shikari has said that he would prefer to raise subme before raising me.

The defaults were last changed when non-pre-scenecut was removed (Feb '09) and when "Rework subme system, add RD refinement in B-frames" was done (Oct '08).

[tph]

PSNR and SSIM should be disabled by default (the calculations reduce speed and are meaningless to the average user).

[neuron2]

Folks, please keep this thread for simple requests/feedback viz-a-viz the proposed modifications. Create new threads for detailed discussion/debate. Thank you.

I have split off the discussion started by roozhou on umh vs. subme 6 vs. subme 7 into a separate thread.

[popper]

Quote:
Originally Posted by Manao
I know that, but I don't think it's good that default settings on 1080p content would lead to a default level of 4.2 or 5.0 if --ref was bumped up.

If someone wants level 4.1 they should specify it.

hmm , so the 360 with its quoted max of 10Mbit/s H@L4.1, ref 3 for 1920×1080 at 30 fps is out of spec ?

how do you propose to handle that 360 as a default ?

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

BTW , thanks for the effort, im not trying to be fussy about the 360, just so thats clear.

im just after a good default so i and the many 360 streaming users can also use the simple "x264 inputfile -o outputfile" and get that Very Good Results as you put it...

id much rather the MS 360 devs refactor the internal CODECs and issue an updated firmware in the next week ;) for making far better use of the 3 PPC/Altivecs SIMD onboard, but they dont seem interested in that, so here we are..

[Sharktooth]

the xbox360 have additional restrictions (other than level 4.1). i dont think it's a good idea to explicitly support a "console" in an encoder since its specs may change and the job could be left up to the GUIs. also, M$ could just make the x360 be compliant with the standards. that said, you just have to add 2 options to the CLI to make x264 encodes work with x360.
same is for PS3 and DXVA hardware...

[benwaggoner]

id much rather the MS 360 devs refactor the internal CODECs and issue an updated firmware in the next week ;) for making far better use of the 3 PPC/Altivecs SIMD onboard, but they dont seem interested in that, so here we are..
FWIW, my understanding is the quoted Xbox 360 specs are the "fully tested, won't ever drop frames even with weird-but-compliant bitstreams" settings.

In practice it should be able to go quite a bit beyond the quoted parameters.

If there are particular files/settings known to cause problems, I'd be happy to pass that info on.

[10L23r]

PSNR and SSIM should be disabled by default (the calculations reduce speed and are meaningless to the average user).

agreed

and i would also prefer boolean values for mixed-refs, 8x8, etc...

but the rest of it sounds good :)

[Dust Signs]

I agree with tph and 10L23r. Those people who really care about the PSNR and SSIM values can use a separate parameter such as "--ssim" or similar. All other's won't mind not having those values in their output.

Dust Signs

[Sharc]

Shouldn't the new defaults include --direct spatial (for a crf encode)?

[Rumbah]

"--direct auto" works fine with crf, too, as often stated by Dark Shikari.

[Sharc]

So which one should/will become the default then?

[Deinorius]

--direct spatial is already default, but why not change to auto?

[Dark Shikari]

--direct spatial is already default, but why not change to auto?The quality per speed benefit is probably too low to make it a default option, especially with CRF as default.

[Deinorius]

OK, that's logical. But I hope you disable PSNR and SSIM by default. Most users really don't need it.

[LoRd_MuldeR]

OK, that's logical. But I hope you disable PSNR and SSIM by default. Most users really don't need it.

And more important: People shouldn't put too much attention on metrics! Especially when Psy optimizations are on by default...

[Dark Shikari]

And more important: People shouldn't put too much attention on metrics! Especially when Psy optimizations are on by default...Yes, as a result of this and the above reasons, psnr and ssim will be off by default.

[10L23r]

would it be possible to use psy as a metric?

[Dark Shikari]

would it be possible to use psy as a metric?No, because it is QP-sensitive (it's more of a heuristic than a metric).

[JohannesL]

I think --crf 21 should be default, since 23 gives rather crappy quality in many cases.

[10L23r]

crf 22 is good 4 me.

[Manao]

I think --crf 21 should be default, since 23 gives rather crappy quality in many cases. crf 22 is good 4 me. And that's why there shouldn't be any default rate control mode settings. It's the setting that will vary among every individual.

[Dark Shikari]

And that's why there shouldn't be any default rate control mode settings. It's the setting that will vary among every individual.It's also the most asked useless question: "what CRF should I use"? "What bitrate should I use"?

The proper answer is to set a default and let people adjust from there, so it gives them an idea of what to start with. If you don't set a default, people end up doing the exact same thing--experimenting--except they don't even have a good starting point.

Also, I think in general Doom9 people are way too picky about video as compared to your average user, so we should err on the side of slightly lower quality and lower filesize as opposed to generating enormous files.

[Atak_Snajpera]

@Dark Shikari
You proposed 23 value but some people want 21. Why not choose something between? I was never disappointed with CRF@22.

[Deinorius]

What about --progress and --vbv settings. At least --progress can get default too.

[Dark Shikari]

What about --progress and --vbv settings. At least --progress can get default too.Good point, it should. I'll do that.

[LoRd_MuldeR]

What about --progress and --vbv settings. At least --progress can get default too.

VBV potentially hurts quality. And really is only needed for certain hardware players. So it should not be default, I think.

Different VBV-presest could be added, but I fear there are far too many devices with pretty different VBV requirements...

[Deinorius]

VBV potentially hurts quality. And really is only needed for certain hardware players. So it should not be default, I think. OK, that's true. But presets should be fine. You only need DXVA SD/HD or maybe Xbox 360/PS3. The other hardware devices need more adjusting of the settings. But I don't know how wide the presets will be set.

[Dark Shikari]

Device presets would go as yet another option, say --target or --device, in a later patch.

[LoRd_MuldeR]

But presets should be fine. You only need DXVA SD/HD or maybe Xbox 360/PS3. The other hardware devices need more adjusting of the settings. But I don't know how wide the presets will be set.

Hmm, I think this would be too specific. There are far too many devices out there. And new devices appear/disappear every month. Who wants to maintain all of them?

IMHO the built-in presets should be more general, like "Fast" vs. "Slow" or like "Film" vs. "Anime". But not specific to one single playback device...

[Deinorius]

I see.

[Audionut]

And new devices appear/disappear every month. Who wants to maintain all of them?

But keeping some profiles for the popular ones makes sense.

[LoRd_MuldeR]

But keeping some profiles for the popular ones makes sense.

Who decides which devices are popular and which are not? I'm sure people will complain when their favorite device is missing ;)

And it may lead people to the wrong idea that x264 supports certain devices, but others not. Don't you think?

[Atak_Snajpera]

I agree with Lord_Mulder. fast , slow etc preset is enough! Is that hard to use any gui for that?

[Selur]

agree, more specific profiles like hardware&co shouldn't be included in the CLI.

[Yoshiyuki Blade]

I'd say anything between CRF 20-22 would be a good default. 23 a tad too high, but we are indeed rather picky, as videophiles. 23 is also not as bad @1080 as it would be @480, if I'm not mistaken. So it's probably a decent borderline between bad and good.

[Dark Shikari]

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

[Yoshiyuki Blade]

Great! I like the organized design of this. Instead of having a ton of individual profiles in 1 long list, you have 2 separate lists that cover everything in an intuitive fashion.

[popper]

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

its a shame, it appears VLC 1.0 released today doesnt have this update and their web sites down due to the demand.

ohh well....

http://forum.videolan.org/
"The forum and wiki have been disabled due to high load during the VLC 1.0.0 release. It will be back once things settle down.

More info about the release on <a href="http://www.videolan.org>VideoLAN's website.
"

[Mug Funky]

i've only read the top and tail of this thread as i'm at work, but here's a couple of suggestions that may or may not have been covered:

- most h.264 playback is happening on apple's atrociously bad quicktime. i would never suggest pulling on the skirt to apple's juggernaut (i love analogies that don't make sense), but perhaps a --quicktime preset could be handy that just changes the couple of settings that quicktime has problems with.

- as you probably know already, having a default bitrate/quality setting is tantamount to making a statement about what quality people should expect to see. i can't help thinking back to when 128kbps was the default for mp3 interchange, and the shitty sound people spent years putting up with. crf is a really good idea as a default, but perhaps before a LAME style --preset-standard is settled upon, there should be some kind of testing/polling process to find a nice quality-based value that not even a mac based person could get wrong. i tend to encode at crf 18 FWIW, but that tends to come in around half of DVD bitrates for standard def stuff (most of what i encode is straight from masters, not from DVDs. you'd be amazed the difference that makes to bitrates, especially with film content)

sorry, that was a bit tl;dr. basically what i'm thinking is should the default please the quality nuts, or should it please the youtube generation? and if so what crf would those imply?