Hi Piotr,
On 12/19/25 08:50, Piotr Oniszczuk wrote:
>
>> Wiadomość napisana przez Detlev Casanova <detlev.casanova@collabora.com> w dniu 19 gru 2025, o godz. 00:28:
>>
>> These variants are found respectively in the RK3588 and RK3576 SoCs.
>> This patch only adds support for H264 and H265 in both variants.
>>
>> As there is a considerable part of the code that can be shared with the
>> already supported rkvdec decoder driver, the support for these variants
>> is added here rather than writing a new driver.
>>
>> This patch set uses the newly introduced hevc_ext_sps_[ls]t_rps v4l2
>> controls for HEVC.
>> Therefore, a patched version of userpace tools is needed for HEVC
>> support (added for GStreamer[1] and in an early stage for FFmpeg[2]).
>>
>> The DTS changes can be found in another patch set: [3]
>>
>> [1]: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9355
>> [2]: https://gitlab.collabora.com/detlev/ffmpeg
>> [3]: https://lore.kernel.org/all/20251020212009.8852-1-detlev.casanova@collabora.com/
>>
> Detlev,
>
> FYI:
>
> In my testbed with
>
> i. v7 of [1] on mainline 6.18.2
> ii ffmpeg8 v4l2_request [2]
> iii. mythv as player [3]
> iv. minimyth2 as distro [4]
> v. NO applied yours ffmpeg sps/rps hinting [5] (as i'm on ffmpeg8)
And [5] won't be compatible anymore actually, I'm waiting for the final
version of the uapi to tackle that.
> I run set of my mpeg2/h264/hevc/vp8/vp9 samples on: rk3328. rk3399, rk3566, rk3576, rk3588 and h616 (just for brief test for potential cross-regressions)
>
> Results:
>
> a. rk3328: no any regressions; all samples are decoded ok
>
> b. rk3399: no any regressions; all samples are decoded ok
>
> c. rk3566: no any regressions (e.g. in vp9. v6 and older were regressing; v7 is ok)
VP9 improvement is expected as I added a missing reg_num multiplier in
VP9 as spotted by Jonas.
> c.1 h264: all ok
> c.2 hevc: samples without long-term sps/rps: all ok.
> c.3 hevc: samples with long-tern sps/rps: v7 is a bit regressing here: it gives me sometimes kernel oops requiring hw. reset to bring decoder back to live.
> Exemplary oops: https://termbin.com/upju
> Older vers of your code were handling such cases without needs of hw. reset
The 3566 support doesn't need any driver changes, only device tree nodes
using the "rockchip,rk3588-vdec" compatible ?
I'll check that oops, I haven't seen it yet.
>
> d. rk3576:
> d.1: h264: works ok - but randomly i'm getting playback with distortions like this: https://postimg.cc/Yh8Djc3L. it is avd. 1 per few playbacks.
> d.2: hevc: the same like c.1 and c.2
>
> e. rk3588
> e.1: h264: all ok
> e.2: hevc: the same like c.1 and c.2
>
> g. h616 with cedrus: all ok.
>
> btw:
> Adding to [1] vp9 android code [6] offers me nice working vp9 hwdec accell on rk3566/3588.
>
> Great work!
Thank you, and thanks for your valuable testing !
>
> [1] https://gitlab.collabora.com/detlev/linux/-/commits/add-vdpu381-and-383-to-rkvdec-v7
> [2] https://code.ffmpeg.org/Kwiboo/FFmpeg/src/branch/v4l2-request-n8.0.1
> [3] https://github.com/MythTV/mythtv
> [4] https://github.com/warpme/minimyth2
> [5] https://gitlab.collabora.com/detlev/ffmpeg
> [6] https://github.com/dvab-sarma/android_kernel_rk_opi/commit/fd0b1b17cbdfcf0c15bc9f411cc7127105157e57
>
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip