[example] x264s crf highly depends on other settings,...

[Selur]

I know most of you, like me, know that crf is not constant quality and that the effect of crf can strongly change depending on the settings you choose. This is a nice thing to know, but to be frank most of the time, at least I, don't really think about it. :P

So, if I for example encode the attached clip with:

x264 --profile high --level 4.1 --min-keyint 25 --bframes 4 --b-pyramid none --b-adapt 2 --sync-lookahead 0 --no-mbtree --subme 6 --trellis 0 --psy-rd 0:0.0 --vbv-maxrate 62500 --vbv-bufsize 78125  --non-deterministic --colormatrix bt470bg --fps 30000/1000 --input-res 848x480 --output "H:\Temp\test.264" -

-> I get a file size of 2.077.665 bytes (inside mkv container)
(the important part is: --sync-lookahead 0 --no-mbtree --trellis 0 --psy-rd 0:0.0)

if I now enable trellis:

x264 --profile high --level 4.1 --min-keyint 25 --bframes 4 --b-pyramid none --b-adapt 2 --sync-lookahead 0 --no-mbtree --subme 6 --psy-rd 0:0 --vbv-maxrate 62500 --vbv-bufsize 78125  --non-deterministic --colormatrix bt470bg --fps 30000/1000 --input-res 848x480 --output "H:\Temp\test.264" -

-> I get 2.564.729 bytes (+25% file size)

and if I take more normal settings like:

x264 --crf 23 --profile high --level 4.1 --min-keyint 25 --bframes 4 --b-pyramid none --b-adapt 2 --subme 6 --vbv-maxrate 62500 --vbv-bufsize 78125  --non-deterministic --colormatrix bt470bg --fps 30000/1000 --input-res 848x480 --output "H:\Temp\test.264"

-> I get 3.351.906 bytes (+60% file size)

using the typical:

x264 --profile high --level 4.1 --vbv-maxrate 62500 --vbv-bufsize 78125 --qpfile GENERATED_QP_FILE --non-deterministic --colormatrix bt470bg --fps 30000/1000 --input-res 848x480 --output "H:\Temp\test.264" -

-> I get 3.871.758 bytes (+85% file size)

Why I post this?

I simply wanted too show/share just how much the effect of crf depends on other settings, since at least I knew that it depended a lot on other settings, but just how much, really surprised me.

Cu Selur

Ps.: the main effects are due mbtree and trellis.

[jagabo]

Of course the final file size depends on the other settings. Try setting a GOP size of 1. But all your encodings at the same CRF look very close in quality, regardless of the file size. Ie, the CRF determines what the picture quality will be. The other settings determine how much compression you'll get.

[Selur]

Of course the final file size depends on the other settings.

Congratulations, you deserve a pat on your back. You are right!! Like I stated, that this is nothing new and that I just wanted to share my surprise just how much trellis and mbtree increase the size. Since these are from my point of view two of the more intuitive concepts.
Since it seems like you expected such a difference, are you able to explain mbtree in an understandable way?

Try setting a GOP size of 1.

Sure IntraFrameCoding will change the file size, but at least for me that is far more obvious than trellis and mbtree.

But all your encodings at the same CRF look very close in quality, regardless of the file size.

then 86% more bit rate does not do much quality wise?

Cu Selur

[deadrats]

i am pretty confused, can someone explain a few things to me:

why is the crf settings so ass backward?

if crf sets a target quality, then why does the bit rate increase as the crf value gets lower? wouldn't it be more logical to make the crf scale linear based on 100%?

also, it's my understanding that at about crf 15 or 16 the encode is transparent to source, if so then what is the point of lower values?

while i'm at it, if you achieve transparency at crf 15 or so, then why not rescale the algorithm so crf 15 becomes crf 0?

at the point where some crf value means transparent encode, does that mean that the bit rate of the encode will equal the bit rate of the source? if not, why not?

and lastly, why would the file size go up with more aggressive settings (the file size increased with mb-tree and trellis).

to me this is just more proof that x264 is way over engineered and quite frankly coded in a half assed way, it's a kludge in the truest sense of the word, they started out with a pathetic h264 implementation and they just kept adding band-aids to it in the hopes of covering up the mess. it manages to exemplify all the worst elements of open source software, over-hyped half assed kludges that should have been deleted years ago.

[jagabo]

if crf sets a target quality, then why does the bit rate increase as the crf value gets lower? wouldn't it be more logical to make the crf scale linear based on 100%?

Because it's based on quantizers.

also, it's my understanding that at about crf 15 or 16 the encode is transparent to source, if so then what is the point of lower values?

It's not always.

while i'm at it, if you achieve transparency at crf 15 or so, then why not rescale the algorithm so crf 15 becomes crf 0?

Because you may want something better than "visually about as good as the source". And, of course, CRF=0 is lossless.

