`ffmpeg-mpp` can not work in kernel v6.1

[wyf9661]

@hbiyik , hello, sorry to ping you, I find that ffmpeg-mpp can not work after I bump to v6.1

jat@opi5plus:~> xfreerdp /u:YF-wangyifan /p:Yfwang@123 /v:172.72.0.31        
[h264_rkmpp_decoder @ 0xffff8c3096b0] Picture format is yuv420p.
[h264_rkmpp_decoder @ 0xffff8c3096b0] Failed to initialize MPP context (code = -1).
[h264_rkmpp_decoder @ 0xffff8c3096b0] Failed to initialize RKMPP Codec.
[10:58:03:468] [20656:20657] [ERROR][com.freerdp.codec] - Failed to open libav codec
[10:58:03:470] [20656:20657] [ERROR][com.freerdp.core.codecs] - Failed to create h264 codec context
[10:58:03:471] [20656:20656] [ERROR][com.freerdp.core] - freerdp_abort_connect:freerdp_set_last_error_ex ERRCONNECT_CONNECT_CANCELLED [0x0002000B]
jat@opi5plus:~> 
jat@opi5plus:~> id
uid=1000(jat) gid=1000(jat) group=1000(jat),966(docker),985(video),998(wheel)
jat@opi5plus:~>

[7Ji]

My gut feeling is that the part not working is not ffmpeg-mpp but rather mpp-git itself, but we'll need a minimal test application for that. IIRC there're a few mpp dec demos in the mpp source tree.

Also this happens on rkbsp 6.1? https://github.com/7Ji-PKGBUILDs/linux-rkbsp-joshua-git . I've seen none commits there yet, but I'll add it to the repo build list so hbiyik could get a quick test.

[hbiyik]

i know this issue, i will send an explanation soon.

[hbiyik]

So rockchip bsp based on linux 6.1 does not have rockchip dma buffer implemented in it yet. Current ffmpeg (and default mpp) fork depends on rockchip dma device to exchange buffers. Therefore it wont work in 6.1 unless it is ported to bsp 6.1

https://github.com/hbiyik/linux/tree/linux-6.1-rkbsp6-panthor-v4

I had done here a cocktail kernel based on rockchip's 6.1 bsp, + dma device from rkr4.1 + panthor driver from 6.7 mainline kernel and it seems to work somehow. I did not test this throughly and im sure there might be issues in it. It was just to check the feasibility of using panthor in rockchip bsp, and while i was on it i just ported dma buffer from rkr4.1.

The actual plan is to migrate ffmpeg to https://github.com/nyanmisaka/ffmpeg-rockchip which is a much more advaced implementation of mpp + rga tp ffmpeg. And it does not use dma buffers, but use DRM buffers which is not rockchip kernel specific, so it should work in 6.1 bsp. ffmpeg-rockchip still needs final touches to improve decoder compatabilty with existing player eco system, so when it is done, this is the future.

See: https://github.com/hbiyik/ffmpeg-rockchip/wiki/Rendering

I can also switch to drm buffer in existing ffmpeg, but i see no value on working on it anymore, we will switch to ffmpeg-rockchip anyways.

So TLDR: 1) Rockchip needs to port its dma device to rkr6.1 (or however it is called) 3) Without the need of rockchip's port the ffmpeg-rockchip will be immune to this issue. Soon.

[nyanmisaka]

@hbiyik Requesting MPP_BUFFER_TYPE_DRM doesn't mean you will get it, but in fact you might get MPP_BUFFER_TYPE_DMA_HEAP.

The priority of the obtained buffer type is hard-coded in the MPP runtime. That means you still need to patch the MPP runtime to run on the develop-6.1 BSP kernel, or it just segfaults.

[hbiyik]

Can we not request manually with ext buffers? I think mpp allocators are not used at that point, because i remember i made it work with 6.1 without missing dma and directly openning the drm device with manual mmaps.

[nyanmisaka]

So if there are no uncached node in /dev/dma_heap/ path, mpp will not use dma_heap allocator.

This commit seems to have fixed it.