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:
-> I get a file size of 2.077.665 bytes (inside mkv container)Code: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" -
(the important part is: --sync-lookahead 0 --no-mbtree --trellis 0 --psy-rd 0:0.0)
if I now enable trellis:
-> I get 2.564.729 bytes (+25% file size)Code: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" -
and if I take more normal settings like:
-> I get 3.351.906 bytes (+60% file size)Code: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"
using the typical:
-> I get 3.871.758 bytes (+85% file size)Code: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" -
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.
Ps.: the main effects are due mbtree and trellis.
+ Reply to Thread
Results 1 to 16 of 16
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.
Last edited by jagabo; 26th Apr 2013 at 17:24.
Of course the final file size depends on the other settings.
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.
But all your encodings at the same CRF look very close in quality, regardless of the file size.
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.
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....
Deadrats knows all this of course. He's just whining. Probably drunk tonight.
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
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
So those added settings are set as default in the first place?
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
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
@jagabo: 'the veryfast preset often delivers smaller files than the normal', trellis is disabled, superfast might even be smaller since mb-tree is disabled,..
and just for you they took down x264.nl *ig*