本文是 IETF 的規范 RFC 6184 的一部分的翻譯，該規范 地址。翻譯這份文檔，主要是為了編寫一段用 RTP 傳輸 H.264 流的代碼。本想在網上找一些文章完成任務了事的，但由于個人之前音視頻編解碼相關的知識比較匱乏，網上找的文章大都沒有辦法把我的問題講的很詳細很明確，所以就找來了這份 IETF 的規范來學習。

當然翻譯這份文檔的另外的原因是，我認為關于軟件開發某些方面的知識，最為權威、準確且可靠的來源大概就是源碼、規范和官方文檔了，其它的信息源，無論是博客還是書籍，都很有可能存在著誤解和不準確的地方。為了讓自己能夠學到更加權威可靠的知識，而翻譯了這份文檔。

RFC 6184這份規范本身比較長，我實在是沒有那么多的時間與精力把這份規范全部翻譯完，于是就只是翻譯了與編寫用 RTP/RTCP 協議傳輸原始 H.264 碼流的代碼最為相關的幾個部分。

下面的內容都翻譯自 RFC 6184。

概述

這份備忘錄描述了 ITU-T Recommendation H.264 視頻編解碼和技術的相應 ISO/IEC 國際標準 14496-10 視頻編解碼的 RTP 載荷格式，不包括 Scalable Video Coding (SVC) 擴展和 Multiview Video Coding 擴展，它們的 RTP 載荷格式在其它地方定義。RTP 載荷格式允許在每個 RTP 載荷中，打包一個或多個由 H.264 視頻編碼器產生的 Network Abstraction Layer Units (NALUs)。有效載荷格式具有廣泛的適用性，它支持從簡單的低比特率對話使用，到具有交錯傳輸的因特網視頻流，到高比特率視頻點播的應用。

這份備忘錄廢棄 RFC 3984。14 小節 總結了自 RFC 3984 以來的改變。15 小節 討論了到 RFC 3984 的向后兼容性。

1. 介紹

這份備忘錄描述了稱為 ITU-T Recommendation H.264 和 ISO/IEC 國際標準 14496-10 （均被稱為高級視頻編碼 (AVC)）的視頻編碼標準的 RTP 載荷規范。在這份備忘錄中，名字 H.264 用于編解碼器和標準，但是這個備忘錄同樣適用于編碼標準的 ISO / IEC 對應物。

這份備忘錄廢棄 RFC 3984。14 小節 總結了自 RFC 3984 以來的改變。15 小節 討論了到 RFC 3984 的向后兼容性。

1.1 H.264 Codec

H.264 視頻編解碼具有廣泛的應用范圍，其覆蓋了所有形式的數字壓縮視頻，從低比特率的互聯網流應用到 HDTV 廣播到幾乎無損編碼的數字影院應用。對比當前的技術狀態，H.264 的總體性能是，據報告比特率節省 50% 或更多。比如據報告，數字衛星 TV 質量，可達到 1.5 Bbit/s，對比當前操作點 MPEG-2 視頻在大約 3.5 Mbit/s。

Codec 規范本身在概念上區分視頻編碼層 (VCL) 和網絡抽象層 (NAL)。VCL 包含 codec 的信號處理功能；諸如變換，量化和運動補償預測的機制；和環路濾波器。它遵循當今大多數視頻編解碼器的一般概念，這是基于宏塊的編碼器，一個基于宏塊的編碼器使用圖像預測，其使用具有運動補償的幀間預測和殘差信號的變換編碼。VCL 編碼器輸出 slices：包含整數個宏塊的宏塊數據的位串和 slice 頭部信息（包含 slice 中第一個宏塊的空間地址，初始的量化參數，及類似的信息）。Slice 中的宏塊以掃描的順序排列，除非使用 slice
組語法指定了不同的宏塊分配。圖像預測只被用于 slice 內。更多信息在 Introduction to the special issue on the H.264/AVC video coding standard 中提供。

NAL 編碼器把 VCL 編碼器的 slice 輸出封裝進網絡抽象層單元（NALUs），其適合于通過分組網絡傳輸，或在面向分組的多種環境下使用。H.264 的附錄 B 定義了通過面向流的網絡傳輸這樣的 NALU 的封裝過程。本備忘錄范圍內，與附錄 B 無關。

在內部，NAL 使用 NAL 單元。NAL 單元由一個字節的頭部和載荷字節串組成。頭部說明了 NAL 單元的類型，NAL 單元載荷中（潛在地）出現的位錯誤或語法違規，及對于解碼過程而言 NAL 單元的相對重要性的信息。本 RTP 載荷規范被設計為對 NAL 單元載荷中的位串無感知。

H.264 的一個主要屬性是完全解耦 slice 和圖像的傳輸時間，解碼時間，和采樣或呈現時間。H.264 中描述的解碼過程對時間無意識，而且 H.264 語法不攜帶諸如跳過的幀數（像在更早的視頻壓縮標準中常見的時間參照這樣的形式）這樣的信息。此外，還有 NAL 單位影響許多圖片，因此是本質上是沒有時間的。基于采樣和呈現時間沒有定義，或傳輸時間未知這些原因，NAL 單元的 RTP 時間戳的處理需要一些特殊的考慮。

1.2 參數集概念

