轉自：https://blog.csdn.net/smilestone_322/article/details/17892967
英文版：http://www.faqs.org/rfcs/rfc3984.html
H.264視訊的RTP荷載格式
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes an RTP Payload format for the ITU-T
Recommendation H.264 video codec and the technically identical
ISO/IEC International Standard 14496-10 video codec. The RTP payload
format allows for packetization of one or more Network Abstraction
Layer Units (NALUs), produced by an H.264 video encoder, in each RTP
payload. The payload format has wide applicability, as it supports
applications from simple low bit-rate conversational usage, to
Internet video streaming with interleaved transmission, to high bit-
rate video-on-demand.
目錄
1. 介紹 ........................................ 3
1.1. H.264 Codec ............................... 3
1.2. 參數集概念 ........................... 4
1.3. 網絡抽象層單元類型............................ 5
2. 約定 ......................................... 6
3. 範圍 ............................................... 6
4. 定義和縮寫 ................................. 6
4.1. 定義 ..................................... 6
5. RTP 荷載格式 ..................................... 8
5.1. RTP 頭的使用.................................. 8
5.2. RTP荷載格式的公共使用 .............. 11
5.3. NAL單言位元組的用法 ............................ 12
5.4. 打包方式 .................................... 14
5.5. 解碼順序号 (DON)............................. 15
5.6. 單個NAL單元包................................. 18
5.7. 複合包 ................................. 18
5.8. 分片單元 (FUs) ............................... 27
6. 分包規則 ................................... 31
6.1. 公共分包規則 .............................. 31
6.2. 單個NAL單元方式............................... 32
6.3. 非交錯方式 ............................... 32
6.4. 交錯方式 ............................... 33
7. 打包過程 (資訊) ........................ 33
7.1. 單NAL單元和非交錯方式 ................ 33
7.2. 交錯方式 ............................... 34
7.3. 附加的打包原則 .................. 36
8. 荷載格式參數 ................................... 37
8.1. MIME 注冊 .................................... 37
8.2. SDP 參數...................................... 52
8.3. 例子.......................................... 58
8.4. 參數集考慮 ............................ 60
9. 安全考慮 ....................................... 62
10. 擁塞控制............................................ 63
11. IANA考慮 ........................................... 64
12. 資訊化附錄: 應用例子 .................... 65
12.1. 根據ITU-T H.241 附錄A的視訊電話............... 65
12.2. 沒有分片資料分區，沒有NAL單元聚合的視訊電話... 65
12.3. 使用NAL單元聚合交錯打包的視訊電話............. 66
12.4. 使用資料分區的視訊電話 .................. 66
12.5. 使用FU和向前糾錯的視訊電話和流................ 67
12.6. 低位率流 .................................. 69
12.7. 視訊流中健壯的包排程 ............. 70
13. 資訊化附錄:解碼順序号的原理 ..... 71
13.1. 介紹.......................................... 71
13.2. 多圖像片斷交錯的例子 ............. 71
13.3. 健壯包排程的例子 .................... 73
13.4. 備援編碼片斷健壯傳輸排程的例子................ 77
13.5. 其它設計可能的提醒 ................... 77
14. 緻謝 .............................................. 78
15. 參考 ............................................... 78
15.1. 标準化參考.................................... 78
15.2. 參考性的參考.................................. 79
作者位址................................................ 81
完全版權聲明 .......................................... 83
1. 介紹
1.1. H.264 Codec
本文指定一個RTP荷載規範用于ITU-T H.264 視訊編碼标準（ISO/IEC 14496 Part 10 [2]）(兩個都稱為進階視訊編碼AVC). H.264建議在2005年5月被ITU-T采納, 草案規範對于公共回顧可用[8]. 本文H.264 縮寫用于codec和标準,但是本文等價于采納 ISO/IEC相似的編碼标準.
H.264 視訊 codec又非常廣泛的應用覆寫所有格式的數字壓縮視訊格式,從低帶寬的Internet流應用到HDTV廣播和數字影院應用。和目前的技術狀态比較, 整個H.264的性能被報告節省50%的位率。例如，數字衛星TV品質被報告在1.5 Mbit/s,就可以實作，而目前的MPEG 2的操作點在大約3.5 Mbit/s [9].
該codec規範自己概念上區分[1]視訊編碼層(VCL)和網絡抽象層(NAL). VCL包含Codec的信令處理功能;以及如轉換，量化，運動補償預測機制；以及循環過濾器。他遵從今天大多數視訊codec的一般概念,基于宏快的編碼器，使用基于運動補償的圖像間預測和殘餘信号的轉換編碼。VCL編碼器輸出片斷: 一個位串包含整數數目宏快的宏塊資料，以及片斷頭資訊(包含片斷内第一個宏快的空間位址, 初始量化參數以及相似資訊). 片斷内的宏快按照掃描順序安排，除非指定一個不同的宏塊配置設定,通過使用被稱為靈活宏塊順序文法Flexible Macroblock Ordering syntax.圖像内的預測隻用于一個片斷内部。更多資訊在[9]提供.
(NAL)編碼器封裝VCL編碼器輸出的片斷到網絡抽象層單元(NAL units),它适合于通過包網路傳輸或用于面向包的多路複用環境。H.264的附錄B定義封裝過程傳輸這樣的NAL單元通過面向位元組流的網絡。本文檔範圍, 附錄 B 不相關的。
NAL使用NAL單元. 一個NAL單元由一位元組的頭和荷載位元組串組成。 頭訓示NAL單元的類型, 是否有位錯誤或文法沖突在NAL單元荷載中,以及對于解碼過程該NAL單元相對重要性的資訊。本RTP荷載規範被設計成不了解NAL單元荷載的位串。
H.264的一個主要特性是傳輸時間，解碼時間，圖像以及片斷采樣示範時間完全的解耦合。H.264中指定的解碼過程是不知道時間的, 并且H.264文法沒有運送如跳過幀數目(在早期視訊壓縮标準，時間參考格式中是普遍的)資訊.同時，有的NAL單元影響許多圖像，是以固有的是無時間性的。因為這樣的原因，處理RTP時戳要求對于采樣或示範時間沒有定義或者在傳輸時間不知道的NAL單元進行一些特殊的考慮。
1.2. 參數集概念
H.264一個非常基本的設計概念是産生自包含包, 使得如RFC2429的頭重複或MPEG-4的頭擴充編碼（HEC）[11]機制變得不必要。這是通過從媒體流解耦合不止一個片斷的相對資訊來實作的。高層meta資訊應該可靠/異步的發送,事先不和包含片斷包的RTP包流發送。(對于沒有通過帶外傳輸信道發送本資訊的應用，通過帶内發送本資訊也提供了手段)。高層參數的組合被稱為參數集。H.264規範包括兩類參數集:順序參數集和圖像參數集。一個活動順序參數集在一個編碼視訊序列中保持不變,一個活動圖像參數集在一個編碼圖像裡保持不變。順序和圖像參數集結構包含如圖像大小，采用的可選的編碼模式，宏塊到片斷組映射等資訊。
為了改變圖像參數(如圖像大小)而不用同步傳送參數集修改給片斷包流,編碼器和解碼器可以維護不止一個順序和圖像參數集的清單。每個片斷頭包含一個碼字訓示使用的順序和圖像參數集。
本機制允許從包流中解耦合參數集的傳輸,通過外部手段傳輸他們(即,作為能力交換的副作用),或通過一個(可靠或不可靠)控制協定他們從沒有被傳送但是被應用設計規範修複甚至是可能的。
1.3. 網絡抽象層單元類型
可以在[12], [13],[14]中找到關于NAL設計的學習資訊.
所有NAL單元有一個單個NAL單元類型位元組,他也作為本RTP荷載格式的荷載頭.後面立即跟随NAL單元的荷載。
NAL單元類型位元組的文法語義在[1]中指定,但是NAL單元類型的基本屬性總結如下。NAL單元類型位元組格式如下：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
NAL單元類型位元組部件的語義在H.264規範中制定, 簡要描述如下.
F: 1 bit
forbidden_zero_bit. H.264規範聲明設定為1訓示文法違例。
NRI: 2 bits
nal_ref_idc. 00值訓示NAL單元的不用于幀間圖像預測的重構參考圖像。這樣的NAL單元可以被丢棄而不用冒參考圖像完整性的風險。大于0的值訓示NAL單元的解碼要求維護參考圖像的完整性。
Type: 5 bits
nal_unit_type. 本部件指定NAL單元荷載類型定義在[1]的表 7-1中和本文後面。為了參考所有目前定義的NAL單元類型和他們的語義，參考 [1]的7.4.1.
本文引入新的NAL單元類型，在5.2示範. 定義在本文的NAL單元類型在[1]中标記為未指定。但是,本規範擴充了F和 NRI的語義，象5.3描述的那樣.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [3].
This specification uses the notion of setting and clearing a bit when
bit fields are handled. Setting a bit is the same as assigning that
bit the value of 1 (On). Clearing a bit is the same as assigning
that bit the value of 0 (Off).
3. Scope
This payload specification can only be used to carry the "naked"
H.264 NAL unit stream over RTP, and not the bitstream format
discussed in Annex B of H.264. Likely, the first applications of
this specification will be in the conversational multimedia field,
video telephony or video conferencing, but the payload format also
covers other applications, such as Internet streaming and TV over IP.
4. 定義和縮寫
4.1. 定義
本文檔使用[1]中的定義. 為了友善以下定義在[1]中的詞語總結出來：
access unit: 一組NAL單元總包括一個主要的編碼圖像。除了主要的編碼圖像,一個 access unit也可以包含一個或多個備援編碼圖像或其他的不包括片斷或編碼圖像片斷分區資料的NAL單元 。access unit的解碼總是導緻一個解碼的圖像。
coded video sequence: A sequence of access units that consists, in
decoding order, of an instantaneous decoding refresh (IDR) access
unit followed by zero or more non-IDR access units including all
subsequent access units up to but not including any subsequent IDR
access unit.
IDR access unit: An access unit in which the primary coded picture
is an IDR picture.
IDR picture: A coded picture containing only slices with I or SI
slice types that causes a "reset" in the decoding process. After
the decoding of an IDR picture, all following coded pictures in
decoding order can be decoded without inter prediction from any
picture decoded prior to the IDR picture.
primary coded picture: The coded representation of a picture to be
used by the decoding process for a bitstream conforming to H.264.
The primary coded picture contains all macroblocks of the picture.
redundant coded picture: A coded representation of a picture or a
part of a picture. The content of a redundant coded picture shall
not be used by the decoding process for a bitstream conforming to
H.264. The content of a redundant coded picture may be used by
the decoding process for a bitstream that contains errors or
losses.
VCL NAL unit: A collective term used to refer to coded slice and
coded data partition NAL units.
In addition, the following definitions apply:
decoding order number (DON): A field in the payload structure, or
a derived variable indicating NAL unit decoding order. Values of
DON are in the range of 0 to 65535, inclusive. After reaching the
maximum value, the value of DON wraps around to 0.
NAL unit decoding order: A NAL unit order that conforms to the
constraints on NAL unit order given in section 7.4.1.2 in [1].
transmission order: The order of packets in ascending RTP sequence
number order (in modulo arithmetic). Within an aggregation
packet, the NAL unit transmission order is the same as the order
of appearance of NAL units in the packet.
media aware network element (MANE): A network element, such as a
middlebox or application layer gateway that is capable of parsing
certain aspects of the RTP payload headers or the RTP payload and
reacting to the contents.
Informative note: The concept of a MANE goes beyond normal
routers or gateways in that a MANE has to be aware of the
signaling (e.g., to learn about the payload type mappings of
the media streams), and in that it has to be trusted when
working with SRTP. The advantage of using MANEs is that they
allow packets to be dropped according to the needs of the media
coding. For example, if a MANE has to drop packets due to
congestion on a certain link, it can identify those packets
whose dropping has the smallest negative impact on the user
experience and remove them in order to remove the congestion
and/or keep the delay low.
縮寫
DON: 解碼順序号
DONB: 解碼順序基
DOND: 解碼順序号差
FEC: 向前糾錯
FU: 分片單元
IDR: 瞬間解碼重新整理
IEC: 國際電子委員會
ISO: 國際标準化組織
ITU-T: 國際電聯-通信标準部門
MANE: 美提感覺網絡元素
MTAP: 多時刻聚合包
MTAP16: 16位時戳位移的MTAP
MTAP24: 24位時戳位移的MTAP
NAL: 網絡抽象層
NALU: NAL單元
SEI: 補充增強資訊
STAP: 單時刻聚合包
STAP-A: STAP類型A
STAP-B: STAP類型B
TS: 時戳
VCL: 視訊編碼層
5. RTP 荷載格式
5.1. RTP頭的使用
RTP 頭的格式在RFC 3550 [4]中指定為了友善在圖1又顯示出來。本載荷格式使用頭中域的方式和該規範一緻。
當一個 NAL 單元封裝在每個RTP包中, 推薦的RTP荷載格式在5.6節指定。對于聚合包/分片包的RTP荷載 (以及一些rtp頭域的設定）在5.7和5.8節指定。
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 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. RTP 頭。
根據RTP荷載格式設定的RTP頭資訊按如下設定：
Marker bit (M): 1 bit
對于RTP時戳訓示的通路單元的最後一個包本位進行設定,符合視訊格式M位的正常使用,以允許有效緩沖處理布局。對于聚合包 (STAP，MTAP),RTP頭中的M位必須設定成最後一個NAL單元如果被傳送在單個RTP包中時M位對應的值。解碼器可以使用本位作為早期最後一個包的訓示,但是不可以依賴本屬性。
注：運送多個NAL單元的聚合包隻有一個M位相關聯。是以,如果一個網關重新打包一個聚合包為幾個包，它可能不會可靠設定這些包的M位。
Payload type (PT): 7 bits
本新的包格式的荷載類型的值超過本文檔的範圍，在此不指明。荷載類型的指派或者通過profile或者通過動态方式。
Sequence number (SN): 16 bits
根據RFC 3550設定使用. 對于單個NALU與非交錯打包方式, 序号用于對定NALU解碼順序。
Timestamp: 32 bits
RTP時戳設定為内容的采樣時戳。必須使用90 kHz 時鐘頻率。
如果NAL單元沒有他自己的時間屬性(即,parameter set and SEI NAL units),RTP時戳設定成通路單元主編碼圖像的RTP時戳,根據[1]的7.4.1.2節。
MTAPs時戳的設定在5.7.2定義.
接收者應該忽略包含在通路單元（隻有一個顯示時戳）的任何圖像時間SEI消息，相反，接收者應該使用RTP時戳同步顯示過程。
RTP發送者你不應該傳送圖像時間 SEI消息對于不支援被顯示成多個場的圖像。
如果一個通路單元有多于一個顯示時戳在圖像時間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時戳中隻可以 運送個時戳。
注釋:因為H.264允許解碼順序可以和顯示順序不同, RTP時戳的值針對于RTP序 号可以不是單調非減的。而且RTCP報告中的抖動區間值可以不是網絡性能問題的訓示, as the calculation rules for interarrival jitter (section 6.4.1 of RFC 3550) assume that the RTP timestamp of a packet is directly proportional to its transmission time.
5.2. RTP 荷載格式的公共結構
荷載格式定義三個不同的基本荷載結構。一個接收者可以識别荷載結構通過RTP荷載的第一個位元組, 他也共享為RTP荷載頭，某些情況下,作為荷載的第一個位元組。本位元組總是結構化為NAL單元頭. NAL單元類型訓示目前使用那個結構. 可能的結構如下：
單個NAL單元包: 荷載中隻包含一個NAL單元。NAL頭類型域等于原始 NAL單元類型,即在範圍1到23之間. 5.6指定
聚合包: 本類型用于聚合多個NAL單元到單個RTP荷載中。本包有四種版本,單時間聚合包類型A (STAP-A), 單時間聚合包類型B (STAP-B), 多時間聚合包類型(MTAP)16位位移(MTAP16), 多時間聚合包類型(MTAP)24位位移(MTAP24)。賦予STAP-A, STAP-B, MTAP16, MTAP24的NAL單元類型号分别是 24, 25, 26, 27。見5.7.
分片單元: 用于分片單個NAL單元到多個RTP包。現存兩個版本FU-A，FU-B,用NAL單元類型 28，29辨別。見5.8.
Table 1. 單元類型以及荷載結構總結
Type Packet Type name Section
---------------------------------------------------------
0 undefined -
1-23 NAL unit Single NAL unit packet per H.264 5.6
24 STAP-A Single-time aggregation packet 5.7.1
25 STAP-B Single-time aggregation packet 5.7.1
26 MTAP16 Multi-time aggregation packet 5.7.2
27 MTAP24 Multi-time aggregation packet 5.7.2
28 FU-A Fragmentation unit 5.8
29 FU-B Fragmentation unit 5.8
30-31 undefined -
注釋: 本規範沒有限制封裝在單個NAL單元包和分片單元的大小。封裝在聚合包中的 NAL單元大小為65535位元組。
5.3. NAL單元位元組使用
NAL單元位元組的結構語義在1.3節介紹。為了友善,NAL單元類型位元組的格式在下面列出：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
本部分根據本規範指定F和NRI的語義。
F: 1 bit
forbidden_zero_bit. A value of 0 indicates that the NAL unit type
octet and payload should not contain bit errors or other syntax
violations. A value of 1 indicates that the NAL unit type octet
and payload may contain bit errors or other syntax violations.
MANEs SHOULD set the F bit to indicate detected bit errors in the
NAL unit. The H.264 specification requires that the F bit is
equal to 0. When the F bit is set, the decoder is advised that
bit errors or any other syntax violations may be present in the
payload or in the NAL unit type octet. The simplest decoder
reaction to a NAL unit in which the F bit is equal to 1 is to
discard such a NAL unit and to conceal the lost data in the
discarded NAL unit.
NRI: 2 bits
nal_ref_idc. 0值和非零值的語義與H.264規範保持一緻。換句話,00值訓示NAL單元的内容不用于重建影響圖像的幀間圖像預測。這樣的NAL單元可以被丢棄而不用冒影響圖像完整性的風險。大于00的值訓示NAL單元的解碼要求維護引用圖像的完整性。
除了上面指定的外, 根據本RTP荷載規範, 大于00的NRI值訓示相對傳輸優先級, 象編碼器決定的一樣。 MANE可以使用本資訊保護更重要的NAL單元。最高的傳輸優先級是11, 依次是 10, 01;00 最低。
注釋: 任何非零的NRI在H.264 解碼器的處理是相同的。是以,接收者在傳送NAL單元給解碼器時不必操作NRI的值。
H.264編碼器必須根據H.264規範設定NRI值(subclause 7.4.1)當nal_unit_type 範圍的是1到12. 特别是, H.264規範要求對于nal_unit_type為6，9，10，11，12的NAL單元的NRI的值應該為0。
對于nal_unit_type等于7，8 (訓示順序參數集或圖像參數集)的NAL單元,H.264編碼器應該設定NRI為11 (二進制格式）對于nal_unit_type等于5的主編碼圖像的編碼片NAL單元(訓示編碼片屬于一個IDR圖像), H.264編碼器應設定NRI為11。
對于映射其他的nal_unit_types到NRI值,以下的例子可以使用并且在某些環境有效[13].其它的映射也可以，依賴于應用以及使用的H.264/AVC Annex A profile.
注釋: 在某些profile中資料分區不可用，即 , 在Main或Baseline profiles. 是以, nal單元類型2, 3,4 隻出現在視訊流符合資料分區被允許的profile情況下，不會出現在符合MAIN/Baseline profile的流中。
Table 2. 編碼片和主編碼參考圖像資料分區的編碼片的NRI值的例子
NAL Unit Type Content of NAL unit NRI (binary)
----------------------------------------------------------------
1 non-IDR coded slice 10
2 Coded slice data partition A 10
3 Coded slice data partition B 01
4 Coded slice data partition C 01
注釋: 像以前提起的, 非參考圖像NRI值是00.
H.264編碼器應該設定備援編碼參考圖像的編碼片和編碼片分區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. 打包方式
本文指定三種打包方式：
o 單NAL單元方式
o 非交錯方式
o 交錯方式
單NAL單元方式目标是正常的系統，該系統相容ITU-T H.241 [15] (12.1). 非交錯方式目标是正常系統，可以不符合ITU-T H.241建議.在非交錯方式, NAL單元按照NAL單元解碼順序傳送。交錯模式目标是不要求非常低端到端延遲的系統。
交錯方式允許傳送NAL單元不按照NAL單元解碼順序。
使用的打包方式可以通過OPTIONAL packetization-mode MIME參數的值指定或外部手段。使用的打包方式控制那個NAL單元類型在RTP荷載中允許。表3 總結對每個打包方式允許的NAL單元類型。有些NAL單元類型值(在表3中訓示為沒有定義）保留為将來擴充. 那些類型的NAL單元不應該被發送者發送，接受者必須忽略他們。例如：1-23, 相關的包類型"NAL unit",允許出現在 "單NAL單元方式" 和"非交錯方式", 不允許在"交錯方式".
打包方式在第六節更詳細解釋。
表 3. 每個打包方式允許的NAL單元類型總結(yes = 允許, no = 不允許, ig = 忽略)
Type Packet Single NAL Non-Interleaved Interleaved
Unit Mode Mode Mode
-------------------------------------------------------------
0 undefined ig ig ig
1-23 NAL unit yes yes no
24 STAP-A no yes no
25 STAP-B no no yes
26 MTAP16 no no yes
27 MTAP24 no no yes
28 FU-A no yes yes
29 FU-B no no yes
30-31 undefined ig ig ig
5.5. 解碼順序号(DON)
在交錯打包方式, NAL單元的傳輸順序允許和NAL單元的解碼順序不同。解碼順序号(DON)是荷載結構中的一個域或一個獲得變量訓示NAL單元的解碼順序。不按解碼順序傳輸的例子和原理以及DON的使用見13節。
傳輸和解碼順序的耦合由OPTIONAL sprop-interleaving-depth MIME參數控制，見下。當OPTIONAL sprop-interleaving-depth MIME 參數的值等于0 (明确或預設) 或者外部手段不允許傳輸NAL單元順序不同于他們的解碼順序, NAL單元的傳輸順序必須和他們的解碼順序一緻。當OPTIONAL sprop-interleaving-depth MIME參數的值大于0或者傳輸NAL單元與解碼序号不一緻通過外部手段被允許時,
o 在MTAP16/MTAP24中的NAL單元順序不要求是NAL單元的解碼順序
o 在兩個連續包中的STAP-B, MTAP,FU解嵌套産生的NAL單元序号不要求是NAL單元解碼序号。
用于單NAL單元包 STAP-A和FU-A的RTP荷載結構不包含DON. STAP-B，FU-B結構包含DON, MTAP結構允許推導DON象5.7.2指定的一樣.
注釋:檔FU-A出現在交錯方式,後邊總跟一個FU-B, 他設定自己的DON.
注釋: 一個傳輸器想封裝單個NAL單元每個包并且傳輸包不按照他們的解碼順序，可以使用STAP-B包類型。
在單個NAL單元打包方式, NAL單元的傳輸順序,由RTP順序号确定, 必須和他們的NAL單元解碼序号一緻。在非交錯打包方式中, 在單NAL單元包,STAP-A,FU-A中NAL單元的傳輸順序必須和他們的NAL單元解碼順序一緻.在一個STAP中的NAL單元必須按照他們的 NAL單元解碼順序出現。是以，解碼順序首先由STAP隐含順序提供, 第二通過RTP序号提供（對于STAPs, FUs, 單個NAL unit包之間的）。
對于運送在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傳輸順序的解碼順序号. 函數don_diff(m,n)定義如下：
If DON(m) == DON(n), don_diff(m,n) = 0
If (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, and DOND; 5.7)必須使得上面指定的DON的值确定的解碼器順序号符合NAL單元解碼序号。如果兩個NAL解碼單元順序的NAL單元交換，新的順序号不符合NAL 單元解碼順序，NAL單元不可以有相同的DON值. 如果在一個NAL單元流中兩個連續NAL單元的序号交換并且新的序号仍符合NAL單元解碼順序号，NAL解碼單元可以有相同的DON值。例如：當使用的視訊編碼profile允許任意分片順序, 一個編碼圖像的所有編碼片的NAL單元可以有相同的DON值。是以，相同DON值的 NAL單元可以按照任何順序解碼,有不同DON值的NAL單元應該按照上面指定的順序傳遞給解碼器。當兩個連續的NAL單元解碼順序的NAL單元有不同的 DON值, 第二個NAL單元的DON應該是第一個NAL單元的DON值加1。
解包過程恢複NAL單元解碼的例子在第7部分給出。
注: 接收者不應該預測兩個解碼順序号連續的NAL的DON值的絕對差等于1,甚至在沒有錯誤的傳輸過程。沒有要求增加1,就像關聯DON的值到NAL單元的時間一樣, 不可能知道所有NAL單元是否分發給接收者。例如：一個網關可以不轉發非引用的編碼的NAL片或SEI NAL 單元，當需要轉發的網絡帶寬不足時。；另外的例子：現場廣播被預先編碼的内容不時的打斷，如廣告。預先編碼的第一個内幀圖像事先傳送使得接收端準備可用。當傳送第一個内幀時，發送者不能精确知道在解碼順序後的第一個内幀前，有多少NAL單元被編碼。是以, 預編碼片斷的第一個内幀的DON值不得不估算，當他們傳送時,是以DON中可能産生空隙。
5.6. 單個NAL單元包
定義在此的單個NAL單元包必須隻包含一個類型定義在[1]中的NAL單元。這意味聚合包和分片單元不可以用在單個NAL單元包中。一個封裝單個NAL單元包到RTP的NAL單元流的RTP序号必須符合NAL單元的解碼順序。單個NAL單元包的結構顯示在圖2。
注: NAL單元的第一位元組和RTP荷載頭第一個位元組重合。
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 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a Single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. 單個NAL單元包的RTP荷載格式。
5.7. 聚合包
聚合包是本荷載規範的NAL單元聚合安排。本計劃的引入是反映兩個主要目标網絡差異巨大的MTU:有線IP網絡(MTU 通常被以太網的MTU限制; 大約1500 位元組), 基于無線通信系統的IP或非IP (ITU-T H.324/M)網絡，它的優先傳輸最大單元是254或更少。為了阻止連個世界媒體的轉換以及避免不必要的打包負擔，引入聚合單元安排。
本規範定義了兩類聚合包:
o 單時間聚合包(STAP): 聚合相同NALU時間的NAL單元。兩類STAP被定義, 一類不包括DON (STAP-A)另一類包括DON (STAP-B).
o 多時間聚合包(MTAP): 聚合具有差異NALU時間的NAL單元. 兩個MTAP被定義, 差别在 NAL單元時戳位移長度不同。
詞語NALU-時間被定義成如果NAL單元被傳輸他自己的RTP包中時RTP的時戳。
運送在一個聚合包中的每個NAL單元封裝在一個聚合單元中。參見下面四個不同聚合單元和他們的特性。
聚合包的RTP荷載格式的結構見圖3。
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 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的類型域
Type Packet 時戳位移域長度（位） DON相關的域(DON, DONB, DOND）是否存在
--------------------------------------------------------
24 STAP-A 0 no
25 STAP-B 0 yes
26 MTAP16 16 yes
27 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-A荷載不包括DON，至少包含一個單時刻聚合單元見圖4. STAP-B荷載包含一個16位的無符号解碼順序号(DON) (網絡位元組序)緊跟至少一個單時刻聚合單元。見圖5.
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 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: |
+-+-+-+-+-+-+-+-+ |
| |
| single-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 4. STAP-A荷載格式
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 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)e535, %是取模運算。
單時刻聚合單元有一個16位無符号大小資訊（網絡位元組序），他訓示後續NAL單元的大小（以位元組為機關）(不包括這兩個位元組,但包括NAL單元類型位元組),後面緊跟NAL單元本身, 包括它的NAL單元類型位元組. 單時刻聚合單元在RTP荷載中是位元組對齊的,單可以不是32位字邊界對齊。圖6 表示單時刻聚合單元的結構。
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 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 6. 單時刻聚合單元的結構
圖 7表示一個例子--一個RTP包包含一個STAP-A. STAP包含兩個單時刻聚合單元, 在圖中用1，2标記。
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 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. RTP包包含一個STAP-A. STAP包含兩個單時刻聚合單元
圖 8 表示一個RTP包包含一個STAP-B. STAP包含兩個單時刻聚合單元, 用 1，2标記。
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 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. 一個RTP包包含一個STAP-B. STAP包含兩個單時刻聚合單元例子
5.7.2. 多時刻聚合包(MTAPs)
多時刻聚合包的NAL單元荷載有16位的無符号解碼順序号基址(DONB) (網絡位元組序）以及一個或多個多時刻聚合單元，如圖9表示。DONB 必須包含MTAP中NAL單元的第一個NAL的DON的值。
注釋:NAL解碼順序中的第一個NAL單元不必要是封裝在MTAP中的第一個NAL單元。
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 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: decoding order number base | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| multi-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 9. MTAP的NAL單元荷載格式
本規範定義兩個不同多時刻聚合單元。兩個都有16位的無符号大小資訊用于後續NAL單元(網絡位元組序),一個8位無符号解碼序号內插補點(DOND), 和n位 (網絡位元組序) 時戳位移(TS 位移)用于本NAL單元,n可以是16/24. 不同MTAP類型的選擇是應用相關的(MTAP16/MTAP24): 時戳位移越大, MTAP的靈活性越大, 但是負擔也越大。
MTAP16/MTAP24多時刻聚合單元的結構分别在圖 10 ，11表示。一個包中的聚合單元的開始/結束不要求位于32位的邊界。跟随NAL單元的DON 等于(DONB + DOND) % 65536, %代表取摸操作. 本文沒有指定MTAP内的NAL單元如何排序，但大多數情況，應該使用NAL單元解碼順序。
時戳位移域必須設定成等于以下公式的值：如果NALU-time大于等于包的RTP時戳,則時戳位移等于(NALU-time - 包的RTP時戳).
如果NALU-time小于包的RTP時戳,則時戳位移等于 NALU-time + (2^32 - 包的RTP時戳).
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 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 10. MTAP16多時刻聚合單元
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 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NALU unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
圖 11. MTAP24多時刻聚合單元
一個MTAP中的最早的聚合單元時戳位移必須為0。是以, MTAP的RTP時戳和最早NALU-time相同.
注釋: 最早多時刻聚合單元是MTAP中所有聚合單元的擴充RTP時戳中的最小者，如果聚合單元封裝在單個NAL單元包中。擴充時戳是有多于32位的時戳，有能力計算時戳域的饒回,是以時戳如果繞回能夠确定時戳的最小值。這樣的“最早“聚合單元可以不是封裝在MTAP中的第一個聚合單元，最早NAL單元不必和 NAL解碼順序的第一個NAL單元相同。
圖 12 表示一個例子，一個RTP包包含一個多時刻MTAP16類型的聚合包，包括兩個多時刻聚合單元，分别用1，2标記。
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 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. 一個RTP包包含一個多時刻MTAP16類型的聚合包，包括兩個多時刻聚合單元
圖 13 表示一個例子，一個RTP包包含一個多時刻MTAP24類型的聚合包，包括兩個多時刻聚合單元，分别用1，2标記。
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 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. RTP包包含一個多時刻MTAP24類型的聚合包，包括兩個多時刻聚合單元
5.8. 分片單元 (FUs)
本荷載類型允許分片一個NAL單元到幾個RTP包中。在應用層這樣做比依賴于底層（IP）的分片有以下好處：
o 荷載格式有能力傳輸NAL單元大于64K位元組的單元通過IPv4網絡，或許存在預編碼的視訊,特别在高清格式 (每個圖像的分片數目有限制，導緻每個圖像的NAL單元數目的限制, 進而導緻大的 NAL單元).
o 分派機制允許分片單個圖像并且采用一般向前的糾錯像12.5描述的那樣.
分片隻定義于單個NAL單元不用于任何聚合包。NAL單元的一個分片由整數個連續NAL單元位元組組成. 每個NAL單元位元組必須正好是該NAL單元一個分片的一部分。相同NAL單元的分片必須使用遞增的RTP序号連續順序發送(第一和最後分片之間沒有其他的 RTP包）。相似, NAL單元必須按照RTP順序号的順序裝配。
當一個NAL單元被分片運送在分片單元(FUs)中時，被引用為分片NAL單元。STAPs,MTAP不可以被分片。 FUs不可以嵌套。即, 一個FU 不可以包含另一個FU.
運送FU的RTP時戳被設定成分片NAL單元的NALU時刻.
圖 14 表示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 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-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 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單元的第一個分片如果用于交錯打包方式，則必須使用NAL單元類型FU-B。NAL單元類型FU-B MUST不可以用于其他情況。換句話, 在交錯打包方式,每個被分片的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 bit
當設定成1,開始位訓示分片NAL單元的開始。當跟随的FU荷載不是分片NAL單元荷載的開始，開始位設為0。
E: 1 bit
當設定成1, 結束位訓示分片NAL單元的結束，即, 荷載的最後位元組也是分片NAL單元的最後一個位元組。當跟随的FU荷載不是分片NAL單元的最後分片,結束位設定為0。
R: 1 bit
保留位必須設定為0，接收者必須忽略該位。
Type: 5 bits
NAL單元荷載類型定義在[1]的表7-1.
FU-B中DON的值的選擇在5.5已經描述.
注: FU-B中的DON域允許網關分片NAL單元到FU-B而不用組織進來的NAL單元到NAL單元解碼順序。
一個分片單元不可以傳輸在一個FU中; 即, 開始位和結束位不可以被同時設定在同一個FU頭中。
FU荷載由分片NAL單元的荷載分片組成，使得如果連續FU的分片單元荷載順序連接配接, 可以重構分片NAL單元的荷載。NAL單元分片的類型位元組不包括，就像在分片單元荷載中一樣,但是分片單元的NAL單元的類型資訊運送FU訓示位元組的F和 NRI域以及FU頭的類型域。一個FU荷載可以有任意位元組也可以為空。
注釋: 空的FUs允許減少某類發送者在幾乎無丢失環境中的延遲。這些發送者特點是他們的NALU完全産生前，可以打包NALU分片,是以,在NALU大小未知之前。如果零長度分片不被允許,發送者不得不産生至少一位資料在目前分片被發送前. 由于H.264的特性, 有時幾個宏快占據0位，這是不希望的并且增加延遲。但是, (潛在)使用0長度的NALU應該仔細權衡增加NALU丢失的風險，因為增加了傳輸包。
如果一個分片單元丢失,接收者應該丢棄後續的所有分片單元對應于相同分片NAL單元的傳輸順序的分片。
終端或MANE中的接收者可以聚合前一個NAL單元的n-1分片到一個(不完全的) NAL單元,甚至分片n沒有接收到. 這種情況下，NAL單元的forbidden_zero_bit必須被設定成1訓示文法違背.
6. 打包規則
打包方式在5.2節介紹. 對于多于一個打包方式的公共打包規則在6.1節指定. 單個NAL單元方式的打包規則，非交錯方式，交錯方式的打包規則分别在6.2, 6.3,6.4節指定。
6.1. 公共打包規則
不管使用那種打包方式，所有發送者必須遵守以下打包規則:
o 屬于同一編碼圖像（共享相同RTP時戳值）的編碼NAL單元片斷或者編碼資料分區NAL單元片斷可以按照定義在[1]中的應用Profile允許的任何順序發送; 但是,對于延遲敏感的系統,他們應該按照他們原始編碼順序發送，以減少延遲。注意：編碼順序不必要是掃描順序，而是NAL包對RTP協定棧可用的順序。
o 參數集根據8.4節給定的規則和建議處理。
o MANEs 不可以重複任何NAL單元，除了順序或圖像參數集NAL單元,同樣本文或者H.264規範也沒有提供手段識别重複的NAL單元。順序和圖像參數集NAL單元可以重複使得他們的糾錯接收更可靠，但是,任何這樣的重複不可以影響任何活動順序或圖像參數集的内容。重複應該在應用層進行，不應通過複制RTP包進行（相同序号）。
使用非交錯方式和交錯方式的發送者必須遵守以下打包規則：
o MANEs可以轉換單個NAL單元包到一個聚合包,轉換一個聚合包到幾個單個NAL單元包,或在RTP轉換器中混合兩個概念。RTP轉換器至少應該考慮如下參數：路徑MTU大小, 不平等的保護機制(即,根據RFC 2733通過基于包的FEC,特别對于順序和圖像參數集NAL單元以及編碼片斷資料分區NAL單元），系統可以忍受的延遲以及接收者緩沖能力。
注：RTP轉換器要求按照每個RFC3550處理RTCP.
6.2. 單個NAL單元模式
本方式應用在OPTIONAL打包方式MIME參數值等于0,不包含打包方式,或者沒有外部手段訓示其他的打包方式的時候。所有的接收者必須支援本方式。它主要用于低延遲應用（和使用ITU-T H.241建議相容的系統）。(見12.1節). 隻有單個NAL單元包可以用在這種方式。STAPs, MTAPs, and FUs 不可以使用。單個NAL單元的傳輸順序必須和NAL解碼順序一緻。
6.3. 非交錯方式
本方式應用在OPTIONAL打包方式MIME參數值等于1或者改方式被外部的手段打開時。本方式應該被支援。它主要用于低延遲應用。本方式隻允許單個 NAL單元包, STAP-As, FU-As包。STAP-Bs, MTAPs,FU-Bs不可以使用。NAL單元的傳輸順序必須和NAL單元解碼順序一緻。
6.4. 交錯方式
本方式應用在OPTIONAL打包方式MIME參數值等于2或者改方式被外部的手段打開時。有些接收者可以支援本方式。可以使用 STAP-Bs, MTAPs, FU-As,FU-Bs。STAP-As 和單個NAL單元包不可以使用。包和NAL單元傳輸順序的限制在5.5節指定。
7. 打包過程 (資訊)
打包過程是實作相關的。是以,下面的描述應該被看成合适實作的例子。其他的方案也可以使用。相關描述算法的優化也是可能的。7.1示範單個NAL單元和非交錯打包方式的打包過程,7.2描述交錯方式的打包過程。7.3 包括附加的封裝指導對于智能接收者。
所有相關于緩沖區管理正常的RTP機制也适用。特别的,重複的過期的RTP包(由RTP序号/時戳訓示)被删除。 為了确定精确的解碼時間, 如可能的延遲因素也被允許為了正确的流之間的同步。
7.1. 單個NAL單元和非交錯方式
接收者包括一個接收緩沖區以補償傳輸延遲和抖動。接收者存儲進來的包按照接收順序在接收緩沖區中。包被解封裝按照RTP序号的順序。如果封裝包是一個單個 NAL單元包,包含在包中的NAL單元直接傳遞給解碼器。如果解封裝的包是一個STAP-AI, 包含在包中的NAL單元按照他們在包中的封裝順序傳遞給解碼器。如果解封裝包是一個FU-A, 所有的分片NAL單元單分片連接配接在一起傳遞給解碼器。
資訊: 如果解碼器支援任意分片順序,編碼的圖像片可以按照任意順序傳送給解碼器而不管他們的接收傳送順序。
7.2. 交錯方式
這些打包規則後面的一般概念是重新排序NAL單元從傳輸順序到NAL單元解碼順序。
接收者包括一個接收緩沖區以補償傳輸延遲抖動以及重新排序包從傳輸順序到NAL單元解碼順序。本部分,接收者操作的描述假設沒有傳輸延遲抖動。為了和實際的差異，一個接收緩沖區也用于補償傳輸延遲抖動,接收者者本部分調用解交錯緩沖區。接收者應該準備傳輸延遲抖動;即, 或者保留單獨的緩沖區用于傳輸延遲抖動緩沖和解交錯緩沖或者使用接收緩沖用于傳輸延遲抖動和解交錯。而且, 接收者應該考慮傳輸延遲抖動在緩沖區操作時，即,在開始解碼和回放前增加緩沖區。
本部分組織如下: 7.2.1 描述如何計算交錯緩沖區的大小. 7.2.2指定接收過程如何組織接收到的NAL單元到NAL解碼順序。
7.2.1. 解交錯緩沖區的大小
當 SDP Offer/Answer 模型或其他任何能力交換過程被使用時, 接收流的屬性應該使得接收者的能力不被超過。在 SDP Offer/Answer 摸型行中, 接收者可以訓示它的能力以配置設定一個解交錯緩沖區使用deintbuf-cap MIME 參數。發送者訓示解交錯緩沖區大小的要求使用sprop-deint-buf-req MIME參數. 是以，推薦設定解交錯緩沖區大小（位元組數目）等于或大于sprop-deint-buf-req MIME 參數指定的值. 參見 8.1 得到更多資訊關于 deint-buf-cap和sprop-deint-buf-req MIME參數，8.2.2 關于他們在SDP Offer/Answer模型中的使用。
在會話建立中一個公布的會話描述被使用,sprop-deint-buf-req MIME參數指定交錯緩沖大小的要求。是以，推薦設定解交錯緩沖區大小（位元組位機關）等于或大于sprop-deint-buf-req MIME 參數的值.
7.2.2. 解交錯過程
在接收者中有兩個緩沖狀态: 初始緩沖和正在播放緩沖。初始緩沖發生在RTP會話被初始化時。初始緩沖後,解碼和播放開始了, 使用緩沖-播放模型。
不管緩沖的狀态,接收者存儲進來的NAL單元按照接收順序,在解交錯緩沖區中。聚合包的 NAL單元存儲在單個解交錯緩沖區中DON的值被計算為所有NAL單元存儲。
描述在下面的接收操作需要以下的函數常數幫助：
o 函數AbsDON在8.1指定.
o 函數don_diff在 5.5 指定.
o 常數 N 是 OPTIONAL sprop-interleaving-depth MIME 類型參數的值( 8.1)加1.
初始緩沖持續直到以下條件完成:
o 在解交錯緩沖區中有 N VCL NAL單元。
o 如果sprop-max-don-diff存在, don_diff(m,n)大于sprop-max-don-diff的值, 其中 n 對應所有接收到的NAL單元中最大AbsDON值的NAL單元，m 對應所有接收到的NAL單元中最小AbsDON值的NAL單元。
o 初始緩沖區已經持續時間等于或大于 OPTIONAL sprop-init-buf-time MIME 參數指定的值.
要從解交錯緩沖區删除的NAL單元的确定如下：
o 如果解交錯緩沖區包含至少N 個VCL NAL單元,NAL單元被從解交錯緩沖區移出傳遞給解碼器按照下面指定的次序直到緩沖區中包含N-1 VCL NAL 單元。
o 如果sprop-max-don-diff存在, 所有的NAL單元 m，他們的don_diff(m,n)大于sprop-max-don-diff的從解交錯緩沖區移出傳送給解碼器按照下面指定的順序。在此, n 對應所有接收到的NAL單元中最大AbsDON值的NAL單元。
NAL單元傳遞給解碼器的順序指定如下：
o 讓PDON是一個變量RTP會話開始時初始化為0。
o 對于每個關聯DON的NAL單元, 按如下計算一個DON距離。如果NAL單元的DON大于PDON的值, DON距離等于DON-PDON.否則DON距離等于 65535 - PDON + DON + 1.
o NAL單元分發給解碼器按照DON距離遞增的順序。如果幾個NAL單元有相同的DON距離，則他們可以按照任意順序遞交給解碼器.
o 當一定數目的NAL單元傳遞給解碼器, PDON的值設定為傳送給解碼器最後一個NAL單元的DON值。
7.3. 附加打包規則
以下附加打包規則可用于實作一個可操作的H.264打包器:
o 智能RTP接收者 (即在網關中) 可以識别丢失的編碼片斷資料分區A (DPAs). 如果發現丢失的DPA,網關可以決定不發送對應的編碼片斷資料分區B和C,因為對于H.264解碼器他們的資訊是無意義的。這樣通過丢棄無用的包而不用分析複雜的位流，一個MANE可以減少網絡負擔。
o 智能RTP接收者(即在網關中) 可以識别丢失的FU. 如果發現丢失一個FU, 網關可以決定不發送同一個分片NAL的後續FU因為對于H.264解碼器他們的資訊是無意義的.這樣通過丢棄無用的包而不用分析複雜的位流，一個MANE可以減少網絡負擔。
o 不得不丢棄包或NALU的智能接收者應該首先丢棄所有NAL單元類型中NRI值等于0的包/NALU. 這樣最小化使用者體驗的影響并保持參考圖像完整。如果更多的包不得不被丢棄,則NRI值低的包應該在NRI值高的前面被丢棄。但是,丢棄任何NRI值大于0 的包可能導緻解碼器飄移應該被避免。
![編譯vlc-android[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)