Hi Jianfeng, Le vendredi 21 juin 2024 à 17:22 +0800, Jianfeng Liu a écrit : > Hi Sebastian, > > Detlev is working on rkvdec2 and gstreamer can't deal with two h264 Just to clarify, since you are right that it won't work well with GStreamer. It does work with multiple decoders (it exposes them all), it is simply that it will randomly pick one when decoding, and it may not pick the best one. > stateless decoders. So it's better to disable h264 decoding feature of > this vpu121, just like what we have done for rk3399. If your multicore > patch can handle the jpeg enc node at fdb50000 with other VEPU121 nodes > properly, we can just use compatible string "rockchip,rk3399-vpu" instead > of "rockchip,rk3568-vpu". In the long term, I'd like to stop having to do "like downstream" and expose them all. I believe the fix is fairly straightforward in GStreamer. We need to expose in the generated element the width/height ranges, and for H.264 the supported profiles and level. With that, we at least won't randomly fail at decoding 4K, and it should be good enough. For RK3588, which is a new SoC, its not a problem to upstream something that does not work with existing userspace. It would only be a regression if we where to enable VDPU121 on RK3399, as now updating linux would cause bugs with existing userspace. For users, it would be best if we get this sorted out in GStreamer by the time we have a second decoder. Note that I have some vacation coming up this month, so there might be extra delays. Yet, its logical to merge this (the "worst" decoder) first, since then randomly picking a better one won't be a regression. Nicolas
