lisamelton / other_video_transcoding

Other tools to transcode videos.
MIT License
540 stars 24 forks source link

Subtitles in wrong location on resized UHD rip #179

Open cal3d opened 1 year ago

cal3d commented 1 year ago

Using the following command to transcode a 4K UHD down to a 1080p version works great - including transferring the HDR metadata - however when the title has subtitles, they appear in the wrong location and the wrong size on screen

other-transcode --x265 --10-bit --burn-subtitle 1 --crop auto --mp4 --main-audio 1 --1080p

Attached screenshot shows the issue. If I had to guess, I'd say that the subtitles were being resized to 1080p and added to the 4K stream before encoding!

Screenshot 2023-02-24 at 12 04 43 PM
lisamelton commented 1 year ago

@cal3d Yep! That's what it looks like to me as well. But that's weird because the overlay filter (which burns the subtitle) is the first filter in the pipeline. So I have no idea what FFmpeg is doing here. This one is going to take awhile to figure out. 🤔

Thanks for finding this bug! I'll try to reproduce it myself and if I can't, I'll contact you.

cal3d commented 1 year ago

thanks. I just ran a test here also - it doesn't happen with every file - for example "Doctor Strange in the Multiverse of Madness" works fine - most others don't. So it's likely something to do with either some missing metadata field - or something else different about how the subtitles are encoded.

lisamelton commented 1 year ago

@cal3d Oh great! It's inconsistent then. 🤦‍♀️

Thanks for the update!

cal3d commented 1 year ago

I ran some experiments here. This isn't related to the resizing of the file - I get the same results if I leave the images uncropped and at the original 4K size.

I've attached a couple of log files for a 1 minute segment that contains subtitles. File a.log is from an encode that looks correct, file b.log from an incorrect encode.

I'm not an expert - but it looks like the 2nd file subtitles are actually stored at 1920x1080, whereas the first file stores them at 3840x2160. So it appears that ffmpeg is not correctly scaling these up. a.log b.log

lisamelton commented 1 year ago

@cal3d The plot thickens! 😀 Thanks for the .log files. I'll take a look at them later this evening. 👍

cal3d commented 1 year ago

I dug into this a bit more. It was as I suspected - the subtitles are a different size than the main video and needed to be scaled by ffmpeg before being overlaid. It looks like the sub2ref command is the best way to address this. The filter complex command that worked for me on my test file is "-filter_complex '[0:2][0:0]scale2ref[sub][ref];[ref][sub]overlay,crop=3840:1604:0:278[v]'" - not sure if this is the best approach or not, but it worked for me.

lisamelton commented 1 year ago

@cal3d That's what @ttys0 (a contributor) suspected as well. That's really a kind of special case and I'm not sure how to build something like that into other-transcode. Because it certainly can't be a common case none of us over here could reproduce the problem with any of our rips.

cal3d commented 1 year ago

I've spotted it on 3 UHD titles so far out of the 10 in my 4K collection that have foreign dialog:

samhutchins commented 1 year ago

@donmelton Having not looked at what scale2ref does, would it be harmful to just include it always?

lisamelton commented 1 year ago

@samhutchins Sorry I missed the notification on your comment two days ago. 🤦‍♀️

That might work! It also might cause a performance issue. But since you're already burning the subtitle maybe that's no big deal?