代码收藏家 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性能已经调到最大。
更新。。。
后来买了一个HDMI编码器，经过测试，发现可以达到110-250ms之间的延迟，平均在140左右，所以有可能是当时那台设备的问题。
不过倒是发现另外一个情况，就是如果我把桌面给关闭掉，甚至可以达到接近100ms的延时，偶尔达到八九十毫秒的延时，这个延时，是从摄像头采集，到编码，到rtp推流，解码，显示之后的延时，这么低的延时是非常低的。
ubuntu关闭和开启桌面显示的方法：
sudo service lightdm stop
sudo service lightdm start
当然了，虽然如此，但是发现对于gstreamer框架来说，rtp视频流的延时可以很低，但是rtsp的貌似效果没有rtp视频流好，特别是decodebin3比decodebin更好用，decodebin偶尔会花屏。
作者：阿龍1787
