Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subtitle position too low when "burning in" and using auto cropping #2038

Open
falagar-fr opened this issue Apr 13, 2019 · 12 comments

Comments

4 participants
@falagar-fr
Copy link

commented Apr 13, 2019

Description of the problem

On a video with subtitles, some on 1 line, others on 2 lines, and black bands under and on the video, only the first line of subtitles is burned. On the two-lines subtitles, the second line disappears.

Ideally, "travelling" through subtitles before compressing job would be perfect.

HandBrake version (e.g., 1.0.0)

1.2.2

Operating system and version (e.g., Ubuntu 18.04 LTS, macOS 10.14 Mojave, Windows 10 1809)

Windows 10

Error message text or screenshot

No error message.

HandBrake Activity Log (see https://handbrake.fr/docs/en/latest/help/activity-log.html)

Please replace this text with the Activity log, or upload the log file to Github by dropping the file on this post.
Leave the ~ marks above and below.
@sr55

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2019

Please provide the information requested in the post template, including the activity log (https://handbrake.fr/docs/en/latest/help/activity-log.html).

Thanks.

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2019

When burning in subtitles, HandBrake relocates any subtitles found in the cropped region. So if this isn't working there is a bug. An activity log and a sample to reproduce the problem with would help us fix it.

@falagar-fr

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

Thank you. I would have given you a sample, but the file is nearly 40 Gb large. Far too large for my poor connection.

I will try to reproduce the bug on a small part of the file, and give you the log.

@falagar-fr

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

First, the screenshot of the original file, with subtitles on 1 line, then on 2 lines.

original-1
original-2

And then, the result with handbrake' encoding. The second comment is lost.

handbrake-output-1
handbrake-output-2

@falagar-fr

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Apr 13, 2019

Is it only subtitles at the top of the frame that are being chopped off?

@falagar-fr

This comment has been minimized.

Copy link
Author

commented Apr 13, 2019

No, same problem with "low" subtitles. Some of them disappaered.

@Synapto

This comment has been minimized.

Copy link

commented Apr 25, 2019

No, same problem with "low" subtitles. Some of them disappaered.

[19:28:20] scan: 10 previews, 1920x1080, 23.976 fps, autocrop = 140/140/60/0, aspect 16:9, PAR 1:1
...
[19:28:20]  * subtitle track 1, Francais [PGS] (track 1, id 0x4, Picture) -> Render/Burn-in

You're using PGS bitmap subtitles which are formatted for 1920x1080 frame dimensions.

[19:28:20]    + Output geometry
[19:28:20]      + storage dimensions: 1674 x 720
[19:28:20]      + pixel aspect ratio: 1 : 1
[19:28:20]      + display dimensions: 1674 x 720

But what are you doing? You're cropping the frame size to 1674x720!

Thanks to your cropping, any subtitle info that's in the "oversized" 246 x 360 pixel area of the PGS bitmaps is ALSO cropped out.

I don't believe that HandBrake automatically rescales PGS to the output dimension. Happy to hear otherwise.

So, why don't you just leave the output dimensions at 1920x1080 and see what happens?

Otherwise, if you want to crop out the black bars and keep the original positioning, you'll need to either remux new PGS after manually resizing them to 720P, or remux ASS/SSA streams converted from the PGS and manually positioned.

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

@Synapto as I said here #2038 (comment), HandBrake relocates subtitles that are in the cropped region. If rendered subtitles are being dropped there is a bug.

But I have not been able to reproduce this with the few sources that I have that place subtitles in the crop region.

@jstebbins

This comment has been minimized.

Copy link
Contributor

commented Apr 25, 2019

One thought occurs to me. Normally the subtitle has a region defined around it that is just large enough for the enclosed text. We relocate the whole region box, i.e. we don't attempt to find the text within the box. It's possible that in this case they created a region box that fills the entire video frame. If this is the case, we would not be able to relocate the box because moving it anywhere would cut off some part of the it.

I would require a sample to verify if this is happening. But if this is the problem, the only solution for you would be to set cropping to 0. A sample would also be useful in testing an improvement to the current renderer that would scan the box for "visible" pixel boundaries and reduce it in cases such as this.

@Synapto

This comment has been minimized.

Copy link

commented Apr 27, 2019

What's happened to the OP is very, very similar to what happens when you convert a "text grid" coded (advanced) SubStationAlpha into a .SUP.

Having had to reverse this fault in many fansub recodes, I was able to knock up this sample for you, which contains both constrained and full-frame regions:
HB_Malformed_PGS_Test.zip

SOURCE:
Source
HB UNTOUCHED:
Uncropped
HB CROPPED (128 top/bottom):
Cropped

This granular "text grid" method is only used by people who don't possess proper Bluray authoring software (where you can position subpictures with pixel accuracy anywhere you like).

Still, why the OP's source was like this remain unknown. Unless it's a fansub...? Or poorly authored.

@Synapto

This comment has been minimized.

Copy link

commented Apr 27, 2019

Ooops, I forgot to add a "full-frame" top-only/bottom-only test.

Here's the .SUP on it's own, with those two extra tests coming after the previous 7 (above).
PGS_Test.zip

Mux it into whatever video you want.

@sr55 sr55 removed the Awaiting Feedback label May 4, 2019

@sr55 sr55 added this to the Unscheduled milestone Jun 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.