fields in its decoded picture buffer:
Min(1024 * max-dpb / ( PicWidthInMbs *
FrameHeightInMbs * 256 * ChromaFormatFactor ),
16)
PicWidthInMbs, FrameHeightInMbs, and
ChromaFormatFactor are defined in [1].
The value of max-dpb MUST be greater than or
equal to the value of MaxDPB for the level
given in Table A-1 of [1]. Senders MAY use
this knowledge to construct coded video streams
with improved compression.
Informative note: This parameter was added
primarily to complement a similar codepoint
in the ITU-T Recommendation H.245, so as to
facilitate signaling gateway designs. The
decoded picture buffer stores reconstructed
samples and is a property of the video
decoder only. There is no relationship
between the size of the decoded picture
buffer and the buffers used in RTP,
especially de-interleaving and de-jitter
buffers.
max-br: The value of max-br is an integer indicating
the maximum video bit rate in units of 1000
bits per second for the VCL HRD parameters (see
A.3.1 item i of [1]) and in units of 1200 bits
per second for the NAL HRD parameters (see
A.3.1 item j of [1]).
The max-br parameter signals that the video
decoder of the receiver is capable of decoding
video at a higher bit rate than is required by
the signaled level conveyed in the value of the
profile-level-id parameter. The value of max-
br MUST be greater than or equal to the value
of MaxBR for the level given in Table A-1 of
[1].
When max-br is signaled, the video codec of the
receiver MUST be able to decode NAL unit
streams that conform to the signaled level,
conveyed in the profile-level-id parameter,
with the following exceptions in the limits
specified by the level:
o The value of max-br replaces the MaxBR value
of the signaled level (in Table A-1 of [1]).
o When the max-cpb parameter is not present,
the result of the following formula replaces
the value of MaxCPB in Table A-1 of [1]:
(MaxCPB of the signaled level) * max-br /
(MaxBR of the signaled level).
For example, if a receiver signals capability
for Level 1.2 with max-br equal to 1550, this
indicates a maximum video bitrate of 1550
kbits/sec for VCL HRD parameters, a maximum
video bitrate of 1860 kbits/sec for NAL HRD
parameters, and a CPB size of 4036458 bits
(1550000 / 384000 * 1000 * 1000).
The value of max-br MUST be greater than or
equal to the value MaxBR for the signaled level
given in Table A-1 of [1].
Senders MAY use this knowledge to send higher
bitrate video as allowed in the level
definition of Annex A of H.264, to achieve
improved video quality.
Informative note: This parameter was added
primarily to complement a similar codepoint
in the ITU-T Recommendation H.245, so as to
facilitate signaling gateway designs. No
assumption can be made from the value of
this parameter that the network is capable
of handling such bit rates at any given
time. In particular, no conclusion can be
drawn that the signaled bit rate is
possible under congestion control
constraints.
redundant-pic-cap:
This parameter signals the capabilities of a
receiver implementation. When equal to 0, the
parameter indicates that the receiver makes no
attempt to use redundant coded pictures to
correct incorrectly decoded primary coded
pictures. When equal to 0, the receiver is not
capable of using redundant slices; therefore, a
sender SHOULD avoid sending redundant slices to
save bandwidth. When equal to 1, the receiver
is capable of decoding any such redundant slice
that covers a corrupted area in a primary
decoded picture (at least partly), and therefore
a sender MAY send redundant slices. When the
parameter is not present, then a value of 0
MUST be used for redundant-pic-cap. When
present, the value of redundant-pic-cap MUST be
either 0 or 1.
When the profile-level-id parameter is present
in the same capability signaling as the
redundant-pic-cap parameter, and the profile
indicated in profile-level-id is such that it
disallows the use of redundant coded pictures
(e.g., Main Profile), the value of redundant-
pic-cap MUST be equal to 0. When a receiver
indicates redundant-pic-cap equal to 0, the
received stream SHOULD NOT contain redundant
coded pictures.
Informative note: Even if redundant-pic-cap
is equal to 0, the decoder is able to
ignore redundant codec pictures provided
that the decoder supports such a profile
(Baseline, Extended) in which redundant
coded pictures are allowed.
Informative note: Even if redundant-pic-cap
is equal to 1, the receiver may also choose
other error concealment strategies to
replace or complement decoding of redundant
slices.
sprop-parameter-sets:
This parameter MAY be used to convey
any sequence and picture parameter set NAL
units (herein referred to as the initial
parameter set NAL units) that MUST precede any
other NAL units in decoding order. The
parameter MUST NOT be used to indicate codec
capability in any capability exchange
procedure. The value of the parameter is the
base64 [6] representation of the initial
parameter set NAL units as specified in
sections 7.3.2.1 and 7.3.2.2 of [1]. The
parameter sets are conveyed in decoding order,
and no framing of the parameter set NAL units
takes place. A comma is used to separate any
pair of parameter sets in the list. Note that
the number of bytes in a parameter set NAL unit
is typically less than 10, but a picture
parameter set NAL unit can contain several
hundreds of bytes.
Informative note: When several payload
types are offered in the SDP Offer/Answer
model, each with its own sprop-parameter-
sets parameter, then the receiver cannot
assume that those parameter sets do not use
conflicting storage locations (i.e.,
identical values of parameter set
identifiers). Therefore, a receiver should
double-buffer all sprop-parameter-sets and
make them available to the decoder instance
that decodes a certain payload type.
parameter-add: This parameter MAY be used to signal whether
the receiver of this parameter is allowed to
add parameter sets in its signaling response
using the sprop-parameter-sets MIME parameter.
The value of this parameter is either 0 or 1.
0 is equal to false; i.e., it is not allowed to
add parameter sets. 1 is equal to true; i.e.,
it is allowed to add parameter sets. If the
parameter is not present, its value MUST be 1.
packetization-mode:
This parameter signals the properties of an
RTP payload type or the capabilities of a
receiver implementation. Only a single
configuration point can be indicated; thus,
when capabilities to support more than one
packetization-mode are declared, multiple
configuration points (RTP payload types) must
be used.
When the value of packetization-mode is equal
to 0 or packetization-mode is not present, the
single NAL mode, as defined in section 6.2 of
RFC 3984, MUST be used. This mode is in use in
standards using ITU-T Recommendation H.241 [15]
(see section 12.1). When the value of
packetization-mode is equal to 1, the non-
interleaved mode, as defined in section 6.3 of
RFC 3984, MUST be used. When the value of
packetization-mode is equal to 2, the
interleaved mode, as defined in section 6.4 of
RFC 3984, MUST be used. The value of
packetization mode MUST be an integer in the
range of 0 to 2, inclusive.
sprop-interleaving-depth:
This parameter MUST NOT be present
when packetization-mode is not present or the
value of packetization-mode is equal to 0 or 1.
This parameter MUST be present when the value
of packetization-mode is equal to 2.
This parameter signals the properties of a NAL
unit stream. It specifies the maximum number
of VCL NAL units that precede any VCL NAL unit
in the NAL unit stream in transmission order
and follow the VCL NAL unit in decoding order.
Consequently, it is guaranteed that receivers
can reconstruct NAL unit decoding order when
the buffer size for NAL unit decoding order
recovery is at least the value of sprop-
interleaving-depth + 1 in terms of VCL NAL
units.
The value of sprop-interleaving-depth MUST be
an integer in the range of 0 to 32767,
inclusive.
sprop-deint-buf-req:
This parameter MUST NOT be present when
packetization-mode is not present or the value
of packetization-mode is equal to 0 or 1. It
MUST be present when the value of
packetization-mode is equal to 2.
sprop-deint-buf-req signals the required size
of the deinterleaving buffer for the NAL unit
stream. The value of the parameter MUST be
greater than or equal to the maximum buffer
occupancy (in units of bytes) required in such
a deinterleaving buffer that is specified in
section 7.2 of RFC 3984. It is guaranteed that
receivers can perform the deinterleaving of
interleaved NAL units into NAL unit decoding
order, when the deinterleaving buffer size is
at least the value of sprop-deint-buf-req in
terms of bytes.
The value of sprop-deint-buf-req MUST be an
integer in the range of 0 to 4294967295,
inclusive.
Informative note: sprop-deint-buf-req
indicates the required size of the
deinterleaving buffer only. When network
jitter can occur, an appropriately sized
jitter buffer has to be provisioned for
as well.
deint-buf-cap: This parameter signals the capabilities of a
receiver implementation and indicates the
amount of deinterleaving buffer space in units
of bytes that the receiver has available for
reconstructing the NAL unit decoding order. A
receiver is able to handle any stream for which
the value of the sprop-deint-buf-req parameter
is smaller than or equal to this parameter.
If the parameter is not present, then a value
of 0 MUST be used for deint-buf-cap. The value