Advanced Kush Gauge calculator - find the "right" video bitrate

[spoRv]

https://s30.postimg.org/s90upfmht/Advanced_Kush_Gauge_Calculator.png

http://blog.sporv.com/advanced-kush-gauge-calculator (http://blog.sporv.com/advanced-kush-gauge-calculator/)

A simple calculator based on the Kush Gauge formula, but with added features; more info linked in the page; in few words, "the Kush Gauge is a rule of thumb to calculate the needed bitrate for H.264 encoded video", but not only...

Something could be added/improved, but it's fully functional.

Hope this little tool will be helpful for anyone!

[Groucho2004]

What about noise? I find that noise has at least the same impact on required bitrate as motion complexity.

[Andouille]

You can qualify this the same as compressibily test in some guis : BS

[spoRv]

As noise impact is difficult to calculate, you could just take this in account choosing an higher motion rank or simply adding a given percentage to the final calculated bitrate (your mileage can vary).

The optimal bitrate to have a good quality video (or to know if your video has a good one) implies the use of a good encoder, the optimal settings and of course a two pass encoding.

EDIT: forgot to mention that, using x264, when I have to encode a video maintaining the grain intact, I usually multiply the optimal result x1.5.

Open to any suggestion to improve it using your experience!

[vivan]

You can qualify this the same as compressibily test in some guis : BSNah, encoding at X crf and then using resulting bitrate is way less stupid than proclaiming that X bpp (with random multiplier) is the right value for any video.

[Groucho2004]

As noise impact is difficult to calculate, you could just take this in account choosing an higher motion rank or simply adding a given percentage to the final calculated bitrate (your mileage can vary).

The optimal bitrate to have a good quality video (or to know if your video has a good one) implies the use of a good encoder, the optimal settings and of course a two pass encoding.

EDIT: forgot to mention that, using x264, when I have to encode a video maintaining the grain intact, I usually multiply the optimal result x1.5.

Open to any suggestion to improve it using your experience!
I'm sorry but your methods are barely an improvement on a wild guess. There is no such thing as calculating the impact that noise or motion have on the required bitrate, you have to analyse the source. As already mentioned, some "GUIs" already have that analysis built in. You could also roll your own analysis tool.

Also, what do you consider "optimal" bitrate? Is it based on some metrics or human perception? You used that term a few times but you did not explain what it is.

[smok3]

At first I thought this is a joke and now I think this is a joke, but the person actually does exist.
http://www.adobe.com/devnet/adobe-media-server/articles/h264_primer.html
p.s. I guess DAR and PAR input fields are joke inside a joke?

The "formula" seems to be this:

width x height x FPS x motion rank x codec constant x chroma subsampling x bit depth = optimal bitrate (bits per second)