H.264 的一個非常基本的設計概念是生成自包含包，使得不再需要諸如 RFC 4629 的頭部復制或 MPEG-4 視覺的頭部擴展碼 (HEC) 這樣的機制。這是通過從媒體流中去除與多個 slice 相關的信息來實現的。這個更高層的 meta 信息應該能夠從包含 slice 包的 RTP 包流中被可靠地異步地預先發送出去。（帶內發送此信息的規定也適用于不具有為了實現此目的的適當的帶外傳輸通道的應用）。更高層參數的結合稱為參數集。H.264 規范包含兩種類型的參數機：序列參數集和圖像參數集。有效的序列參數集在整個編碼的視頻序列中保持不變，而有效的圖像參數集在一個編碼的圖像內保持不變。序列和圖像參數集結構包含了諸如圖像大小，可選的所用的編碼模式，和宏塊到 slice 組的映射這樣的信息。

為了能夠修改圖像參數（比如圖像大小）而無需同步地傳輸參數集合更新給 slice 包流，編碼器和解碼器可以維護一個多于一個序列和圖像參數集合的列表。每個 slice 頭部包含一個編碼字，來指示要使用的序列和圖像參數集。

這種機制允許將參數集合的傳輸從包流的傳輸中解耦出來，并通過外部的方法（比如，作為能力交換的一部分）或通過一個控制協議（可靠的或不可靠的）傳輸它們。甚至可能不傳輸它們，但通過應用設計規范來固定。

1.3 網絡抽象層單元類型

關于 NAL 設計的教程信息可以在 “H.264/AVC over IP”，“H.26L over IP: The IP-Network Adaptation Layer” 和 “H.26L/JVT Coding Network Abstraction Layer and IP-Based Transport” 等幾份文檔中找到。

所有的 NAL 單元由單個 NAL 單元類型字節組成，其共同作為該 RTP 載荷格式的載荷頭部。NAL 單元載荷的描述如下。

NAL 單元類型字節的語法和語義在 ITU-T Recommendation H.264 中描述，但 NAL 單元類型字節的必要屬性總結如下。NAL 單元類型字節具有如下的格式：

+---------------+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|F|NRI| Type |+---------------+

NAL 單元類型字節的組件的語義，如 H.264規范所定，清晰地描述如下：

• F：1 位
  forbidden_zero_bit。H.264 規范聲明值為 1 表示語法違規。

• NRI：2 位
  nal_ref_idc。值為 00 表示 NAL 單元的內容不被用于重建圖像預測的參考圖像。這種 NAL 單元可以被丟棄而不危及參考圖像的完整性。大于 00 的值表示需要解碼該 NAL 單元來維護參考圖像的完整性。

• Type：5 位
  nal_unit_type。這個組件指定 NAL 單元載荷的類型，如 ITU-T Recommendation H.264 的表 7-1 和本備忘錄后面所定義的那樣。要參考當前所有已定義 NAL 單元類型和它們的語義，請參考 ITU-T Recommendation H.264 的 7.4.1 節。

本備忘錄引入了新的 NAL 單元類型，它們在 5.2 節 中說明。本備忘錄中定義的 NAL 單元類型被標記為 ITU-T Recommendation H.264 中的 unspecified。此外，本規范擴展了 F 和 NRI 的語義，如 5.3 節 所述。

5. 載荷格式

5.1 RTP Header 用法

RFC 3550 中描述了 RTP Header 的格式，且為了方便在圖 1 中再次展示了它。這里的載荷格式使用頭部字段的方式與那份規范相同。

當一個 NALU 被封裝進每個 RTP 包時，建議采用的 RTP 載荷格式在 5.6 小節 中描述。聚合包和分片單元的 RTP 載荷（及一些 RTP 頭部位的設置）分別在 5.7.2 和 5.8 小節描述。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|V=2|P|X| CC |M| PT | sequence number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| timestamp |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| synchronization source (SSRC) identifier |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| contributing source (CSRC) identifiers || .... |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 1. RFC 3550 的 RTP 頭部

根據本 RTP 載荷格式所需設置的 RTP 頭部信息按如下方式設置：

• Marker bit (M): 1 bit
  設置由 RTP 時間戳表示的訪問單元的最后一個數據包，符合視頻格式的 M 位的正常使用，以允許高效的播放緩沖處理。對于聚合包（STAP 和 MTAP），RTP 頭部中的 marker 位 必須被設置為，就像聚合包的最后一個 NAL 單元在其自己的 RTP 包中傳輸那樣的值。解碼器可以使用這個位作為訪問單元最后一個數據包的早期指示，但不得依賴此屬性。
  xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  訪問單元通常指一幀的圖像數據？ 對于聚合包來說，這個位的值主要依賴于聚合包中的最后一個 NALU ？
  yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
  資料性說明：攜帶多個 NAL 單元的聚合包只有一個 M 位與之關聯。這樣，如果網關將聚合包重新分包為多個包，則它無法可靠地設置那些包的 M 位。
• 載荷類型 (PT)：7 位
  對于新的數據包格式，RTP負載類型的分配不屬于本文檔的范圍，這里不再贅述。載荷類型的分配必須通過所使用的 profile 或以動態的方式來執行。
• 序列號 (SN)：16 位
  根據 RFC 3550 設置和使用。對于單獨的 NALU 和非交錯的打包模式，序列號用于決定 NALU 解碼的順序。
