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. 调整视频源的发送分辨率和降低比特率
相关推荐
热爱跑步的恒川37 分钟前
【论文复现】基于图卷积网络的轻量化推荐模型
网络·人工智能·开源·aigc·ai编程
云飞云共享云桌面2 小时前
8位机械工程师如何共享一台图形工作站算力?
linux·服务器·网络
音徽编程4 小时前
Rust异步运行时框架tokio保姆级教程
开发语言·网络·rust
幺零九零零5 小时前
【C++】socket套接字编程
linux·服务器·网络·c++
岁月小龙5 小时前
如何让ffmpeg运行时从当前目录加载库,而不是从/lib64
ffmpeg·origin·ffprobe·rpath
23zhgjx-NanKon5 小时前
华为eNSP:QinQ
网络·安全·华为
23zhgjx-NanKon6 小时前
华为eNSP:mux-vlan
网络·安全·华为
点点滴滴的记录6 小时前
RPC核心实现原理
网络·网络协议·rpc
Lionhacker6 小时前
网络工程师这个行业可以一直干到退休吗?
网络·数据库·网络安全·黑客·黑客技术
程思扬7 小时前
为什么Uptime+Kuma本地部署与远程使用是网站监控新选择?
linux·服务器·网络·经验分享·后端·网络协议·1024程序员节