PGS Subtitles Stretching When Video Is Cropped [Solved]

[Deleted User 44600]

Description of problem or question: I have a video that is 1920x1080 originally. I used handbrake and I kept all of the picture settings as they were (as automatically determined by the handbrake software with anamorphic set to automatic). Final output was 1920x800 and cropped 128 from the top and 152 from the bottom. However, the PGS subtitles that I passed through (not burned in) are now stretched horizontally. I don't know if this matters but I am using VLC. I thought about leaving the final output resolution the same as the source to get rid of the stretching but I like getting rid of all the black in the final file. I am not sure how much cropping changes the final file size though. Is there a way to crop it and keep the PGS subtitles un-stretched? Or should I just not crop?

HandBrake version: 1.0.7

Operating system: Windows 10 Home

HandBrake activity log: https://pastebin.com/mFeJxPLn

[Woodstock]

The passed-through PGS subtitles are images that are 1920x1080 in size. VLC is "crushing" them to map them into the now-800-pixel height. This is the "best option" in VLC's logic, since there is really no way to know where in the image the subtitle itself is. This is the usual result when the disk authors take advantage of the letterbox area to place the subtitles.

When I encounter this, I manually stop handbrake from cropping the video, leaving the letterbox in place so the subtitles are properly sized. The result is a bigger file.

[Deleted User 44600]

I tried it again with no cropping. As you said, and as I suspected, this fixed the stretching issue. However, the final file size with cropping was 2.87 GB and the final size without cropping was 2.85 GB. How is that even possible?

[Woodstock]

Good question - non-cropped files usually increase slightly in size, because the black bars have to be encoded somehow. They do encode well (assuming they really are a smooth color background), but it should still be larger.

[mduell]

The big black areas throw off the "constant" quality rate control a bit. Your file is a bit lower quality overall.

[Deleted User 44600]

Well that is what I am saying, it is not larger. It is a smaller file size with the black areas. That doesn't make mathematical sense. With the black areas the file should be larger but it is smaller.

[rollin_eng]

Before it was analyzing just the cropped part, now it has to analyze the whole frame.

So now you have the same ‘quality’ for both but the bit in the middle will be of lower quality in the no crop version.

[Deleted User 44600]

Okay. That makes sense now. Thank you all for the help.