我正在从IP摄像头传输rtsp流。我有一个解析器，它根据rtp有效负载类型将数据打包成帧。解析器能够处理I帧，因为它们包含帧的开始和帧结束的数据包，以及它们之间的数据包（这是FU-A有效载荷类型）。
这些组合起来创建一个完整的框架。当我尝试构造P帧时出现问题，来自wireshark转储中的一些似乎是分段的（FU-A有效载荷类型），它们包含帧的开始和帧结束的数据包，但是这些包含在它们之间的数据包。此外，在某些情况下，相机会发送带有1号负载的奇怪标记数据包，根据我的理解，这应该是一个完整的帧。
在处理这两个版本的P帧后，我使用ffmpeg尝试解码帧，我收到错误消息，如顶部块无法用于帧内模式4x4。
起初我认为这可能是由于旧的ffmpeg版本，但我在网上搜索并重新编译ffmpeg同样的问题。
I帧看似碎片并包含大量数据包，有些P帧有帧起始（0x81）和EOF（0x41），但中间没有数据包，有些只是看起来已损坏，从0x41开始（看起来应该是第二个字节）它给出了有效载荷类型1.我是新手，当涉及到这些问题，但我看了rtp文档，我找不到如何处理数据的问题。
此外，我从VLC流式传输，这似乎很好，但似乎将帧速率减半，我不确定它们如何能够重建帧。
请有人帮忙。
答案 0 :(得分：1)
I帧通常被分段，因为它们通常比p帧大很多。然而，P帧也可以是分段的。然而，已经被分段成2个RTP分组的P帧没有任何问题，即一个具有FU报头起始位设置，并且后一个具有结束位设置。中间不需要包。例如，如果MTU为1500，并且NAL单元为1600字节大，则将其分段为2个RTP数据包。
对于从0x41开始而没有带有0x81的先前数据包的“看起来已损坏”的数据包，您应该检查RTP标头中的序列号，因为这将立即告诉您数据包是否丢失。如果您看到丢包，首先要尝试增加套接字接收缓冲区大小。
由于VLC能够播放流，因此您重新组装NAL单元的方式很可能存在问题。
此外，在您的问题中，并不总是清楚您指的是哪个字节：我假设0x41和0x81出现在RTP有效负载的第二个字节中，即在NAL单元的情况下出现FU标头第一个字节的类型是FU-A。
最后，请注意“有效载荷类型”是RTP有效载荷类型（RFC3550），而不是H.264标准中定义的NAL单元类型。