MKV crop tags applied but DAR not re-adjusted, resulting in wrong display dimensions

[Marth64x]

mpv Information

mpv v0.39.0-723-g38ad1ed03b Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Feb  2 2025 22:03:51
libplacebo version: v7.350.0 (v7.349.0-30-g056b8520)
FFmpeg version: N-118406-g957eb2323a
FFmpeg library versions:
   libavcodec      61.32.100
   libavdevice     61.4.100
   libavfilter     10.9.100
   libavformat     61.9.106
   libavutil       59.56.100
   libswresample   5.4.100
   libswscale      8.13.100

Other Information

- Linux version: Xubuntu 24.04.1 LTS
- Kernel Version: 6.8.0-52-generic #53-Ubuntu SMP PREEMPT_DYNAMIC Sat Jan 11 00:06:25 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
- GPU Model: NVIDIA 4060 TI
- Mesa/GPU Driver Version: NVIDIA driver 550
- Window Manager and Version: XFCE
- Source of mpv: https://github.com/mpv-player/mpv
- Latest known working version: N/A
- Issue started after the following happened: N/A

Reproduction Steps

First, note this text of Matroska spec notes (https://www.matroska.org/technical/notes.html):

Cropping has to be performed before resizing and the display dimensions given by DisplayWidth, DisplayHeight and DisplayUnit apply to the already cropped image.

Also note the following from the element specifications (https://www.matroska.org/technical/elements.html):

DisplayWidth: Applies to the video frame after cropping (PixelCrop* Elements).
DisplayHeight: Height of the video frames to display. Applies to the video frame after cropping (PixelCrop* Elements).

Given the following:

• An MKV with a 1280x720 stream; for example: ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 TestSrc.mkv
• Crop tags being set on the MKV (via mkvtoolnix for example). Let's say we want crop-left=160, crop-right=160 to get a 960x720 video which we want in 4:3 DAR
• DAR tags being set on the MKV, in this example we will set display-width=4 display-height=3 (and display-unit=3 for aspect ratio)

Now, open the file in mpv.

mpv TestSrcCROP.mkv 
[mkv] Discarding potentially broken or useless index.
● Video  --vid=1  (h264 1280x720 30 fps)
VO: [gpu] 1280x720 => 960x960 yuv444p
V: 00:00:09 / 00:00:10 (99%) Dropped: 4
Exiting... (End of file)

Observe that the view is squished, and not rendered to 4:3.

Expected Behavior

Let us now observe the behavior after transcoding the video with FFmpeg, which honors the crop tags and sets the correct SAR.

$ ffmpeg -i TestSrcCROP.mkv TestSrcCROP_TranscodedByFfmpeg.mkv

ffmpeg version N-118421-g774f36756a Copyright (c) 2000-2025 the FFmpeg developers
  built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04)
  configuration: --enable-debug=3 --enable-ffplay --enable-gpl --enable-nonfree --enable-ffnvcodec --enable-vulkan --enable-libx264 --enable-libfdk_aac --enable-openssl --enable-version3 --enable-demuxer=dvdvideo --enable-libdvdread --enable-libdvdnav --samples=fate-suite/
  libavutil      59. 56.100 / 59. 56.100
  libavcodec     61. 32.100 / 61. 32.100
  libavformat    61.  9.106 / 61.  9.106
  libavdevice    61.  4.100 / 61.  4.100
  libavfilter    10.  9.100 / 10.  9.100
  libswscale      8. 13.100 /  8. 13.100
  libswresample   5.  4.100 /  5.  4.100
  libpostproc    58.  4.100 / 58.  4.100
Input #0, matroska,webm, from 'TestSrcCROP.mkv':
  Metadata:
    ENCODER         : Lavf61.9.106
  Duration: 00:00:10.00, start: 0.000000, bitrate: 96 kb/s
  Stream #0:0: Video: h264 (High 4:4:4 Predictive), yuv444p(tv, progressive), 1280x720 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1k tbn
    Metadata:
      ENCODER         : Lavc61.32.100 libx264
      DURATION        : 00:00:10.000000000
    Side data:
      Frame cropping: 160/160/0/0
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
Press [q] to stop, [?] for help
[libx264 @ 0x645aee834bc0] using SAR=1/1
[libx264 @ 0x645aee834bc0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x645aee834bc0] profile High 4:4:4 Predictive, level 3.1, 4:4:4, 8-bit
[libx264 @ 0x645aee834bc0] 264 - core 164 r3108 31e19f9 - H.264/MPEG-4 AVC codec - Copyleft 2003-2023 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=4 threads=22 lookahead_threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, matroska, to 'TestSrcCROP_TranscodedByFfmpeg.mkv':
  Metadata:
    encoder         : Lavf61.9.106
  Stream #0:0: Video: h264 (H264 / 0x34363248), yuv444p(tv, progressive), 960x720 [SAR 1:1 DAR 4:3], q=2-31, 30 fps, 1k tbn
    Metadata:
      encoder         : Lavc61.32.100 libx264
      DURATION        : 00:00:10.000000000
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
[out#0/matroska @ 0x645aee856b40] video:99KiB audio:0KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 2.685832%
frame=  300 fps=0.0 q=-1.0 Lsize=     102KiB time=00:00:09.93 bitrate=  84.0kbits/s speed=20.8x    
[libx264 @ 0x645aee834bc0] frame I:2     Avg QP:11.79  size:  6800
[libx264 @ 0x645aee834bc0] frame P:77    Avg QP:12.62  size:   739
[libx264 @ 0x645aee834bc0] frame B:221   Avg QP:14.82  size:   137
[libx264 @ 0x645aee834bc0] consecutive B-frames:  1.3%  0.0%  4.0% 94.7%
[libx264 @ 0x645aee834bc0] mb I  I16..4: 57.1% 38.2%  4.7%
[libx264 @ 0x645aee834bc0] mb P  I16..4:  2.5%  1.2%  0.2%  P16..4:  4.9%  0.5%  0.0%  0.0%  0.0%    skip:90.7%
[libx264 @ 0x645aee834bc0] mb B  I16..4:  0.1%  0.1%  0.0%  B16..8:  2.3%  0.0%  0.0%  direct: 0.0%  skip:97.5%  L0:44.1% L1:55.1% BI: 0.8%
[libx264 @ 0x645aee834bc0] 8x8 transform intra:34.8% inter:86.8%
[libx264 @ 0x645aee834bc0] coded y,u,v intra: 2.9% 2.9% 3.0% inter: 0.0% 0.1% 0.1%
[libx264 @ 0x645aee834bc0] i16 v,h,dc,p: 71% 24%  1%  5%
[libx264 @ 0x645aee834bc0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 48% 18% 33%  0%  0%  0%  0%  0%  0%
[libx264 @ 0x645aee834bc0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 50% 27%  2%  1%  1%  0%  1%  0%
[libx264 @ 0x645aee834bc0] Weighted P-Frames: Y:0.0% UV:0.0%
[libx264 @ 0x645aee834bc0] ref P L0: 67.5%  1.7% 19.7% 11.1%
[libx264 @ 0x645aee834bc0] ref B L0: 85.7% 13.4%  0.9%
[libx264 @ 0x645aee834bc0] ref B L1: 96.2%  3.8%
[libx264 @ 0x645aee834bc0] kb/s:80.70

The transcoded file now gets the correct SAR in mpv and presents in 4:3 as expected

:

mpv TestSrcCROP_TranscodedByFfmpeg.mkv 
● Video  --vid=1  (h264 960x720 30 fps)
VO: [gpu] 960x720 yuv444p
V: 00:00:06 / 00:00:10 (66%)
Exiting... (Quit)

Actual Behavior

See "Reproduction Steps"

Log File

Attached (without --gpu-debug as that seemed to cause unrelated issues)

output.txt

Sample Files

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 TestSrc.mkv

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[kasper93]

It's known issue and defined like that, because this is what most the files are using and what makes actually sense in the bigger picture.

You can read previous discussions here #13446 and https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2389

To not repeat everything, the key-points are:

• Files with DisplayWidth/DisplayHeight applied after cropping are compatible only with players that understand cropping. Which is unrealistic to expect that all players do. Therefore files like that are pretty useless.
• DisplayWidth/DisplayHeight is (or were) not automatically adjusted by MKVToolNix, so adding crop parameters is not enough to produce "spec-compliant" files. Therefore files produced by MKVToolNix, are not "spec-compliant", unless user manually fixed that.
• There was research made to find files on the internet and asses the impact of the point above. Overwhelming amount of them are in-fact not spec compliant.

Based on that and other extensive discussion, we decided to not endorse and follow the current Matroska specification, which makes only things more complex and awkward to handle in the context of various players.

There was an idea to amend Matroska spec to update the wording to reflect more closely what the reality is. But we didn't follow up on this and it's my fault probably, because I didn't have time initially and forgot later.

Also note that mpv is only reacting to already established state of affairs, I tried to apply spec-compliant behavior in f8db02b, which were reverted in 81102b0 and then was an attempt to reapply it in #13446

Note that we could have compact option to handle this in mpv, but it doesn't resolve bigger issue of supporting non-cropping aware players, so the option in mpv wouldn't really change this... and Matroska files with crop would still be inherently broken.

[Marth64x]

Thank you for the history @kasper93 .
I understand now. Will close ticket.

[kasper93]

I see that Matroska cropping has been added in FFmpeg not so long ago. It's probably good reminder that we should follow-up on this topic with Matroska spec. I will try to draft email about this.

I will keep it open for now, because this issue is not really fully resolved.