为什么RTP/RTSP要插手我的H.264 NAL？
我查看了RFC，没有任何东西可以解释为什么会发生以下情况(尽管解码器仍然可以生成原始电影)。
我使用VSSH.264编码器传输了H.264/AVC nals，字节流看起来像这样的E5 46 0E 4F FF A0 23...
当我在RTP广播/RTSP接收器之后的接收器端读取电影数据时，我得到额外的未知数据，但总是在相同的位置，8个字节被添加到起始码前缀(0x00000001)之前，2个字节被添加到起始码前缀之后它看起来像这样。
XX 00 00 00 01 XX XX，然后我查看Wireshark，我可以看到RTP将字节添加到数据有效负载。
为什么会这样?为什么？为什么解码器似乎能很好地处理这些额外的字节？！
回答 2
Stack Overflow用户
发布于 2011-10-06 07:22:53
那是一些乱七八糟的上游。你可以把它弄得更乱，但它仍然可以工作，因为解码器会将它解析为0x000001起始码，跳过在开头添加的字节。末尾的那两个新字节必须是H264碎片字节...或者H264相关的东西，因为它们可以工作。
因此，基本上，这是由于有缺陷的分组器/RTSP源过滤器。我的猜测是，如果您对这8个字节进行ASCII编码，您将获得RTSP源过滤器的供应商名称……xD
Stack Overflow用户
发布于 2011-09-28 16:11:46
正如我在另一篇文章Changing NALU h.264/avc, for RTP encupsulation中提到的，H.264是通过RFC3984中定义的RTP传输的。这特别定义了如何准确地将大的NAL单元分解成适合较小消息大小的较小部分，例如UDP数据报大小。也就是说，碎片化。
Receiver对数据进行解包并恢复NALU，然后使用这些额外信息来完成此工作。
因此，您实际上需要的是将您拥有的原始数据与RFC 3984格式进行比较。此外，Wireshark已经通过将流量分解为可读项目为您做了部分工作。
https://stackoverflow.com/questions/7580069
复制相似问题
腾讯云开发者
