Log in

View Full Version : x264 defaults changing


Pages : [1] 2

Dark Shikari
2nd July 2009, 01:15
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
2nd July 2009, 01:28
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
2nd July 2009, 01:31
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
2nd July 2009, 02:20
sounds like a great idea. But maybe crf 23 is a bit too high. i'd prefer crf 21 ;)

+1 :)

Chengbin
2nd July 2009, 03:07
How about some partitions set as default?

Sagekilla
2nd July 2009, 03:27
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
2nd July 2009, 04:31
--ref 3
Maybe 4 or even possibly 5? Or would it not be worth the loss in speed (for defaults of course:D)?

Manao
2nd July 2009, 05:39
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
2nd July 2009, 06:05
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
2nd July 2009, 06:17
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
2nd July 2009, 06:26
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
2nd July 2009, 06:35
"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
2nd July 2009, 07:20
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
2nd July 2009, 07:43
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
2nd July 2009, 07:51
Instead of --option/--no-option, what about "--option boolean", with boolean allowed to be 0/false/off-1/true/on ?

greath
2nd July 2009, 08:12
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
2nd July 2009, 08:52
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
2nd July 2009, 09:24
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
2nd July 2009, 09:27
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
2nd July 2009, 09:33
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
2nd July 2009, 09:35
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
2nd July 2009, 09:40
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
2nd July 2009, 09:42
Does p4x4 break dxva compatibility?
No i does not

roozhou
2nd July 2009, 09:53
No i does not

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

juGGaKNot
2nd July 2009, 10:05
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
2nd July 2009, 10:22
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
2nd July 2009, 10:31
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
2nd July 2009, 10:39
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
2nd July 2009, 11:00
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
2nd July 2009, 11:08
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
2nd July 2009, 11:43
He did. He said "New defaults [are x]. Logically, this results in the following changes in commandline options"

Selur
2nd July 2009, 12:15
--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
2nd July 2009, 12:17
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
2nd July 2009, 12:35
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
2nd July 2009, 12:49
~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
2nd July 2009, 13:44
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
2nd July 2009, 13:51
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
2nd July 2009, 13:57
^^^^
Agreed. And it's been explained on these very forums more than enough times.

Selur
2nd July 2009, 14:47
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
2nd July 2009, 14:54
whenever the defaults change?

When was the last time the defaults were changed?

Selur
2nd July 2009, 15:02
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
2nd July 2009, 15:17
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
2nd July 2009, 15:44
PSNR and SSIM should be disabled by default (the calculations reduce speed and are meaningless to the average user).

Guest
3rd July 2009, 00:06
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
3rd July 2009, 16:42
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
3rd July 2009, 18:14
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
3rd July 2009, 18:57
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
4th July 2009, 06:13
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
4th July 2009, 10:45
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
5th July 2009, 11:54
Shouldn't the new defaults include --direct spatial (for a crf encode)?