為什么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已經通過將流量分解為可讀項來部分為您完成此操作。