of RFC 4425 for specific rules for how this parameter is
used with the SDP Offer/Answer model.
Optional parameters:
config:
The value is a base16 [6] (hexadecimal) representation of an
octet string that expresses the decoder initialization
parameters. Decoder initialization parameters are mapped
onto the base16 octet string in an MSB-first basis. The
first bit of the decoder initialization parameters MUST be
located at the MSB of the first octet. If the decoder
initialization parameters are not multiples of 8 bits, up to
7 zero-valued padding bits MUST be added in the last octet
to achieve octet alignment.
For Simple and Main profiles, the decoder initialization
parameters are STRUCT_C, as defined in Annex J of SMPTE 421M
[1].
For Advanced profile, the decoder initialization parameters
are a sequence layer header directly followed by an entry-
point header. The two headers MUST be in EBDU format,
meaning that they must include their Start Codes and must
use the encapsulation method defined in Annex E of SMPTE
421M [1].
width:
The value is an integer greater than zero, specifying the
maximum horizontal size of the coded frames, in luma samples
(pixels in the luma picture).
For Simple and Main profiles, the value SHALL be identical
to the actual horizontal size of the coded frames.
For Advanced profile, the value SHALL be greater than, or
equal to, the largest horizontal size of the coded frames.
If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the specified profile and
level.
height:
The value is an integer greater than zero, specifying the
maximum vertical size of the coded frames, in luma samples
(pixels in a progressively coded luma picture).
For Simple and Main profiles, the value SHALL be identical
to the actual vertical size of the coded frames.
For Advanced profile, the value SHALL be greater than, or
equal to, the largest vertical size of the coded frames.
If this parameter is not specified, it defaults to the
maximum vertical size allowed by the specified profile and
level.
bitrate:
The value is an integer greater than zero, specifying the
peak transmission rate of the coded bit stream in bits per
second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP, or IP headers.
If this parameter is not specified, it defaults to the
maximum bit rate allowed by the specified profile and level.
See the values for "RMax" in Annex D of SMPTE 421M [1].
buffer:
The value is an integer specifying the leaky bucket size, B,
in milliseconds, required to contain a stream transmitted at
the transmission rate specified by the bitrate parameter.
This parameter is defined in the hypothetical reference
decoder model for VC-1, in Annex C of SMPTE 421M [1].
Note that this parameter relates to the codec bit stream
only, and does not account for any buffering time that may
be required to compensate for jitter in the network.
If this parameter is not specified, it defaults to the
maximum buffer size allowed by the specified profile and
level. See the values for "BMax" and "RMax" in Annex D of
SMPTE 421M [1].
framerate:
The value is an integer greater than zero, specifying the
maximum number of frames per second in the coded bit stream,
multiplied by 1000 and rounded to the nearest integer value.
For example, 30000/1001 (approximately 29.97) frames per
second is represented as 29970.
This parameter can be used to control resource allocation at
the receiver. For example, a receiver may choose to perform
additional post-processing on decoded frames only if the
frame rate is expected to be low. The parameter MUST NOT be
used for pacing of the rendering process, since the actual
frame rate may differ from the specified value.
If the parameter is not specified, it defaults to the
maximum frame rate allowed by the specified profile and
level.
bpic:
This parameter signals that B- and BI-pictures may be
present when Advanced profile is used. If this parameter is
present, and B- or BI-pictures may be present in the coded
bit stream, this parameter MUST be equal to 1.
A value of 0 indicates that B- and BI-pictures SHALL NOT be
present in the coded bit stream, even if the sequence layer
header changes. Inclusion of this parameter with a value of
0 is RECOMMENDED, if neither B- nor BI-pictures are included
in the coded bit stream.
This parameter MUST NOT be used with Simple and Main
profiles. For Main profile, the presence of B- and
BI-pictures is indicated by the MAXBFRAMES field in STRUCT_C
decoder initialization parameter.
For Advanced profile, if this parameter is not specified, a
value of 1 SHALL be assumed.
mode:
The value is an integer specifying the use of the sequence
layer header and the entry-point header. This parameter is
only defined for Advanced profile. The following values are
defined:
0: Both the sequence layer header and the entry-point header
may change, and changed headers will be included in the
RTP packets.
1: The sequence layer header specified in the config
parameter never changes. The rules in section 4.8 of RFC
4425 MUST be followed.
3: The sequence layer header and the entry-point header
specified in the config parameter never change. The
rules in section 4.9 of RFC 4425 MUST be followed.
If the mode parameter is not specified, a value of 0 SHALL
be assumed. The mode parameter SHOULD be specified if modes
1 or 3 apply to the VC-1 bit stream.
max-width, max-height, max-bitrate, max-buffer, max-framerate:
These parameters are defined for use in a capability
exchange procedure. The parameters do not signal properties
of the coded bit stream, but rather upper limits or
preferred values for the "width", "height", "bitrate",
"buffer", and "framerate" parameters. Section 6.3 of RFC
4425 provides specific rules for how these parameters are
used with the SDP Offer/Answer model.
Receivers that signal support for a given profile and level
MUST support the maximum values for these parameters for
that profile and level. For example, a receiver that
indicates support for Main profile, Low level, must support
a width of 352 luma samples and a height of 288 luma
samples, even if this requires scaling the image to fit the
resolution of a smaller display device.
A receiver MAY use any of the max-width, max-height, max-
bitrate, max-buffer, and max-framerate parameters to
indicate preferred capabilities. For example, a receiver
may choose to specify values for max-width and max-height
that match the resolution of its display device, since a bit
stream encoded using those parameters would not need to be
rescaled.
If any of the max-width, max-height, max-bitrate, max-
buffer, and max-framerate parameters signal a capability
that is less than the required capabilities of the signaled
profile and level, then the parameter SHALL be interpreted
as a preferred value for that capability.
Any of the parameters MAY also be used to signal
capabilities that exceed the required capabilities of the
signaled profile and level. In that case, the parameter
SHALL be interpreted as the maximum value that can be
supported for that capability.
When more than one parameter from the set (max-width,
max-height, max-bitrate, max-buffer, and max-framerate) is
present, all signaled capabilities MUST be supported
simultaneously.
A sender or receiver MUST NOT use these parameters to signal
capabilities that meet the requirements of a higher level of
the VC-1 profile than that specified in the "level"
parameter, even if the sender or receiver can support all
the properties of the higher level, except if specifying a
higher level is not allowed due to other restrictions. As
an example of such a restriction, in the SDP Offer/Answer
model, the value of the level parameter that can be used in
an Answer is limited by what was specified in the Offer.
max-width:
The value is an integer greater than zero, specifying a
horizontal size for the coded frames, in luma samples
(pixels in the luma picture). If the value is less than the
maximum horizontal size allowed by the profile and level,
then the value specifies the preferred horizontal size.
Otherwise, it specifies the maximum horizontal size that is
supported.
If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the specified profile and
level.
max-height:
The value is an integer greater than zero, specifying a
vertical size for the coded frames, in luma samples (pixels
in a progressively coded luma picture). If the value is
less than the maximum vertical size allowed by the profile
and level, then the value specifies the preferred vertical
size. Otherwise, it specifies the maximum vertical size
that is supported.
If this parameter is not specified, it defaults to the
maximum vertical size allowed by the specified profile and
level.
max-bitrate:
The value is an integer greater than zero, specifying a peak
transmission rate for the coded bit stream in bits per
second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP, or IP headers.
If the value is less than the maximum bit rate allowed by
the profile and level, then the value specifies the
preferred bit rate. Otherwise, it specifies the maximum bit
rate that is supported.
If this parameter is not specified, it defaults to the
maximum bit rate allowed by the specified profile and level.
See the values for "RMax" in Annex D of SMPTE 421M [1].
max-buffer:
The value is an integer specifying a leaky bucket size, B,
in milliseconds, required to contain a stream transmitted at
the transmission rate specified by the max-bitrate
parameter. This parameter is defined in the hypothetical
reference decoder model for VC-1, in Annex C of SMPTE 421M
[1].
Note that this parameter relates to the codec bit stream
only and does not account for any buffering time that may be
required to compensate for jitter in the network.
If the value is less than the maximum leaky bucket size
allowed by the max-bitrate parameter and the profile and
level, then the value specifies the preferred leaky bucket
size. Otherwise, it specifies the maximum leaky bucket size
that is supported for the bit rate specified by the max-
bitrate parameter.
If this parameter is not specified, it defaults to the
maximum buffer size allowed by the specified profile and
level. See the values for "BMax" and "RMax" in Annex D of
SMPTE 421M [1].
max-framerate:
The value is an integer greater than zero, specifying a
number of frames per second for the coded bit stream. The
value is the frame rate multiplied by 1000 and rounded to
the nearest integer value. For example, 30000/1001
(approximately 29.97) frames per second is represented as
29970.
If the value is less than the maximum frame rate allowed by
the profile and level, then the value specifies the
preferred frame rate. Otherwise, it specifies the maximum
frame rate that is supported.
If the parameter is not specified, it defaults to the
maximum frame rate allowed by the specified profile and
level.
Encoding considerations:
This media type is framed and contains binary data.
Security considerations:
See Section 7 of RFC 4425.
Interoperability considerations:
None.
Published specification:
RFC 4425.
Applications that use this media type:
Multimedia streaming and conferencing tools.
Additional Information:
None.
Person & email address to contact for further information:
Anders Klemets <anderskl@microsoft.com>
IETF AVT working group.
Intended Usage:
COMMON
Restrictions on usage:
This media type depends on RTP framing; therefore, it is
only defined for transfer via RTP [3].
Authors:
Anders Klemets
Change controller:
IETF Audio/Video Transport Working Group delegated from the
IESG.
6.2. Mapping of media type parameters to SDP
The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[4]. If SDP is used to specify sessions using this payload format,
the mapping is done as follows:
o The media name in the "m=" line of SDP MUST be video (the type
name).
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the
subtype name).
o The clock rate in the "a=rtpmap" line MUST be 90000.
o The REQUIRED parameters "profile" and "level" MUST be included in
the "a=fmtp" line of SDP.
These parameters are expressed in the form of a semicolon
separated list of parameter=value pairs.
o The OPTIONAL parameters "config", "width", "height", "bitrate",
"buffer", "framerate", "bpic", "mode", "max-width", "max-height",
"max-bitrate", "max-buffer", and "max-framerate", when present,
MUST be included in the "a=fmtp" line of SDP.
These parameters are expressed in the form of a semicolon
separated list of parameter=value pairs:
a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>]
o Any unknown parameters to the device that uses the SDP MUST be
ignored. For example, parameters defined in later specifications
MAY be copied into the SDP and MUST be ignored by receivers that
do not understand them.
6.3. Usage with the SDP Offer/Answer Model
When VC-1 is offered over RTP using SDP in an Offer/Answer model [5]
for negotiation for unicast usage, the following rules and
limitations apply:
o The "profile" parameter MUST be used symmetrically, i.e., the
answerer MUST either maintain the parameter or remove the media
format (payload type) completely if the offered VC-1 profile is
not supported.
o The "level" parameter specifies the highest level of the VC-1
profile supported by the codec.
The answerer MUST NOT specify a numerically higher level in the
answer than that specified in the offer. The answerer MAY specify
a level that is lower than that specified in the offer, i.e., the
level parameter can be "downgraded".
If the offer specifies the sendrecv or sendonly direction
attribute and the answer downgrades the level parameter, this may
require a new offer to specify an updated "config" parameter. If
the "config" parameter cannot be used with the level specified in
the answer, then the offerer MUST initiate another Offer/Answer
round or not use media format (payload type).
o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer", and "mode", describe the properties of the
VC-1 bit stream that the offerer or answerer is sending for this
media format configuration.
In the case of unicast usage and when the direction attribute in
the offer or answer is recvonly, the interpretation of these
parameters is undefined and they MUST NOT be used.
o The parameters "config", "width", "height", "bitrate", and
"buffer" MUST be specified when the direction attribute is
sendrecv or sendonly.
o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate", and "max-buffer" MAY be specified in an offer or an
answer, and their interpretation is as follows:
When the direction attribute is sendonly, the parameters describe
the limits of the VC-1 bit stream that the sender is capable of
producing for the given profile and level, and for any lower level
of the same profile.
When the direction attribute is recvonly or sendrecv, the
parameters describe properties of the receiver implementation. If
the value of a property is less than that allowed by the level of
the VC-1 profile, then it SHALL be interpreted as a preferred
value and the sender’s VC-1 bit stream SHOULD NOT exceed it. If
the value of a property is greater than what is allowed by the
level of the VC-1 profile, then it SHALL be interpreted as the
upper limit of the value that the receiver accepts for the given
profile and level, and for any lower level of the same profile.
For example, if a recvonly or sendrecv offer specifies
"profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a
suggested bit rate, because all receiver implementations of Simple
profile, Low level, are required to support bit rates of up to 96
kbps. Assuming that the offer is accepted, the answerer should
specify "bitrate=48000" in the answer, but any value up to 96000
is allowed. But if the offer specifies "max-bitrate=200000", this
means that the receiver implementation supports a maximum of 200
kbps for the given profile and level (or lower level). In this
case, the answerer is allowed to answer with a bitrate parameter
of up to 200000.
o If an offerer wishes to have non-symmetrical capabilities between
sending and receiving, e.g., use different levels in each
direction, then the offerer has to offer different RTP sessions.
This can be done by specifying different media lines declared as
"recvonly" and "sendonly", respectively.
For streams being delivered over multicast, the following rules apply
in addition:
o The "level" parameter specifies the highest level of the VC-1
profile used by the participants in the multicast session. The