at the point where some crf value means transparent encode, does that mean that the bit rate of the encode will equal the bit rate of the source? if not, why not?

Because the two are unrelated.

and lastly, why would the file size go up with more aggressive settings (the file size increased with mb-tree and trellis).

Some more settings increase the quality a bit, not the compression, so they require more bitrate.

[_Al_]

CRF is based on CQ, simply same thing but it cheats while there is motion, CQ keeps quantizer at some level, you have quantize = zero you get lossless encoding, think of quantizer as a number that simplifies data in video, zero same as original , lossless, so file is huge (cannot be same as original as you say, because that is already compressed), you have number bigger, it simplifies data much more, hence higher compression. So that is why it is backwards. Sure for the logic sake they could set it backwords but then it would not be quantizer but quality settings, and you would have to set it for example from 0-100. Where 100 is lossless and zero is what?, how do you define biggest garbage compression. So you would have to make up scale where there is best and worse CRF, made up numbers. Zero - lossles and higher number - higher compression is beautiful definition.

As a free stuff a on the other hand cannot believe that it works well as it does. I would care less about some quirks in terminology or oddity if there is such. Default settings are more than enough, good for everyday use. You have professional videoeditors and they do not have constant rate factor encodings up to today! Folks have to calculate some average bs or set a bitrate like in some sort of lottery, which is constant crash with anybody using it first time. Or take zones for example, or working with buffers settings and max bitrate settings where you can define bitrate for 1pass only, not having used CBR which is waste of resources. CRF sets lower bitrate if it is not needed and keeps max in some sort of check at the same time..., etc....

[jagabo]

Deadrats knows all this of course. He's just whining. Probably drunk tonight.

[_Al_]

I have here 23 min HD video,shot with camcorder, hand held, encoded with basic line:

x264 --crf=18 --profile High --level 4.1 --ref 4 --vbv-bufsize 31000 --vbv-maxrate 30000 --output out.h264 in.avs

and then I tried to add those things that suppose to change volume of video: --sync-lookahead 0 --no-mbtree --subme 6 --trellis 0 --psy-rd 0:0.0

x264 --crf=18 --profile High --level 4.1 --ref 4 --sync-lookahead 0 --no-mbtree --subme 6 --trellis 0 --psy-rd 0:0.0  --vbv-bufsize 31000 --vbv-maxrate 30000 --output out.h264 in.avs

and size is exactly the same (4kB difference in about 2.85GB video)

So those added settings are set as default in the first place?

[alom]

Hi all! I'm new here

I recently done some testing and was really surprised that trellis increases the size while using crf (and how much!).
On a sample 20min clip in 1024x567 encoded with crf=19, subme 9

trellis 0 - 348MB
trellis 1 psy-rd 1:0.2 - 400MB (15% increase)
trellis 2 psy-rd 1:0.2 - 385MB (10% increase)

I compared few frames from the clip and I didn't noticed quality difference between trellis 1 and 2 but both were slightly sharper than trellis 0.
Till now I was convinced that using trellis should make video size smaller, which is definitely not the case.
So like the author of this thread I'm a bit surprised hot "unreliable" CRF is.
I was even thinking that this might be a bug in new x264 build and done one more encode with trellis 0 but I changed CRF to 18
crf 18, trellis 0 - 410MB (18% increase)
and after comparing the frames it looks like the files encoded with crf 19 but with trellis on are still better/sharper!
I guess trellis might be good after all it's just that if you want lower bitrate you might want to increase crf value before turning on trellis - this should even thing out

[skaleton]

the CRF determines what the picture quality will be. The other settings determine how much compression you'll get.

Clear and concise

[jagabo]

the CRF determines what the picture quality will be. The other settings determine how much compression you'll get.

Clear and concise

It's a fair general rule but not 100 percent true. The settings can make a difference in quality. For example, even with the same CRF, the veryfast preset often delivers smaller files than the normal preset but it also a little lower in quality.

[skaleton]

Maybe I'm wrong but I thought your answer was 100 percent true in the context of the opening post, which I understood as making small changes in the global settings, which could be a preset.
I just wanted to mention that I liked the way your put it
and fair general rules are usually good and easy to keep in mind

[Selur]

@jagabo: 'the veryfast preset often delivers smaller files than the normal', trellis is disabled, superfast might even be smaller since mb-tree is disabled,..

[deadrats]

@jagabo: 'the veryfast preset often delivers smaller files than the normal', trellis is disabled, superfast might even be smaller since mb-tree is disabled,..

i think x264 itself should be disabled, people need to start using a nice high quality encoder like apple's h264 or rovi's.

[Selur]

and just for you they took down x264.nl *ig*

[El Heggunte]

Come on, x264 is not that bad, all that it needs is a COMPREHENSIVE manpage, not just a --fullhelp switch or a half-assed corner at Megui's wiki.