x264 presets, profiles, and tuning system

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

[Guest]

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.