为什么RTP / RTSP干扰我的H.264 NAL？

我查看了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将字节添加到数据有效负载。

为什么会发生这种情况？为什么解码器似乎能够很好地应对那些额外的字节？！

这是一些混乱的上游……你可以把它弄得更糟，它仍然可以工作，因为解码器解析它为0x000001起始码，跳过开头添加的字节。最后这两个新字节必须是H264碎片字节…或者因为它们起作用而与H264相关的东西。

基本上，这是由于有缺陷的打包器/ RTSP源滤波器造成的。我的猜测是，如果您对这8个字节进行ASCII编码，您将获得RTSP源filter的供应商名称… xD

正如我在另一篇文章中提到的更改NALU h.264 / avc，对于RTP encupsulation ，H.264是通过RFC 3984中定义的RTP传输的。这特别定义了如何将大的NAL单元分成适合较小消息大小的较小部分，例如UDP数据报大小。那就是碎片化。

接收器将数据解包并恢复NALU，并使用这些额外信息来完成工作。

因此，您基本上需要的是将您拥有的原始数据与RFC 3984格式进行比较。此外，Wireshark已经通过将流量分解为可读项目而部分为您完成此操作。