x264 presets, profiles, and tuning system

[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

[Guest]

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.