Final file size HB 9.6

[waldstein]

This is my first post here, so I apologize if this is more a "support" question and inappropriate here.

In any case, I have been using HB for quite some time and have been VERY happy with its ability to come very close to a pre-determined final file size, using full 2-pass, in version 9.5. In 9.6, however, I see no way to set the final file size. Is this intentional, or am I missing some option that will enable "target size"? For now, I've reverted back to 9.5 in order to keep the option.

All advice much appreciated.
TIA

[JohnAStebbins]

search.php?st=0&sk=t&sd=d&sr=posts&keywords=target+size

[waldstein]

I'll start by replying to myself. I decided (admittedly, too late) to query "target" and discovered that MANY users have addressed this issue, and that hardly any have been satisfied by the peremptory "if you don't like it here, go back to where you came from" sort of response.

OK, I can live with that, but what I would really appreciate NOW is a much more helpful explanation of how to equate RF values with EITHER size (eg, "normative" values for MB's per hour of output video depending upon RF percent chosen) or quality (eg: a chart giving rough estimates for output file size at RF value depending upon source bitrate and resolution).

Honestly friends, telling us that that "we know what's good for you, and think of all the space you'll save" doesn't really help all that much. PLEASE, more guidance. (And I have read a great many of the "explanatory" posts already and have found them not very helpful.)

Again, thanks in advance.

[jamiemlaw]

The only metric that exists to relate RF to both quality and file size is that, for a given source, for every 6 points you lower the RF, you can expect the file size to double, and the difference between the input and output quality to halve. So if you run an encode with an RF of 20, and the result is a 1GB video with SSIM of 0.98, if you were to run the same video again at RF 14, it'd come out, in theory, at 2GB and have an SSIM of 0.9. And at RF 8, 4GB and an SSIM of 0.95.

But as you can work out, there is no way short of encoding the video to know what the file size will be for a given RF: it depends entirely on the complexity of the source. Grainy sources will have higher bit rates and lower quality; smooth sources will have lower bit rates and higher quality.

[JohnAStebbins]

First, you must not have read all the posts completely because I've answered these questions myself dozens of times and am frankly getting tired of it. I can't blame you though because there is so much spam on this topic.

The #1 reason target file size was eliminated is because it was broken and getting more broken with each new release of HandBrake. None of the developers use it, so it got very little attention. Target file size made new development increasingly difficult because we are adding new features that require special casing and/or disabling target file size if those features are used. This special casing also makes the GUI unintuitive (e.g. why is target file size available sometimes and not others?)

I would really appreciate NOW is a much more helpful explanation of how to equate RF values with ... or quality (eg: a chart giving rough estimates for output file size at RF value depending upon source bitrate and resolution).

This comment illustrates one of the other reasons for eliminating it. Quality and file size have almost no relation to one another. The animation Madagascar gets encoded to a file size that is 5 times smaller than my grainy copy of Blade Runner, yet both are the same quality. If you are truly interested in getting the best possible quality while conserving disk space, you must use constant quality mode (RF). You can't equate RF to file size or bitrate. It uses as many (or as few) bits are as necessary to achieve the requested quality.

To use constant quality mode effectively, follow these steps.
1. Pick some sample video
2. Encode a few minutes of that video at RF 17
3. Inspect the output
4. Increase the RF by 1 (lower the quality)
5. Encode the sample again
6. Inspect the output
7. If you are still happy with the quality, go back to step 4
8. Decrease the RF value by 1 (the last value you were happy with)
9. Use this RF value on ALL your video.

This will give you consistent quality without wasting disk space on video that doesn't require a higher bitrate. And at the same time, it will provide extra bitrate for complex grainy video that needs it in order to not look like crap.

[waldstein]

JohnAStebbins: I like the nine-step process you recommend and will most definitely give it a try. Thanks.

[Deleted User 11865]

The only metric that exists to relate RF to both quality and file size is that, for a given source, for every 6 points you lower the RF, you can expect the file size to double, and the difference between the input and output quality to halve. So if you run an encode with an RF of 20, and the result is a 1GB video with SSIM of 0.98, if you were to run the same video again at RF 14, it'd come out, in theory, at 2GB and have an SSIM of 0.9. And at RF 8, 4GB and an SSIM of 0.95.

Even that is not always true.
For grainy Blu-ray sources, you usually need much less than 6 RF points to double/halve the file size (at least in my experience).

[mithrandir]

I've seen (uncommon) situations where reducing RF by 1 increased bitrate by 35%, which means a doubling/halving of bitrate per 2.3 RF adjustment. And it's not linear either. The steepest part of the curve (i.e. where the bitrate jump per RF is most pronounced) appears to be in the RF 20-22 range (for DVD material). Generally this is where fine grain starts getting recognized and "picked up" by the encoder and we all know grain is hardly compressible.