access unit, where tSEI1 is the earliest of all such timestamps.
Let tmadjst() be a function that adjusts the SEI messages time
scale to a 90-kHz time scale. Let TS be the RTP timestamp. Then,
the display time for the event associated with tSEI1 is TS. The
display time for the event with tSEIx, where x is [2..n] is TS +
tmadjst (tSEIx - tSEI1).
Informative note: Displaying coded frames as fields is needed
commonly in an operation known as 3:2 pulldown, in which film
content that consists of coded frames is displayed on a display
using interlaced scanning. The picture timing SEI message
enables carriage of multiple timestamps for the same coded
picture, and therefore the 3:2 pulldown process is perfectly
controlled. The picture timing SEI message mechanism is
necessary because only one timestamp per coded frame can be
conveyed in the RTP timestamp.
Informative note: Because H.264 allows the decoding order to be
different from the display order, values of RTP timestamps may
not be monotonically non-decreasing as a function of RTP
sequence numbers. Furthermore, the value for interarrival
jitter reported in the RTCP reports may not be a trustworthy
indication of the network performance, 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. Common Structure of the RTP Payload Format
The payload format defines three different basic payload structures.
A receiver can identify the payload structure by the first byte of
the RTP payload, which co-serves as the RTP payload header and, in
some cases, as the first byte of the payload. This byte is always
structured as a NAL unit header. The NAL unit type field indicates
which structure is present. The possible structures are as follows:
Single NAL Unit Packet: Contains only a single NAL unit in the
payload. The NAL header type field will be equal to the original NAL
unit type; i.e., in the range of 1 to 23, inclusive. Specified in
section 5.6.
Aggregation packet: Packet type used to aggregate multiple NAL units
into a single RTP payload. This packet exists in four versions, the
Single-Time Aggregation Packet type A (STAP-A), the Single-Time
Aggregation Packet type B (STAP-B), Multi-Time Aggregation Packet
(MTAP) with 16-bit offset (MTAP16), and Multi-Time Aggregation Packet
(MTAP) with 24-bit offset (MTAP24). The NAL unit type numbers
assigned for STAP-A, STAP-B, MTAP16, and MTAP24 are 24, 25, 26, and
27, respectively. Specified in section 5.7.
Fragmentation unit: Used to fragment a single NAL unit over multiple
RTP packets. Exists with two versions, FU-A and FU-B, identified
with the NAL unit type numbers 28 and 29, respectively. Specified in
section 5.8.
Table 1. Summary of NAL unit types and their payload structures
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 -
Informative note: This specification does not limit the size of
NAL units encapsulated in single NAL unit packets and
fragmentation units. The maximum size of a NAL unit encapsulated
in any aggregation packet is 65535 bytes.
5.3. NAL Unit Octet Usage
The structure and semantics of the NAL unit octet were introduced in
section 1.3. For convenience, the format of the NAL unit type octet
is reprinted below:
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
This section specifies the semantics of F and NRI according to this
specification.
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. The semantics of value 00 and a non-zero value
remain unchanged from the H.264 specification. In other words, a
value of 00 indicates that the content of the NAL unit is not used
to reconstruct reference pictures for inter picture prediction.
Such NAL units can be discarded without risking the integrity of
the reference pictures. Values greater than 00 indicate that the
decoding of the NAL unit is required to maintain the integrity of
the reference pictures.
In addition to the specification above, according to this RTP
payload specification, values of NRI greater than 00 indicate the
relative transport priority, as determined by the encoder. MANEs
can use this information to protect more important NAL units
better than they do less important NAL units. The highest
transport priority is 11, followed by 10, and then by 01; finally,
00 is the lowest.
Informative note: Any non-zero value of NRI is handled
identically in H.264 decoders. Therefore, receivers need not
manipulate the value of NRI when passing NAL units to the
decoder.
An H.264 encoder MUST set the value of NRI according to the H.264
specification (subclause 7.4.1) when the value of nal_unit_type is
in the range of 1 to 12, inclusive. In particular, the H.264
specification requires that the value of NRI SHALL be equal to 0
for all NAL units having nal_unit_type equal to 6, 9, 10, 11, or
12.
For NAL units having nal_unit_type equal to 7 or 8 (indicating a
sequence parameter set or a picture parameter set, respectively),
an H.264 encoder SHOULD set the value of NRI to 11 (in binary
format). For coded slice NAL units of a primary coded picture
having nal_unit_type equal to 5 (indicating a coded slice
belonging to an IDR picture), an H.264 encoder SHOULD set the
value of NRI to 11 (in binary format).
For a mapping of the remaining nal_unit_types to NRI values, the
following example MAY be used and has been shown to be efficient
in a certain environment [13]. Other mappings MAY also be
desirable, depending on the application and the H.264/AVC Annex A
profile in use.
Informative note: Data Partitioning is not available in certain
profiles; e.g., in the Main or Baseline profiles.
Consequently, the nal unit types 2, 3, and 4 can occur only if
the video bitstream conforms to a profile in which data
partitioning is allowed and not in streams that conform to the
Main or Baseline profiles.
Table 2. Example of NRI values for coded slices and coded slice
data partitions of primary coded reference pictures
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
Informative note: As mentioned before, the NRI value of non-
reference pictures is 00 as mandated by H.264/AVC.
An H.264 encoder SHOULD set the value of NRI for coded slice and
coded slice data partition NAL units of redundant coded reference
pictures equal to 01 (in binary format).
Definitions of the values for NRI for NAL unit types 24 to 29,
inclusive, are given in sections 5.7 and 5.8 of this memo.
No recommendation for the value of NRI is given for NAL units
having nal_unit_type in the range of 13 to 23, inclusive, because
these values are reserved for ITU-T and ISO/IEC. No
recommendation for the value of NRI is given for NAL units having
nal_unit_type equal to 0 or in the range of 30 to 31, inclusive,
as the semantics of these values are not specified in this memo.
5.4. Packetization Modes
This memo specifies three cases of packetization modes:
o Single NAL unit mode
o Non-interleaved mode
o Interleaved mode
The single NAL unit mode is targeted for conversational systems that
comply with ITU-T Recommendation H.241 [15] (see section 12.1). The
non-interleaved mode is targeted for conversational systems that may
not comply with ITU-T Recommendation H.241. In the non-interleaved
mode, NAL units are transmitted in NAL unit decoding order. The
interleaved mode is targeted for systems that do not require very low
end-to-end latency. The interleaved mode allows transmission of NAL
units out of NAL unit decoding order.
The packetization mode in use MAY be signaled by the value of the
OPTIONAL packetization-mode MIME parameter or by external means. The
used packetization mode governs which NAL unit types are allowed in
RTP payloads. Table 3 summarizes the allowed NAL unit types for each
packetization mode. Some NAL unit type values (indicated as
undefined in Table 3) are reserved for future extensions. NAL units
of those types SHOULD NOT be sent by a sender and MUST be ignored by
a receiver. For example, the Types 1-23, with the associated packet
type "NAL unit", are allowed in "Single NAL Unit Mode" and in "Non-
Interleaved Mode", but disallowed in "Interleaved Mode".
Packetization modes are explained in more detail in section 6.
Table 3. Summary of allowed NAL unit types for each packetization
mode (yes = allowed, no = disallowed, ig = ignore)
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. Decoding Order Number (DON)
In the interleaved packetization mode, the transmission order of NAL
units is allowed to differ from the decoding order of the NAL units.
Decoding order number (DON) is a field in the payload structure or a
derived variable that indicates the NAL unit decoding order.
Rationale and examples of use cases for transmission out of decoding
order and for the use of DON are given in section 13.
The coupling of transmission and decoding order is controlled by the
OPTIONAL sprop-interleaving-depth MIME parameter as follows. When
the value of the OPTIONAL sprop-interleaving-depth MIME parameter is
equal to 0 (explicitly or per default) or transmission of NAL units
out of their decoding order is disallowed by external means, the
transmission order of NAL units MUST conform to the NAL unit decoding
order. When the value of the OPTIONAL sprop-interleaving-depth MIME
parameter is greater than 0 or transmission of NAL units out of their
decoding order is allowed by external means,
o the order of NAL units in an MTAP16 and an MTAP24 is NOT REQUIRED
to be the NAL unit decoding order, and
o the order of NAL units generated by decapsulating STAP-Bs, MTAPs,
and FUs in two consecutive packets is NOT REQUIRED to be the NAL
unit decoding order.
The RTP payload structures for a single NAL unit packet, an STAP-A,
and an FU-A do not include DON. STAP-B and FU-B structures include
DON, and the structure of MTAPs enables derivation of DON as
specified in section 5.7.2.
Informative note: When an FU-A occurs in interleaved mode, it
always follows an FU-B, which sets its DON.
Informative note: If a transmitter wants to encapsulate a single
NAL unit per packet and transmit packets out of their decoding
order, STAP-B packet type can be used.
In the single NAL unit packetization mode, the transmission order of
NAL units, determined by the RTP sequence number, MUST be the same as
their NAL unit decoding order. In the non-interleaved packetization
mode, the transmission order of NAL units in single NAL unit packets,
STAP-As, and FU-As MUST be the same as their NAL unit decoding order.
The NAL units within an STAP MUST appear in the NAL unit decoding
order. Thus, the decoding order is first provided through the
implicit order within a STAP, and second provided through the RTP
sequence number for the order between STAPs, FUs, and single NAL unit
packets.
Signaling of the value of DON for NAL units carried in STAP-B, MTAP,
and a series of fragmentation units starting with an FU-B is
specified in sections 5.7.1, 5.7.2, and 5.8, respectively. The DON
value of the first NAL unit in transmission order MAY be set to any
value. 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.
The decoding order of two NAL units contained in any STAP-B, MTAP, or
a series of fragmentation units starting with an FU-B is determined
as follows. Let DON(i) be the decoding order number of the NAL unit
having index i in the transmission order. Function don_diff(m,n) is
specified as follows:
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))
A positive value of don_diff(m,n) indicates that the NAL unit having
transmission order index n follows, in decoding order, the NAL unit
having transmission order index m. When don_diff(m,n) is equal to 0,
then the NAL unit decoding order of the two NAL units can be in
either order. A negative value of don_diff(m,n) indicates that the
NAL unit having transmission order index n precedes, in decoding
order, the NAL unit having transmission order index m.
Values of DON related fields (DON, DONB, and DOND; see section 5.7)
MUST be such that the decoding order determined by the values of DON,
as specified above, conforms to the NAL unit decoding order. If the
order of two NAL units in NAL unit decoding order is switched and the
new order does not conform to the NAL unit decoding order, the NAL
units MUST NOT have the same value of DON. If the order of two
consecutive NAL units in the NAL unit stream is switched and the new
order still conforms to the NAL unit decoding order, the NAL units
MAY have the same value of DON. For example, when arbitrary slice
order is allowed by the video coding profile in use, all the coded
slice NAL units of a coded picture are allowed to have the same value
of DON. Consequently, NAL units having the same value of DON can be
decoded in any order, and two NAL units having a different value of
DON should be passed to the decoder in the order specified above.
When two consecutive NAL units in the NAL unit decoding order have a
different value of DON, the value of DON for the second NAL unit in
decoding order SHOULD be the value of DON for the first, incremented
by one.
An example of the decapsulation process to recover the NAL unit
decoding order is given in section 7.
Informative note: Receivers should not expect that the absolute
difference of values of DON for two consecutive NAL units in the
NAL unit decoding order will be equal to one, even in error-free
transmission. An increment by one is not required, as at the time
of associating values of DON to NAL units, it may not be known
whether all NAL units are delivered to the receiver. For example,
a gateway may not forward coded slice NAL units of non-reference
pictures or SEI NAL units when there is a shortage of bit rate in
the network to which the packets are forwarded. In another
example, a live broadcast is interrupted by pre-encoded content,
such as commercials, from time to time. The first intra picture
of a pre-encoded clip is transmitted in advance to ensure that it
is readily available in the receiver. When transmitting the first
intra picture, the originator does not exactly know how many NAL
units will be encoded before the first intra picture of the pre-
encoded clip follows in decoding order. Thus, the values of DON
for the NAL units of the first intra picture of the pre-encoded
clip have to be estimated when they are transmitted, and gaps in
values of DON may occur.
5.6. Single NAL Unit Packet
The single NAL unit packet defined here MUST contain only one NAL
unit, of the types defined in [1]. This means that neither an
aggregation packet nor a fragmentation unit can be used within a
single NAL unit packet. A NAL unit stream composed by decapsulating
single NAL unit packets in RTP sequence number order MUST conform to
the NAL unit decoding order. The structure of the single NAL unit
packet is shown in Figure 2.
Informative note: The first byte of a NAL unit co-serves as the
RTP payload header.
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. RTP payload format for single NAL unit packet
5.7. Aggregation Packets
Aggregation packets are the NAL unit aggregation scheme of this
payload specification. The scheme is introduced to reflect the
dramatically different MTU sizes of two key target networks:
wireline IP networks (with an MTU size that is often limited by the
Ethernet MTU size; roughly 1500 bytes), and IP or non-IP (e.g., ITU-T
H.324/M) based wireless communication systems with preferred
transmission unit sizes of 254 bytes or less. To prevent media
transcoding between the two worlds, and to avoid undesirable
packetization overhead, a NAL unit aggregation scheme is introduced.
Two types of aggregation packets are defined by this specification:
o Single-time aggregation packet (STAP): aggregates NAL units with
identical NALU-time. Two types of STAPs are defined, one without
DON (STAP-A) and another including DON (STAP-B).
o Multi-time aggregation packet (MTAP): aggregates NAL units with
potentially differing NALU-time. Two different MTAPs are defined,
differing in the length of the NAL unit timestamp offset.
The term NALU-time is defined as the value that the RTP timestamp
would have if that NAL unit would be transported in its own RTP
packet.
Each NAL unit to be carried in an aggregation packet is encapsulated