• 時間戳：32 位
  RTP 時間戳被設置為內容的采樣時間戳。必須使用 90 kHz 始終頻率。
  如果 NAL 單元沒有它自己的時序屬性（比如，參數集和 SEI NAL 單元），RTP 時間戳被設置為訪問單元的主編碼圖像，其中包含了 NAL 單元，的 RTP 時間戳，根據 ITU-T Recommendation H.264 的 7.4.1.2 節。
  MTAPs 的 RTP 時間戳的設置在 5.7.2 小節 定義。
  接收者應該忽略只包含一個顯示時間戳的訪問單元中包含的任何圖像時序 SEI 消息。相反，接收者應該使用 RTP 時序來同步顯示過程。
  如果一個訪問單元在圖像時序 SEI 消息中攜帶了多個顯示時間戳，則 SEI 消息中的信息應當被視為 RTP 時間戳的相對時間來處理，其中最早的事件發生在 RTP 時間戳給出的時間，其它事件隨后發生，由圖像時序 SEI 消息中攜帶的圖像時間值的差給出。
  令 tSEI1，tSEI2，…，tSEIn 為訪問單元的 SEI 消息中攜帶的顯示時間戳，其中 tSEI1 為所有這些時間戳中最早的一個。令 tmadjst() 為將 SEI 消息時間調整為一個 90 kHz 時間的函數。令 TS 為 RTP 時間戳。則與 tSEI1 關聯的事件的顯示時間為 TS。tSEIx 的事件的顯示時間為，其中 x 為 [2..n]，是 TS + tmadjst (tSEIx - tSEI1)。
  資料性說明：稱為 3：2 下拉的操作中通常需要將編碼的幀顯示為字段，其中由編碼幀組成的膠片內容使用隔行掃描顯示在顯示器上。圖片時序 SEI 消息能夠為相同的編碼圖像攜帶多個時間戳，因此 3：2 下拉過程被完全地控制。圖像定時
  SEI 消息機制是必要的，因為 RTP 時間戳只能為每個編碼幀傳送一個時間戳。

5.2 載荷結構

有效載荷格式定義三種不同的基本載荷結構。接收者可以通過 RTP 包載荷的第一個字節識別載荷結構，其共同用作 RTP 有效載荷報頭，在某些情況下，作為載荷的第一個字節。這個字節總是被構造為 NAL 單元頭。NAL 單元類型字段表示是哪種結構。可能的結構如下。

單個 NAL 單元包：載荷中包含一個單獨的 NAL 單元。NAL 頭部類型等于原始的 NAL 單元類型，比如，范圍在 1 到 23 ，包括 23。在 5.6 小節 中描述。

聚合包：用于將多個 NAL 單元聚合為一個單獨的 RTP 載荷的包類型。這個包有四個版本，單時間聚合包類型 A (STAP-A)，單時間聚合包類型 B (STAP-B)，16 位偏移多時間聚合包 (MTAP) (MTAP16)，和 24 位偏移多時間聚合包 (MTAP) (MTAP24)。為 STAP-A，STAP-B，MTAP16 和 MTAP24 分配的數字值分別為 24，25，26，和 27。在 5.7 小節 中描述。

分片單元：用于將一個單獨的 NAL 單元分割為多個 RTP 包。有兩個版本，FU-A 和 FU-B，分別由 NAL 單元類型數字 28 和 29 標識。在 5.8 小節 中描述。

資料性說明：本規范不限制在單個 NAL 單元包中封裝的 NAL 單元和分片單元的大小。在任何聚合包中封裝的 NAL 單元的最大大小為 65535 字節。

表 1 總結了當這些 NAL 單元直接被用作一個包載荷時，NAL 單元類型和對應的 RTP 包類型，以及本備忘錄中描述這些類型的章節。

表 1. NAL 單元類型和對應的包類型總結

NAL Unit Packet Packet Type Name SectionType Type-------------------------------------------------------------0 reserved -1-23 NAL unit Single NAL unit packet 5.624 STAP-A Single-time aggregation packet 5.7.125 STAP-B Single-time aggregation packet 5.7.126 MTAP16 Multi-time aggregation packet 5.7.227 MTAP24 Multi-time aggregation packet 5.7.228 FU-A Fragmentation unit 5.829 FU-B Fragmentation unit 5.830-31 reserved -

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
聚合包中的單時間聚合包中，多個 NAL 單元的存儲結構是什么樣的？NAL 單元間是否需要 NAL 單元分割序列 0x00000001？
yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy

5.3 NAL 單元頭部使用

NAL 單元頭部的結構和語義在 1.3 節 中介紹。為了方便，NAL 單元頭部的格式重新顯示如下：

+---------------+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|F|NRI| Type |+---------------+

