MKV crop tags applied but DAR not re-adjusted, resulting in wrong display dimensions #15800
Description
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.100Other 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)
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.