本文主要是介绍记录：Rk3588播放RTSP视频流有延时和卡顿（CPU性能问题），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
前言
前段时间做项目，花了几天时间开发了一款基于RK3588平台，进行RTSP和RTP的解码软件，接收其他软件发送的UDP控制指令，进行位置、大小、显示的前后顺序、播放链接、参数等动态调整，使用QT+Gstreamer框架开发。
管道：rtspsrc location=rtsp://admin@passpwd:192.9.200.113 port-range=10000-10010 drop-on-latency=true latency=17 ! queue ! decodebin3 ! queue ! glimagesink sync=false
遇到的问题：
相同的代码，在虚拟机里面，播放VLC推流的RTSP和RTP流，都可以正常播放，没有任何异常，将RTSP视频源换为海康威视带用户名和密码的RTSP视频流连接，在虚拟机内一样可以运行，没有延时和卡顿，但是在公司生产得以RK3588为核心的计算机上，明明使用得是硬解码，依然会出现卡顿，并且延时越来越多。
解决过程记录：
1. 排查是否使用mpp
最开始，怀疑是没有使用mpp解码，于是指定使用软解：
rtspsrc location=rtsp://admin@passpwd:192.9.200.113 port-range=10000-10010 drop-on-latency=true latency=17 ! queue ! rtph264depay ! h264parse ! avdec_h264 ! queue ! glimagesink sync=false
发现延时更大，而且显示都有花屏。 改为指定mpp：
rtspsrc location=rtsp://admin@passpwd:192.9.200.113 port-range=10000-10010 drop-on-latency=true latency=17 ! queue ! rtph264depay ! h264parse ! mppvideodec ! queue ! glimagesink sync=false
发现效果和之前相同。而且查看decodebin的打印信息，会发现确实是自动使用了mpp解码。
而且这时候比较CPU占用率，发现明显降低了一些，虽然还是有一些CPU占用，大概每个核15%，使用软解，每个核心平均50%。
2. 排查是否是丢包的问题：
将rtsp改成rtspt，指定使用tcp协议传输，发现效果好了一些，但是依然有稳定的延时，实时性不够。
使用iperf3 指定使用udp去测试丢包，发现低带宽不丢包，高带宽1-2%丢包。但问题是压缩过后的视频占用的带宽是很低的。而且很难去解决这个udp丢包的问题。
3.查看是否是mppvideodec插件本身的问题
使用个人使用的RK3588开发板，买的鲁班猫5，其实人家做的还不错，发现延时较低。
4.调节CPU占用和性能
这是个偶然发现，发现将CPU性能调整为最大的时候，竟然没有延时了！！！
scaling_frequency.sh -c rk3588 将性能调为最大。
后来问了做底层的同事，默认出厂，CPU和GPU性能都不是最大的。
于是当时那个问题算是暂时解决了。
后期偶然发现的问题：
使用海思的解码器，使用C语言写的代码，同样的组播视频流查看摄像头画面，延时大概120ms，但是我使用RK3588，gstreamer和mpp解码，最好情况也是两百多毫秒，在我们主机上延时可以将近1秒，目前暂时不知道如何解决，此时CPU性能已经调到最大。
这篇关于记录：Rk3588播放RTSP视频流有延时和卡顿（CPU性能问题）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
