我查看了RFC并注意到可以解释为什么会发生以下情况（虽然解码器仍然可以制作原始电影）。
我使用VSS h.264编码器传输H.264 / AVC nals，字节流看起来像这样E5 46 0E 4F FF A0 23 ...
当我在RTP Broadcaster / RTSP接收器之后读取接收器侧的电影数据时，我获得了额外的未知数据，但总是在相同的位置，在开始代码前缀（0x00000001）之前添加了8个字节， 在开始代码前缀之后添加了2个字节，它看起来像这样。
XX XX XX XX XX XX XX XX 00 00 00 01 XX XX，然后我查看Wireshark，我可以看到RTP将字节添加到数据有效负载。
为什么会发生这种情况？为什么解码器似乎能很好地处理那些额外的字节？！
答案 0 :(得分：1)
这有些搞砸了......而且你可以把它弄得更糟，它仍然可以工作，因为解码器会为0x000001起始代码解析它，跳过开头添加的字节。最后这两个新字节必须是H264碎片字节......或者因为它们起作用而与H264相关的东西。
基本上，这是由于有缺陷的打包器/ RTSP源滤波器造成的。我的猜测是，如果您对这8个字节进行ASCII编码，您将获得RTSP源过滤器的供应商名称... xD
答案 1 :(得分：0)
正如我在另一篇文章Changing NALU h.264/avc, for RTP encupsulation中提到的，H.264是通过RFC 3984中定义的RTP传输的。这特别定义了如何将大的NAL单元分成适合较小消息大小的较小部分，例如UDP数据报大小。那就是碎片化。
Receiver解包数据并恢复NALU，并使用这些额外信息来完成工作。
因此，您基本上需要的是将您拥有的原始数据与RFC 3984格式进行比较。此外，Wireshark通过将流量分解为可读项目已经部分地为您做了这一点。