为什么RTP / RTSP与我的H.264 NAL混为一谈？

Question

我查看了RFC，并注意到可以解释为什么发生以下情况（尽管解码器仍可以生成原始电影）。

我使用VSS h.264编码器传输了H.264 / AVC信号，字节流看起来像这样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将字节添加到数据有效载荷中。

为什么会发生为什么呢？ 以及为什么解码器似乎能够很好地处理这些额外的字节？

Answer 1

多数民众赞成在混乱的流...您可以将其弄乱的更多，它仍然可以工作，因为解码器将其解析为0x000001起始代码，跳过开头添加的字节。 最后两个新字节必须是H264碎片字节...或与H264相关的东西，因为它们可以工作。

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

Answer 2

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

Receiver对数据进行解包并还原NALU，然后它使用此额外信息来完成工作。

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