本節根據本規范描述了 F 和 NRI 的語義。
* F：1 位
forbidden_zero_bit。值為 0，表示 NAL 單元型八位位組和有效載荷不應包含位錯誤或其他語法違規。值為 1 表示 NAL 單元類型八位位組可能包含位錯誤或其它語法違規。
MANEs 應該設置 F 位來表示在 NAL 單元中探測到位錯誤。H.264 規范要求 F 位等于 0。當設置了 F 位時，則告訴解碼器 NAL 單元類型八位位組中或載荷中可能存在位錯誤或其它語法違規。最簡單的解碼器對 F 位等于 1 的 NAL 單元的響應為，丟棄這個 NAL 單元并隱藏丟棄的 NAL 單元中丟失的數據。
* NRI：2 位
nal_ref_idc。00 和非零值的語義與 H.264 規范中的保持不變。換句話說，00 值表示 NAL 單元的內容不用于重建用于幀間預測的參考圖像。這樣 NAL 單元可以被丟棄而不危及參考圖像的完整性。大于 00 的值表示，為了維護參考圖像的完整性，需要解碼 NAL 單元。
除了上面的規范，根據本 RTP 載荷規范，NRI 的值表示由編碼器決定的相對的傳輸優先級。MANEs 可以使用這個信息，相對于不那么重要的 NAL 單元，更好地保護更重要的 NAL 單元。最高的傳輸優先級為 11，后面是 10，然后是 01；最后，00 最低。
資料性說明：在 H.264 解碼器中，以同樣的方式處理 NRI 的任何非零值。因此，當接收者傳遞 NAL 單元給解碼器時，不需要管理 NRI 值。
當 nal_unit_type 的值在 1 到 12 （包括）范圍內時，H.264 編碼器必須根據 H.264 規范（7.4.1 單元）設置 NRI 的值。特別的，H.264 規范要求，對于所有 nal_unit_type 等于 6，9，10，11，或 12 的 NAL 單元，NRI 的值應該等于 0。
對于 nal_unit_type 等于 7 或 8（分別表示序列參數集或圖像參數集）的 NAL 單元，H.264 編碼器應該把 NRI 的值設置為 11（二進制格式）。對于主編碼圖像的編碼的 slice NAL 單元，其 nal_unit_type 等于 5（表示一個編碼的 slice 屬于 IDR 圖像），H.264 編碼器應該把 NRI 的值設置為 11（二進制格式）。
其余的 nal_unit_types 到 NRI 值的映射，可以使用以下示例，并且已經被證明在某一環境中是有效的。其他映射也可能是可取的，具體取決于應用程序和使用的 H.264 配置文件。
資料性說明：數據分區在某些配置中是不可用的，比如在 Main 和 Baseline 配置中。因此，NAL 單元類型 2，3，和 4 只發生在允許數據分區的視頻比特流配置中，而不在符合 Main 或 Baseline 配置的流中。
表 2. 主編碼參考圖像的編碼 slice 和 編碼 slice 數據分區的 NRI 值示例

NAL Unit Type Content of NAL Unit NRI (binary)----------------------------------------------------------------1 non-IDR coded slice 102 Coded slice data partition A 103 Coded slice data partition B 014 Coded slice data partition C 01

資料性說明：如前面提到的，H.264 強制非參考圖像的 NRI 值為 00。
H.264 編碼器應該設置冗余的編碼參考圖像的編碼 slice 和 編碼 slice 數據分區 NAL 單元的 NRI 的值為 01 （二進制格式）。
NAL 單元類型 24 到 29（包含）的 NRI 值的定義，在本備忘錄的 5.7 和 5.8 節中給出。
nal_unit_type 在范圍 13 到 23 （包含）內的 NAL 單元的 NRI 值沒有建議值，因為這些值為 ITU-T 和 ISO/IEC 所保留。nal_unit_type 等于 0 或在范圍 30 到 31 （包含）的 NAL 單元的 NRI 值也沒有建議值，因為這些值的語義不在本備忘錄中描述。

5.4 打包模式

本備忘錄描述打包模式的三種情況：

• 單 NAL 單元模式
• 非交錯模式
• 交錯模式

單 NAL 單元模式針對符合 ITU-T Recommendation H.241 的會話系統（參考 12.1 節）。非交錯模式針對不符合 ITU-T Recommendation H.241 的會話系統。在非交錯模式中，NAL 單元以 NAL 單元解碼的順序傳輸。交錯模式針對不需要很低的端到端延遲的系統。交錯模式允許不以 NAL 單元解碼的順序傳輸。

使用的打包模式可以通過可選的 packetization-mode 媒體類型參數的值來通知。所用的打包模式管理在 RTP 載荷中允許哪些 NAL 單元類型。表 3 總結了每種打包模式允許的包載荷類型。第 6 節 更詳細地解釋了打包模式。

表 3. 每種打包模式允許的 NAL 單元類型總結 (yes = allowed, no = disallowed, ig = ignore)

Payload Packet Single NAL Non-Interleaved InterleavedType Type Unit Mode Mode Mode-------------------------------------------------------------0 reserved ig ig ig1-23 NAL unit yes yes no24 STAP-A no yes no25 STAP-B no no yes26 MTAP16 no no yes27 MTAP24 no no yes28 FU-A no yes yes29 FU-B no no yes30-31 reserved ig ig ig

一些 NAL 單元或載荷類型值（如 表 3 中的 reserved 所示）被保留，以用于未來擴展。發送者不應該發送那些類型的 NAL 單元（直接作為包載荷，作為聚合包中的聚合單元，或作為 FU 包中的分片），且接收者必須忽略它們。比如，載荷類型 1-23，具有關聯的包類型 “NAL unit”，它可以出現在 “Single NAL Unit Mode” 和 “Non-Interleaved Mode” 中，但不能出現在 “Interleaved Mode” 中。然而，NAL 單元類型 1-23 的 NAL 單元可被用于 “Interleaved Mode”，作為 STAP-B，MTAP16，和 MTAP24 包中的聚合單元，也可以作為 FU-A 和 FU-B 包中的分片單元。類似地，NAL 單元類型 1-23 的 NAL 單元也可被用于 “Non-Interleaved Mode” 作為 STAP-A 包中的聚合單元或 FU-A 包中的分片單元，除了直接被用作包載荷。

