H264的RTP負載打包的數據包格式,分組,分片
1. RTP數據包格式
RTP報文頭格式（見RFC3550 Page12）：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
版本(V):2比特此域定義了RTP的版本.此協議定義的版本是2.
填料(P):1比特若填料比特被設置,此包包含一到多個附加在末端的填充比特,不是負載的一部分.填料的最後一個字節包含可以忽略多少個填充比特.填料可能用於某些具有固定長度的加密算法,或者在底層數據單元中傳輸多個RTP包.
擴展(X):1比特 若設置擴展比特,固定頭(僅)後面跟隨一個頭擴展.
CSRC計數(CC):4比特 CSRC計數包含了跟在固定頭後面CSRC識別符的數目.
標誌(M):1比特 標誌的解釋由具體協議規定.它用來允許在比特流中標記重要的事件,如幀範圍.規定該標誌在靜音後的第一個語音包時置位.
負載類型(PT):7比特 此域定義了負載的格式,由具體應用決定其解釋.協議可以規定負載類型碼和負載格式之間一個默認的匹配.其他的負載類型碼可以通過非RTP方法動態定義.RTP發射機在任意給定時間發出一個單獨的RTP負載類型;此域不用來複用不同的媒體流.
序列號（sequence number）:16比特 每發送一個RTP數據包,序列號加一,接收機可以據此檢測包損和重建包序列.序列號的初始值是隨機的(不可預測),以使即便在源本身不加密時(有時包要通過翻譯器,它會這樣做),對加密算法泛知的普通文本攻擊也會更加困難.
時間標誌（timestamp）:32比特 時間標誌反映了RTP數據包中第一個比特的抽樣瞬間.抽樣瞬間必須由隨時間單調和線形增長的時鐘得到,以進行同步和抖動計算.時鐘的分辨率必須滿足要求的同步準確度,足以進行包到達抖動測量.時鐘頻率與作爲負載傳輸的數據格式獨立,在協議中或定義此格式的負載類型說明中靜態定義,也可以在通過非RTP方法定義的負載格式中動態說明.若RTP包週期性生成,可以使用由抽樣時鐘確定的額定抽樣瞬間,而不是讀系統時鐘.例如,對於固定速率語音,時間標誌鍾可以每個抽樣週期加1.若語音設備從輸入設備讀取覆蓋160個抽樣週期的數據塊,對於每個這樣的數據塊,時間標誌增加160,無論此塊被髮送還是被靜音壓縮. 時間標誌的起始值是隨機的,如同序列號.多個連續的RTP包可能由同樣的時間標誌,若他們在邏輯上同時產生.如屬於同一個圖象幀.若數據沒有按照抽樣的 順序發送,連續的RTP包可以包含不單調的時間標誌,如MPEG交織圖象幀.
同步源（SSRC）:32比特 SSRC域用以識別同步源.標識符被隨機生成,以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符.儘管多個源選擇同一個SSRC識別符的概率很低,所有RTP實現工具都必須準備檢測和解決衝突.若一個源改變本身的源傳輸地址,必須選擇新的SSRC識別符,以避免被當作一個環路源.
有貢獻源（CSRC）列表:0到15項,每項32比特 CSRC列表識別在此包中負載的有貢獻源.識別符的數目在CC域中給定.若有貢獻源多於15個,僅識別15個.CSRC識別符由混合器插入,用有貢獻源的SSRC識別符.例如語音包,混合產生新包的所有源的SSRC標識符都被陳列,以期在接收機處正確指示交談者.
注意：前12個字節出現在每個RTP包中,僅僅在被混合器插入時,纔出現CSRC識別符列表.
RTP報文擴展頭格式（見RFC3550 Page18）：
0 1 2 3
0 1 2 3 4 56 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| defined by profile | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header extension |
| .... |
若RTP頭中的擴展比特位X置1,則一個長度可變的頭擴展部分被加到RTP固定頭之後,.頭擴展包含16比特的長度域,指示擴展項中32比特字的個數,不包括4個字節擴展頭(因此零是有效值).RTP固定頭之後只允許有一個頭擴展.爲允許多個互操作實現獨立生成不同的頭擴展,或某種特定實現有多種不同的頭擴展,擴展項的前16比特用以識別標識符或參數.這16比特的格式由具體實現的上層協議定義.基本的RTP說明並不定義任何頭擴展本身。
2. 網絡抽象層單元 (NALU)
NALU 頭由一個字節組成, 它的語法如下:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
F: 1 個比特. forbidden_zero_bit. 在H.264 規範中規定了這一位必須爲 0.
NRI: 2 個比特.nal_ref_idc. 取 00 ~ 11, 似乎指示這個 NALU 的重要性, 如 00 的 NALU 解碼器可以丟棄它而不影響圖像的回放. 不過一般情況下不太關心這個屬性.
Type: 5 個比特.nal_unit_type.這個 NALU 單元的類型.
Type Packet Type name
---------------------------------------------------------
0 undefined
1-23 NAL unit Single NAL unit packetper H.264
24 STAP-A Single-time aggregationpacket
25 STAP-B Single-time aggregationpacket
26 MTAP16 Multi-time aggregationpacket
27 MTAP24 Multi-time aggregationpacket
28 FU-A Fragmentation unit
29 FU-B Fragmentation unit
30-31 undefined
H264 over RTP基本上分三種類型：
(1)Single NAL unit packet 也就是實際的NAL類型，可以理解爲一個包就是一幀H264數據，這個在實際中是比較多的。
(2)Aggregation packet 一包數據中含有多個H264幀。
STAP-A 包內的幀含有相同的NALU-Time，沒有DON
STAP-B 包內的幀含有相同的NALU-Time，有DON
MTAP16 包內的幀含有不同的NALU-Time，timestamp offset = 16
MTAP24 包內的幀含有不同的NALU-Time，timestamp offset = 24
封裝在Aggregation packet中的 NAL單元大小爲65535字節
(3) Fragmentation unit 一幀數據被分爲多個RTP包，這也是很常見的，特別是對於關鍵幀。現存兩個版本FU-A，FU-B。
實際應用就是要加上個H264 STREAM 的頭h264_stream_head =0x00,0x00,0x00,0x01 4字節，送去解碼即可。
3.分包規則
3.1單個NAL單元包（1-23）
對於 NALU 的長度小於MTU 大小的包,一般採用單個NAL 單元模式.一個原始的 H.264 NALU單元常由 [Start Code] [NALU Header][NALU Payload]三部分組成, 其中 Start Code 用於標示這是一個 NALU 單元的開始, 必須是"00 00 00 01" 或 "00 00 01", NALU 頭僅一個字節, 其後都是 NALU 單元內容.打包時去除 "00 00 01"或 "00 00 00 01" 的開始碼, 把其他數據封包的 RTP 包即可.
一個封裝單個NAL單元包到RTP的NAL單元流的RTP序號必須符合NAL單元的解碼順序。單個NAL單元包的結構顯示如圖。（NAL單元的第一字節和RTP荷載頭第一個字節重合）
0 1 2 3
0 1 23 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a Single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
一個包就是一幀數據。h264_stream_head + NAL_unit_type... 就可以直接送去解碼了。
3.2組合包（24-27）
3.2.1單時間組合包（24-25）
STAP應該用於當組合在一起的NAL單元共享相同的NALU時刻。STAP-A（24）荷載不包括DON，至少包含一個單時刻組合單元. STAP-B（25）荷載包含一個16位的無符號解碼順序號(DON) (網絡字節序)緊跟至少一個單時刻組合單元.
DON域指定STAP-B傳輸順序中第一個NAL單元的DON值. 對每個後續出現在STAP-B中的NAL單元，它的DON值等於(STAP-B中前一個NAL的DON值+1)%65535, %是取模運算。
單時刻組合單元有一個16位無符號大小信息（網絡字節序），它指示後續NAL單元的大小（以字節爲單位）(不包括這兩個字節,但包括NAL單元類型字節),後面緊跟NAL單元本身, 包括它的NAL單元類型字節. 單時刻聚合單元在RTP荷載中是字節對齊的,但是可以不是32位字邊界對齊。
STAP-A：一個RTP包包含一個STAP-A. STAP包含兩個單時刻組合單元：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 56 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Data |
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
STAP-B：一個RTP包包含一個STAP-B. STAP包含兩個單時刻組合單元：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-B NAL HDR | DON | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR | NALU 1 Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
看這個結構應該很清楚了，先是16位的長度，就可以得到一幀，h264_stream_head + NALU 1HDR...送去解碼。再算下一幀。需要注意的這個NALU Size 是不包括他本身這2個字節。STAP-B還要考慮DON
3.2.2多時間組合包（26-27）
多時刻時間包的NAL單元荷載有16位的無符號解碼順序號基址(DONB) (網絡字節序）以及一個或多個多時刻聚合單元，DONB 必須包含MTAP中NAL單元的第一個NAL的DON的值。
NAL解碼順序中的第一個NAL單元不必要是封裝在MTAP中的第一個NAL單元。、
兩個多時刻組合單元都有16位的無符號大小信息用於後續NAL單元(網絡字節序),一個8位無符號解碼序號差值(DOND),和n位 (網絡字節序) 時戳位移(TS 位移)用於本NAL單元,n可以是16/24. 不同MTAP類型的選擇是應用相關的時戳位移越大, MTAP的靈活性越大, 但是負擔也越大。
MTAP16/MTAP24多時刻組合單元的結構如圖示。
MTAP16：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MTAP24:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NALU unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
一個包中的組合單元的開始/結束不要求位於32位的邊界。跟隨NAL單元的DON 等於(DONB + DOND) % 65536, %代表取摸操作. 本文沒有指定MTAP內的NAL單元如何排序，但大多數情況，應該使用NAL單元解碼順序。
時戳位移域必須設置成等於以下公式的值：如果NALU-time大於等於包的RTP時戳,則時戳位移等於(NALU-time - 包的RTP時戳).如果NALU-time小於包的RTP時戳,則時戳位移等於 NALU-time + (2^32 - 包的RTP時戳).
（1）一個RTP包包含一個多時刻MTAP16類型的組合包，包括兩個多時刻組合單元
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP16 NAL HDR | decoding order number base | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 DOND | NALU 1 TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | NALU 1 DATA |
+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 SIZE | NALU 2 DOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 TS offset | NALU 2 HDR | NALU 2 DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
（2）一個RTP包包含一個多時刻MTAP24類型的組合包，包括兩個多時刻組合單元
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP24 NAL HDR | decoding order number base | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 DOND | NALU 1 TS offs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NALU 1 TS offs | NALU 1 HDR | NALU 1 DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 SIZE | NALU 2 DOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 TS offset | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU2 DATA |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
看這個結構應該很清楚了，先是16位的DONB，然後是16位的長度，8位的DOND，根據DONB計算出DON，去掉時間戳（16-24bits），就可以得到一幀，h264_stream_head + NALU 1 HDR...。得到該RTP包中所有的NAL單元后，根據DON確定解碼順序。需要注意的這個NALU Size 是不包括他本身這2個字節。
3.2.2分片單元 (FUs)（28-29）
當NALU 的長度超過 MTU 時, 就必須對 NALU 單元進行分片封包，NAL單元的一個分片由整數個連續NAL單元字節組成. 每個NAL單元字節必須正好是該NAL單元一個分片的一部分。相同NAL單元的分片必須使用遞增的RTP序號連續順序發送(第一和最後分片之間沒有其他的RTP包）。相似, NAL單元必須按照RTP順序號的順序裝配。
當一個NAL單元被分片運送在分片單元(FUs)中時，被引用爲分片NAL單元。STAPs,MTAP不可以被分片。 FUs不可以嵌套，即,一個FU 不可以包含另一個FU. 運送FU的RTP時戳被設置成分片NAL單元的NALU時刻.
FU-A的RTP荷載格式。FU-A由1字節的分片單元指示，1字節的分片單元頭，和分片單元荷載組成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FU-B的RTP荷載格式. FU-B由1字節的分片單元指示，1字節的分片單元頭，和解碼順序號（DON）以及分片單元荷載組成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | DON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTPpadding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
對於分片NAL單元的第一個分片如果用於交錯打包方式，則必須使用NAL單元類型FU-B。NAL單元類型FU-BMUST不可以用於其他情況。換句話, 在交錯打包方式,每個被分片的NALU，FU-B作爲第一個分片,後面跟隨的是一個或多個FU-A分片.
FU指示字節有以下格式：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
FU指示字節的類型域的28，29表示FU-A和FU-B。NRI域的值必須根據分片NAL單元的NRI域的值設置。
FU頭的格式如下：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
S：1 表示是一幀的開始包
E：1 表示是一幀的結束包，和RTP marker位一致
R：0 必須
這裏要注意一下，組包時，NAL unit type 必須自己拼裝FU Indicator前四字節+ FU Header後四字節。也就是type字段是 FU header裏的nal_unit_type= (fu_indicator & 0xe0) | (fu_header & 0x1f)等幀收齊了，加上H264_streaming_head+ nal_unit_type....送去解碼。