Huge file size increase encoding with bars cropping x264

[romulax]

I recently noticed a huge file size reduction when encoding without Handbrake's auto cropping (black bars removal).
This seemed strange, because Handbrake's documentation explains that cropping those black bars can reduce file size, since they don't have to be encoded when cropped.
I made some tests:

I encoded 10 min (10:00) of Dune (the 1984 movie in restored version) in H.264 using x264 with RF 22, encoder set to slow and main profile.
Source file is 1440*1080, with a video bitrate of 4663kb/s. There are black bars, top and bottom, each 132 pixels high (So 0 left, 0 right, 132 top, 132 bottom).
I encoded the source file 2 times, with the same parameters except first run is not cropped, while second run is cropped.
First run : without cropping, output file is 122MB, with average video bitrate of 1379kb/s
Second run : with cropping, output file is 150MB, with average video bitrate of 1771kb/s

The cropped one is 28MB heavier than the not cropped one, making a 22.95% increase in file size for using something supposed to do the opposite.
Does anyone know is this behavior is normal, and if/if not why?


HandBrake version is 1.3.3, running of Windows 10 Home 64, 2004 version.

[rollin_eng]

Could you please post your HB logs from both encodes, instructions can be found here:

https://handbrake.fr/docs/en/latest/hel ... y-log.html

[romulax]

Here is log for run 1 (without cropping) : https://pastebin.com/qSUTQswa
Here is log for run 2 (with cropping) : https://pastebin.com/bRQKzCC7

[Woodstock]

With cropping:

Code: Select all

[18:16:10]    + Output geometry
[18:16:10]      + storage dimensions: 1440 x 816
[18:16:10]      + pixel aspect ratio: 4 : 3
[18:16:10]      + display dimensions: 1920 x 816

Without cropping:

Code: Select all

[18:37:15]      + storage dimensions: 1440 x 816
[18:37:15]      + pixel aspect ratio: 136 : 135
[18:37:15]      + display dimensions: 1450 x 816

The cropped video gave a larger display dimension with a different PAR, which would explain at least part of the size difference.

[romulax]

Thanks for your answer!
Ok so that would mean that it is partly normal because it changes the pixel aspect ratio, so it is not a "bug", but something that should be expected. (tell me if I understood it wrong)
Following this logic, I can expect all cropped videos to be always heavier than non-cropped ones?
If yes why is this feature described as allowing reducing file size?
And do you think that there might be others reasons? (even if you don't know them)

[Woodstock]

I have seen some discussion around about cropping letterboxing. You're converting "less" picture, so it should be smaller. But, the letterbox itself doesn't change from frame to frames, so it compresses very well. Which ends up being smaller?

Hopefully, one of the REAL experts will chime in...

[romulax]

I see
It would be nice to hear what an expert think about this, I'm actually curious.
And I don't know if the file size increase is caused by the encoder or by Handbrake, so it could be great to find out

[mduell]

The large flat black areas change the encoders perspective of how well its doing (since they're easy to represent), so the bitrate ends up lower with them present.

[rollin_eng]

Your 'no crop' has resized your video to 1440 x 816, this video still has black bars thus its smaller.

Set your 'no crop' to 1440 x 1080 and it will probably be bigger.

[Deleted User 11865]

Both encodes are 1440x816 storage, but the no-crop has letterboxing, thus only 1440x616 of those pixels contain video data (the remaining 200 pixels contain black bars that are easily compressed). The cropped version uses all 1440x816 pixels (none of it letterboxing) and therefore has about 25% more actual (i.e. non-black) pixels, hence the 23% or so larger output size.

[romulax]

Wow that's what I call an answer!
I have to admit that I didn't expect this kind of precision.
Thanks you all for helping me understand this mystery, you're awesome!