search

jc-kynesim / rpi-ffmpeg

FFmpeg work for RPI
Other
111 stars 27 forks source link

Hardware accelerated decode in mpv #61

Closed EmperorPenguin18 closed 1 year ago

EmperorPenguin18 commented 1 year ago

Hello, I've been trying to get hardware accelerated playback with H264 (v4l2m2m) and HEVC (drm_prime) to work on mpv. The closest I've gotten is tracked here. I was using the ffmpeg-rpi package created by the Arch Linux ARM folks which if I understand correctly uses some code from this repository. The conclusion at the end of that thread is that ffmpeg is outputting to an image format that mpv doesn't support. I was wondering why this is the case and if the situation could be remedied somehow? This issue may also be related to https://github.com/jc-kynesim/rpi-ffmpeg/issues/60

jc-kynesim commented 1 year ago

H264 should produce "normal" format images i.e. NV12 or I420, H265 produces SAND8 (for 8-bit) or SAND30 (for 10-bit). This is what the h/w does and can't be changed. Obviously you can convert them in s/w but that takes too long for 4k. The SAND8/30 formats can be consumed directly if you are outputting to DRM, and EGL knows about SAND8 and will shortly know about SAND30 (in HoT mesa as well as Pi backports).

EmperorPenguin18 commented 1 year ago

Do you know what situation will cause output to be in NV12 format? I'm only getting I420 and I think if I can get NV12 it would be informative.

vanfanel commented 1 year ago

This interests me a lot, too

EmperorPenguin18 commented 1 year ago

H264 should produce "normal" format images i.e. NV12 or I420, H265 produces SAND8 (for 8-bit) or SAND30 (for 10-bit). This is what the h/w does and can't be changed. Obviously you can convert them in s/w but that takes too long for 4k. The SAND8/30 formats can be consumed directly if you are outputting to DRM, and EGL knows about SAND8 and will shortly know about SAND30 (in HoT mesa as well as Pi backports).

When you say EGL knows about it, are you referring to https://gitlab.freedesktop.org/mesa/drm/-/blob/main/include/drm/drm_fourcc.h#L964 till https://gitlab.freedesktop.org/mesa/drm/-/blob/main/include/drm/drm_fourcc.h#L1010 ?

jc-kynesim commented 1 year ago

I mean 'knows about' in the sense that you can pass it to eglCreateImageKHR and it "just works"

EmperorPenguin18 commented 1 year ago

I have this working now, and changes will hopefully be upstream soon. I'm closing issue as there was literally nothing wrong with this part of the stack.

Hopefully you are able to get this fork upstreamed to ffmpeg!