Changing mkv aspect ratio doesn't affect the subtitles

[Jeanrobb]

Hi everyone! I'm having a bit of an issue with my files.

I'm trying to take a bunch of 16/9 mkv files (1912x1072)



and crop the sides in order to obtain a 4/3 file (1428x1072)



I had no problem with the cropping, I opened mkvmerge gui, I used these settings



Output file is ok, but the subtitles don't seem to care about the new aspect ratio



They keep appearing at a 16/9 ratio, and when I stretch the pitcure to 16/9 in vlc, they are perfectly centered.

I have to add that these are external subs, in a .srt format. The mkv has a built-in subtitle track, but it's also out of place on the screen.

I try to change their resolution/aspect ratio using aegisub, it didn't work...

I tried using the aspect ratio tool, it just squeezes the picture without cropping it...
I tried cropping and changing the resolution, it also squeezes the picture (unless I manually change the aspect ratio in vlc to 4/3)

By lurking around, I think this has to do with the display aspect ratio, but I don't know where to change that...

Does anyone have an idea? My other option is to convert the files using handbrake, but if I want to keep the same quality, the export time is about 9 hours... for each episode... Whereas Mkvmerge is pretty instant.

[ndjamena]

Which version of VLC re you using? I just cropped the side bars from ST:TOS and played it back and the subtitles were squeezed to fit the new resolution.

But that's PGS, maybe srt is different, I'll check.

2.1.5 Rincewind

[ndjamena]

Right, srts don't play back properly. That's what you'd call a bug in VLC, you should report it on their bug tracker. (Maybe try downloading a nightly first though.)

[jagabo]

Yes, issues like this are player specific.

[Jeanrobb]

I'm up to date with vlc. I have to add that when I use vlc's built-in screencap fonction, the resulting picture isn't cropped, it's in its original 16/9 format. Maybe that's why the subtitles don't behave as they should? They think they're in a uncropped version of the file?

[jagabo]

VLC is probably calculating the subtitle position (center of the frame) based on the full frame size. Then placing the subs in the cropped frame based on that calculated position.

[Jeanrobb]

VLC is probably calculating the subtitle position (center of the frame) based on the full frame size. Then placing the subs in the cropped frame based on that calculated position.

I think that's exactly it... How can I make vlc "understand" that the full frame is the cropped verion? By changing the display aspect ratio?

[ndjamena]

With the PGS it would have to render the subtitles in 16:9, resize them to 4:3 and then overlay them on top of the video, which seems to work fine.

For SRT, they would either have to do the same, or render them straight to 4:3 and then overlay them. What it seems to be doing is rendering them in 16:9 then overlaying them on the video without resizing, which is obviously wrong. (Most of these special MKV features aren't used much, so there's a lot of bugs in players that never get fixed since no-one reports them.)

[ndjamena]

I told you, go to the VLC bug tracker and report it. It's a bug, there's no other solution.

[Jeanrobb]

So I guess the easiest way for me would be to convert my .srt into .sup...
I found out that I can do this with tsmuxer but I don't really understand what I should do with it, anyone care to help?

And I reported it, thanks for the tip!

[Jeanrobb]

The subs are also out of alignement if I use VLC's built-in function to crop the picture when I play the original file, so yeah, definitely a bug on their end. How fast do they fix these kind of things?

[ndjamena]

I don't know, I only made my first report a few days ago, at the moment VLC is interpreting subchapter time-codes as if they are relative to the parent chapter when it's supposed to interpret them as absolute. I can't really start adding subchapters seriously until it's fixed. MPC-HC interprets them properly but isn't really suited to the tasks need to throw at it.

I guess we'll both have to wait and see.

(neither fix should be all that difficult, but on the same token, they're not high on the list of priorities either.)