5.5 解碼順序號（DON）

在交錯打包模式下，NAL 單元的傳輸順序允許和其解碼順序不同。解碼順序號（DON）是載荷結構中表示 NAL 單元解碼順序的一個字段或一個派生變量。傳輸順序與解碼順序不同的用例的基本原理和實例，以及 DON 的使用在 13 小節 給出。

傳輸和解碼順序的耦合由可選的 sprop-interleaving-depth 媒體類型參數控制如下。當可選的 sprop-interleaving-depth 媒體類型參數的值為 0 時（明確地或默認的），NAL 單元的傳輸順序必須與 NAL 單元的解碼順序一致。當可選的 sprop-interleaving-depth 媒體類型參數的值大于 0 時：

• MTAP16 和 MTAP24 中的 NAL 單元順序不需要是 NAL 單元解碼的順序，且
• 由解包兩個連續的包中的 STAP-Bs，MTAPs，和 FUs 產生的 NAL 單元的順序不需要是 NAL 單元解碼的順序。

單 NAL 單元包的 RTP 載荷結構，一個 STAP-A 或一個 FU-A 不包含 DON。STAP-B 和 FU-B 結構包含 DON，MTAPs 的結構允許 DON 的繼承，如 5.7.2 小節 所述。

資料性說明：當 FU-A 出現在交錯模式中時，它總是跟在 FU-B 后面，后者設置它自己的 DON。

資料性說明：如果發送端想要每個包封裝一個 NAL 單元并以非解碼順序傳輸包，則可以使用 STAP-B 包類型。

在單 NAL 單元打包模式中，NAL 單元的傳輸順序，由 RTP 序列號決定，必須與它們的 NAL 單元解碼順序相同。在非交錯打包模式中，單 NAL 單元包中的 NAL 單元的傳輸順序， STAP-As，和 FU-As 必須與它們的 NAL 單元解碼順序相同。STAP 內的 NAL 單元必須以它們解碼的順序出現。這樣，首先通過 STAP 內的順序明確地提供解碼順序，然后通過 STAPs，FUs 和單 NAL 單元包之間的順序的 RTP 序列號提供。

STAP-B，MTAP，和一系列以 FU-B 開頭的分片單元中攜帶的 NAL 單元的 DON 值的信令分別在 5.7.1，5.7.2 和 5.8 節中描述。傳輸順序中第一個 NAL 單元的 DON 值可以被設置為任何值。DON 值的范圍為 0 到 65535（包含）。在達到最大值之后，DON 的值環繞到 0。

任何 STAP-B，MTAP，和一系列以 FU-B 開頭的分片單元中包含的兩個 NAL 單元的解碼順序按如下方式決定。令 DON(i) 為傳輸序列中索引為 i 的 NAL 單元的解碼順序號。函數 don_diff(m,n) 描述如下：

If DON(m) == DON(n), don_diff(m,n) = 0If (DON(m) < DON(n) and DON(n) - DON(m) < 32768),don_diff(m,n) = DON(n) - DON(m)If (DON(m) > DON(n) and DON(m) - DON(n) >= 32768),don_diff(m,n) = 65536 - DON(m) + DON(n)If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768),don_diff(m,n) = - (DON(m) + 65536 - DON(n))If (DON(m) > DON(n) and DON(m) - DON(n) < 32768),don_diff(m,n) = - (DON(m) - DON(n))

正的 don_diff(m,n) 值表示發送順序索引為 n 的 NAL 單元，其解碼順序在傳輸順序索引為 m 的 NAL單元之后。當 don_diff(m,n) 等于 0 時，兩個 NAL 單元的 NAL 單元解碼順序可以為任意順序。負的 don_diff(m,n) 值表示發送順序索引為 n 的 NAL 單元，其解碼順序在傳輸順序索引為 m 的 NAL單元之前。

DON 相關字段（DON，DONB，和 DOND；參考 5.7 節）的值必須使得由上述 DON 值決定的解碼順序符合 NAL 單元解碼順序。

如果 NAL 單元解碼順序中的兩個 NAL 單元順序切換，且新的順序與 NAL 單元解碼順序不一致，則 NAL 單元必須不具有相同的 DON。如果 NAL 單元流中兩個連續 NAL 單元的順序被交換，且新的順序依然符合 NAL 單元解碼順序，則 NAL 單元可以具有相同的 DON 值。比如，所用的視頻編碼配置允許任意的編碼 slice 順序，編碼圖片的所有編碼 slice NAL 單元允許具有相同的 DON。因此，具有相同 DON 值的 NAL 單元可以以任意順序解碼，而具有不同 DON 值的兩個 NAL 單元應該以上面描述的順序傳給解碼器。當 NAL 單元解碼順序中的兩個連續 NAL 單元具有不同的 DON 值時，解碼順序中第二個 NAL 單元的 DON 值應該是第一個的 DON 值加一。

解包過程恢復 NAL 單元解碼順序的示例在 第 7 節 中描述。

