Mpv: Toggling hardware decoding on crops video

[TempSpas]

I originally posted this issue on IINA's issue tracker, which can be found here. I was directed to open an issue here because IINA implements mpv.

mpv version and platform

mpv 0.28.2 (via IINA 0.0.15.1)
macOS 10.13.6

Also tested on mpv 0.29.0

Reproduction steps

1. Open a compatible file with hwdec=videotoolbox
2. Observe video dimensions are altered.

Example video info screenshots:

Expected behavior

Video should not be cropped when hardware decoding is enabled.

Actual behavior

Opening a file with hardware decoding enabled via hwdec=videotoolbox results in cropped video and loss of visual information.

Log file

Both of these logs were obtained on mpv 0.29.0:

Log with hwdec=videotoolbox: https://paste.ubuntu.com/p/kfYXQ4fNdW/

Log with hwdec=no: https://paste.ubuntu.com/p/RNHrVRnpZ7/

Sample files

This issue happens consistently reliably with any files I throw at IINA that works with VideoToolbox, but if testers really can't reproduce it, I can upload a file.

[Akemi]

i recently got hardware decoding on my hackintosh to work and tried to debug this issue. it's not an mpv issue, but rather a ffmpeg or videotoolbox one. though i couldn't replicate it in VLC, which is a bit unexpected. i could find something like this in the VLC logs:

main debug: original format sz 1920x1088, of (0,0), vsz 1920x1080, 4cc CVPN, sar 1:1, msk r0x0 g0x0 b0x0

seems like it also returned a frame with 8 more pixels, which would negate the cropping.

the problem is that both the h264 and hevc parser return a 8px bottom crop. i also couldn't reproduce this with all files.

someone more knowledge of ffmpeg probably needs to look at this.

[Akemi]

@jeeb mentioned mod16 resolutions and that seems to be it. i can only reproduce it with my 1080p samples, but not with 720p or 4k ones. OPs sample is also 360p which isn't mod16 either.

[Akemi]

okay i bisected ffmpeg and found the commit that broke it. for h264 the last working commit is https://github.com/FFmpeg/FFmpeg/commit/6505e8cfd02b9112e24bb40c145d6c760f15d622 and the first broken one is https://github.com/FFmpeg/FFmpeg/commit/07596e45c5a0195b6e4e57597497ec7066817739.

with that being said https://github.com/FFmpeg/FFmpeg/commit/000fb61a71c6288c377167fea1541700aef3612d probably broke the hevc hw-decoding but i can't confirm it since videotoolbox only got hevc support a lot later.

https://github.com/FFmpeg/FFmpeg/commit/a9a6d51ca447be6364298a350336a25125f0af07 might have broken something for theora, but also untested.

https://github.com/FFmpeg/FFmpeg/commit/000fb61a71c6288c377167fea1541700aef3612d is the first commit that started changing the cropping mechanism.

a h264 test file https://0x0.st/sICQ.mkv and a hevc one https://0x0.st/sIC2.mkv.

[Akemi]

https://github.com/Akemi/FFmpeg/commit/c1c339c52912a09a892e53f04e1ef859dfc72698 this will fix the issue. it's basically cropping twice because videotoolbox returns an already cropped stream.

[Akemi]

fixed with https://github.com/FFmpeg/FFmpeg/commit/233cd89056405c76f01cc6f5315aa566454132fa.