other-transcode generating laterally compressed video for SOME sources
wassilywabbit opened this issue · 11 comments
I’m using other-transcode for ripping Blu-rays to .m4v (so it can get added to the TV app for my iPad), and for some reason, some files are coming out laterally compressed [QuickTime Player shows the resolution as 1920 × 1080 (1080 × 1080); see attached screenshot. The source material is MKV (generated my MakeMKV 1.17.5) ripped from the rereleased blu-ray of The Way.
The arguments are pretty basic & more or less the same for everything (variations for audio and/or subtitles, etc). This is the command for an extra (the movie itself had cropping of 22:22:0:0):
other-transcode --mp4 --vt --crop 0:0:0:0 --main-audio 1
The scripts used to work just fine with the same switches, so I'm confused as to what may be causing this. FWIW, I just tried other-encode with a different disk (Criterion's Blu-ray of Walkabout) & it encoded fine, so I guess it's just something weird with the other MKV file.
ffmpeg often gets updated when I upgrade my homebrew catalog (I had to update PowerShell recently), but I'm not using the nightlies. I've seen something similar before with an older DVD, so I wonder if it's something weird in the source, though the MKV plays fine in VLC.
I don't have a MediaInfo dump, but I do have the log file (attached). How would I do a MediaInfo dump? Is that just what the --scan option returns?
[The Way - Conversation with Rick Steves.mp4.log](https://github.com/lisamelton/other_video_transcoding/files/14453039/The.Way.-.Conversation.with.Rick.Steves.mp4.log)
[The Way - Conversation with Rick Steves scan.txt](https://github.com/lisamelton/other_video_transcoding/files/14453058/The.Way.-.Conversation.with.Rick.Steves.scan.txt)While we're waiting for Lisa and Sean:
I've assumed you are using a Mac, apologies if you aren't. Still, there may be some of my response that you can use. Have you heard of Lisa’s more-video-encoding? It’s on Github. I even posted an AppleScript gist for it. You’ll need the Handbrake CLI. You'll also need Lisa's "two-pass-transcode.rb" script with "more-video-transcoding". Be sure to get the one that was recently updated to use "multi-pass" instead of "two-pass". You might be interested in my ffmpeg method for getting better crop values (below).
Two-pass transcode AppleScript
And here’s a command construct to help you get accurate crop values:
ffmpeg -ss 00:01:00 -t 00:00:12 -i input.mkv -vf cropdetect -f null - 2>&1 | awk '/crop/ { print $NF }' | tail -1
Now that won’t give you much error checking, so be sure that your input file is more than 1 minute and 12 seconds in duration and actually has some “croppable” areas.
LL
And here's (still assuming Mac) a command line that you may want to look at which incorporates a likely solution to your problem (I'm still looking to make sure I know exactly what the problem is). The ffmpeg executable is needed for other-video-transcoding to work, so you can use "which ffmpeg" to find it, if needed. Use your own crop values and bit rate. You may need to encode the audio, this just copies it. Current or recent ffmpeg is needed (6.1 or higher probably). The input.mkv file can go into your home folder, then you should be able to just paste this command:
ffmpeg -i ~/input.mkv -map 0:0 -vf crop=1920:800:0:140 -c:v hevc_videotoolbox -b:v 3800k -color_primaries:v bt709 -color_trc:v bt709 -colorspace:v bt709 -metadata:s:v title= -disposition:v default -map 0:1 -c:a:0 copy -metadata:s:a:0 title= -disposition:a:0 default -sn -metadata:g title= -default_mode passthrough ~/output.mkv
And if you really need libx264:
ffmpeg -i ~/input.mkv -map 0:0 -c:v:0 libx264 -b:v 3800k -fps_mode cfr -vf crop=1920:800:0:140 -map 0:1 -c:a copy -metadata:s:a:0 title= -disposition:a:0 default -sn -metadata:g title= -default_mode passthrough -movflags +faststart ~/ouput.mp4
BTW, I think your problem will be solved by providing more accurate crop values. Notwithstanding the command line I provided (in case it doesn't work for your source file), have you tried --crop 1920:1080:0:0 ?
BTW, I think your problem will be solved by providing more accurate crop values. Notwithstanding the command line I provided (in case it doesn't work for your source file), have you tried
--crop 1920:1080:0:0?
I tried that, but got the same compressed output (at 1080x1080)
Any chance it's a problem with Quicktime Player rather than the file itself? If you can play it correctly in mpv, VLC, and IINA without the unwanted aspect ratio, that may be the issue.
However...
This may be cheating a little, but it could provide a quick fix if the info for your file is accurate. You can probably fix it using mp4box from the gpac package. If you have to build gpac, just be sure your build output includes mp4box. You may be able to get a standalone version of mp4box for your system somewhere else.
This command is for a two stream file - 1 video and 1 audio. (I got those out of order in the first version of this.) If you can feed it one of the errant output files, it should yield a working muxed video to which you can add other streams later.
mp4box -add input.mp4#1:par=1:1 -add input.mp4#2 output.mp4
Yes, you're providing the input file path twice. If it works, it could be pretty quick. mp4box cleans up for itself pretty well if the command is completed. But if your command fails, the temp files could start adding up. You may want to watch for that. Good luck!
Any chance it's a problem with Quicktime Player rather than the file itself? If you can play it correctly in mpv, VLC, and IINA without the unwanted aspect ratio, that may be the issue.
I opened the file with VLC & it's showing the same compression, so it's something weird in the output.
I haven't had time to try other suggestions yet (well, I tried one of the ffmpeg suggestions, but it generated an error & I haven't had time to follow up)
mp4box has fixed similar issues for me before. Now that Lisa has labeled this as a bug, it's just a workaround to try because the log file appears to recognize the 1920X1080 ar. Your command for a dump from mediainfo should be as simple as
mediainfo input.mp4
(or mediainfo input.m4v)
Would this issue be related to the following issue I'm experiencing?
I was transcoding 4 movies in a series today. The 2nd, 3rd, and 4th all transcoded fine and open as expected in VLC or other players. The first transcoded without issue, and plays fine in some players, but in VLC with the default aspect ratio the video appears very tall and very thin. Looking at the metadata the video dimensions are correct, and if I manually change the aspect ratio to 2.39:1 it plays as it should when using the default aspect ratio. I use the exact same set of arguments on other-transcode for each of the four movies: --nvenc --hevc --crop auto --add-audio eng --add-audio fre --eac3 --copy-track-names.
I'm stumped trying to figure out why this one mkv transcode results in this odd vertically squished behavior with the default aspect ratio.
UPDATE: I figured out my issue. Turns out the --crop auto was the problem. For the first title in the series, the auto crop resulted in -filter:v "crop=716:360:0:58" being applied in the ffmpeg command arguments, and for some reason that 716 width was causing VLC problems (I suspect this is due to a bug in VLC). Each of the other transcode commands were using a crop width of 720, so I manually changed the ffmpeg command arguments to use -filter:v "crop=720:360:0:58" instead, re-transcoded the file, and that resolved the issue. VLC plays the new file just fine with the default aspect ratio.
Hooray for log files, because comparing those allowed me to figure out what was going wrong here.
If VLC doesn't yield good results, I use mpv.
I finally had a chance to install MediaInfo & pull reports on some of the problem videos (& a successful rip for comparison). The full reports are attached, but this seems like the critical info:
The Way (movie) source
Size: 1920x1080
Display aspect ratio: 1.000
Original display aspect ratio: 16:9
The Way (movie) output
Size: 1920x1036 (22:22:0:0 cropping applied)
Display aspect ratio: 1.042
Original display aspect ratio: 1.85:1
The Way (extra) source
Size: 1920x1080
Display aspect ratio: 1.000
Original display aspect ratio: 16:9
The Way (extra) output
Size: 1920x1080 (no cropping needed)
Display aspect ratio: 0.999
Original display aspect ratio: 16:9
I tried changing the aspect ratio in VLC to 16:9 and both of these looked about right (no sign of lateral compression), but unfortunately, my end goal is to load these into the TV app on my iPad, so this isn't really an option.
This is a Criterion Blu-ray that rips just fine:
Walkabout source
Size: 1920x1080
Display aspect ratio: 16:9
Original display aspect ratio: this line is missing
Walkabout output
Size: 1920x1080 (no cropping needed)
Display aspect ratio: 16:9
Original display aspect ratio: this line is missing
The takeaway for me is that The Way has the display aspect ratio encoded weirdly, but the question is this: what can I do to compensate for that?
MediaInfo.The Way.txt
MediaInfo.The Way-mp4.txt
MediaInfo.The Way-chat.txt
MediaInfo.The Way-chat-mp4.txt
MediaInfo.Walkabout.txt
MediaInfo.Walkabout-mp4.txt