--vf=vavpp - crashes when VAAPI decoding is not used

[aufkrawall]

Important Information

mpv-git-0.31.0_60_ga3ddddff3a-1
Arch recent custom
self-compiled mpv build
If known which version of mpv introduced the problem: nope
mesa-git 59d30fd4bc60f3562ca4c8247340389e97e494ae
RX 570 Polaris

Reproduction steps

Play a video codec that is not supported by the hardware (e.g. VP9 on Polaris) via mpv --no-config --vf=vavpp=deint=auto:interlaced-only=yes.
Edit: Well, that way without --hwdec=vaapi specified, it crashes with anything.

Expected behavior

It shouldn't crash. Perhaps it would do the trick by ignoring vavpp when VAAPI hardware decoding isn't used?

Background:
--hwdec=vaapi --vf=vavpp=deint=auto:interlaced-only=yesseems to work nicely as auto deinterlacer and doesn't seem to cause issues when VAAPI decoding works.

With this MR VAAPI deinterlacing btw. doesn't crash for me anymore on Polaris:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3341
It can't be evoked during playback though.

Actual behavior

mpv tries auto converting and crashes:

[autoconvert] HW-uploading to vaapi
[hwupload] upload yuv420p -> yuv420p (rgb0)
Speicherzugriffsfehler (Speicherabzug geschrieben)

Can rebuild with debug symbols and provide crash dump if required.

Log file

output.txt

Sample files

Can likely be anything that isn't decoded via VAAPI.

[CounterPillow]

I don't have debug symbols for anything lower level than mpv but it crashes in a /usr/lib/dri/radeonsi_drv_video.so call into libc.

Thread 1 "mpv" received signal SIGSEGV, Segmentation fault.
0x00007ffff69c9918 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
(gdb) bt full
#0  0x00007ffff69c9918 in __memmove_avx_unaligned_erms () from /usr/lib/libc.so.6
No symbol table info available.
#1  0x00007fff8264aad3 in ?? () from /usr/lib/dri/radeonsi_drv_video.so
No symbol table info available.
#2  0x00007fff8264abe7 in ?? () from /usr/lib/dri/radeonsi_drv_video.so
No symbol table info available.
#3  0x00007fff82997983 in ?? () from /usr/lib/dri/radeonsi_drv_video.so
No symbol table info available.
#4  0x00007fff825e1d2e in ?? () from /usr/lib/dri/radeonsi_drv_video.so
No symbol table info available.
#5  0x00007ffff75b4ffd in vaPutImage () from /usr/lib/libva.so.2
No symbol table info available.
#6  0x00005555564e2662 in vaapi_unmap_frame ()
No symbol table info available.
#7  0x00005555564e0d6f in ff_hwframe_unmap ()
No symbol table info available.
#8  0x00005555564d64fe in av_buffer_unref ()
No symbol table info available.
#9  0x00005555564de5d4 in av_frame_unref ()
No symbol table info available.
#10 0x00005555564de726 in av_frame_free ()
No symbol table info available.
#11 0x00005555564e27ec in vaapi_transfer_data_to ()
No symbol table info available.
#12 0x00005555564e13e7 in av_hwframe_transfer_data ()
No symbol table info available.
#13 0x00005555557b641a in mp_image_hw_upload (src=0x5555577d6920, hw_img=0x5555577d9ba0)
    at ../video/mp_image_pool.c:346
        ok = false
        dstav = 0x555557a9e600
        srcav = 0x555557a9e980
        ok = <optimized out>
        dstav = <optimized out>
        srcav = <optimized out>
#14 mp_image_hw_upload (hw_img=0x5555577d9ba0, src=0x5555577d6920)
    at ../video/mp_image_pool.c:323
        ok = <optimized out>
        dstav = <optimized out>
        srcav = <optimized out>
#15 0x00005555557b660f in mp_av_pool_image_hw_upload (hw_frames_ctx=<optimized out>, 
    src=src@entry=0x5555577d6920) at ../video/mp_image_pool.c:421
        av_frame = 0x0
        dst = 0x5555577d9ba0
#16 0x0000555555746f54 in process (f=0x5555577d9d90) at ../filters/f_hwtransfer.c:125
        p = 0x5555577d9e20
        frame = {
          type = MP_FRAME_VIDEO, 
          data = 0x5555577d6920
        }
        src = 0x5555577d6920
        dst = <optimized out>
#17 0x000055555574e072 in mp_filter_run (filter=<optimized out>) at ../filters/filter.c:194
        next = <optimized out>
        r = 0x5555573ac390
        externals = <optimized out>
        __PRETTY_FUNCTION__ = "mp_filter_run"

not sure if this is due to incorrect API usage (that AMD doesn't check) or simply an AMD bug.

[ghost]

The log message before the crash makes no sense in the first place, I strongly suspect mpv logic error.

[ghost]

It turns out ffmpeg or vaapi returned nonsense metadata, which lead to the crash. mpv made a strange (but correct) choice with the nonsense metadata, which made things worse. I've worked it around with a vaapi whitelist.

Someone who is into this kinky shit should probably take a look at ffmpeg/vaapi to fix the underlying cause, I sure as hell won't. I'*ll curse these projects instead.

Untested with vavpp, I don't want to lock up my system.

[aufkrawall]

Thanks so far. Continuing as the bearer of bad news :( : mpv still occasionally crashes with that change when opening videos that are not decoded by VAAPI. If it doesn't crash, the rendered video frames are in gray tones.

[autoconvert] HW-uploading to vaapi
[autoconvert] Converting yuv420p -> nv12
[hwupload] upload nv12 -> vaapi (nv12, upload as nv12)
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 3840x2160 vaapi[nv12]
Speicherzugriffsfehler (Speicherabzug geschrieben)/0

[ghost]

Well this is the case that should work, and I can't reproduce it (I think).

[ghost]

Pushed some more commits related to this, but didn't find/fix anything that could have caused this. The previous situation already looked like a ffmpeg and/or libva bugfest, so whatever, I'll just blame them and forget about this.

[aufkrawall]

Yeah, still unchanged. But be it so. :)