實時視頻系統中的媒體傳輸,絕大多數都會採用RTP(實時傳輸協議)標準。H.264視頻作為當前應用最廣泛的視頻編碼標準,其傳輸協議也會首選RTP標準。在設計實現H.264的實時傳輸時,H.264協議基於RTP的打包和解包定義於IETF標準-RFC6184,RTC系統需要遵循這個標準來設計打包和解包處理模塊。在通信理論中,這個過程可以被認為是基於傳輸的信道編碼。本篇技術文章帶你了解H.264在RTP中的基本格式和技術實踐。使用RTP對H.264打包和解包需要遵循IETF標準RFC6184, 我們先來了解一下H.264在RTP中的封包協議。
圖1RTP報頭
對於H.264的RTP負載格式而言,RTP報頭的格式和RFC 3550裡面的定義是一致的,不過有一些字段需要特別說明一下。對RTP時間戳所對應訪問單元的最後一個數據包來設置標記位,符合視頻中M位的正常使用格式,以允許有效的播放緩衝處理。解碼器可以使用這個位作為訪問單元最後一個數據包的早期指示,但是不能完全依賴這個屬性。根據RFC 3550設置和使用。對於單NAL單元和非交錯打包模式,序列號用於確定NAL單元的解碼順序。RTP時間戳設置為視頻內容的採樣時間戳。必須使用90 kHz時鐘頻率。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。
用於將單個NAL單元分片到多個RTP 數據包。存在兩個版本:FU-A 和 FU-B,負載類型編號分別為 28 和 29。單NAL單元模式
所有的接收端都必須支持這種模式,主要應用於兼容低時延應用中的硬件設備。只有單NAL單元數據包可以在這種模式下使用。
非交錯模式
建議接收端去支持這種模式,主要應用於低時延應用。只有單NAL單元、STAP-A和FU-A數據包可以在這種模式下使用。
交錯模式
有需求的接收端可以去支持這種模式,主要應用於非低延時應用。STAP-B、兩種MTAP、FU-A和FU-B數據包可以在這種模式下使用。
單NAL單元和非交錯模式中,NAL單元必須以NAL單元解碼順序傳輸,這兩種模式更適合低延時需求的交互系統。
交錯模式中NAL單元的傳輸順序和解碼順序可以是不一致的,導致接收端的解包過程中需要按照解碼順序重新排序,引入更多的時延,因此並不適合需要低時延的交互系統。

H.264的RTP負載報頭位於負載的第1個字節,分成三個字段:
forbidden_zero_bit。值為 0 表示NAL單元類型字節和負載不應包含位錯誤或其他語法違規。值為 1 表示NAL單元類型字節和負載可能包含位錯誤或其他語法違規。nal_ref_idc。00值和非零值的語義與H.264規範保持不變。值00表示NAL單元的內容不是用於重建圖片間預測的參考圖片,這樣的NAL單元可以被丟棄並不會導致參考圖片的不完整。值大於00表示需要對NAL單元進行解碼以保持參考圖片的完整性。因為只有單NAL單元模式和非交錯模式打包模式更適合應用於低時延交互系統中,而這兩種打包模式所涉及的只有單NAL數據包、單時間聚合包A(STAP-A)和分片單元A(FU-A)三種RTP負載,所以在這裡只對這三種負載格式做個簡單的介紹。

單NAL數據包就是將原始的NAL單元直接放置到RTP的負載中,NAL單元頭就是作為單NAL數據包的負載類型。
單時間聚合包A(STAP-A)

聚合數據包的負載中包含一個或者多個聚合單元。一個聚合包可以攜帶儘可能多的聚合單元;不過聚合數據包中的總數據量應該選擇合適大小,以便生成的IP數據包小於MTU大小。聚合數據包負載報頭中的NRI字段的值必須是所有聚合NAL單元中最大值。

STAP-A數據包中,每個聚合單元的NAL都應該是共享相同的NALU時間。負載的首字節是STAP-A負載報頭,每個聚合單元是由兩字節的NAL單元尺寸字段和原始NAL單元組成。如果STAP-A數據包中包含兩個聚合單元,負載格式如下圖:

FU-A數據包的負載包含1字節的分片單元標識(負載報頭)、1字節的分片單元報頭和分片單元負載。分片單元負載報頭中的NRI字段的值等同於被分片NAL單元的值。
起始位。當設置為 1 時,指示一個分片NAL 單元的開始。當 FU 負載不是分片NAL單元的開始片段,設置起始位為 0。結束位。當設置為 1 時,指示一個分片NAL單元的結束。當 FU負載不是分片NAL單元的最後一個片段,設置結束位為 0 。
RTC系統中的視頻處理的結構大致如下圖,RTP打包解包是視頻編解碼和傳輸之間的橋樑。圖9視頻流工作流程
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包。
在此只對三種打包模式下的解包過程做一個大致的介紹。
接收端包括一個接收緩衝器來補償傳輸延遲和抖動。接收端將傳入的數據包按照接收順序存儲到接收緩衝器中。數據包按RTP序列號的順序被解包。如果解包的數據包是單個NAL單元包,包中包含的NAL單元直接傳遞給解碼器。如果解包的數據包是 STAP-A,則包含在數據包中的NAL單元按照它們封裝在數據包中的順序被傳遞給解碼器。對於所有 FU-A包含單個NAL單元片段的數據包,解包的片段按其發送順序恢復出NAL單元,然後傳遞給解碼器。交錯模式的解包規則一般是從傳輸順序到解碼順序來重新排序NAL單元。在實時系統中應用比較少見,具體過程在此就不展開了。參考文獻1、RFC 3550 – RTP: A Transport Protocol for Real-time Application2、RFC 6184 – RTP Payload Format for H.264 Video
-- END --
進技術交流群,掃碼添加我的微信:Byte-Flow

推薦:
Android FFmpeg 實現帶濾鏡的微信小視頻錄製功能
全網最全的 Android 音視頻和 OpenGL ES 乾貨,都在這了
一文掌握 YUV 圖像的基本處理
抖音傳送帶特效是怎麼實現的?
所有你想要的圖片轉場效果,都在這了