ffmpeg拉取rtsp网络视频流报错解析

在使用ffmpeg调用api方式对一个rtsp网络视频流拉流播放时,应用程序出现了一些错误提示,并且拉流播放的画面也出现了一些马赛克的现象。所以这里便对应用程序所产生的错误提示进行了详细的研究和分析。这里将分析结果贴在下面,若其他朋友遇到类似的错误,供参考。

rtsp @ 0x560bbad10b00 max delay reached. need to consume packet-------------该报错说明ffmpeg接收端的缓冲区已满,达到最大延迟限制,接收端无法及时处理这些视频帧

rtsp @ 0x560bbad10b00 RTP: missed 152 packets-------丢失了部分rtp协议数据包,造成的影响是可能是马赛克 卡顿或者跳帧

Invalid UE golomb code--------解码失败或者部分失败

h264 @ 0x560bbad513c0 cbp too large (3199971767) at 86 31-------h264 @ 0x560bbad513c0: 表示这是 H.264 解码器报告的错误,后面的十六进制数是解码器实例的内存地址。"cbp too large (3199971767)": CBP 代表 Coded Block Pattern,这个值异常大。"at 86 31": 可能表示错误发生在第 86 帧的第 31 个宏块(或者是其他相关的位置信息),问题原因可能是解码器版本与编码器版本不匹配或者编码器生成了不符合h264的数据流

h264 @ 0x560bbad513c0 error while decoding MB 86 31-----h264 @ 0x560bbad513c0: 表示这是 H.264 解码器报告的错误,后面的十六进制数是解码器实例的内存地址。"error while decoding MB 86 31": 表示在解码第 86 个宏块(Macroblock)的第 31 个子块时发生了错误。

h264 @ 0x560bbad513c0 concealing 4403 DC, 4403 AC, 4403 MV errors in P frame------h264 @ 0x560bbad513c0: 表示这是 H.264 解码器报告的信息,后面的十六进制数是解码器实例的内存地址。"concealing": 表示解码器正在尝试隐藏(或修复)错误。"4403 DC, 4403 AC, 4403 MV errors": 指出了三种不同类型的错误及其数量。"in P frame": 表明这些错误发生在 P 帧(预测帧)中。DC(直流)系数:表示块的平均亮度或色度。
AC(交流)系数:表示块内的细节和纹理信息。
MV(运动矢量):用于预测帧间运动的向量。
P 帧:预测帧,依赖于之前的 I 帧或 P 帧进行编码。
a. DC 错误:影响整个宏块的基本亮度或色度。
b. AC 错误:影响块内的细节和纹理。
c. MV 错误:影响运动预测的准确性。
错误原因:
网络传输过程中的数据包丢失或损坏。 b. 存储介质问题:
硬盘或其他存储设备上的文件损坏。 c. 编码问题:
编码器生成了不完全符合标准的比特流。 d. 解码器限制:
解码器可能无法处理某些特定的编码特性。
影响:
视频质量下降:可能会出现马赛克、模糊或冻结的画面。
运动不连贯:由于 MV 错误,可能导致运动预测不准确。
色彩或亮度异常:DC 错误可能导致整个区块的颜色或亮度出现问题。

h264 @ 0x560bbad513c0 Increasing reorder buffer to 1-------h264 @ 0x560bbad513c0: 表示这是 H.264 解码器报告的信息,后面的十六进制数是解码器实例的内存地址。
"Increasing reorder buffer to 1": 表示解码器正在增加其重排序缓冲区的大小到 1。
为什么会出现这个消息:
a. 初始化过程:
解码器在开始时可能不知道需要多大的重排序缓冲区。
它可能从较小的值开始,然后根据需要增加。
b. 适应视频特性:
某些视频流可能需要更大的重排序缓冲区来正确处理帧序列。
c. 编码特性:
视频可能使用了 B 帧(双向预测帧)或复杂的 GOP(图像组)结构。
影响:
这通常不会导致任何问题或错误。
它是解码器正常工作和自我调整的一部分。
可能会略微增加内存使用。

"Increasing reorder buffer to 1" 是一个正常的操作日志,表示 H.264 解码器正在调整其内部缓冲区以更好地处理输入的视频流。这种自适应行为有助于确保视频的正确解码和流畅播放