if you wonder (don't).

[spoRv]

@smok3: may you elaborate your joke theory, please? Really, I'm curious; maybe I did this just for nothing, thinking it was useful, but id it's just a waste of time, let me know, thanks!

[spoRv]

@Groucho: maybe I had to write "educated guess", but optimal sounds nicers, and it's shorter! :D

Seriously, I read the original paper and I thought that the guy who wrote the original formula, working there, and having (I think) some experience, *maybe* write it with something right in mind; to me, "optimal" in this case is when you get a good image, free of compression artefacts, that retain (almost all) the original image quality. Or, let's say, a great compromise between a blocky mess and the original one.

I agree that the motion variable is, well... very variable, but a talking head show will be equal to 1, a comedy 2, and an Hollywood action movie would fall into 3, maybe better 4; your mileage can vary on recognizing which is the "right" motion rank.

I added few factors; the mid-hi motion rank (just to fill the gap), the bit depth and chroma subsampling (based just on math), and other codec constants (based on several papers I read about codec comparisons, both subjective and objective) - so I am the sole responsible for those ones.

What I noted is it's fairly accurate; just let's try it as "checker" with some of your sources: pick ugly ones, and good ones, and compare the actual bitrates and the calculated ones. I did it with a fairly high number of sources - DVD, BD, HDTV - and the results were right - what I (and others) repute bad has a bitrate well under the calculated one (often half, if not less), and other great sources had a bitrate twice of more the calculated one.

At the end, it should be taken "cum grano salis"; and, I think that an educated guess is better than nothing... but maybe (probably?) I'm wrong.

[Groucho2004]

I should point out the variables that are not covered by your formulas:

I ran a bunch of tests a while ago by analysing portions of the source via Avisynth/SelectRangeEvery/x264 to determine the required bitrate for a given CRF value. More often than not the results were far off from what one would have expected based on resolution and motion complexity, usually caused by some type of noise.

Even if you limit the target format to h.264 you have to consider the different efficiency of encoders. For example, if you use NVENC you have use a much higher target bitrate in order to get the same quality as with x264 (yes I tested that too, NVENC is terrible).

Nowadays I don't bother with this any more since all movies are on a NAS so I just use CRF and let the encoder use the bitrate it needs.

[spoRv]

Yes, CRF would certainly make a better job, but what if I have to stay inside a limit, like the one of a physical media?

I agree with you, different encoders = different results at the same bitrate.
Indeed, as you noted, I chose two different constants for the MPEG-2 encoders - one hardware, one software, following the directions found on some of the papers I wrote before.

Maybe I should add the advice that the "optimal bitrate" (or maybe I should change it to "educated guessed bitrate"?) could be applied to x264 for AVC, x265 for HEVC, while VC-1 has just Microsoft encoder (AFAIK); dunno what MPEG-2 should be advised, though - x262? HC-Enc?

I would also add that it could be used not only to find out the needed bitrate to encode a video, but also to check if a given source (BD, DVD, HDTV etc.) has a "sufficient" quality - again, better to have some sort of easy measurement, albeit far from perfection, instead of saying "it's good/bad to me!"

Sure, it would be great if different users would give it a try, and see what they think - subjectively, and possibly objectively - to check if effectively it works (or not); because it's easy to give a brief look at an idea, and say it's a joke (or bulls**t), while it's harder to take some time and make experiments, and finally say it's working, or not, with something more than an opinion to justify that sentence.

[Groucho2004]

I would also add that it could be used not only to find out the needed bitrate to encode a video, but also to check if a given source (BD, DVD, HDTV etc.) has a "sufficient" qualityYou have to elaborate on that statement. How would a bitrate calculator be able to determine the quality of a source?

Sure, it would be great if different users would give it a try, and see what they think - subjectively, and possibly objectively - to check if effectively it works (or not); because it's easy to give a brief look at an idea, and say it's a joke (or bulls**t), while it's harder to take some time and make experiments, and finally say it's working, or not, with something more than an opinion to justify that sentence.The feedback you got is not based on opinions. The science behind your arguments is simply wrong. No matter what correction factors for motion complexity you use, you can't predict the needed bitrate for a desired quality this way.
Why do you think most of the computing time in an encoder is spent in source analysis? Certainly not to heat up the CPU and your room.

For many contemporary movies your calculator will probably provide acceptable results but for others it will fail. For example, "Black Swan" or "300" have artificially added noise, they need 2-3 times the bitrate you would expect (or your bitrate calculator would tell you) to reproduce this properly. Another example would be old movies with lots of film grain.

[spoRv]

How would a bitrate calculator be able to determine the quality of a source?


Maybe I explained myself wrong. First, of course, we let to give this calculator some chance it works, ok? Second, if, for a given source, you supply the calculator the needed data - again, motion rank is the most variable - and the source is a lot far from it, *probably* its bitrate is not high enough (if much lower) or has a great quality (much higher).


...you can't predict the needed bitrate for a desired quality this way.

I'm aware of this. Let's call it an empirical way to get a bitrate that gives you acceptable quality, and hopely not too much compression artefacts. Better?


For many contemporary movies your calculator will probably provide acceptable results but for others it will fail. For example, "Black Swan" or "300" have artificially added noise, they need 2-3 times the bitrate you would expect (or your bitrate calculator would tell you) to reproduce this properly. Another example would be old movies with lots of film grain.

Yes, I'm aware of this, too. It's not a scientific calculator, more a mathematically way to find it. If it's right the most of the times, then it could be useful, most of the times... of course, the human behind the encoder would determine if the source has noise, grain etc. and act in consequence; for example, I add 50% to the result for grainy sources, not based on any scientific proof, but just to experience. And it work most of the time.

So, if someone would take some time to experiment with this, it will be nice to get the result and compile statistics; let's say it works 90% of the time well, and, in the other 10% of the case, when grain/added noise (or other factors) are involved, maybe it's possible to find a further variable to the formula.

Is it the perfect solution to find the best bitrate for every source? Absolutely not! Does it work well with any source? Surely not. Does it gives you an idea of what bitrate could be fine to obtain a subjectively good result? I think so, most of the time.

It's just a nice tool. Far from perfection. Gives you an advice. As I wrote in the linked page (if anyone gave it a look), I stated that "the Kush Gauge is a rule of thumb to calculate the needed bitrate for H.264 encoded video". Going to add this line to the first post, just to be clear.