Closed Ichisich closed 2 years ago
I found the culprit. It's DisplayHeight/Width
https://www.matroska.org/technical/elements.html#PixelWidth
MkvToolNix standard integer value was Video Display Width=3
and Video Display Height=2
which resulted in a botched 1,5 aspect ratio and thus 1620x1080 instead of the correct 1600x1080 PixellWidth/Height
.
FFmpeg on the other hand doesn't even bother with those two entries (you could also just set them to 0) forcing the actual pixel count as parameter.
I changed the values both to 0 and voilà:
Out of curiosity, because I'm not really familiar with MkvToolNix. Is there are a reason you're using MkvToolNix as a muxer for native clients instead of ffmpeg? MkvToolNix comes with a whooping extra 156mb.
MKVToolnix is used to support VFR and Subtitle Support.
FFmpeg has problems regarding PGS Subtitles.
I think the problem in this particular case is this commit: Use Aspect Ratio of Source if external encoder is used
This "feature" / "bug" was added, as piping to the external encoder would lead to it defaulting to a 1:1 pixel aspect ratio, which resulted in DVD encodes not having the correct aspect ratio.
I think the easiest solution would be, to only set the aspect ratio, if it detects that it's not the default 1:1 pixel aspect ratio.
NEAV1E 2.0.5 Windows 10
When using native encoders (aom/rav1e/svt-av1) some aspect ratios get distorted on the container level. FFmpeg's encoders are not affected, so I guess the problem lies in the external muxing process. I guess you're using mkvtoolnix?
Some examples------
Original cropped video (1600x1080)pixel/scaled:
Encoded with aomenc (1600x1080)pixel (1620x1080)scaled:
Encoded with FFmpeg's aomenc (1600x1080)pixel/scaled:
Using .mp4 and .webm bears the same results as .mkv. Given, this problem only affects media players which obtain the aspect ratio from the container and not the bitstream directly, like VLC or mpv with default setting.