p帧上的rtp解码问题

Question

我正在从 IP 摄像机流式传输 rtsp 流。我有一个解析器，它根据 rtp 有效负载类型将数据打包成帧。解析器能够处理 I 帧，因为它们包含帧开始和帧结束数据包，以及介于两者之间的数据包（这是 FU-A 有效负载类型）。

这些组合在一起形成一个完整的框架。当我尝试构建 P 帧时，问题就出现了，从 Wireshark 转储中，其中一些似乎是碎片化的（FU-A 有效负载类型），它们包含帧开始和帧结束数据包，但是它们之间不包含数据包.此外，在某些情况下，相机会发送带有有效载荷类型 1 的奇怪标记数据包，根据我的理解，这应该是一个完整的帧。

在处理这两个版本的 P 帧后，我使用 ffmpeg 尝试对帧进行解码，我收到错误消息，例如 top block 无法用于帧内模式 4x4。

起初我认为这可能是由于旧的 ffmpeg 版本，但我搜索了网络并重新编译了 ffmpeg，但遇到了同样的问题。

I 帧出现碎片并包含大量数据包，一些 P 帧有一个帧开始 (0x81) 和 EOF (0x41)，但中间没有数据包，有些看起来从 0x41 开始损坏（看起来应该是第二个字节），它给出的有效载荷类型为 1。当涉及到这些问题时，我是一个新手，但我查看了 rtp 文档，但我找不到如何处理数据的问题。

我也从 VLC 流式传输，这看起来不错，但似乎将帧速率减半，我不确定他们如何能够重建帧。

请有人帮忙。

Answer 1

I 帧通常是碎片化的，因为它们通常比 p 帧大很多。然而，P 帧也可以被分段。然而，一个 P 帧被分成 2 个 RTP 数据包没有任何问题，即一个设置了 FU-header 起始位，另一个设置了结束位。中间不需要有数据包。例如，如果 MTU 为 1500，而 NAL 单元为 1600 字节大，这将被分片为 2 个 RTP 数据包。

对于从 0x41 开始而没有先前的 0x81 数据包的“看起来已损坏”的数据包，您应该检查 RTP 标头中的序列号，因为如果数据包丢失，这将立即告诉您。如果您发现丢包，首先要尝试增加您的套接字接收器缓冲区大小。

由于 VLC 能够播放流，因此您重新组装 NAL 单元的方式很可能存在问题。

此外，在您的问题中，您所指的字节并不总是很清楚：我假设 0x41 和 0x81 出现在 RTP 有效负载的第二个字节中，即 NAL 单元中的 FU 标头第一个字节的类型是FU-A。

最后，注意“payload type”是RTP payload type (RFC3550)，而不是H.264标准中定义的NAL unit type。