資料性說明：接收者不應該期待 NAL 單元解碼順序中兩個連續 NAL 單元的 DON 值的絕對差值等于 1，即使是在可靠傳輸中。在將 DON 值與 NAL 單元關聯時，不要求遞增 1，可能不知道所有NAL單元是否被傳送到接收器。比如，當分組轉發到的網絡中存在缺少比特率時，網關可能不轉發非參考圖像或 SEI NAL 單元的編碼 slice NAL 單元 。在另一個例子中，實況廣播由預編碼的內容（例如商業廣告）不時地中斷。預先編碼剪輯的第一幀圖像被預先發送，以確保其在接收機中容易獲得。當傳輸第一幀圖像時，在解碼順序中后面的預編碼裁剪的第一幀圖像之前，發起端不能精確地知道將編碼多少 NAL 單元。這樣，預編碼裁剪的第一幀圖像的 NAL 單元的DON 的值必須在它們被傳輸時評估，則 DON 值的 gaps 可能出現。

5.6 單 NAL 單元包

這里定義的單 NAL 單元包必須只包含一個 ITU-T Recommendation H.264 中定義的類型的 NAL 單元。這意味著聚合包或分片單元都不能用在單 NAL 單元包中。通過以
RTP 序列號順序對單 NAL 單元包進行解包組合的 NAL 單元流必須符合 NAL 單元解碼順序。單 NAL 單元包的結構如圖 2 所示。

資料性說明：NAL 單元的第一個字節共同作為 RTP 載荷頭。

0 1 2 30 1 2 3 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 RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 2. 單 NAL 單元包的 RTP 載荷格式

5.7 聚合包

聚合包是這份載荷規范的 NAL 單元聚合方案。引入該方案以反映兩個關鍵目標網絡的顯著不同的MTU大小：有線 IP 網絡（具有常常由以太網 MTU 大小限制的 MTU 大小，大約 1500 字節）和基于 IP 或非基于 IP（比如，ITU-T H.324/M）的無線通信系統，其優選傳輸單元為 254 字節或更少。為了防止兩個世界間的媒體傳輸編碼，并避免不必要的分組化開銷，引入了 NAL 單元聚合方案。

本規范定義了兩種聚合包類型：
* 單時間聚合包（STAP）：聚合具有相同 NALU 時間的 NAL 單元。定義兩種 STAPs 類型，一個沒有 DON（STAP-A），另一個包含 DON（STAP-B）。
* 多時間聚合包（MTAP）：聚合具有潛在不同 NALU 時間的 NAL 單元。定義了兩個不同的 MTAPs，其 NAL 單元的時間戳偏移的長度不同。

聚合包中攜帶的每個 NAL 單元被封裝在一個聚合單元中。請參考下文來了解四種不同的聚合單元及其特性。

聚合包的 RTP 載荷格式結構如圖 3 所示。

0 1 2 30 1 2 3 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 | |+-+-+-+-+-+-+-+-+ || || one or more aggregation units || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :...OPTIONAL RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 3. 聚合包的 RTP 載荷格式

MTAPs 和 STAPs 共享如下的打包規則：

• RTP 時間戳必須被設置為被聚合的所有 NAL 單元中 NALU 時間最早的那個。
• NAL 單元類型八位位組的類型字段必須被設置為適當的值，如表 4 所示。
• 如果被聚合的所有 NAL 單元的 F 位為 0，則 F 位必須被清除；否則，它必須被設置。
• NRI 值必須是聚合包中攜帶的所有 NAL 單元的最大值。

表 4. STAPs 和 MTAPs 的字段類型

Table 4. Type field for STAPs and MTAPsType Packet Timestamp offset DON-related fieldsfield length (DON, DONB, DOND)(in bits) present--------------------------------------------------------24 STAP-A 0 no25 STAP-B 0 yes26 MTAP16 16 yes27 MTAP24 24 yes

RTP 頭部中的 marker 位的值被設置為，就像聚合包的最后一個 NAL 單元在其自己的 RTP 包中傳輸時它的 marker 位一樣的值。

聚合包的載荷由一個或多個聚合單元組成。參考 5.7.1 和 5.7.2 節來了解四種不同類型的聚合單元。聚合包可以根據需要攜帶盡可能多的聚合單元；然而，聚合包中總的數據量明顯地必須剛好放入一個 IP 包中，選擇的大小應該讓最終的 IP 包大小小于 MTU 大小。聚合包必須不包含分片單元，如 5.8 節 所述。聚合包必須不嵌套；即，聚合包必須不包含另一個聚合包。

5.7.1 單時間聚合包（STAP）

所有要聚合的 NAL 單元共享相同的 NALU 時間時應該使用單時間聚合包（STAP）。STAP-A 載荷不包含 DON，且由至少一個單時間聚合單元組成，如圖 4 所示。STAP-B 載荷由一個 16 位無符號解碼順序號（DON）（以網絡字節序）后跟至少一個單時間聚合單元組成，如圖 5. 所示。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: |+-+-+-+-+-+-+-+-+ || || single-time aggregation units || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 4. STAP-A 載荷格式

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: decoding order number (DON) | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || || single-time aggregation units || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 5. STAP-B 的 載荷格式

DON 字段描述了 STAP-B 中傳輸順序的第一個 NAL 單元的 DON 值。對于 STAP-B 中的每個連續的 NAL 單元，其 DON 值等于 (STAP-B 中前一個 NAL 單元的 DON 值+ 1) % 65536，其中 ‘%’ 表示取模操作。

