VideoHelp Forum




+ Reply to Thread
Results 1 to 8 of 8
  1. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    no, not the way it works, i understand that it's supposed to track changes as the propagate across frames, what i don't understand is the following from the x264 wiki:

    http://mewiki.project357.com/wiki/X264_Settings#no-mbtree

    no-mbtree

    Default: Not Set
    Disable macroblock tree ratecontrol. Using macroblock tree ratecontrol overall improves the compression by keeping track of temporal propagation across frames and weighting accordingly. Requires a new large statsfile in addition to the already existing for multipass encodes.
    Recommendation: Defaul


    qcomp

    Default: 0.60

    Quantizer curve compression factor. 0.0 => Constant Bitrate, 1.0 => Constant Quantizer.When used with mbtree, it affects the strength of mbtree. (Higher qcomp = weaker mbtree).

    Recommendation: Default




    to me the above seems inherently contradictory, mb-tree supposedly improves the compression, so a stronger mb-tree setting would logically imply that crompression strength is also improved thus as maximum mb-tree strength compression benefits from mb-tree should be at their maximum potential, yet qcomp, which controls the strength of mb-tree results in constant quantizer as mb-tree gets bigger and constant bitrate as max mb-tree.

    am i the only one that things this doesn't make any sense at all? i always thought that constant quantizer resulted in constant quality throughout the video while constant bitrate simply made the stream more stable but everyone always says that CQ would result in better quality than CB.

    however if mb-tree improves compression and thus quality at a given bitrate (with regards to no-mb-tree vs mb-tree) and as qcomp strengthens mb-tree as bitrate approaches constant bitrate then that means that constant bitrate gives superior quality to constant quantizer.

    also, what is the deal with:

    pbratio

    Default: 1.30
    Modifies the target average decrease in quantizer for B-frames as compared to P-frames. Higher values decrease the quality of B-frames generated. Not used with mbtree (enabled by default), which calculates the optimum value automatically.
    See also: --ipratio
    so according to this pbratio modifies the quantizer for b-frames as compared to p-frames but this value is automatically calculated by mb-tree but as was stated above as qcomp goes lower mb-tree gets stronger and bitrate goes to constant bitrate which means that at max mb-tree no quantizer is being calculated for any frames and this both ipratio and pbratio must both have values of 1.

    am i missing something with the above or this just another case of a software developer that has just over-engineered a piece of software which has resulted in circular reasoning with regards to the settings?

    based on the above explanation of settings setting qcomp to 0.0 and mb-tree=1 results in the exact same thing as if you set ipratio and pbratio to 1, bitrate to constant and disabled mb-tree; which basically means that for maximum quality the x264 developers wasted their time coding mb-tree and qcomp and they should go shoot themselves for breaking my damn balls with their silly software this saturday afternoon.

    freaken bastards, they should all be deported to jupiter.
    Quote Quote  
  2. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    DISCLAIMER: I am no x264-expert, and I have done relatively-few encodes with x264, and I've never paid much attention to what I was doing then.

    First thing: that's a MeGUI wiki, and apparently it's not taken seriously by Dark Shikari nor by Loren Merritt.

    Secondly: there is a difference between CRF and CQ. CQ disables the mbtree algorithm in x264. Besides, I've noticed that CRF + mbtree = pbratio unspecified in the encoding parameters displayed in komisar's builds of x264. But according to the damn wiki, pbratio

    is not used with mbtree (enabled by default), which calculates the optimum value automatically
    P.S.: MeGUI was developed/maintained by Sharktooth and Kurtnoise , therefore
    it has always sucked and it will keep sucking forever.
    Last edited by El Heggunte; 16th Feb 2013 at 18:20. Reason: correct myself
    Quote Quote  
  3. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    LOL@El Heggunte

    i swear, the more i use x264 the more i believe that it's arguable the most over-rated and over-engineered piece of software anyone has ever conceived; i wonder if main concept's h264 encoder or CCE's were legally free or if x264 cost as much as either with similar licensing terms, would the x264 faithful still worship at the alter of x264 or would they wake up and smell the cappuccino.
    Quote Quote  
  4. Member
    Join Date
    Aug 2010
    Location
    Indian Ocean
    Search Comp PM
    Well, I use x264 too, and to be fair, it does provide excellent compression. But it's a real hassle to get the right settings. MPEG-2 encoding is child's play, compared to it.

    It's funny you should mention the x264 faithful. I was reading a thread on doom9 once, and someone said he used a commercial encoder for scenes requiring high bitrate. Sure enough, the "faithful" started attacking him relentlessly, as if he committed some crime.
    Quote Quote  
  5. DECEASED
    Join Date
    Jun 2009
    Location
    Heaven
    Search Comp PM
    The following is a totally subjective/"unscientific" report, but I will post it "just for the notes" ......

    I did run some H.264 testing encodes in MainConcept Reference "sometime before 1975" , and to my eyes at least, the visual quality of the MCR encodes was noticeably *more constant* than the visual quality of the x264 encodes. However I am an old and impatient man already, so I sticked to x264 only because it's faster than MCR.

    Anyway, I won't be able to give an appropriate answer to your original request
    ( « can someone explain mb-tree to me? » ),
    therefore, apologies for going off-topic =^.^=
    Quote Quote  
  6. Originally Posted by deadrats View Post

    pbratio

    Default: 1.30
    Modifies the target average decrease in quantizer for B-frames as compared to P-frames. Higher values decrease the quality of B-frames generated. Not used with mbtree (enabled by default), which calculates the optimum value automatically.
    See also: --ipratio
    so according to this pbratio modifies the quantizer for b-frames as compared to p-frames but this value is automatically calculated by mb-tree but as was stated above as qcomp goes lower mb-tree gets stronger and bitrate goes to constant bitrate which means that at max mb-tree no quantizer is being calculated for any frames and this both ipratio and pbratio must both have values of 1.

    am i missing something with the above or this just another case of a software developer that has just over-engineered a piece of software which has resulted in circular reasoning with regards to the settings?

    based on the above explanation of settings setting qcomp to 0.0 and mb-tree=1 results in the exact same thing as if you set ipratio and pbratio to 1, bitrate to constant and disabled mb-tree; which basically means that for maximum quality the x264 developers wasted their time coding mb-tree and qcomp and they should go shoot themselves for breaking my damn balls with their silly software this saturday afternoon.

    freaken bastards, they should all be deported to jupiter.
    Read up on what constant bitrate means. Hint: constant bitrate doesn't necessarily mean i=p=b quantizer or coded frame size . You can have CBR encodes with different IPB ratios, even with other codecs - eg. think of what CBR MPEG2 looks like, the I,P,B quantizers are certainly not equivalent... .



    My opinion on mb-tree:

    Pros: it's excellent for static scenes, like interviews, talking heads, conference calls that sort of thing

    Cons: it's tends to take bits away from dark scenes and fades, some people disable it for that reason (or raise qcomp to reduce the effect, or use zones). This (in part) prompted other patches like the fade compensate patch
    Quote Quote  
  7. Banned
    Join Date
    Nov 2005
    Location
    United States
    Search Comp PM
    Originally Posted by poisondeathray View Post
    Read up on what constant bitrate means. Hint: constant bitrate doesn't necessarily mean i=p=b quantizer or coded frame size . You can have CBR encodes with different IPB ratios, even with other codecs - eg. think of what CBR MPEG2 looks like, the I,P,B quantizers are certainly not equivalent... .
    maybe i'm being too literal but to me constant bitrate means just that, the bitrate doesn't fluctuate between each second of time interval, i.e. 4000 mb/s cbr means that if i divide the video into 1 second intervals each and every single one of them will have a bitrate of 4000 mb/s.

    however when you look at what the developers say with regards to cbr, cq, mb-tree, qcomp, pb-ratio and the like there is a logical disconnect in the various explanations, taken together it effectively means that cq+mb-tree+p/b-ratio are a complete waste of time, you can get the same results by using cbr and calling it a day.

    i just don't get it, i wish all codec developers would just code their encoder to produce the highest quality output for a given bitrate and that's it, no need for an end user to have to fiddle with all kinds of settings, the only possible output should be "best quality for this target bitrate" and that's it.
    Quote Quote  
  8. Originally Posted by deadrats View Post

    however when you look at what the developers say with regards to cbr, cq, mb-tree, qcomp, pb-ratio and the like there is a logical disconnect in the various explanations, taken together it effectively means that cq+mb-tree+p/b-ratio are a complete waste of time, you can get the same results by using cbr and calling it a day.
    But it's not the same, and you don't get the same results .


    i just don't get it, i wish all codec developers would just code their encoder to produce the highest quality output for a given bitrate and that's it, no need for an end user to have to fiddle with all kinds of settings, the only possible output should be "best quality for this target bitrate" and that's it.
    The problem is different types of content will do better with different settings. Different bitrate ranges and goals require different settings. For example, you wouldn't use the same settings for and ipod as you would for blu-ray. You wouldn't encode simple anime the same way you would a live action movie. It would be impossible for software to accurately determine the "best" settings for every scenario. Moreover, there are speed/quality tradeoffs - some people don't want to encode 10x longer for 2.5% better "quality" ...but some don't mind... you get the idea...

    They've simplified it for beginners, there are tunings and presets which is a good place to start . Many GUI's have modified presets and device compatibility profiles . It's really the "best" of both worlds. Those that know how to dial in settings can get custom results. Those who have no clue have a good place to start and they can read and experiment at their own leisure
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!