VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Results 1 to 16 of 16
Thread
  1. 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:

    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" -
    -> 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:
    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" -
    -> I get 2.564.729 bytes (+25% file size)

    and if I take more normal settings like:
    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"
    -> I get 3.351.906 bytes (+60% file size)

    using the typical:
    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" -
    -> 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.
    Quote Quote  
  2. 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.
    Quote Quote  
  3. 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
    Quote Quote  
  4. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    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.
    Quote Quote  
  5. Originally Posted by deadrats View Post
    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.

    Originally Posted by deadrats View Post
    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.

    Originally Posted by deadrats View Post
    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.

    Originally Posted by deadrats View Post
    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.

    Originally Posted by deadrats View Post
    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.
    Quote Quote  
  6. 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....
    Quote Quote  
  7. Deadrats knows all this of course. He's just whining. Probably drunk tonight.
    Quote Quote  
  8. I have here 23 min HD video,shot with camcorder, hand held, encoded with basic line:
    Code:
    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
    Code:
    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?
    Quote Quote  
  9. Member
    Join Date
    May 2013
    Location
    Poland
    Search Comp PM
    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
    Quote Quote  
  10. Member
    Join Date
    May 2007
    Location
    United States
    Search Comp PM
    Originally Posted by jagabo View Post
    the CRF determines what the picture quality will be. The other settings determine how much compression you'll get.
    Clear and concise
    Quote Quote  
  11. Originally Posted by skaleton View Post
    Originally Posted by jagabo View Post
    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.
    Quote Quote  
  12. Member
    Join Date
    May 2007
    Location
    United States
    Search Comp PM
    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
    Quote Quote  
  13. @jagabo: 'the veryfast preset often delivers smaller files than the normal', trellis is disabled, superfast might even be smaller since mb-tree is disabled,..
    Quote Quote  
  14. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by Selur View Post
    @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.
    Quote Quote  
  15. and just for you they took down x264.nl *ig*
    Quote Quote  
  16. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    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.
    Quote Quote  



Similar Threads