#01
基本格式
01
H.264的RTP報頭
圖1 RTP報頭
02
H.264的RTP負載類型
H.264的RTP負載可分爲三大類,類型如下:
此類RTP負載中僅包含單個NAL單元。負載報頭類型編號等於原始NAL單元類型,即從 1 到 23 的範圍值,詳見H.264規範。
此類型用於聚合多個NAL單元成爲單個 RTP 負載。這類數據包有四個細分版本:單時間聚合包A (STAP-A)、單時間聚合包B (STAP-B)、16位偏移多時間聚合包 (MTAP16) 和24位偏移多時間聚合包 (MTAP24)。負載類型編號分配給 STAP-A、STAP-B、MTAP16 和 MTAP24 的值分別爲 24、25、26 和27。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
03
H.264的RTP打包模式
單NAL單元模式
所有的接收端都必須支持這種模式,主要應用於兼容低時延應用中的硬件設備。只有單NAL單元數據包可以在這種模式下使用。
非交錯模式
建議接收端去支持這種模式,主要應用於低時延應用。只有單NAL單元、STAP-A和FU-A數據包可以在這種模式下使用。
交錯模式
有需求的接收端可以去支持這種模式,主要應用於非低延時應用。STAP-B、兩種MTAP、FU-A和FU-B數據包可以在這種模式下使用。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
單NAL單元和非交錯模式中,NAL單元必須以NAL單元解碼順序傳輸,這兩種模式更適合低延時需求的交互系統。
交錯模式中NAL單元的傳輸順序和解碼順序可以是不一致的,導致接收端的解包過程中需要按照解碼順序重新排序,引入更多的時延,因此並不適合需要低時延的交互系統。
04
H.264的RTP負載報頭
H.264的RTP負載報頭位於負載的第1個字節,分成三個字段:
05
H.264的RTP負載格式
因爲只有單NAL單元模式和非交錯模式打包模式更適合應用於低時延交互系統中,而這兩種打包模式所涉及的只有單NAL數據包、單時間聚合包A(STAP-A)和分片單元A(FU-A)三種RTP負載,所以在這裏只對這三種負載格式做個簡單的介紹。
單NAL數據包就是將原始的NAL單元直接放置到RTP的負載中,NAL單元頭就是作爲單NAL數據包的負載類型。
單時間聚合包A(STAP-A)
聚合數據包的負載中包含一個或者多個聚合單元。一個聚合包可以攜帶儘可能多的聚合單元;不過聚合數據包中的總數據量應該選擇合適大小,以便生成的IP數據包小於MTU大小。聚合數據包負載報頭中的NRI字段的值必須是所有聚合NAL單元中最大值。
#02
實踐分享
圖9 視頻流工作流程
01
H.264打包
H.264的打包的基本流程大致如下:
-
輸入H.264 NAL,判決當前的H.264 NAL的打包格式,可以選擇單NAL單元包格式、STAP-A包格式,或者是FU-A格式。MTAP格式一般不在實時系統中使用,考量的重點在於兼顧打包效率和傳輸效率。 -
Single-NAL-Unit 打包比較簡單,一個NAL封裝爲一個RTP包。 -
STAP-A在NAL包比較小的時候採用,多個相同時間戳的NAL包被打到一個RTP包。 FU在NAL包比較大的時候採用,限制RTP包的大小小於MTU。一個NAL包被拆成多個碎片(Fragment), 碎片被打成RTP包。
02
H.264解包
在此只對三種打包模式下的解包過程做一個大致的介紹。
參考文獻
2、RFC 6184 – RTP Payload Format for H.264 Video
本文分享自微信公衆號 - 音視頻開發進階(glumes_blog)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。