Color Cartoon Aspect Compression - but not in B&W!

Server Version#: 1.21.2.3943
Player Version#: Various, all latest/greatest on ATV4, iOS, Web 4.51.1

This is a very weird issue - a minor one, but I can’t get it to make sense. I have a cartoon library (under TV Shows) which includes the Popeye series from Warner’s recent (2018-19-20) Popeye release on DVD. I have the DVD version, so all the files on disc are 720 x 480 p (SD). I’ve ripped the discs using MakeMKV and everything is playing well, at the proper aspect ratio, from my PMS on my WD PR2100, across all players: Apple TV, Vizio SmarTV, Roku, iOS, Windows, you name it.

Here’s the weirdness: starting with the 1945 cartoons, in the “The 1940s Volume 2” DVD, the B&W cartoons all play at correct aspect but the Cinecolor and Technicolor cartoons play at a “square” aspect ratio - it is as if the left and right sides are cut off and the rest of the image is squashed. The file info in PMS shows 720 x 480, but when playing the player reports back 720 x 540.

My player(s) have Direct Play set ON and Automatically Adjust Quality set ON. When I turn both of these OFF, these color cartoons play in the proper aspect ratio. But of course, that slows down the playing of everything else on the server.

One last observation: the affected ripped MKV files on my PMS play properly using an MKV player (such as VLC) and they play properly from the DVD.

It’s a minor, but annoying issue and I’m curious if anyone has observed anything like it before. It only affects the color cartoons on this one DVD, and the B&W cartoons on the same DVD are not affected in this way.

I’m glad to re-rip them if I have to at different settings (?).

Thanks in advance for any ideas from the Community!

I’ll bet you anything that those episodes are actually encoded differently on disc. This is probably not a ripping problem.

DVDs have an aspect ratio encoded in the video stream itself, as well as in the DVD structure.

When ripped from DVD, you get a container MKV with the DVD aspect ratio indicated, as well as the video stream with an embedded ratio.

If they play properly in VLC, or when “Direct Play” is OFF, that means your player is obeying the container-level aspect ratio.

If they play incorrectly when “Direct Play” is ON, that means your player is using the (incorrect) information in the stream itself.

This can be edited, with some effort, by passing the stream through ffmpeg with the right parameters.

Share output from mediainfo if you like. Or send me a sample, I’ll try to figure out a command line to fix up the files.

See this:

Replace hevc_metadata with h264_metadata for DVD if you want to play with it. :slight_smile:

Wow - thanks for the fascinating reply. It’s a bit over my head, but only slightly. Here is the mediainfo data for the file:

MediaInfo.txt (4.6 KB)

Here’s a link to the file in question: Popeye cartoon

I’m looking at “Display Aspect Ratio” versus “Original Display Aspect Ratio”…

I have ffmpeg installed somewhere, maybe as part of my Handbrake or kmttg installation.

Check out the mediainfo output first, and we can take it from there.

Really appreciate the helping hand! Thanks!

Alan

I also found this:

https://forums.plex.tv/t/not-answered-all-files-with-the-original-display-aspect-ratio-tag-play-at-wrong-resolution/148989

Seems like this has been hanging out there for a while. I tried the Restream app solution in Windows; didn’t work. It seemed to strip out the sound. Maybe because I’m using an MKV as input and not a “true” MPEG-2 file?

Yep. This was my fix: Not Answered: All files with the 'Original display aspect ratio' tag play at wrong resolution - #72 by Afullmark

1 Like

Yes, the difference between Display Aspect Ratio and Original Display Aspect Ratio confirms that the stream-level and container-level aspect ratios disagree.

Start by trying this.

EDIT: OH WAIT THAT’S DUMB, THIS IS DVD NOT H264, IGNORE THE BELOW

ffmpeg -i input.mkv -acodec copy -vcodec copy -bsf:v h264_metadata=sample_aspect_ratio=1 output.mkv

Or share a file sample, or the line containing this information - the SAR and DAR:

    Stream #0:0(eng): Video: h264 (High), yuv420p(tv, bt709, progressive), 1920x1080 [SAR 1:1 DAR 16:9], 60 fps, 60 tbr, 1k tbn, 120 tbc (default)

From this command:

ffmpeg -i input.mkv

1 Like

That looks like the exact same problem indeed.

The file had inconsistent information in the stream vs. headers, and the player was using the “wrong” information.

So you edited the stream to contain the information you wanted. (Or rather, you removed the information you didn’t want.)

Now I’m wanting to know how to do this with ffmpeg for MPEG2 myself, instead of adding more tools to the process.

I’m guessing that ffmpeg can do this too.

ffmpeg -i input.mkv -acodec copy -vcodec copy -bsf:v mpeg2_metadata=display_aspect_ratio=4/3 output.mkv

I’m going to gin up a sample file.

I only know the way I mention in the post I made.

1 Like

Here’s the ffmpeg -i information you asked for:

 Stream #0:0(eng): Video: mpeg2video (Main), yuv420p(tv, smpte170m), 720x480 [SAR 32:27 DAR 16:9], max. 9800 kb/s, SAR 1:1 DAR 3:2, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc

I put the MKV file in a public Dropbox folder (see below). Any ideas appreciated!

I don’t think the Dropbox link came through.

Sorry - scroll up to an edited reply by me where it says “Here’s the link to the file in question”

But here it is again anyway

OH!

This file is backwards from some of the above descriptions, and I think it’s the quicker/easier thing to fix.

The stream has the correct aspect ratio (16:9) indicated.
The container has the incorrect aspect ratio (4:3).

This is easy to fix, either with ffmpeg:

ffmpeg -i input.mkv -acodec copy -vcodec copy -aspect 16/9 output.mkv

Or in MKVToolNix, using the Header Editor -

Video display unit3
Video display width16
Video display height9

3 Likes

Fantastic! I think this works. The resulting image doesn’t quite fill the screen the way the B&W ones do, but I think it’s “close enough for Government work”. I will try this approach out on a few other files and report back if there’s anything amiss.

(Do you know if there’s a “batch” mode for either ffmpeg or MKVToolNix - that way I could just stack up all the relevant files, zap 'em, and be on my way, instead of file-by-files editing…)

Thank you! You’ve been really helpful and I think I learned something in the process, too…

1 Like

There’s no batch mode in those tools … but are you on macOS? A quick bit of command-line scripting could do this.

I could find you some examples for Windows too.

I’m on macOS but also have Windows 10 running in a Parallels VM, so… either one would work.

Put the files you want to modify into a directory, and using macOS Terminal.app, cd into it.

for file in *.mkv
do
mv -n $file $file.orig
ffmpeg -i $file.orig -acodec copy -vcodec copy -aspect 16/9 $file
done

Hi - thanks for this but I’m having trouble with it in macOS, most likely due to my thin knowledge of Terminal and UNIX. The files to be fixed are in one directory; the ffpeg executables and libraries are in another. If I execute from the file directory, Terminal can’t find ffmpeg; If I execute from the ffmpeg directory, either the execution fails or the MKV files can’t be found. In old DOS terms, it has to do with the PATH environment variable :slight_smile:

I don’t want to waste your time with a Terminal tutorial, but if there’s an equivalent batch file in Windows, or if the command lines you provided can be explained more, I’ll give it another go. Otherwise, I’ll just do a line by line conversion using Command Prompt in Windows.

Thanks again!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.