多路rtsp取流解码时decode_put_packet失败

[denghengli]

一、运行环境 1、芯片平台：RK3568 2、内核版本 尝试过两个版本 （1）Linux version 5.10.198 (xxx) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 10.3.1 20210621, GNU ld (GNU Toolchain for the A-profile Architecture 10.3-2021.07 (arm-10.29)) 2.36.1.20210621) #13 SMP Wed May 15 09:59:54 CST 2024 （2）Linux version 4.19.232-g61c221948966-dirty (xxx) (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)), GNU ld (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 2.33.1.20191209) #29 SMP Fri Apr 26 12:01:16 CST 2024 3、mpp驱动版本（5.10内核版本） ~ # cat /proc/mpp_service/version ea89a0945141 author: Yandong Lin 2023-12-20 video: rockchip: mpp: fix watch dog interrupt storm issue 4、librockchip_mpp版本

二、应用说明 1、同时开启多个线程对多路网络摄像头实时进行rtsp取流、mpp解码、mpp编码，具体如下： 线程1：camera1 rtsp取流 ---> mpp解码 --> H265编码+OSD字符叠加 线程2：camera1 rtsp取流 ---> mpp解码 --> MJPEG编码 线程3：camera2 rtsp取流 ---> mpp解码 --> H265编码+OSD字符叠加 线程4：camera3 rtsp取流 ---> mpp解码 --> MJPEG编码 ... 目前测试了2路摄像头就出现了下述问题

2、内存管理使用的纯内部分配模式，输入码流的形式 分帧、不分帧都试过，现象一样

三、问题描述 运行一段时间后（时长不固定，有时挂测了1天多都没事，有时几分钟就会出现） 1、程序报错 decode_put_packet 往解码器喂数据时返回失败，延时3ms多次重试后还是会一直失败，此时重新复位、初始化解码器也不起作用 2、内核报错

mpp多路rtsp取流后解码异常.zip

[HermanChen]

看起来解码器异常恢复不了，可能是内核驱动的问题 上层送码流的时候，如果送失败了需要继续送，rtsp 流是会出错的，最好先看下 rtsp 存下来的数据是不是正常，把存下来的码流文件给 mpi_dec_test 解码看看是不是有问题，再把收流和解码合起来验证。先分段确认各个环节是否可靠，再看系统整合是否正常

[denghengli]

看起来解码器异常恢复不了，可能是内核驱动的问题 上层送码流的时候，如果送失败了需要继续送，rtsp 流是会出错的，最好先看下 rtsp 存下来的数据是不是正常，把存下来的码流文件给 mpi_dec_test 解码看看是不是有问题，再把收流和解码合起来验证。先分段确认各个环节是否可靠，再看系统整合是否正常

1、内核驱动问题，能解决吗，我们尝试了用5.10内核版本的也没解决。 2、rtsp码流是使用ffmpeg从海康的网络摄像头取的，然后循环的av_read_frame送给解码器，每次出现这个问题的时候都是decode_put_packet返回失败了，而且出现的时长不定，那假如说rtsp的某一帧出错了，如果还一直送岂不是decode_put_packet就会一直失败，我参考的mpi_dec_test，在这种情况下demo里是延时3ms再重新送，但是这样处理后就死循环出不来了（实际情况就是这样） 3、会跟多路同时解码+编码有关系吗，多个解码器线程（实例）不会互相竞争编解码器吧，内部是支持同时解码多路的吗 4、rkvdec2_link_wait_result:1332: task 13709:72815 statue 1 timeout -> abort 这个报错什么情况下才能出现呢，当出现这个错误的时候可以判定驱动就挂掉了，重新初始化解码器都没用，需要重启才能恢复。出现下面的报错的时候还能恢复一下，如果配置成阻塞输入跟阻塞输出能解决这种驱动解码超时的问题吗 [ 4909.794777] mpp_rkvdec2 fdf80200.rkvdec: resend task 452199 [ 4910.299697] mpp_rkvdec2 fdf80200.rkvdec: session 2 task 452199 state 0x14f timeout, cnt 25 [ 4910.299707] mpp_rkvdec2 fdf80200.rkvdec: session 14 task 452200 state 0x14f timeout, cnt 26 [ 4910.299779] mpp_rkvdec2 fdf80200.rkvdec: session 1 task 452198 state 0x14f timeout, cnt 27 [ 4910.299796] mpp_rkvdec2 fdf80200.rkvdec: session 14 task 452197 state 0x14f timeout, cnt 28 [ 4910.299809] mpp_rkvdec2 fdf80200.rkvdec: session 1 task 452196 state 0x14f timeout, cnt 29 [ 4910.299821] mpp_rkvdec2 fdf80200.rkvdec: session 16 task 452195 state 0x14f timeout, cnt 30 [ 4910.299832] mpp_rkvdec2 fdf80200.rkvdec: session 16 task 452194 state 0x14f timeout, cnt 31 [ 4910.299842] mpp_rkvdec2 fdf80200.rkvdec: session 2 task 452193 state 0x14f timeout, cnt 32 [ 4910.299853] mpp_rkvdec2 fdf80200.rkvdec: session 14 task 452192 state 0x14f timeout, cnt 33 [ 4910.299865] mpp_rkvdec2 fdf80200.rkvdec: session 1 task 452191 state 0x14f timeout, cnt 34 [ 4910.299887] mpp_rkvdec2 fdf80200.rkvdec: session 2 task 452190 state 0x14f timeout, cnt 35 [ 4910.299897] mpp_rkvdec2 fdf80200.rkvdec: session 16 task 452189 state 0x14f timeout, cnt 36 [ 4910.299906] mpp_rkvdec2 fdf80200.rkvdec: session 16 task 452189 timeout 1 abort 0 force_dequeue 0 [ 4910.299912] mpp_rkvdec2 fdf80200.rkvdec: resetting... [ 4910.301090] rk_iommu fdf80800.iommu: Error during raw reset. MMU_DTE_ADDR is not functioning [ 4910.301113] mpp_rkvdec2 fdf80200.rkvdec: reset done

[denghengli]

看起来解码器异常恢复不了，可能是内核驱动的问题 上层送码流的时候，如果送失败了需要继续送，rtsp 流是会出错的，最好先看下 rtsp 存下来的数据是不是正常，把存下来的码流文件给 mpi_dec_test 解码看看是不是有问题，再把收流和解码合起来验证。先分段确认各个环节是否可靠，再看系统整合是否正常

我按照您的方法排查了下，确实是解码异常的时候的rtsp码流不对，保存下来的h265码流文件通过mpi_dec_test也解码也失败，rtsp码流中有丢帧跟乱序的。导致这个问题的原因跟下面这个issue很相似，也是同时有多路 H265编码 跟 MJPEG编码，导致每帧处理时间很长，我rtsp取流又是跟编解码在同一个线程中顺序执行的，导致netstat -ant中Recv-Q堆积了大量数据 https://github.com/rockchip-linux/mpp/issues/143

想请教下，rk3568的 H264/H265解码器、H264/H265编码器、MJPEG编码器 哪些是独立哪些是分时复用的呢？ 不能多路同时265编码跟MJPEG编码吗

[HermanChen]

可以多路同时，是硬件是时分复用的，上层可以开多个实例，内核会对任务做排序

[denghengli]

可以多路同时，是硬件是时分复用的，上层可以开多个实例，内核会对任务做排序

如果多个实例都一直不断的喂数据给解码器，解码器能处理过来吗，3568最多能支持多少个这样的实例呢

[HermanChen]

可以的，不超过总性能就可以，3568 解码好像是 4K@60 的总性能，看下 benchmark