Even better than dvd::rip, except...

[o69]

Since long ago I use dvd::rip to rip DVDs to xvid+mp3.avi. Recently I discovered handbrake and it's even easier and as powerful as dvd::rip! I really like it.

I only miss one detail: to find optimal width and height if filesize or bitrate is fixed, dvd::rip can use average bpp (bits per pixel). With mpeg4 about 0.2 bpp gives optimal sharpness without block artefacts. Using handbrake I have to calculate bpp by hand.

So I see 2 solutions: (3 if calculating by hand counts )
* hb could only _display_ bpp (under tab "Picture" it would be nice) - easy to implement and already helpful, at least for gui user.
* like dvd::rip hb could let the user _define_ bpp (in the window "Picture - Preview" under "Scaling")

Problems that I see:
* A defined average bpp is very good for mpeg4. But I dont know if this is true for other codecs.
* If video bitrate is not fixed but defined by "Quality", it does not make sense to also set bpp. How could this be represented in the gui without confusing the user?

Anyway, my thanks to all devs of hb!

[realityking]

A warning, bpp isn't a concept thats thought about highly around here. And to be honest I don't really get it either, I'd suggest to look into
Constant Quality since it is regarded as superior. I doubt bpp will be in HandBrake in any form.

[JohnAStebbins]

Well, to be fair, a smart well informed user could use bpp as a metric in their guess whether the resulting video is going to look like crap or not. bpp = bps / (fps*width*height), judging picture quality by bpp is a total swag and the desired bpp will vary depending on video content just as bitrate does. fps can also be variable which complicates things further. The desired bpp will also depend on the codec used and the particular settings being used for that codec. So the user needs some experience and some knowledge of the source being encoded to make informed decisions.

For an example, start with the quicktime preset that has 1800kbps video.
Film 1800 / (24*720*352) = 0.21
TV 1800 / (30*720*480) = 0.17

Are these rates high enough? Grainy film could need more. Documentary talking heads TV could require less. The content is really the more important variable.

All that being said, the trend in handbrake development is to cater to features that preserve the original content as much as possible. None of the developers are really interested in downscaling for the purpose of cramming a video into a specific size file. Simple economics, no developer interest, no pony.

[o69]

You're right. To control quality, bpp is not suitable. And quality is what its all about.

But there _is_ a "bitrate" and a "total filesize" setting in hb, and for that a bpp around 0.2 is nice to prevent you from too many pixels. IMHO a little less sharpness is definitely better than blocky action scenes!

Thanks for your quicktime calc's: 0.17 ... 0.21 bpp is what's expected to be ok for mpeg4 too. I usually use 0.2 bpp for DVDRips and then round down the cropped width to a multiple of 32, the height down to a multiple of 16 - works great for quiet, fast, dark and bright movies, even comics.

I started tests with different "Quality" settings and will compare PSNR with that of a bpp0.2-file with same filesize.

[jbrjake]

But there _is_ a "bitrate" and a "total filesize" setting in hb, and for that a bpp around 0.2 is nice to prevent you from too many pixels.

...but as John already explained to you, that is simply not true. You cannot make sweeping pronouncements based on BPP because it is utterly meaningless. There is no such thing as a set number for "too many pixels" without regard to things like the source and far more importantly the settings!

[o69]

0.2 BPP equals 51.2 "bits per 16x16-block". Most encoders write frames built from such blocks.
The less kbps you spend, the less blocks (and width x height) you can have for the same quality.
So a constant BPP just connects kbps with width and height.

Of course you need the same experience to increase BPP to 0.25 for heavy action movies.
But its easier to deal with, than with kbps, width and height, because its only one number.

When using HandBrakeCLI in a script, these calculations can easily be done in the script.
So it's no problem. What counts for me then is hb's ingenious "autocrop" feature!

thanx for your feedback!

[jbrjake]

If you care about quality you shouldn't be using a bitrate-based rate control method, period.

What you're doing is entirely arbitrary. You're classing it up with a bunch of talk about macroblocks but that doesn't change the fact that the bitrate needed for a particular quality varies for every single source (by both scene complexity and framerate variance) and every single option set. There is absolutely no way you can address that by looking at picture dimensions.