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 小时前
蠕虫病毒(网络安全小知识)
服务器·网络·web安全
叫我龙翔1 小时前
【计网】从零开始掌握序列化 --- 实现网络计算器项目
服务器·网络·c++·网络协议
Proxy7111 小时前
动态住宅IP的多元化应用
网络·网络协议·tcp/ip
Chrikk1 小时前
美团中间件C++一面-面经总结
网络·c++·中间件
智电云2 小时前
基于Java语言的桩底层直连协议和云快充协议
网络·云快充协议
Hello_wshuo2 小时前
linux开启wol (网络唤醒)
linux·运维·网络
好看资源平台2 小时前
网络安全:应对新时代的安全挑战
网络·安全·web安全
安科瑞刘鸿鹏2 小时前
工业能源物联网的建设与维护该如何实现
运维·服务器·网络·数据结构·物联网·能源
cuijiecheng20183 小时前
音视频入门基础:FLV专题(5)——FFmpeg源码中,判断某文件是否为FLV文件的实现
ffmpeg·音视频