單時間聚合單元由一個表示下面的 NAL 單元的字節大小（不包含這兩個8位位組，但包含 NAL 單元的 NAL 單元類型八位位組）的 16 位無符號大小信息（以網絡字節序），后跟 NAL 單元自身，包含它的 NAL 單元類型字節組成。單時間聚合單元是 RTP 載荷內字節對齊的，但它可能不是對齊到 32 位字邊界的。圖 6 展示了單時間聚合單元的結構。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: NAL unit size | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || || NAL unit || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 6. 單時間聚合單元的結構

圖 7 展示了一個 RTP 包的示例，其包含了一個 STAP-A。STAP 包含兩個單時間聚合單元，由圖中的 1 和 2 表示。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 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 RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 7. 包含一個包含兩個單時間聚合單元的 STAP-A 的 RTP 包示例

圖 8 展示了一個 RTP 包示例，其包含一個 STAP-B。STAP 包含兩個單時間聚合單元，由圖中的 1 和 2 標識。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 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 RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 8. 包含一個包含兩個單時間聚合單元的 STAP-B 的 RTP 包示例

5.7.2 多時間聚合包（MTAPs）

MTAPs 的 NAL 單元載荷由一個 16 位的無符號解碼順序號基數（DONB）（以網絡字節序）和一個或多個多時間聚合單元組成，如圖 9 所示。DONB 必須是 MTAP 中的 NAL 單元的 NAL 單元解碼順序號中的第一個的 DON 值。

資料性說明：NAL 單元解碼順序號的第一個 NAL 單元不一定是按封裝進 MTAP 的順序來算的第一個 NAL 單元。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: decoding order number base | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || || multi-time aggregation units || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 9. MTAPs 的 NAL 單元載荷格式

本規范定義了兩個不同的多時間聚合單元。它們都由后面的 NAL 單元的 16 位無符號大小信息（以網絡字節序），一個 8 位無符號解碼順序號差值（DOND），和這個 NAL 單元的 n 位（以網絡字節序）時間戳偏移（TS offset）組成，其中 n 可以是 16 或 24。不同 MTAP 類型（MTAP16 和 MTAP24）間的選擇依賴于應用：時間戳偏移越大，MTAP 的靈活性越高，但開銷也更高。

MTAP16 和 MTAP24 的多時間聚合單元的結構分別如圖 10 和 11 所示。一個包內聚合單元的開始或結束位置不要求是 32 位字的邊界。一個多時間聚合單元中包含的 NAL 單元的 DON 等于(DONB + DOND) % 65536，其中 % 表示取模操作。本備忘錄不描述 MTAP 內的 NAL 單元如何排序，但是，在大多數情況下，應該使用 NAL 單元解碼順序。

必須將時間戳偏移字段設置為等于以下公式的值：如果 NALU 時間大于等于包的 RTP 時間戳，則時間戳偏移等于 (NAL 單元的 NALU 時間 - 包的 RTP 時間戳)。如果 NALU 時間小于包的 RTP 時間戳，則時間戳偏移等于 NALU 時間 +
(2^32 - 包的 RTP 時間戳)。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: NAL unit size | DOND | TS offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TS offset | |+-+-+-+-+-+-+-+-+ NAL unit || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 10. MTAP16 的多時間聚合單元

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+: NAL unit size | DOND | TS offset |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| TS offset | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || NAL unit || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 11. MTAP24 的多時間聚合單元

對于一個 MTAP 中 “最早的” 多時間聚合單元，其時間戳偏移必須是 0。因此，MTAP 自身的 RTP 時間戳與最早的 NALU 時間一樣。

資料性說明：如果包含在聚合單元中的 NAL 單元被封裝在單個 NAL 單元包中，則“最早”的多時間聚合單元將是 MTAP 的所有聚合單元中具有最小擴展 RTP 時間戳的那個。擴展時間戳是具有超過32位的時間戳，并且能夠對時間戳字段的環繞進行計數，因此可以在時間戳環繞時確定最小值。這個 “最早的” 聚合單元可能不是以封裝進 MTAP 中的順序來計算的第一個聚合單元。“最早的” NAL 單元不需要與 NAL 單元解碼順序的第一個 NAL 單元相同。

圖 12 展示了一個 RTP 包的示例，其包含了一個 MTAP16 類型的多時間聚合包，其中包含了兩個多時間聚合單元，由圖中的 1 和 2 標識。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 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 RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 12. 包含一個包含了兩個多時間聚合單元的類型 MTAP16 的多時間聚合包的 RTP 包

圖 13 展示了一個 RTP 包的示例，其包含了一個 MTAP24 類型的多時間聚合包，其中包含了兩個多時間聚合單元，由圖中的 1 和 2 標識。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| NALU 2 DATA |: :| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :...OPTIONAL RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 13. 包含一個包含了兩個多時間聚合單元的類型 MTAP24 的多時間聚合包的 RTP 包

5.8 分片單元（FUs）

這個載荷類型允許把一個 NAL 單元分片為多個 RTP 包。在應用層做這件事，而不是依賴于更底層的分片（比如，通過 IP）具有如下這些優勢：

• 載荷格式能夠通過 IPv4 網絡傳輸可能出現在預錄制視頻中大于 64 kbytes 的 NAL 單元，特別是高清格式。（有一個每圖片最大 slice 數的限制，其將導致每圖片 NAL 單元的限制，其可能導致大的 NAL 單元）。
• 分片機制允許將單個 NAL 單元分片，并應用 12.5 節 所述的通用的前向糾錯。

