记录：Rk3588播放RTSP视频流有延时和卡顿（CPU性能问题）

本文主要是介绍记录：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性能都不是最大的。

于是当时那个问题算是暂时解决了。