rtsp @ 0x560bbad10b00 max delay reached. need to consume packet-----这是与 RTSP(Real Time Streaming Protocol)流相关的一个警告或错误提示,rtsp @ 0x560bbad10b00: 表示这是 RTSP协议处理器报告的信息,后面的十六进制数是处理器实例的内存地址。"max delay reached": 表示达到了最大允许的延迟时间。"need to consume packet": 提示需要消费(处理)数据包。
出现这个消息的原因:
a. 处理速度不足:
接收数据包的速度快于处理数据包的速度。
可能是由于解码器处理速度慢或系统资源不足导致的。
b. 网络延迟:
网络传输延迟导致数据包堆积。
c. 缓冲区设置不当:
接收缓冲区可能设置得太小,无法容纳足够的数据包。
d. 流媒体服务器问题:
服务器可能发送数据的速度过快。
解决方法:增加缓冲区大小和最大延迟时间 -buffer_size 10240k -max_delay 5000000或者使用更快的解码器例如nvidia的解码器或者降低接收视频的质量

rtsp @ 0x560bbad10b00 RTP: missed 3 packets

h264 @ 0x560bbad513c0 out of range intra chroma pred mode----这是h264解码器的一个错误,h264 @ 0x560bbad513c0: 表示这是 H.264 解码器报告的信息,后面的十六进制数是解码器实例的内存地址。
"out of range intra chroma pred mode": 表示在帧内(intra)色度(chroma)预测模式中遇到了超出范围的值。
错误原因:
解码器遇到了一个不在预定义范围内的色度预测模式值。
这通常意味着比特流中的数据可能已经损坏或不符合 H.264 标准。
可能的原因:
视频文件损坏:
文件在传输或存储过程中可能被部分损坏。 b. 编码器错误:
编码视频的软件可能存在 bug,生成了不合规的比特流。 c. 不兼容的编码设置:
使用了解码器不支持的高级或非标准的编码特性。 d. 解码器 bug:
在某些罕见情况下,可能是解码器自身的问题。

从上面的日志可以得到结论:自己的程序出现马赛克的原因很大一部分原因是缓冲区满,达到了ffmpeg允许的最大延迟限制;也有一部分原因可能是编码器出现了一些不符合H264协议的数据流;另外也有接收端服务器性能问题。

解决方面的问题方法有以下几个方面:

  1. 降低服务端的帧率,这样数据流就会较小,可能会减少这种报错
  2. 接收解码端使用更快的解码器,例如nvida的h264_cuvid等
  3. 接收端扩大缓冲区的大小和增加最大延迟时间
  4. 调整视频源的发送分辨率和降低比特率
相关推荐
托尼的甜1 小时前
Spring Cloud Gateway 的 SpEL 表达式注入漏洞(CVE-2022-22947)
网络
Gauss松鼠会1 小时前
Prometheus 实现 openGauss 的指标监控(二)Prometheus 中添加 openGauss指标
网络·数据库·oracle·prometheus·opengauss·经验总结
勿忘初心12211 小时前
【Windows流媒体实战1】FFmpeg+Nginx-RTMP Windows详细搭建教程
ffmpeg·nginx-rtmp·windows流媒体搭建·rtmp直播
钒星物联网2 小时前
北斗二号停服倒计时!磐钴提供五大升级服务
大数据·网络
古月方枘Fry2 小时前
基于大模型+MySQL的innoai助手(可适配多数环境)
网络·数据库·mysql·aigc
hz567892 小时前
应急管理部门跨部门会商用什么系统?指挥调度视频会议方案解析
网络·安全·音视频·实时音视频·信息与通信
平行宇宙喜欢吃橙2 小时前
Agent Harness 实战指南:构建生产级 AI Agent 的“马具“框架
网络·人工智能
laboratory agent开发3 小时前
工具调用失败后怎么办?重试分层与降级回路的三种路线
服务器·前端·网络
肥胖小羊4 小时前
企业微信自建应用多环境联调与路由代理方案
服务器·前端·网络
白猫不黑4 小时前
Web 应用中“敏感信息泄露“的常见位置?
前端·网络·web安全·网络安全·信息安全·渗透测试