分片只是為單 NAL 單元定義的，而不是為任何聚合包定義的。NAL 單元的片由一個該 NAL 單元的連續八位位組的整數組成。NAL單元的每個八位字節必須是該NAL單元的正好一個片段的一部分。相同 NAL 單元的片段必須連續順序發送，具有升序的 RTP 序列號（被發送的相同 RTP 包流中第一個和最后一個片段間沒有其它 RTP 包）。類似地，NAL 單元必須以 RTP 序列號順序重新裝好。

當 NAL 單元被分片并在分片單元（FUs）中傳送時，它被稱為一個分片的 NAL 單元。STAPs 和 MTAPs 必須不被分片。FUs 必須不被嵌套；即，FU 必須不包含另一個 FU。

攜帶一個 FU 的 RTP 包的 RTP 時間戳被設置為被分片的 NAL 單元的 NAL 時間。

圖 14 展示了 FU-As 的 RTP 載荷格式。FU-A 由一個八位的分片單元指示器，一個八位的分片單元頭，和一個分片單元載荷構成。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| FU indicator | FU header | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || || FU payload || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :...OPTIONAL RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 14. FU-A RTP 載荷格式

圖 15 展示了 FU-Bs 的 RTP 載荷格式。FU-B 由一個八位的分片單元指示器，一個八位的分片單元頭，一個解碼順序號（DON）（以網絡字節序），和一個分片單元載荷構成。換句話說，FU-B 的結構與 FU-A 的結構相同，除了額外的 DON 字段。

0 1 2 30 1 2 3 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| FU indicator | FU header | DON |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|| || FU payload || || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| :...OPTIONAL RTP padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

圖 15. FU-B RTP 載荷格式

NAL 單元類型 FU-B 必須被用在交錯打包模式中，被分片的 NAL 單元的第一個分片單元中。NAL 單元類型 FU-B 必須不被用在其它情況下。換句話說，在交錯打包模式中，被分片的每個 NALU 單元具有一個 FU-B 作為第一個片段，后面是一個或多個 FU-A 片段。

FU 指示器字節具有如下的格式：

+---------------+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|F|NRI| Type |+---------------+

FU 指示器的類型字段的值 28 和 29 分別標識 FU-A 和 FU-B。F 位的使用如 5.3 節 所述。NRI 字段的值必須根據被分片的 NAL 單元中 NRI 字段的值設置。

FU 頭部具有如下的格式：

+---------------+|0|1|2|3|4|5|6|7|+-+-+-+-+-+-+-+-+|S|E|R| Type |+---------------+

• S：1 位
  當被設置為 1 時，Start 位表示被分片 NAL 單元的開始。當后面的 FU 載荷不是被分片 NAL 單元載荷的開始時，Start 位被設置為 0。

• E：1 位
  當被設置為 1 時，End 位表示被分片 NAL 單元的結束，比如，載荷的最后一個字節也是被分片的 NAL 單元的最后一個字節。當后面的 FU 載荷不是被分片的 NAL 單元的最后一個片段時，End 位被設置為0。

• R：1 位
  Reserved 位必須等于 0，且接收者必須忽略它。

• Type：5 位
  NAL 單元載荷類型，如 ITU-T Recommendation H.264 的表 7-1 所定義的那樣。

FU-Bs 中的 DON 的值的選擇如 5.5 節 所描述的那樣。

資料性說明：FU-Bs 中的 DON 字段允許網關把 NAL 單元分片為 FU-Bs，而不將傳入的 NAL 單元組織到 NAL 單元解碼順序。

被分片的 NAL 單元必須不在一個 FU 中傳輸：即，Start 位和 End 位必須不在相同的 FU 頭中同時設置。

FU 載荷由被分片的 NAL 單元的載荷的片段組成，使得如果連續的 FU 的分片單元載荷被順序連接，則可以重構分段的 NAL 單元的有載荷。被分片 NAL 單元的 NAL 單元類型字節沒有包含分片單元載荷中，而是被分片 NAL 單元的 NAL 單元類型字節的的信息，由分片單元的 FU 指示器字節的 F 和 NRI 字段，以及 FU 頭部的類型字段攜帶。FU 載荷可以具有任何數量的字節且可以是空的。

資料性說明：允許空的 FUs 減少幾乎無損環境中某一類發送者的延遲。這些發送者的特征是，它們在 NALU 完全生成之前打包 NALU 片段，因此，在 NALU 大小已知之前。如果不允許零長度 NALU 片段，則發送方必須在可以發送當前片段之前，生成后面的片段的至少一位數據。由于H.264的特點，有時幾個宏塊占用零個位，這是不希望的，并且可以增加延遲。然而，應該仔細權衡零長度 NALU 片段的（潛在）使用，因為用于傳輸的附加數據包，NALU 的至少一部分丟失的風險增加了。

如果分片單元丟失了，則接收者應該丟棄以傳輸順序對應于相同被分片 NAL 單元的所有后面的分片單元。

一端的接收者或 MANE 中可以聚合 NAL 單元的前面 n - 1 個片段為一個（不完整的）NAL 單元，即使那個 NAL 單元的片段 n 沒有收到。在這種情況下，NAL 單元的 forbidden_zero_bit 必須被設置為 1 以表示語法違規。

原文

總結

以上是生活随笔為你收集整理的H.264 视频的 RTP 载荷格式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。