GStreamer解码RTSP视频流出现高CPU占用或返回旧帧问题求解

现象是否属于预期 #

两种现象均符合你当前配置下的预期行为，核心原因是GStreamer的解码调度逻辑和你的业务处理速度不匹配，加上pipeline配置没有做流控导致。

问题原因说明 #

• 配置1（drop=true）高CPU问题
  rtspsrc默认会按视频流的原始帧率全量拉取数据，解码逻辑和你的read()调用完全异步，哪怕你业务处理慢来不及取帧，GStreamer也会持续解码新帧，缓存满了就丢弃旧帧。大量解码出来的帧还没被处理就被丢弃，做了很多无用解码工作，直接导致CPU占用过高、实际解码帧数远超可处理帧数。
• 配置2（drop=false）返回旧帧问题
  配置了不允许丢帧且缓存只有1帧时，GStreamer解码出一帧后如果一直没被取走，就会暂停解码流程等待消费，长时间运行后解码进度会严重滞后于实时流的最新进度，你取到的就是缓存里积压了很久的旧帧，运行几小时后拿到历史帧完全符合该配置的逻辑。

解决方案 #

1. 优化GStreamer pipeline配置 #

核心思路是从链路层面限制无用解码，避免帧积压，调整后参考pipeline如下：

self.pipeline = f"rtspsrc location={self.url} latency=10 do-retransmission=false buffer-mode=0 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! videorate max-rate=5 drop=true ! appsink max-buffers=1 drop=true"

调整点说明：

• 新增do-retransmission=false buffer-mode=0：关闭rtsp流的丢包重传，启用低延迟模式，避免rtspsrc缓存过多历史流数据
• 新增videorate max-rate=X drop=true：将X替换为你业务实际能处理的每秒帧率，多余的帧直接在进缓存前丢弃，避免无用解码
• 保留appsink的drop=true，防止极端情况帧积压
  如果你的设备支持硬件解码，把avdec_h264替换成对应硬件解码器（比如英伟达平台用nvv4l2decoder、瑞芯微平台用rkh264dec），可以直接降低80%以上的解码CPU占用。

2. 代码逻辑优化 #

单独启动一个独立线程负责调用read()取帧，只缓存最新的一帧覆盖旧帧，业务处理线程直接读取最新缓存的帧即可，避免业务处理慢卡住读帧流程导致的链路积压。
另外可以加帧的时间戳校验逻辑，如果取到的帧和当前时间差超过设定阈值，直接重建VideoCapture实例重置流，避免长时间运行后帧延迟过大。

内容的提问来源于stack exchange，提问作者user1315621