draft-ietf-avt-rtp-vc1-06.txt   rfc4425.txt 
Internet Engineering Task Force Network Working Group A. Klemets
Internet Draft A. Klemets Request for Comments: 4425 Microsoft
Document: draft-ietf-avt-rtp-vc1-06.txt Microsoft Category: Standards Track February 2006
Expires: July 2006 January 2006
RTP Payload Format for Video Codec 1 (VC-1) RTP Payload Format for Video Codec 1 (VC-1)
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This memo specifies an RTP payload format for encapsulating Video This memo specifies an RTP payload format for encapsulating Video
Codec 1 (VC-1) compressed bit streams, as defined by the Society of Codec 1 (VC-1) compressed bit streams, as defined by the Society of
Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.
SMPTE is the main standardizing body in the motion imaging industry SMPTE is the main standardizing body in the motion imaging industry,
and the SMPTE 421M standard defines a compressed video bit stream and the SMPTE 421M standard defines a compressed video bit stream
format and decoding process for television. format and decoding process for television.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................2
1.1 Conventions used in this document..........................3 1.1. Conventions Used in This Document ..........................3
2. Definitions and abbreviations..................................3 2. Definitions and Abbreviations ...................................3
3. Overview of VC-1...............................................5 3. Overview of VC-1 ................................................5
3.1 VC-1 bit stream layering model.............................5 3.1. VC-1 Bit Stream Layering Model .............................6
3.2 Bit-stream Data Units in Advanced profile..................6 3.2. Bit-stream Data Units in Advanced Profile ..................7
3.3 Decoder initialization parameters..........................6 3.3. Decoder Initialization Parameters ..........................7
3.4 Ordering of frames.........................................7 3.4. Ordering of Frames .........................................8
4. Encapsulation of VC-1 format bit streams in RTP................8 4. Encapsulation of VC-1 Format Bit Streams in RTP .................9
4.1 Access Units...............................................8 4.1. Access Units ...............................................9
4.2 Fragmentation of VC-1 frames...............................9 4.2. Fragmentation of VC-1 frames ..............................10
4.3 Time stamp considerations.................................10 4.3. Time Stamp Considerations .................................11
4.4 Random Access Points......................................12 4.4. Random Access Points ......................................13
4.5 Removal of HRD parameters.................................13 4.5. Removal of HRD Parameters .................................14
4.6 Repeating the Sequence Layer header.......................13 4.6. Repeating the Sequence Layer Header .......................14
4.7 Signaling of media type parameters........................14 4.7. Signaling of Media Type Parameters ........................15
4.8 The "mode=1" media type parameter.........................15 4.8. The "mode=1" Media Type Parameter .........................16
4.9 The "mode=3" media type parameter.........................15 4.9. The "mode=3" Media Type Parameter .........................16
5. RTP Payload Format syntax.....................................15 5. RTP Payload Format Syntax ......................................17
5.1 RTP header usage..........................................15 5.1. RTP Header Usage ..........................................17
5.2 AU header syntax..........................................16 5.2. AU Header Syntax ..........................................18
5.3 AU Control field syntax...................................18 5.3. AU Control Field Syntax ...................................19
6. RTP Payload format parameters.................................19 6. RTP Payload Format Parameters ..................................20
6.1 Media type Registration...................................19 6.1. Media type Registration ...................................20
6.2 Mapping of media type parameters to SDP...................26 6.2. Mapping of media type parameters to SDP ...................28
6.3 Usage with the SDP Offer/Answer Model.....................27 6.3. Usage with the SDP Offer/Answer Model .....................29
6.4 Usage in Declarative Session Descriptions.................29 6.4. Usage in Declarative Session Descriptions .................31
7. Security Considerations.......................................29 7. Security Considerations ........................................32
8. Congestion Control............................................30 8. Congestion Control .............................................33
9. IANA Considerations...........................................32 9. IANA Considerations ............................................34
10. References...................................................32 10. References ....................................................34
10.1 Normative references.....................................32 10.1. Normative References .....................................34
10.2 Informative references...................................32 10.2. Informative References ...................................35
1. Introduction 1. Introduction
This memo specifies an RTP payload format for the video coding This memo specifies an RTP payload format for the video coding
standard Video Codec 1, also known as VC-1. The specification for standard Video Codec 1, also known as VC-1. The specification for
the VC-1 bit stream format and decoding process is published by the the VC-1 bit stream format and decoding process is published by the
Society of Motion Picture and Television Engineers (SMPTE) as SMPTE Society of Motion Picture and Television Engineers (SMPTE) as SMPTE
421M [1]. 421M [1].
VC-1 has a broad applicability, being suitable for low bit rate VC-1 has a broad applicability, as it is suitable for low bit rate
Internet streaming applications to HDTV broadcast and Digital Cinema Internet streaming applications to High Definition Television (HDTV)
applications with nearly lossless coding. The overall performance of broadcast and Digital Cinema applications with nearly lossless
VC-1 is such that bit rate savings of more than 50% are reported [9], coding. The overall performance of VC-1 is such that bit rate
when compared against MPEG-2. See [9] for further details about how savings of more than 50% are reported [9] when compared with MPEG-2.
VC-1 compares against other codecs, such as MPEG-4 and H.264/AVC. See [9] for further details about how VC-1 compares with other
(In [9], VC-1 is referred to by its earlier name, VC-9.) codecs, such as MPEG-4 and H.264/AVC. (In [9], VC-1 is referred to
by its earlier name, VC-9.)
VC-1 is widely used for downloading and streaming of movies on the VC-1 is widely used for downloading and streaming movies on the
Internet, in the form of Windows Media Video 9 (WMV-9) [9], because Internet, in the form of Windows Media Video 9 (WMV-9) [9], because
the WMV-9 codec is compliant with the VC-1 standard. VC-1 has also the WMV-9 codec is compliant with the VC-1 standard. VC-1 has also
recently been adopted as a mandatory compression format for the high- recently been adopted as a mandatory compression format for the
definition DVD formats HD DVD and Blu-ray. high-definition DVD formats HD DVD and Blu-ray.
SMPTE 421M defines the VC-1 bit stream syntax and specifies SMPTE 421M defines the VC-1 bit stream syntax and specifies
constraints that must be met by VC-1 conformant bit streams. SMPTE constraints that must be met by VC-1 conformant bit streams. SMPTE
421M also specifies the complete process required to decode the bit 421M also specifies the complete process required to decode the bit
stream. However, it does not specify the VC-1 compression algorithm, stream. However, it does not specify the VC-1 compression algorithm,
thus allowing for different ways to implement a VC-1 encoder. thus allowing for different ways of implementing a VC-1 encoder.
The VC-1 bit stream syntax has three profiles. Each profile has The VC-1 bit stream syntax has three profiles. Each profile has
specific bit stream syntax elements and algorithms associated with specific bit stream syntax elements and algorithms associated with
it. Depending on the application in which VC-1 is used, some it. Depending on the application in which VC-1 is used, some
profiles may be more suitable than others. For example, Simple profiles may be more suitable than others. For example, Simple
profile is designed for low bit rate Internet streaming and for profile is designed for low bit rate Internet streaming and for
playback on devices that can only handle low complexity decoding. playback on devices that can only handle low-complexity decoding.
Advanced profile is designed for broadcast applications, such as Advanced profile is designed for broadcast applications, such as
digital TV, HD DVD or HDTV. Advanced profile is the only VC-1 digital TV, HD DVD, or HDTV. Advanced profile is the only VC-1
profile that supports interlaced video frames and non-square pixels. profile that supports interlaced video frames and non-square pixels.
Section 2 defines the abbreviations used in this document. Section 3 Section 2 defines the abbreviations used in this document. Section 3
provides a more detailed overview of VC-1. Sections 4 and 5 define provides a more detailed overview of VC-1. Sections 4 and 5 define
the RTP payload format for VC-1, and section 6 defines the media type the RTP payload format for VC-1, and section 6 defines the media type
and SDP parameters for VC-1. See section 7 for security and SDP parameters for VC-1. See section 7 for security
considerations, and section 8 for congestion control requirements. considerations, and section 8 for congestion control requirements.
1.1 Conventions used in this document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2]. document are to be interpreted as described in BCP 14, RFC 2119 [2].
2. Definitions and abbreviations 2. Definitions and Abbreviations
This document uses the definitions in SMPTE 421M [1]. For This document uses the definitions in SMPTE 421M [1]. For
convenience, the following terms from SMPTE 421M are restated here: convenience, the following terms from SMPTE 421M are restated here:
B-picture: A picture that is coded using motion compensated B-picture:
prediction from past and/or future reference fields or frames. A B- A picture that is coded using motion compensated prediction
picture cannot be used for predicting any other picture. from past and/or future reference fields or frames. A
B-picture cannot be used for predicting any other picture.
BI-picture: A B-picture that is coded using information only from BI-picture:
itself. A BI-picture cannot be used for predicting any other A B-picture that is coded using information only from itself.
picture. A BI-picture cannot be used for predicting any other picture.
Bit-stream data unit (BDU): A unit of the compressed data which may Bit-stream data unit (BDU):
be parsed (i.e., syntax decoded) independently of other information A unit of the compressed data which may be parsed (i.e., syntax
at the same hierarchical level. A BDU can be, for example, a decoded) independently of other information at the same
sequence layer header, an entry-point header, a frame, or a slice. hierarchical level. A BDU can be, for example, a sequence
layer header, an entry-point header, a frame, or a slice.
Encapsulated BDU (EBDU): A BDU which has been encapsulated using the Encapsulated BDU (EBDU):
encapsulation mechanism described in Annex E of SMPTE 421M [1], to A BDU that has been encapsulated using the encapsulation
prevent emulation of the start code prefix in the bit stream. mechanism described in Annex E of SMPTE 421M [1], to prevent
emulation of the start code prefix in the bit stream.
Entry-point: A point in the bit stream that offers random access. Entry-point:
A point in the bit stream that offers random access.
frame: A frame contains lines of spatial information of a video frame:
signal. For progressive video, these lines contain samples starting A frame contains lines of spatial information of a video
from one time instant and continuing through successive lines to the signal. For progressive video, these lines contain samples
bottom of the frame. For interlaced video, a frame consists of two starting from one time instant and continuing through
fields, a top field and a bottom field. One of these fields will successive lines to the bottom of the frame. For interlaced
commence one field period later than the other. video, a frame consists of two fields, a top field and a bottom
field. One of these fields will commence one field period
later than the other.
interlace: The property of frames where alternating lines of the interlace:
frame represent different instances in time. In an interlaced frame, The property of frames where alternating lines of the frame
represent different instances in time. In an interlaced frame,
one of the fields is meant to be displayed first. one of the fields is meant to be displayed first.
I-picture: A picture coded using information only from itself. I-picture:
A picture coded using information only from itself.
level: A defined set of constraints on the values which may be taken level:
by the parameters (such as bit rate and buffer size) within a A defined set of constraints on the values that may be taken by
the parameters (such as bit rate and buffer size) within a
particular profile. A profile may contain one or more levels. particular profile. A profile may contain one or more levels.
P-picture: A picture that is coded using motion compensated P-picture:
prediction from past reference fields or frames. A picture that is coded using motion compensated prediction
from past reference fields or frames.
picture: For progressive video, a picture is identical to a frame, picture:
while for interlaced video, a picture may refer to a frame, or the For progressive video, a picture is identical to a frame, while
top field or the bottom field of the frame depending on the context. for interlaced video, a picture may refer to a frame, or the
top field or the bottom field of the frame depending on the
context.
profile: A defined subset of the syntax of VC-1, with a specific set profile:
of coding tools, algorithms, and syntax associated with it. There A defined subset of the syntax of VC-1 with a specific set of
are three VC-1 profiles: Simple, Main and Advanced. coding tools, algorithms, and syntax associated with it. There
are three VC-1 profiles: Simple, Main, and Advanced.
progressive: The property of frames where all the samples of the progressive:
frame represent the same instance in time. The property of frames where all the samples of the frame
represent the same instance in time.
random access: A random access point in the bit stream is defined by random access:
the following guarantee: If decoding begins at this point, all frames A random access point in the bit stream is defined by the
needed for display after this point will have no decoding dependency following guarantee: If decoding begins at this point, all
on any data preceding this point, and are also present in the frames needed for display after this point will have no
decoding sequence after this point. A random access point is also decoding dependency on any data preceding this point, and they
called an entry-point. are also present in the decoding sequence after this point. A
random access point is also called an entry-point.
sequence: A coded representation of a series of one or more pictures. sequence:
In VC-1 Advanced profile, a sequence consists of a series of one or A coded representation of a series of one or more pictures. In
more entry-point segments, where each entry-point segment consists of VC-1 Advanced profile, a sequence consists of a series of one
a series of one or more pictures, and where the first picture in each or more entry-point segments, where each entry-point segment
entry-point segment provides random access. In VC-1 Simple and Main consists of a series of one or more pictures, and where the
profiles, the first picture in each sequence is an I-picture. first picture in each entry-point segment provides random
access. In VC-1 Simple and Main profiles, the first picture in
each sequence is an I-picture.
slice: A consecutive series of macroblock rows in a picture, which slice:
are encoded as a single unit. A consecutive series of macroblock rows in a picture, which are
encoded as a single unit.
start codes (SC): 32-bit codes embedded in that coded bit stream that start codes (SC):
are unique, and identify the beginning of a BDU. Start codes consist Unique 32-bit codes that are embedded in the coded bit stream
of a unique three-byte Start Code Prefix (SCP), and a one-byte Start and identify the beginning of a BDU. Start codes consist of a
unique three-byte Start Code Prefix (SCP), and a one-byte Start
Code Suffix (SCS). Code Suffix (SCS).
3. Overview of VC-1 3. Overview of VC-1
The VC-1 bit stream syntax consists of three profiles: Simple, Main, The VC-1 bit stream syntax consists of three profiles: Simple, Main,
and Advanced. Simple profile is designed for low bit rates and for and Advanced. Simple profile is designed for low bit rates and for
low complexity applications, such as playback of media on personal low complexity applications, such as playback of media on personal
digital assistants. The maximum bit rate supported by Simple profile digital assistants. The maximum bit rate supported by Simple profile
is 384 kbps. Main profile is targets high bit rate applications, is 384 kbps. Main profile targets high bit rate applications, such
such as streaming and TV over IP. Main profile supports B-pictures, as streaming and TV over IP. Main profile supports B-pictures, which
which provide improved compression efficiency at the cost of higher provide improved compression efficiency at the cost of higher
complexity. complexity.
Certain features that can be used to achieve high compression Certain features that can be used to achieve high compression
efficiency, such as non-square pixels and support for interlaced efficiency, such as non-square pixels and support for interlaced
pictures, are only included in Advanced profile. The maximum bit pictures, are only included in Advanced profile. The maximum bit
rate supported by the Advanced profile is 135 Mbps, making it rate supported by the Advanced profile is 135 Mbps, making it
suitable for nearly lossless encoding of HDTV signals. suitable for nearly lossless encoding of HDTV signals.
Only Advanced profile supports carrying user-data (meta-data) in-band Only Advanced profile supports carrying user-data (meta-data) in-band
with the compressed bit stream. The user-data can be used for closed with the compressed bit stream. The user-data can be used for closed
captioning support, for example. captioning support, for example.
Of the three profiles, only Advanced profile allows codec Of the three profiles, only Advanced profile allows codec
configuration parameters, such as the picture aspect ratio, to be configuration parameters, such as the picture aspect ratio, to be
changed through in-band signaling in the compressed bit stream. changed through in-band signaling in the compressed bit stream.
For each of the profiles, a certain number of "levels" have been For each of the profiles, a certain number of "levels" have been
defined. Unlike a "profile", which implies a certain set of features defined. Unlike a "profile", which implies a certain set of features
skipping to change at page 5, line 42 skipping to change at page 6, line 26
with the compressed bit stream. The user-data can be used for closed with the compressed bit stream. The user-data can be used for closed
captioning support, for example. captioning support, for example.
Of the three profiles, only Advanced profile allows codec Of the three profiles, only Advanced profile allows codec
configuration parameters, such as the picture aspect ratio, to be configuration parameters, such as the picture aspect ratio, to be
changed through in-band signaling in the compressed bit stream. changed through in-band signaling in the compressed bit stream.
For each of the profiles, a certain number of "levels" have been For each of the profiles, a certain number of "levels" have been
defined. Unlike a "profile", which implies a certain set of features defined. Unlike a "profile", which implies a certain set of features
or syntax elements, a "level" is a set of constraints on the values or syntax elements, a "level" is a set of constraints on the values
of parameters in a profile, such as the bit rate or buffer size. VC- of parameters in a profile, such as the bit rate or buffer size.
1 Simple profile has two levels, Main profile has three, and Advanced VC-1 Simple profile has two levels, Main profile has three, and
profile has five levels. See Annex D of SMPTE 421M [1] for a Advanced profile has five. See Annex D of SMPTE 421M [1] for a
detailed list of the profiles and levels. detailed list of the profiles and levels.
3.1 VC-1 bit stream layering model 3.1. VC-1 Bit Stream Layering Model
The VC-1 bit stream is defined as a hierarchy of layers. This is The VC-1 bit stream is defined as a hierarchy of layers. This is
conceptually similar to the notion of a protocol stack of networking conceptually similar to the notion of a protocol stack of networking
protocols. The outermost layer is called the sequence layer. The protocols. The outermost layer is called the sequence layer. The
other layers are entry-point, picture, slice, macroblock and block. other layers are entry-point, picture, slice, macroblock, and block.
In Simple and Main profiles, a sequence in the sequence layer In Simple and Main profiles, a sequence in the sequence layer
consists of a series of one or more coded pictures. In Advanced consists of a series of one or more coded pictures. In Advanced
profile, a sequence consists of one or more entry-point segments, profile, a sequence consists of one or more entry-point segments,
where each entry-point segment consists of a series of one or more where each entry-point segment consists of a series of one or more
pictures, and where the first picture in each entry-point segment pictures, and where the first picture in each entry-point segment
provides random access. A picture is decomposed into macroblocks. A provides random access. A picture is decomposed into macroblocks. A
slice comprises one or more contiguous rows of macroblocks. slice comprises one or more contiguous rows of macroblocks.
The entry-point and slice layers are only present in Advanced The entry-point and slice layers are only present in Advanced
profile. In Advanced profile, the start of each entry-point layer profile. In Advanced profile, the start of each entry-point layer
segment indicates a random access point. In Simple and Main profiles segment indicates a random access point. In Simple and Main
each I-picture is a random access point. profiles, each I-picture is a random access point.
Each picture can be coded as an I-picture, P-picture, skipped Each picture can be coded as an I-picture, P-picture, skipped
picture, BI-picture, or as a B-picture. These terms are defined in picture, BI-picture, or as a B-picture. These terms are defined in
section 2 of this document and in section 4.12 of SMPTE 421M [1]. section 2 of this document and in section 4.12 of SMPTE 421M [1].
3.2 Bit-stream Data Units in Advanced profile 3.2. Bit-stream Data Units in Advanced Profile
In Advanced profile, each picture and slice is considered a Bit- In Advanced profile, each picture and slice is considered a Bit-
stream Data Unit (BDU). A BDU is always byte-aligned and is defined stream Data Unit (BDU). A BDU is always byte-aligned and is defined
as a unit that can be parsed (i.e., syntax decoded) independently of as a unit that can be parsed (i.e., syntax decoded) independently of
other information in the same layer. other information in the same layer.
The beginning of a BDU is signaled by an identifier called Start Code The beginning of a BDU is signaled by an identifier called Start Code
(SC). Sequence layer headers and entry-point headers are also BDUs (SC). Sequence layer headers and entry-point headers are also BDUs
and thus can be easily identified by their Start Codes. See Annex E and thus can be easily identified by their Start Codes. See Annex E
of SMPTE 421M [1] for a complete list of Start Codes. Blocks and of SMPTE 421M [1] for a complete list of Start Codes. Blocks and
skipping to change at page 6, line 45 skipping to change at page 7, line 32
The Start Code consists of four bytes. The first three bytes are The Start Code consists of four bytes. The first three bytes are
0x00, 0x00 and 0x01. The fourth byte is called the Start Code Suffix 0x00, 0x00 and 0x01. The fourth byte is called the Start Code Suffix
(SCS) and it is used to indicate the type of BDU that follows the (SCS) and it is used to indicate the type of BDU that follows the
Start Code. For example, the SCS of a sequence layer header (0x0F) Start Code. For example, the SCS of a sequence layer header (0x0F)
is different from the SCS of an entry-point header (0x0E). The Start is different from the SCS of an entry-point header (0x0E). The Start
Code is always byte-aligned and is transmitted in network byte order. Code is always byte-aligned and is transmitted in network byte order.
To prevent accidental emulation of the Start Code in the coded bit To prevent accidental emulation of the Start Code in the coded bit
stream, SMPTE 421M defines an encapsulation mechanism that uses byte stream, SMPTE 421M defines an encapsulation mechanism that uses byte
stuffing. A BDU which has been encapsulated by this mechanism is stuffing. A BDU that has been encapsulated by this mechanism is
referred to as an Encapsulated BDU, or EBDU. referred to as an Encapsulated BDU, or EBDU.
3.3 Decoder initialization parameters 3.3. Decoder Initialization Parameters
In VC-1 Advanced profile, the sequence layer header contains In VC-1 Advanced profile, the sequence layer header contains
parameters that are necessary to initialize the VC-1 decoder. parameters that are necessary to initialize the VC-1 decoder.
The parameters apply to all entry-point segments until the next The parameters apply to all entry-point segments until the next
occurrence of a sequence layer header in the coded bit stream. occurrence of a sequence layer header in the coded bit stream.
The parameters in the sequence layer header include the Advanced The parameters in the sequence layer header include the Advanced
profile level, the maximum dimensions of the coded frames, the aspect profile level, the maximum dimensions of the coded frames, the aspect
ratio, interlace information, the frame rate and up to 31 leaky ratio, interlace information, the frame rate and up to 31 leaky
bucket parameter sets for the Hypothetical Reference Decoder (HRD). bucket parameter sets for the Hypothetical Reference Decoder (HRD).
Section 6.1 of SMPTE 421M [1] provides the formal specification of Section 6.1 of SMPTE 421M [1] provides the formal specification of
the sequence layer header. the sequence layer header.
A sequence layer header is not defined for VC-1 Simple and Main A sequence layer header is not defined for VC-1 Simple and Main
profiles. For these profiles, decoder initialization parameters MUST profiles. For these profiles, decoder initialization parameters MUST
be conveyed out-of-band. The decoder initialization parameters for be conveyed out-of-band. The decoder initialization parameters for
Simple and Main profiles include the maximum dimensions of the coded Simple and Main profiles include the maximum dimensions of the coded
frames, and a leaky bucket parameter set for the HRD. Section 4.7 frames and a leaky bucket parameter set for the HRD. Section 4.7
specifies how the parameters are conveyed by this RTP payload format. specifies how the parameters are conveyed by this RTP payload format.
Each leaky bucket parameter set for the HRD specifies a peak Each leaky bucket parameter set for the HRD specifies a peak
transmission bit rate and a decoder buffer capacity. The coded bit transmission bit rate and a decoder buffer capacity. The coded bit
stream is restricted by these parameters. The HRD model does not stream is restricted by these parameters. The HRD model does not
mandate buffering by the decoder. Its purpose is to limit the mandate buffering by the decoder. Its purpose is to limit the
encoder's bit rate fluctuations according to a basic buffering model, encoder's bit rate fluctuations according to a basic buffering model
so that the resources necessary to decode the bit stream are so that the resources necessary to decode the bit stream are
predictable. The HRD has a constant-delay mode and a variable-delay predictable. The HRD has a constant-delay mode and a variable-delay
mode. The constant-delay mode is appropriate for broadcast and mode. The constant-delay mode is appropriate for broadcast and
streaming applications, while the variable-delay mode is designed for streaming applications, while the variable-delay mode is designed for
video conferencing applications. video-conferencing applications.
Annex C of SMPTE 421M [1] specifies the usage of the hypothetical Annex C of SMPTE 421M [1] specifies the usage of the hypothetical
reference decoder for VC-1 bit streams. A general description of the reference decoder for VC-1 bit streams. A general description of the
theory of the HRD can be found in [10]. theory of the HRD can be found in [10].
For Simple and Main profiles, the current buffer fullness value for For Simple and Main profiles, the current buffer fullness value for
the HRD leaky bucket is signaled using the BF syntax element in the the HRD leaky bucket is signaled using the BF syntax element in the
picture header of I-pictures and BI-pictures. picture header of I-pictures and BI-pictures.
For Advanced profile, the entry-point header specifies current buffer For Advanced profile, the entry-point header specifies current buffer
fullness values for the leaky buckets in the HRD. The entry-point fullness values for the leaky buckets in the HRD. The entry-point
header also specifies coding control parameters that are in effect header also specifies coding control parameters that are in effect
until the occurrence of the next entry-point header in the bit until the occurrence of the next entry-point header in the bit
stream. The concept of an entry-point layer applies only to VC-1 stream. The concept of an entry-point layer applies only to VC-1
Advanced profile. See Section 6.2 of SMPTE 421M [1] for the formal Advanced profile. See Section 6.2 of SMPTE 421M [1] for the formal
specification of the entry-point header. specification of the entry-point header.
3.4 Ordering of frames 3.4. Ordering of Frames
Frames are transmitted in the same order in which they are captured, Frames are transmitted in the same order in which they are captured,
except if B-pictures or BI-pictures are present in the coded bit except if B-pictures or BI-pictures are present in the coded bit
stream. A BI-picture is a special kind of B-picture, and in the stream. A BI-picture is a special kind of B-picture, and in the
remainder of this section the terms B-picture and B-frame also apply remainder of this section the terms B-picture and B-frame also apply
to BI-pictures and BI-frames, respectively. to BI-pictures and BI-frames, respectively.
When B-pictures are present in the coded bit stream, the frames are When B-pictures are present in the coded bit stream, the frames are
transmitted such that the frames that the B-pictures depend on are transmitted such that the frames that the B-pictures depend on are
transmitted first. This is referred to as the coded order of the transmitted first. This is referred to as the coded order of the
skipping to change at page 8, line 36 skipping to change at page 9, line 28
Capture: |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9 ... Capture: |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9 ...
| |
Coded order: | I0 P1 P4 B2 B3 P7 B5 B6 ... Coded order: | I0 P1 P4 B2 B3 P7 B5 B6 ...
| |
Display order: | I0 P1 B2 B3 P4 B5 B6 ... Display order: | I0 P1 B2 B3 P4 B5 B6 ...
| |
|+---+---+---+---+---+---+---+---+---+--> time |+---+---+---+---+---+---+---+---+---+--> time
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
Figure 1. Frame reordering when B-pictures are present. Figure 1. Frame reordering when B-pictures are present
If B-pictures are not present, the coded order and the display order If B-pictures are not present, the coded order and the display order
are identical, and frames can then be displayed without additional are identical, and frames can then be displayed without the
delay shown in Figure 1. additional delay shown in Figure 1.
4. Encapsulation of VC-1 format bit streams in RTP 4. Encapsulation of VC-1 Format Bit Streams in RTP
4.1 Access Units 4.1. Access Units
Each RTP packet contains an integral number of application data units Each RTP packet contains an integral number of application data units
(ADUs). For VC-1 format bit streams, an ADU is equivalent to one (ADUs). For VC-1 format bit streams, an ADU is equivalent to one
Access Unit (AU). An Access Unit is defined as the AU header Access Unit (AU). An Access Unit is defined as the AU header
(defined in section 5.2) followed by a variable length payload, with (defined in section 5.2) followed by a variable length payload, with
the rules and constraints described in sections 4.1 and 4.2. Figure the rules and constraints described in sections 4.1 and 4.2. Figure
2 shows the layout of an RTP packet with multiple AUs. 2 shows the layout of an RTP packet with multiple AUs.
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
| RTP | AU(1) | AU(2) | | AU(n) | | RTP | AU(1) | AU(2) | | AU(n) |
| Header | | | | | | Header | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
Figure 2. RTP packet structure. Figure 2. RTP packet structure
Each Access Unit MUST start with the AU header defined in section Each Access Unit MUST start with the AU header defined in section
5.2. The AU payload MUST contain data belonging to exactly one VC-1 5.2. The AU payload MUST contain data belonging to exactly one VC-1
frame. This means that data from different VC-1 frames will always frame. This means that data from different VC-1 frames will always
be in different AUs, however, it possible for a single VC-1 frame to be in different AUs. However, it possible for a single VC-1 frame to
be fragmented across multiple AUs (see section 4.2.) be fragmented across multiple AUs (see section 4.2).
In the case of interlaced video, a VC-1 frame consists of two fields In the case of interlaced video, a VC-1 frame consists of two fields
that may be coded as separate pictures. The two pictures still that may be coded as separate pictures. The two pictures still
belong to the same VC-1 frame. belong to the same VC-1 frame.
The following rules apply to the contents of each AU payload when VC- The following rules apply to the contents of each AU payload when
1 Advanced profile is used: VC-1 Advanced profile is used:
- The AU payload MUST contain VC-1 bit stream data in EBDU format - The AU payload MUST contain VC-1 bit stream data in EBDU format
(i.e., the bit stream must use the byte-stuffing encapsulation (i.e., the bit stream must use the byte-stuffing encapsulation
mode defined in Annex E of SMPTE 421M [1].) mode defined in Annex E of SMPTE 421M [1].)
- The AU payload MAY contain multiple EBDUs, e.g., a sequence layer - The AU payload MAY contain multiple EBDUs, e.g., a sequence layer
header, an entry-point header, a frame (picture) header, a field header, an entry-point header, a frame (picture) header, a field
header, and multiple slices and the associated user-data. header, and multiple slices and the associated user-data.
(However, all slices and their corresponding macroblocks MUST However, all slices and their corresponding macroblocks MUST
belong to the same video frame.) belong to the same video frame.
- The AU payload MUST start at an EBDU boundary, except when the AU - The AU payload MUST start at an EBDU boundary, except when the AU
payload contains a fragmented frame, in which case the rules in payload contains a fragmented frame, in which case the rules in
section 4.2 apply. section 4.2 apply.
When VC-1 Simple or Main profiles are used, the AU payload MUST start When VC-1 Simple or Main profiles are used, the AU payload MUST start
at the beginning of a frame, except when the AU payload contains a at the beginning of a frame, except when the AU payload contains a
fragmented frame. Section 4.2 describes how to handle fragmented fragmented frame. Section 4.2 describes how to handle fragmented
frames. frames.
Access Units MUST be byte-aligned. If the data in an AU (EBDUs in Access Units MUST be byte-aligned. If the data in an AU (EBDUs in
the case of Advanced profile and frame in the case of Simple and the case of Advanced profile and frame in the case of Simple and
Main) does not end at an octet boundary, up to 7 zero-valued padding Main) does not end at an octet boundary, up to 7 zero-valued padding
bits MUST be added to achieve octet-alignment. bits MUST be added to achieve octet-alignment.
4.2 Fragmentation of VC-1 frames 4.2. Fragmentation of VC-1 frames
Each AU payload SHOULD contain a complete VC-1 frame. However, if Each AU payload SHOULD contain a complete VC-1 frame. However, if
this would cause the RTP packet to exceed the MTU size, the frame this would cause the RTP packet to exceed the MTU size, the frame
SHOULD be fragmented into multiple AUs to avoid IP-level SHOULD be fragmented into multiple AUs to avoid IP-level
fragmentation. When an AU contains a fragmented frame, this MUST be fragmentation. When an AU contains a fragmented frame, this MUST be
indicated by setting the FRAG field in the AU header as defined in indicated by setting the FRAG field in the AU header as defined in
section 5.3. section 5.3.
AU payloads that do not contain a fragmented frame, or that contain AU payloads that do not contain a fragmented frame or that contain
the first fragment of a frame, MUST start at an EBDU boundary if the first fragment of a frame MUST start at an EBDU boundary if
Advanced profile is used. In this case, for Simple and Main Advanced profile is used. In this case, for Simple and Main
profiles, the AU payload MUST start at the beginning of a frame. profiles, the AU payload MUST start at the beginning of a frame.
If Advanced profile is used, AU payloads that contain a fragment of a If Advanced profile is used, AU payloads that contain a fragment of a
frame other than the first fragment, SHOULD start at an EBDU frame other than the first fragment SHOULD start at an EBDU boundary,
boundary, such as at the start of a slice. such as at the start of a slice.
However, slices are only defined for Advanced profile, and are not However, slices are only defined for Advanced profile, and are not
always used. Blocks and macroblocks are not BDUs (have no Start always used. Blocks and macroblocks are not BDUs (have no Start
Code) and are not byte-aligned. Therefore, it may not always be Code) and are not byte-aligned. Therefore, it may not always be
possible to continue a fragmented frame at an EBDU boundary. One can possible to continue a fragmented frame at an EBDU boundary. One can
determine if an AU payload starts at an EBDU boundary by inspecting determine if an AU payload starts at an EBDU boundary by inspecting
the first three bytes of the AU payload. The AU payload starts at an the first three bytes of the AU payload. The AU payload starts at an
EBDU boundary if the first three bytes are identical to the Start EBDU boundary if the first three bytes are identical to the Start
Code Prefix (i.e., 0x00, 0x00, 0x01.) Code Prefix (i.e., 0x00, 0x00, 0x01).
In the case of Simple and Main profiles, since the blocks and In the case of Simple and Main profiles, since the blocks and
macroblocks are not byte-aligned, the fragmentation boundary may be macroblocks are not byte-aligned, the fragmentation boundary may be
chosen arbitrarily. chosen arbitrarily.
If an RTP packet contains an AU with the last fragment of a frame, If an RTP packet contains an AU with the last fragment of a frame,
additional AUs SHOULD NOT be included in the RTP packet. additional AUs SHOULD NOT be included in the RTP packet.
If the PTS Delta field in the AU header is present, each fragment of If the PTS Delta field in the AU header is present, each fragment of
a frame MUST have the same presentation time. If the DTS Delta field a frame MUST have the same presentation time. If the DTS Delta field
in the AU header is present, each fragment of a frame MUST have the in the AU header is present, each fragment of a frame MUST have the
same decode time. same decode time.
4.3 Time stamp considerations 4.3. Time Stamp Considerations
VC-1 video frames MUST be transmitted in the coded order. Coded VC-1 video frames MUST be transmitted in the coded order. A coded
order implies that no frames are dependent on subsequent frames, as order implies that no frames are dependent on subsequent frames, as
discussed in section 3.4. When a video frame consists of a single discussed in section 3.4. When a video frame consists of a single
picture, the presentation time of the frame is identical to the picture, the presentation time of the frame is identical to the
presentation time of the picture. When the VC-1 interlace coding presentation time of the picture. When the VC-1 interlace coding
mode is used, frames may contain two pictures, one for each field. mode is used, frames may contain two pictures, one for each field.
In that case, the presentation time of a frame is the presentation In that case, the presentation time of a frame is the presentation
time of the field that is displayed first. time of the field that is displayed first.
The RTP timestamp field MUST be set to the presentation time of the The RTP timestamp field MUST be set to the presentation time of the
video frame contained in the first AU in the RTP packet. The video frame contained in the first AU in the RTP packet. The
skipping to change at page 11, line 26 skipping to change at page 12, line 24
B- nor BI-pictures are present in the coded bit stream, then the B- nor BI-pictures are present in the coded bit stream, then the
decode time of a frame SHALL be equal to the presentation time of the decode time of a frame SHALL be equal to the presentation time of the
frame. A BI-picture is a special kind of B-picture, and in the frame. A BI-picture is a special kind of B-picture, and in the
remainder of this section the terms B-picture and B-frame also apply remainder of this section the terms B-picture and B-frame also apply
to BI-pictures and BI-frames, respectively. to BI-pictures and BI-frames, respectively.
If B-pictures may be present in the coded bit stream, then the decode If B-pictures may be present in the coded bit stream, then the decode
times of frames are determined as follows: times of frames are determined as follows:
- B-frames: - B-frames:
The decode time SHALL be equal to the presentation time of the B- The decode time SHALL be equal to the presentation time of the
frame. B-frame.
- First non-B frame in the coded order: - First non-B frame in the coded order:
The decode time SHALL be at least one frame period less than the The decode time SHALL be at least one frame period less than the
decode time of the next frame in the coded order. A frame period decode time of the next frame in the coded order. A frame period
is defined as the inverse of the frame rate used in the coded bit is defined as the inverse of the frame rate used in the coded bit
stream (e.g., 100 milliseconds if the frame rate is 10 frames per stream (e.g., 100 milliseconds if the frame rate is 10 frames per
seconds.) For bit streams with a variable frame rate, the maximum seconds.) For bit streams with a variable frame rate, the maximum
frame rate SHALL determine the frame period. If the maximum frame frame rate SHALL determine the frame period. If the maximum frame
is not specified, the maximum frame rate allowed by the profile is not specified, the maximum frame rate allowed by the profile
and level SHALL be used. and level SHALL be used.
skipping to change at page 12, line 24 skipping to change at page 13, line 21
possible uses include buffer management and pacing of frames prior to possible uses include buffer management and pacing of frames prior to
decoding. If RTP packets are lost, it is possible to use the DTS decoding. If RTP packets are lost, it is possible to use the DTS
Delta field to determine if the sequence of lost RTP packets Delta field to determine if the sequence of lost RTP packets
contained reference frames or only B-frames. This can be done by contained reference frames or only B-frames. This can be done by
comparing the decode and presentation times of the first frame comparing the decode and presentation times of the first frame
received after the lost sequence against the presentation time of the received after the lost sequence against the presentation time of the
last reference frame received prior to the lost sequence. last reference frame received prior to the lost sequence.
Knowing if the stream will contain B-pictures may help the receiver Knowing if the stream will contain B-pictures may help the receiver
allocate resources more efficiently and can reduce delay, as an allocate resources more efficiently and can reduce delay, as an
absence of B-pictures in the stream implies that no reordering absence of B-pictures in the stream implies that no reordering of
of frames will be needed between the decoding process and the display frames will be needed between the decoding process and the display of
of the decoded frames. This may be important for interactive the decoded frames. This may be important for interactive
applications. applications.
The receiver SHALL assume that the coded bit stream may contain B- The receiver SHALL assume that the coded bit stream may contain
pictures in the following cases: B-pictures in the following cases:
- Advanced profile: If the value of the "bpic" media type parameter - Advanced profile:
defined in section 6.1 is 1, or if the "bpic" parameter is not If the value of the "bpic" media type parameter defined in section
specified. 6.1 is 1, or if the "bpic" parameter is not specified.
- Main profile: If the MAXBFRAMES field in STRUCT_C decoder - Main profile:
initialization parameter has a non-zero value. STRUCT_C is If the MAXBFRAMES field in STRUCT_C decoder initialization
conveyed in the "config" media type parameter, which is defined in parameter has a non-zero value. STRUCT_C is conveyed in the
section 6.1. "config" media type parameter, which is defined in section 6.1.
Simple profile does not use B-pictures. Simple profile does not use B-pictures.
4.4 Random Access Points 4.4. Random Access Points
The entry-point header contains information that is needed by the The entry-point header contains information that is needed by the
decoder to decode the frames in that entry-point segment. This means decoder to decode the frames in that entry-point segment. This means
that in the event of lost RTP packets the decoder may be unable to that in the event of lost RTP packets, the decoder may be unable to
decode frames until the next entry-point header is received. decode frames until the next entry-point header is received.
The first frame after an entry-point header is a random access points The first frame after an entry-point header is a random access point
into the coded bit stream. Simple and Main profiles do not have into the coded bit stream. Simple and Main profiles do not have
entry-point headers, so for those profiles each I-picture is a random entry-point headers, so for those profiles, each I-picture is a
access point. random access point.
To allow the RTP receiver to detect that an RTP packet which was lost To allow the RTP receiver to detect that an RTP packet that was lost
contained a random access point, this RTP payload format defines a contained a random access point, this RTP payload format defines a
field called "RA Count". This field is present in every AU, and its field called "RA Count". This field is present in every AU, and its
value is incremented (modulo 256) for every random access point. For value is incremented (modulo 256) for every random access point. For
additional details, see the definition of "RA Count" in section 5.2. additional details, see the definition of "RA Count" in section 5.2.
To make it easy to determine if an AU contains a random access point, To make it easy to determine if an AU contains a random access point,
this RTP payload format also defines a bit called the "RA" flag in this RTP payload format also defines a bit called the "RA" flag in
the AU Control field. This bit is set to 1 only on those AU's that the AU Control field. This bit is set to 1 only on those AU's that
contain a random access point. The RA bit is defined in section 5.3. contain a random access point. The RA bit is defined in section 5.3.
4.5 Removal of HRD parameters 4.5. Removal of HRD Parameters
The sequence layer header of Advanced profile may include up to 31 The sequence layer header of Advanced profile may include up to 31
leaky bucket parameter sets for the Hypothetical Reference Decoder leaky bucket parameter sets for the Hypothetical Reference Decoder
(HRD). Each leaky bucket parameter set specifies a possible peak (HRD). Each leaky bucket parameter set specifies a possible peak
transmission bit rate (HRD_RATE) and a decoder buffer capacity transmission bit rate (HRD_RATE) and a decoder buffer capacity
(HRD_BUFFER). (See section 3.3 for additional discussion about the (HRD_BUFFER). See section 3.3 for additional discussion about the
HRD.) HRD.
If the actual peak transmission rate is known by the RTP sender, the If the actual peak transmission rate is known by the RTP sender, the
RTP sender MAY remove all leaky bucket parameter sets except for the RTP sender MAY remove all leaky bucket parameter sets except for the
one corresponding to the actual peak transmission rate. one corresponding to the actual peak transmission rate.
For each leaky bucket parameter set in the sequence layer header, For each leaky bucket parameter set in the sequence layer header,
there is also parameter in the entry-point header that specifies the there is also a parameter in the entry-point header that specifies
initial fullness (HRD_FULL) of the leaky bucket. the initial fullness (HRD_FULL) of the leaky bucket.
If the RTP sender has removed any leaky bucket parameter sets from If the RTP sender has removed any leaky bucket parameter sets from
the sequence layer header, then for any removed leaky bucket the sequence layer header, then for any removed leaky bucket
parameter set, it MUST also remove the corresponding HRD_FULL parameter set, it MUST also remove the corresponding HRD_FULL
parameter in the entry-point header. parameter in the entry-point header.
Removing leaky bucket parameter sets, as described above, may Removing leaky bucket parameter sets, as described above, may
significantly reduce the size of the sequence layer headers and the significantly reduce the size of the sequence layer headers and the
entry-point headers. entry-point headers.
4.6 Repeating the Sequence Layer header 4.6. Repeating the Sequence Layer Header
To improve robustness against loss of RTP packets, it is RECOMMENDED To improve robustness against loss of RTP packets, it is RECOMMENDED
that if the sequence layer header changes, it should be repeated that if the sequence layer header changes, it should be repeated
frequently in the bit stream. In this is case, it is RECOMMENDED frequently in the bit stream. In this case, it is RECOMMENDED that
that the number of leaky bucket parameters in the sequence layer the number of leaky bucket parameters in the sequence layer header
header and the entry point headers be reduced to one, as described in and the entry-point headers be reduced to one, as described in
section 4.5. This will help reduce the overhead caused by repeating section 4.5. This will help reduce the overhead caused by repeating
the sequence layer header. the sequence layer header.
Any data in the VC-1 bit stream, including repeated copies of the Any data in the VC-1 bit stream, including repeated copies of the
sequence header itself, must be accounted for when computing the sequence header itself, must be accounted for when computing the
leaky bucket parameter for the HRD. (See section 3.3 for a leaky bucket parameter for the HRD. See section 3.3 for a discussion
discussion about the HRD.) about the HRD.
If the value of TFCNTRFLAG in the sequence layer header is 1, each If the value of TFCNTRFLAG in the sequence layer header is 1, each
picture header contains a frame counter field (TFCNTR). Each time picture header contains a frame counter field (TFCNTR). Each time
the sequence layer header is inserted in the bit stream, the value of the sequence layer header is inserted in the bit stream, the value of
this counter MUST be reset. this counter MUST be reset.
To allow the RTP receiver to detect that an RTP packet which was lost To allow the RTP receiver to detect that an RTP packet that was lost
contained a new sequence layer header, the AU Control field defines a contained a new sequence layer header, the AU Control field defines a
bit called the "SL" flag. This bit is toggled when a sequence layer bit called the "SL" flag. This bit is toggled when a sequence layer
header is transmitted, but only if that header is different from the header is transmitted, but only if that header is different from the
most recently transmitted sequence layer header. The SL bit is most recently transmitted sequence layer header. The SL bit is
defined in section 5.3. defined in section 5.3.
4.7 Signaling of media type parameters 4.7. Signaling of Media Type Parameters
When this RTP payload format is used with SDP, the decoder When this RTP payload format is used with SDP, the decoder
initialization parameters described in section 3.3 MUST be signaled initialization parameters described in section 3.3 MUST be signaled
in SDP using the media type parameters specified in section 6.1. in SDP using the media type parameters specified in section 6.1.
Section 6.2 specifies how to map the media type parameters to SDP Section 6.2 specifies how to map the media type parameters to SDP
[5], and section 6.3 defines rules specific to the SDP Offer/Answer [5], section 6.3 defines rules specific to the SDP Offer/Answer
model, and section 6.4 defines rules for when SDP is used in a model, and section 6.4 defines rules for when SDP is used in a
declarative style. declarative style.
When Simple or Main profiles are used, it is not possible to change When Simple or Main profiles are used, it is not possible to change
the decoder initialization parameters through the coded bit stream. the decoder initialization parameters through the coded bit stream.
Any changes to the decoder initialization parameters would have to be Any changes to the decoder initialization parameters would have to be
done through out-of-band means, e.g., by a SIP [14] re-invite or done through out-of-band means, e.g., by a SIP [14] re-invite or
similar means that convey an updated session description. similar means that convey an updated session description.
When Advanced profile is used, the decoder initialization parameters When Advanced profile is used, the decoder initialization parameters
MAY be changed by inserting a new sequence layer header or an entry- MAY be changed by inserting a new sequence layer header or an entry-
point header in the coded bit stream. point header in the coded bit stream.
The sequence layer header specifies the VC-1 level, the maximum size The sequence layer header specifies the VC-1 level, the maximum size
of the coded frames and optionally also the maximum frame rate. The of the coded frames and optionally also the maximum frame rate. The
media type parameters "level", "width", "height" and "framerate" media type parameters "level", "width", "height", and "framerate"
specify upper limits for these parameters. Thus, the sequence layer specify upper limits for these parameters. Thus, the sequence layer
header MAY specify values that are lower than the values of the media header MAY specify values that are lower than the values of the media
type parameters "level", "width", "height" or "framerate", but the type parameters "level", "width", "height", or "framerate", but the
sequence layer header MUST NOT exceed the values of any of these sequence layer header MUST NOT exceed the values of any of these
media type parameters. media type parameters.
4.8 The "mode=1" media type parameter 4.8. The "mode=1" Media Type Parameter
In certain applications using Advanced profile, the sequence layer In certain applications using Advanced profile, the sequence layer
header never changes. This MAY be signaled with the media type header never changes. This MAY be signaled with the media type
parameter "mode=1". (The "mode" parameter is defined in section 6.1.) parameter "mode=1". (The "mode" parameter is defined in section
The "mode=1" parameter serves as a "hint" to the RTP receiver that 6.1.) The "mode=1" parameter serves as a "hint" to the RTP receiver
all sequence layer headers in the bit stream will be identical. If that all sequence layer headers in the bit stream will be identical.
"mode=1" is signaled and a sequence layer header is present in the If "mode=1" is signaled and a sequence layer header is present in the
coded bit stream, then it MUST be identical to the sequence layer coded bit stream, then it MUST be identical to the sequence layer
header specified by the "config" media type parameter. header specified by the "config" media type parameter.
Since the sequence layer header never changes in "mode=1", the RTP Since the sequence layer header never changes in "mode=1", the RTP
sender MAY remove it from the bit stream. Note, however, that if the sender MAY remove it from the bit stream. Note, however, that if the
value of TFCNTRFLAG in the sequence layer header is 1, each picture value of TFCNTRFLAG in the sequence layer header is 1, each picture
header contains a frame counter field (TFCNTR). This field is reset header contains a frame counter field (TFCNTR). This field is reset
each time the sequence layer header occurs in the bit stream. If the each time the sequence layer header occurs in the bit stream. If the
RTP sender chooses to remove the sequence layer header, then it MUST RTP sender chooses to remove the sequence layer header, then it MUST
ensure that the resulting bit stream is still compliant with the VC-1 ensure that the resulting bit stream is still compliant with the VC-1
specification (e.g., by adjusting the TFCNTR field, if necessary.) specification (e.g., by adjusting the TFCNTR field, if necessary.)
4.9 The "mode=3" media type parameter 4.9. The "mode=3" Media Type Parameter
In certain applications using Advanced profile, both the sequence In certain applications using Advanced profile, both the sequence
layer header and the entry-point header never change. This MAY be layer header and the entry-point header never change. This MAY be
signaled with the media type parameter "mode=3". The same rules signaled with the media type parameter "mode=3". The same rules
apply to "mode=3" as for "mode=1", described in section 4.8. apply to "mode=3" as for "mode=1", described in section 4.8.
Additionally, if "mode=3" is signaled, then the RTP sender MAY Additionally, if "mode=3" is signaled, then the RTP sender MAY
"compress" the coded bit stream by not including sequence layer "compress" the coded bit stream by not including sequence layer
headers and entry-point headers in the RTP packets. headers and entry-point headers in the RTP packets.
The RTP receiver MUST "decompress" the coded bit stream by re- The RTP receiver MUST "decompress" the coded bit stream by
inserting the entry-point headers prior to delivering the coded bit re-inserting the entry-point headers prior to delivering the coded
stream to the VC-1 decoder. The sequence layer header does not need bit stream to the VC-1 decoder. The sequence layer header does not
to be decompressed by the receiver, since it never changes. need to be decompressed by the receiver, as it never changes.
If "mode=3" is signaled and the RTP receiver receives a complete AU If "mode=3" is signaled and the RTP receiver receives a complete AU
or the first fragment of an AU, and the RA bit is set to 1 but the AU or the first fragment of an AU, and the RA bit is set to 1 but the AU
does not begin with an entry-point header, then this indicates that does not begin with an entry-point header, then this indicates that
entry-point header has been "compressed". In that case, the RTP the entry-point header has been "compressed". In that case, the RTP
receiver MUST insert an entry-point header at the beginning of the receiver MUST insert an entry-point header at the beginning of the
AU. When inserting the entry-point header, the RTP receiver MUST use AU. When inserting the entry-point header, the RTP receiver MUST use
the one that was specified by the "config" media type parameter. the one that was specified by the "config" media type parameter.
5. RTP Payload Format syntax 5. RTP Payload Format Syntax
5.1 RTP header usage 5.1. RTP Header Usage
The format of the RTP header is specified in RFC 3550 [3] and is The format of the RTP header is specified in RFC 3550 [3] and is
reprinted in Figure 3 for convenience. reprinted in Figure 3 for convenience.
0 1 2 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 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 | |V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp | | timestamp |
skipping to change at page 16, line 25 skipping to change at page 17, line 32
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP header according to RFC 3550 Figure 3. RTP header according to RFC 3550
The fields of the fixed RTP header have their usual meaning, which is The fields of the fixed RTP header have their usual meaning, which is
defined in RFC 3550 and by the RTP profile in use, with the following defined in RFC 3550 and by the RTP profile in use, with the following
additional notes: additional notes:
Marker bit (M): 1 bit Marker bit (M): 1 bit
This bit is set to 1 if the RTP packet contains an Access This bit is set to 1 if the RTP packet contains an Access Unit
Unit containing a complete VC-1 frame, or the last fragment containing a complete VC-1 frame or the last fragment of a VC-1
of a VC-1 frame. frame.
Payload type (PT): 7 bits Payload type (PT): 7 bits
This document does not assign an RTP payload type for this This document does not assign an RTP payload type for this RTP
RTP payload format. The assignment of a payload type has to payload format. The assignment of a payload type has to be
be performed either through the RTP profile used or in a performed either through the RTP profile used or in a dynamic
dynamic way. way.
Sequence Number: 16 bits Sequence Number: 16 bits
The RTP receiver can use the sequence number field to recover The RTP receiver can use the sequence number field to recover
the coded order of the VC-1 frames. (A typical VC-1 decoder the coded order of the VC-1 frames. A typical VC-1 decoder
will require the VC-1 frames to be delivered in coded order.) will require the VC-1 frames to be delivered in coded order.
When VC-1 frames have been fragmented across RTP packets, the When VC-1 frames have been fragmented across RTP packets, the
RTP receiver can use the sequence number field to ensure that RTP receiver can use the sequence number field to ensure that
no fragment is missing. no fragment is missing.
Timestamp: 32 bits Timestamp: 32 bits
The RTP timestamp is set to the presentation time of the VC-1 The RTP timestamp is set to the presentation time of the VC-1
frame in the first Access Unit. frame in the first Access Unit. A clock rate of 90 kHz MUST be
A clock rate of 90 kHz MUST be used. used.
5.2 AU header syntax 5.2. AU Header Syntax
The Access Unit header consists of a one-byte AU Control field, the The Access Unit header consists of a one-byte AU Control field, the
RA Count field and 3 optional fields. All fields MUST be written in RA Count field, and 3 optional fields. All fields MUST be written in
network byte order. The structure of the AU header is illustrated in network byte order. The structure of the AU header is illustrated in
Figure 4. Figure 4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS | |AU | RA | AUP | PTS | DTS |
|Control| Count | Len | Delta | Delta | |Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Structure of AU header. Figure 4. Structure of AU header
AU Control: 8 bits AU Control: 8 bits
The usage of the AU Control field is defined in section 5.3. The usage of the AU Control field is defined in section 5.3.
RA Count: 8 bits RA Count: 8 bits
Random Access Point Counter. This field is a binary modulo Random Access Point Counter. This field is a binary modulo 256
256 counter. The value of this field MUST be incremented by counter. The value of this field MUST be incremented by 1 each
1 each time an AU is transmitted where the RA bit in the AU time an AU is transmitted where the RA bit in the AU Control
Control field is set to 1. The initial value of this field field is set to 1. The initial value of this field is
is undefined and MAY be chosen randomly. undefined and MAY be chosen randomly.
AUP Len: 16 bits AUP Len: 16 bits
Access Unit Payload Length. Specifies the size, in bytes, of Access Unit Payload Length. Specifies the size, in bytes, of
the payload of the Access Unit. The field does not include the payload of the Access Unit. The field does not include the
the size of the AU header itself. The field MUST be included size of the AU header itself. The field MUST be included in
in each AU header in an RTP packet, except for the last AU each AU header in an RTP packet, except for the last AU header
header in the packet. If this field is not included, the in the packet. If this field is not included, the payload of
payload of the Access Unit SHALL be assumed to extend to the the Access Unit SHALL be assumed to extend to the end of the
end of the RTP payload. RTP payload.
PTS Delta: 32 bits PTS Delta: 32 bits
Presentation time delta. Specifies the presentation time of Presentation time delta. Specifies the presentation time of
the frame as a 2's complement offset (delta) from the the frame as a 2's complement offset (delta) from the timestamp
timestamp field in the RTP header of this RTP packet. The field in the RTP header of this RTP packet. The PTS Delta
PTS Delta field MUST use the same clock rate as the timestamp field MUST use the same clock rate as the timestamp field in
field in the RTP header.
This field SHOULD NOT be included in the first AU header in
the RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU. If this
field is not included, the presentation time of the frame
SHALL be assumed to be specified by the timestamp field in
the RTP header. the RTP header.
This field SHOULD NOT be included in the first AU header in the
RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU. If this field
is not included, the presentation time of the frame SHALL be
assumed to be specified by the timestamp field in the RTP
header.
DTS Delta: 32 bits DTS Delta: 32 bits
Decode time delta. Specifies the decode time of the frame as Decode time delta. Specifies the decode time of the frame as a
a 2's complement offset (delta) between the presentation time 2's complement offset (delta) between the presentation time and
and the decode time. Note that if the presentation time is the decode time. Note that if the presentation time is larger
larger than the decode time, this results in a value for the than the decode time, this results in a value for the DTS Delta
DTS Delta field that is greater than zero. The DTS Delta field that is greater than zero. The DTS Delta field MUST use
field MUST use the same clock rate as the timestamp field in the same clock rate as the timestamp field in the RTP header.
the RTP header. If this field is not included, the decode If this field is not included, the decode time of the frame
time of the frame SHALL be assumed to be identical to the SHALL be assumed to be identical to the presentation time of
presentation time of the frame. the frame.
5.3 AU Control field syntax 5.3. AU Control Field Syntax
The structure of the 8-bit AU Control field is shown in Figure 5. The structure of the 8-bit AU Control field is shown in Figure 5.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R | | FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
Figure 5. Syntax of AU Control field. Figure 5. Syntax of AU Control field.
FRAG: 2 bits FRAG: 2 bits
Fragmentation Information. This field indicates if the AU Fragmentation Information. This field indicates if the AU
payload contains a complete frame or a fragment of a frame. payload contains a complete frame or a fragment of a frame. It
It MUST be set as follows: MUST be set as follows:
0: The AU payload contains a fragment of a frame other than
the first or last fragment. 0: The AU payload contains a fragment of a frame other than the
first or last fragment.
1: The AU payload contains the first fragment of a frame. 1: The AU payload contains the first fragment of a frame.
2: The AU payload contains the last fragment of a frame. 2: The AU payload contains the last fragment of a frame.
3: The AU payload contains a complete frame (not fragmented.) 3: The AU payload contains a complete frame (not fragmented.)
RA: 1 bit RA: 1 bit
Random Access Point indicator. This bit MUST be set to 1 if Random Access Point indicator. This bit MUST be set to 1 if
the AU contains a frame that is a random access point. In the AU contains a frame that is a random access point. In the
the case of Simple and Main profiles, any I-picture is a case of Simple and Main profiles, any I-picture is a random
random access point. access point.
In the case of Advanced profile, the first frame after an In the case of Advanced profile, the first frame after an
entry-point header is a random access point. entry-point header is a random access point.
If entry-point headers are not transmitted at every random If entry-point headers are not transmitted at every random
access point, this MUST be indicated using the media type access point, this MUST be indicated using the media type
parameter "mode=3". parameter "mode=3".
SL: 1 bit SL: 1 bit
Sequence Layer Counter. This bit MUST be toggled, i.e., Sequence Layer Counter. This bit MUST be toggled, i.e.,
changed from 0 to 1 or from 1 to 0, if the AU contains a changed from 0 to 1 or from 1 to 0, if the AU contains a
sequence layer header and if it is different from the most sequence layer header and if it is different from the most
recently transmitted sequence layer header. Otherwise, the recently transmitted sequence layer header. Otherwise, the
value of this bit must be identical to the value of the SL value of this bit must be identical to the value of the SL bit
bit in the previous AU. in the previous AU.
The initial value of this bit is undefined and MAY be chosen The initial value of this bit is undefined and MAY be chosen
randomly. randomly.
The bit MUST be 0 for Simple and Main profile bit streams or
if the sequence layer header never changes. The bit MUST be 0 for Simple and Main profile bit streams or if
the sequence layer header never changes.
LP: 1 bit LP: 1 bit
Length Present. This bit MUST be set to 1 if the AU header Length Present. This bit MUST be set to 1 if the AU header
includes the AUP Len field. includes the AUP Len field.
PT: 1 bit PT: 1 bit
PTS Delta Present. This bit MUST be set to 1 if the AU PTS Delta Present. This bit MUST be set to 1 if the AU header
header includes the PTS Delta field. includes the PTS Delta field.
DT: 1 bit DT: 1 bit
DTS Delta Present. This bit MUST be set to 1 if the AU DTS Delta Present. This bit MUST be set to 1 if the AU header
header includes the DTS Delta field. includes the DTS Delta field.
R: 1 bit R: 1 bit
Reserved. This bit MUST be set to 0 and MUST be ignored by Reserved. This bit MUST be set to 0 and MUST be ignored by
receivers. receivers.
6. RTP Payload format parameters 6. RTP Payload Format Parameters
6.1 Media type Registration 6.1. Media type Registration
This registration uses the template defined in RFC 4288 [7] and This registration uses the template defined in RFC 4288 [7] and
follows RFC 3555 [8]. follows RFC 3555 [8].
Type name: video Type name: video
Subtype name: vc1 Subtype name: vc1
Required parameters: Required parameters:
profile: profile:
The value is an integer identifying the VC-1 profile. The The value is an integer identifying the VC-1 profile. The
following values are defined: following values are defined:
0: Simple profile.
1: Main profile. 0: Simple profile
3: Advanced profile. 1: Main profile
3: Advanced profile
If the profile parameter is used to indicate properties of a If the profile parameter is used to indicate properties of a
coded bit stream, it indicates the VC-1 profile that a coded bit stream, it indicates the VC-1 profile that a
decoder has to support when it decodes the bit stream. decoder has to support when it decodes the bit stream.
If the profile parameter is used for capability exchange or If the profile parameter is used for capability exchange or
in a session setup procedure, it indicates the VC-1 profile in a session setup procedure, it indicates the VC-1 profile
that the codec supports. that the codec supports.
level: level:
The value is an integer specifying the level of the VC-1 The value is an integer that specifies the level of the VC-1
profile. profile.
For Advanced profile, valid values are 0 to 4, which For Advanced profile, valid values are 0 through 4, which
correspond to levels L0 to L4, respectively. For Simple and correspond to levels L0 through L4, respectively. For
Main profiles, the following values are defined: Simple and Main profiles, the following values are defined:
1: Low Level 1: Low Level
2: Medium Level 2: Medium Level
3: High Level (only valid for Main profile) 3: High Level (only valid for Main profile)
If the level parameter is used to indicate properties of a If the level parameter is used to indicate properties of a
coded bit stream, it indicates the highest level of the VC-1 coded bit stream, it indicates the highest level of the VC-1
profile that a decoder has to support when it decodes the bit profile that a decoder has to support when it decodes the
stream. Note that support for a level implies support for bit stream. Note that support for a level implies support
all numerically lower levels of the given profile. for all numerically lower levels of the given profile.
If the level parameter is used for capability exchange or in If the level parameter is used for capability exchange or in
a session setup procedure, it indicates the highest level of a session setup procedure, it indicates the highest level of
the VC-1 profile that the codec supports. See section 6.3 of the VC-1 profile that the codec supports. See section 6.3
RFC XXXX for specific rules for how this parameter is used of RFC 4425 for specific rules for how this parameter is
with the SDP Offer/Answer model. used with the SDP Offer/Answer model.
Optional parameters: Optional parameters:
config: config:
The value is a base16 [6] (hexadecimal) representation of an The value is a base16 [6] (hexadecimal) representation of an
octet string that expresses the decoder initialization octet string that expresses the decoder initialization
parameters. Decoder initialization parameters are mapped parameters. Decoder initialization parameters are mapped
onto the base16 octet string in an MSB-first basis. The onto the base16 octet string in an MSB-first basis. The
first bit of the decoder initialization parameters MUST be first bit of the decoder initialization parameters MUST be
located at the MSB of the first octet. If the decoder located at the MSB of the first octet. If the decoder
initialization parameters are not multiple of 8 bits, in the initialization parameters are not multiples of 8 bits, up to
last octet up to 7 zero-valued padding bits MUST be added to 7 zero-valued padding bits MUST be added in the last octet
achieve octet alignment. to achieve octet alignment.
For Simple and Main profiles, the decoder initialization For Simple and Main profiles, the decoder initialization
parameters are STRUCT_C, as defined in Annex J of SMPTE 421M parameters are STRUCT_C, as defined in Annex J of SMPTE 421M
[1]. [1].
For Advanced profile, the decoder initialization parameters For Advanced profile, the decoder initialization parameters
are a sequence layer header directly followed by an entry- are a sequence layer header directly followed by an entry-
point header. The two headers MUST be in EBDU format, point header. The two headers MUST be in EBDU format,
meaning that they must include their Start Codes and must use meaning that they must include their Start Codes and must
the encapsulation method defined in Annex E of SMPTE 421M use the encapsulation method defined in Annex E of SMPTE
[1]. 421M [1].
width: width:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
maximum horizontal size of the coded frames, in luma samples maximum horizontal size of the coded frames, in luma samples
(pixels in the luma picture.) (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 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 For Advanced profile, the value SHALL be greater than, or
equal to, the largest horizontal size of the coded frames. equal to, the largest horizontal size of the coded frames.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the specified profile and maximum horizontal size allowed by the specified profile and
level. level.
height: height:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
maximum vertical size of the coded frames, in luma samples maximum vertical size of the coded frames, in luma samples
(pixels in a progressively coded luma picture.) (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 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 For Advanced profile, the value SHALL be greater than, or
equal to, the largest vertical size of the coded frames. equal to, the largest vertical size of the coded frames.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum vertical size allowed by the specified profile and maximum vertical size allowed by the specified profile and
level. level.
bitrate: bitrate:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
peak transmission rate of the coded bit stream in bits per peak transmission rate of the coded bit stream in bits per
second. The number does not include the overhead caused by second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers, RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP or IP headers. or any of the RTP, UDP, or IP headers.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum bit rate allowed by the specified profile and level. maximum bit rate allowed by the specified profile and level.
(See the values for "RMax" in Annex D of SMPTE 421M [1].) See the values for "RMax" in Annex D of SMPTE 421M [1].
buffer: buffer:
The value is an integer specifying the leaky bucket size, B, The value is an integer specifying the leaky bucket size, B,
in milliseconds, required to contain a stream transmitted at in milliseconds, required to contain a stream transmitted at
the transmission rate specified by the bitrate parameter. the transmission rate specified by the bitrate parameter.
This parameter is defined in the hypothetical reference This parameter is defined in the hypothetical reference
decoder model for VC-1, in Annex C of SMPTE 421M [1]. decoder model for VC-1, in Annex C of SMPTE 421M [1].
Note that this parameter relates to the codec bit stream Note that this parameter relates to the codec bit stream
only, and does not account for any buffering time that may be only, and does not account for any buffering time that may
required to compensate for jitter in the network. be required to compensate for jitter in the network.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum buffer size allowed by the specified profile and maximum buffer size allowed by the specified profile and
level. (See the values for "BMax" and "RMax" in Annex D of level. See the values for "BMax" and "RMax" in Annex D of
SMPTE 421M [1].) SMPTE 421M [1].
framerate: framerate:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
maximum number of frames per second in the coded bit stream, maximum number of frames per second in the coded bit stream,
multiplied by 1000 and rounded to the nearest integer value. multiplied by 1000 and rounded to the nearest integer value.
For example, 30000/1001 (approximately 29.97) frames per For example, 30000/1001 (approximately 29.97) frames per
second is represented as 29970. second is represented as 29970.
This parameter can be used to control resource allocation at This parameter can be used to control resource allocation at
the receiver. For example, a receiver may choose to perform the receiver. For example, a receiver may choose to perform
additional post-processing on decoded frames only if the additional post-processing on decoded frames only if the
frame rate is expected to be low. The parameter MUST NOT be frame rate is expected to be low. The parameter MUST NOT be
used for pacing of the rendering process, since the actual used for pacing of the rendering process, since the actual
frame rate may differ from the specified value. frame rate may differ from the specified value.
If the parameter is not specified, it defaults to the maximum If the parameter is not specified, it defaults to the
frame rate allowed by the specified profile and level. maximum frame rate allowed by the specified profile and
level.
bpic: bpic:
This parameter signals that B- and BI-pictures may be present This parameter signals that B- and BI-pictures may be
when Advanced profile is used. If this parameter is present, present when Advanced profile is used. If this parameter is
and B- or BI-pictures may be present in the coded bit stream, present, and B- or BI-pictures may be present in the coded
this parameter MUST be equal to 1. bit stream, this parameter MUST be equal to 1.
A value of 0 indicates that B- and BI-pictures SHALL NOT be A value of 0 indicates that B- and BI-pictures SHALL NOT be
present in the coded bit stream, even if the sequence layer present in the coded bit stream, even if the sequence layer
header changes. It is RECOMMENDED to include this parameter, header changes. Inclusion of this parameter with a value of
with a value of 0, if neither B- nor BI-pictures are included 0 is RECOMMENDED, if neither B- nor BI-pictures are included
in the coded bit stream. in the coded bit stream.
This parameter MUST NOT be used with Simple and Main This parameter MUST NOT be used with Simple and Main
profiles. (For Main profile, the presence of B- and BI- profiles. For Main profile, the presence of B- and
pictures is indicated by the MAXBFRAMES field in STRUCT_C BI-pictures is indicated by the MAXBFRAMES field in STRUCT_C
decoder initialization parameter.) decoder initialization parameter.
For Advanced profile, if this parameter is not specified, a For Advanced profile, if this parameter is not specified, a
value of 1 SHALL be assumed. value of 1 SHALL be assumed.
mode: mode:
The value is an integer specifying the use of the sequence The value is an integer specifying the use of the sequence
layer header and the entry-point header. This parameter is layer header and the entry-point header. This parameter is
only defined for Advanced profile. The following values are only defined for Advanced profile. The following values are
defined: defined:
0: Both the sequence layer header and the entry-point header 0: Both the sequence layer header and the entry-point header
may change, and changed headers will be included in the RTP may change, and changed headers will be included in the
packets. RTP packets.
1: The sequence layer header specified in the config 1: The sequence layer header specified in the config
parameter never changes. The rules in section 4.8 of RFC parameter never changes. The rules in section 4.8 of RFC
XXXX MUST be followed. 4425 MUST be followed.
3: The sequence layer header and the entry-point header 3: The sequence layer header and the entry-point header
specified in the config parameter never change. The rules in specified in the config parameter never change. The
section 4.9 of RFC XXXX MUST be followed. rules in section 4.9 of RFC 4425 MUST be followed.
If the mode parameter is not specified, a value of 0 SHALL be If the mode parameter is not specified, a value of 0 SHALL
assumed. The mode parameter SHOULD be specified if modes 1 be assumed. The mode parameter SHOULD be specified if modes
or 3 apply to the VC-1 bit stream. 1 or 3 apply to the VC-1 bit stream.
max-width, max-height, max-bitrate, max-buffer, max-framerate: max-width, max-height, max-bitrate, max-buffer, max-framerate:
These parameters are defined for use in a capability exchange These parameters are defined for use in a capability
procedure. The parameters do not signal properties of the exchange procedure. The parameters do not signal properties
coded bit stream, but rather upper limits or preferred values of the coded bit stream, but rather upper limits or
for the "width", "height", "bitrate", "buffer" and preferred values for the "width", "height", "bitrate",
"framerate" parameters. Section 6.3 of RFC XXXX provides "buffer", and "framerate" parameters. Section 6.3 of RFC
specific rules for these parameters are used with the SDP 4425 provides specific rules for how these parameters are
Offer/Answer model. used with the SDP Offer/Answer model.
Receivers that signal support for a given profile and level Receivers that signal support for a given profile and level
MUST support the maximum values for these parameters for that MUST support the maximum values for these parameters for
profile and level. For example, a receiver that indicates that profile and level. For example, a receiver that
support for Main profile, Low level, must support a width of indicates support for Main profile, Low level, must support
352 luma samples and a height of 288 luma samples, even if a width of 352 luma samples and a height of 288 luma
this requires scaling the image to fit the resolution of a samples, even if this requires scaling the image to fit the
smaller display device. resolution of a smaller display device.
A receiver MAY use any of the max-width, max-height, max- A receiver MAY use any of the max-width, max-height, max-
bitrate, max-buffer and max-framerate parameters to indicate bitrate, max-buffer, and max-framerate parameters to
preferred capabilities. For example, a receiver may choose indicate preferred capabilities. For example, a receiver
to specify values for max-width and max-height that match the may choose to specify values for max-width and max-height
resolution of its display device, since a bit stream encoded that match the resolution of its display device, since a bit
using those parameters would not need to be rescaled. stream encoded using those parameters would not need to be
rescaled.
If any of the max-width, max-height, max-bitrate, max-buffer If any of the max-width, max-height, max-bitrate, max-
and max-framerate parameters signal a capability that is less buffer, and max-framerate parameters signal a capability
than the required capabilities of the signaled profile and that is less than the required capabilities of the signaled
level, then the parameter SHALL be interpreted as a preferred profile and level, then the parameter SHALL be interpreted
value for that capability. as a preferred value for that capability.
Any of the parameters MAY also be used to signal capabilities Any of the parameters MAY also be used to signal
that exceed the required capabilities of the signaled profile capabilities that exceed the required capabilities of the
and level. In that case, the parameter SHALL be interpreted signaled profile and level. In that case, the parameter
as the maximum value that can be supported for that SHALL be interpreted as the maximum value that can be
capability. supported for that capability.
When more than one parameter from the set (max-width, max- When more than one parameter from the set (max-width,
height, max-bitrate, max-buffer and max-framerate) is max-height, max-bitrate, max-buffer, and max-framerate) is
present, all signaled capabilities MUST be supported present, all signaled capabilities MUST be supported
simultaneously. simultaneously.
A sender or receiver MUST NOT use these parameters to signal A sender or receiver MUST NOT use these parameters to signal
capabilities that meet the requirements of a higher level of capabilities that meet the requirements of a higher level of
the VC-1 profile than the one specified in the "level" the VC-1 profile than that specified in the "level"
parameter, if the sender or receiver can support all the parameter, even if the sender or receiver can support all
properties of the higher level, except if specifying a higher the properties of the higher level, except if specifying a
level is not allowed due to other restrictions. (As an higher level is not allowed due to other restrictions. As
example of such a restriction, in the SDP Offer/Answer model, an example of such a restriction, in the SDP Offer/Answer
the value of the level parameter that can be used in an model, the value of the level parameter that can be used in
Answer is limited by what was specified in the Offer.) an Answer is limited by what was specified in the Offer.
max-width: max-width:
The value is an integer greater than zero, specifying a The value is an integer greater than zero, specifying a
horizontal size for the coded frames, in luma samples (pixels horizontal size for the coded frames, in luma samples
in the luma picture.) If the value is less than the maximum (pixels in the luma picture). If the value is less than the
horizontal size allowed by the profile and level, then the maximum horizontal size allowed by the profile and level,
value specifies the preferred horizontal size. Otherwise, it then the value specifies the preferred horizontal size.
specifies the maximum horizontal size that is supported. Otherwise, it specifies the maximum horizontal size that is
supported.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the specified profile and maximum horizontal size allowed by the specified profile and
level. level.
max-height: max-height:
The value is an integer greater than zero, specifying a The value is an integer greater than zero, specifying a
vertical size for the coded frames, in luma samples (pixels vertical size for the coded frames, in luma samples (pixels
in a progressively coded luma picture.) If the value is less in a progressively coded luma picture). If the value is
than the maximum vertical size allowed by the profile and less than the maximum vertical size allowed by the profile
level, then the value specifies the preferred vertical size. and level, then the value specifies the preferred vertical
Otherwise, it specifies the maximum vertical size that is size. Otherwise, it specifies the maximum vertical size
supported. that is supported.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum vertical size allowed by the specified profile and maximum vertical size allowed by the specified profile and
level. level.
max-bitrate: max-bitrate:
The value is an integer greater than zero, specifying a peak The value is an integer greater than zero, specifying a peak
transmission rate for the coded bit stream in bits per transmission rate for the coded bit stream in bits per
second. The number does not include the overhead caused by second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers, RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP or IP headers. or any of the RTP, UDP, or IP headers.
If the value is less than the maximum bit rate allowed by the If the value is less than the maximum bit rate allowed by
profile and level, then the value specifies the preferred bit the profile and level, then the value specifies the
rate. Otherwise, it specifies the maximum bit rate that is preferred bit rate. Otherwise, it specifies the maximum bit
supported. rate that is supported.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum bit rate allowed by the specified profile and level. maximum bit rate allowed by the specified profile and level.
(See the values for "RMax" in Annex D of SMPTE 421M [1].) See the values for "RMax" in Annex D of SMPTE 421M [1].
max-buffer: max-buffer:
The value is an integer specifying a leaky bucket size, B, in The value is an integer specifying a leaky bucket size, B,
milliseconds, required to contain a stream transmitted at the in milliseconds, required to contain a stream transmitted at
transmission rate specified by the max-bitrate parameter. the transmission rate specified by the max-bitrate
This parameter is defined in the hypothetical reference parameter. This parameter is defined in the hypothetical
decoder model for VC-1, in Annex C of SMPTE 421M [1]. reference decoder model for VC-1, in Annex C of SMPTE 421M
[1].
Note that this parameter relates to the codec bit stream Note that this parameter relates to the codec bit stream
only, and does not account for any buffering time that may be only and does not account for any buffering time that may be
required to compensate for jitter in the network. required to compensate for jitter in the network.
If the value is less than the maximum leaky bucket size If the value is less than the maximum leaky bucket size
allowed by the max-bitrate parameter and the profile and allowed by the max-bitrate parameter and the profile and
level, then the value specifies the preferred leaky bucket level, then the value specifies the preferred leaky bucket
size. Otherwise, it specifies the maximum leaky bucket size size. Otherwise, it specifies the maximum leaky bucket size
that is supported for the bit rate specified by the max- that is supported for the bit rate specified by the max-
bitrate parameter. bitrate parameter.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum buffer size allowed by the specified profile and maximum buffer size allowed by the specified profile and
level. (See the values for "BMax" and "RMax" in Annex D of level. See the values for "BMax" and "RMax" in Annex D of
SMPTE 421M [1].) SMPTE 421M [1].
max-framerate: max-framerate:
The value is an integer greater than zero, specifying a The value is an integer greater than zero, specifying a
number of frames per second for the coded bit stream. The number of frames per second for the coded bit stream. The
value is the frame rate multiplied by 1000 and rounded to the value is the frame rate multiplied by 1000 and rounded to
nearest integer value. For example, 30000/1001 the nearest integer value. For example, 30000/1001
(approximately 29.97) frames per second is represented as (approximately 29.97) frames per second is represented as
29970. 29970.
If the value is less than the maximum frame rate allowed by If the value is less than the maximum frame rate allowed by
the profile and level, then the value specifies the preferred the profile and level, then the value specifies the
frame rate. Otherwise, it specifies the maximum frame rate preferred frame rate. Otherwise, it specifies the maximum
that is supported. frame rate that is supported.
If the parameter is not specified, it defaults to the maximum If the parameter is not specified, it defaults to the
frame rate allowed by the specified profile and level. maximum frame rate allowed by the specified profile and
level.
Encoding considerations: Encoding considerations:
This media type is framed and contains binary data. This media type is framed and contains binary data.
Security considerations: Security considerations:
See Section 7 of RFC XXXX. See Section 7 of RFC 4425.
Interoperability considerations: Interoperability considerations:
None. None.
Published specification: Published specification:
RFC XXXX. RFC 4425.
Applications which use this media type: Applications that use this media type:
Multimedia streaming and conferencing tools. Multimedia streaming and conferencing tools.
Additional Information: Additional Information:
None. None.
Person & email address to contact for further information: Person & email address to contact for further information:
Anders Klemets <anderskl@microsoft.com> Anders Klemets <anderskl@microsoft.com>
IETF AVT working group. IETF AVT working group.
Intended Usage: Intended Usage:
COMMON COMMON
Restrictions on usage: Restrictions on usage:
This media type depends on RTP framing, and hence is only This media type depends on RTP framing; therefore, it is
defined for transfer via RTP [3]. only defined for transfer via RTP [3].
Authors: Authors:
Anders Klemets Anders Klemets
Change controller: Change controller:
IETF Audio/Video Transport Working Group delegated from the IETF Audio/Video Transport Working Group delegated from the
IESG. IESG.
6.2 Mapping of media type parameters to SDP 6.2. Mapping of media type parameters to SDP
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[4]. If SDP is used to specify sessions using this payload format, [4]. If SDP is used to specify sessions using this payload format,
the mapping is done as follows: the mapping is done as follows:
o The media name in the "m=" line of SDP MUST be video (the type o The media name in the "m=" line of SDP MUST be video (the type
name). name).
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the
skipping to change at page 26, line 52 skipping to change at page 28, line 46
o The media name in the "m=" line of SDP MUST be video (the type o The media name in the "m=" line of SDP MUST be video (the type
name). name).
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the
subtype name). subtype name).
o The clock rate in the "a=rtpmap" line MUST be 90000. o The clock rate in the "a=rtpmap" line MUST be 90000.
o The REQUIRED parameters "profile" and "level" MUST be included in o The REQUIRED parameters "profile" and "level" MUST be included in
the "a=fmtp" line of SDP. the "a=fmtp" line of SDP.
These parameters are expressed in the form of a semicolon These parameters are expressed in the form of a semicolon
separated list of parameter=value pairs. separated list of parameter=value pairs.
o The OPTIONAL parameters "config", "width", "height", "bitrate", o The OPTIONAL parameters "config", "width", "height", "bitrate",
"buffer", "framerate", "bpic", "mode", "max-width", "max-height", "buffer", "framerate", "bpic", "mode", "max-width", "max-height",
"max-bitrate", "max-buffer" and "max-framerate", when present, "max-bitrate", "max-buffer", and "max-framerate", when present,
MUST be included in the "a=fmtp" line of SDP. MUST be included in the "a=fmtp" line of SDP.
These parameters are expressed in the form of a semicolon These parameters are expressed in the form of a semicolon
separated list of parameter=value pairs: separated list of parameter=value pairs:
a=fmtp:<dynamic payload type> <parameter a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>] name>=<value>[,<value>][; <parameter name>=<value>]
o Any unknown parameters to the device that uses the SDP MUST be o Any unknown parameters to the device that uses the SDP MUST be
ignored. For example, parameters defined in later specifications ignored. For example, parameters defined in later specifications
MAY be copied into the SDP and MUST be ignored by receivers that MAY be copied into the SDP and MUST be ignored by receivers that
do not understand them. do not understand them.
skipping to change at page 27, line 21 skipping to change at page 29, line 21
separated list of parameter=value pairs: separated list of parameter=value pairs:
a=fmtp:<dynamic payload type> <parameter a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>] name>=<value>[,<value>][; <parameter name>=<value>]
o Any unknown parameters to the device that uses the SDP MUST be o Any unknown parameters to the device that uses the SDP MUST be
ignored. For example, parameters defined in later specifications ignored. For example, parameters defined in later specifications
MAY be copied into the SDP and MUST be ignored by receivers that MAY be copied into the SDP and MUST be ignored by receivers that
do not understand them. do not understand them.
6.3 Usage with the SDP Offer/Answer Model 6.3. Usage with the SDP Offer/Answer Model
When VC-1 is offered over RTP using SDP in an Offer/Answer model [5] When VC-1 is offered over RTP using SDP in an Offer/Answer model [5]
for negotiation for unicast usage, the following rules and for negotiation for unicast usage, the following rules and
limitations apply: limitations apply:
o The "profile" parameter MUST be used symmetrically, i.e., the o The "profile" parameter MUST be used symmetrically, i.e., the
answerer MUST either maintain the parameter or remove the media answerer MUST either maintain the parameter or remove the media
format (payload type) completely if the offered VC-1 profile is format (payload type) completely if the offered VC-1 profile is
not supported. not supported.
o The "level" parameter specifies the highest level of the VC-1 o The "level" parameter specifies the highest level of the VC-1
profile supported by the codec. profile supported by the codec.
The answerer MUST NOT specify a numerically higher level in the The answerer MUST NOT specify a numerically higher level in the
answer than what was specified in the offer. The answerer MAY answer than that specified in the offer. The answerer MAY specify
specify a level that is lower than what was specified in the a level that is lower than that specified in the offer, i.e., the
offer, i.e., the level parameter can be "downgraded". level parameter can be "downgraded".
If the offer specifies the sendrecv or sendonly direction If the offer specifies the sendrecv or sendonly direction
attribute, and the answer downgrades the level parameter, this may attribute and the answer downgrades the level parameter, this may
require a new offer to specify an updated "config" parameter. If require a new offer to specify an updated "config" parameter. If
the "config" parameter cannot be used with the level specified in the "config" parameter cannot be used with the level specified in
the answer, then the offerer MUST initiate another Offer/Answer the answer, then the offerer MUST initiate another Offer/Answer
round, or not use media format (payload type). round or not use media format (payload type).
o The parameters "config", "bpic", "width", "height", "framerate", o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer" and "mode", describe the properties of the VC- "bitrate", "buffer", and "mode", describe the properties of the
1 bit stream that the offerer or answerer is sending for this VC-1 bit stream that the offerer or answerer is sending for this
media format configuration. media format configuration.
In the case of unicast usage and when the direction attribute in In the case of unicast usage and when the direction attribute in
the offer or answer is recvonly, the interpretation of these the offer or answer is recvonly, the interpretation of these
parameters is undefined and they MUST NOT be used. parameters is undefined and they MUST NOT be used.
o The parameters "config", "width", "height", "bitrate" and "buffer" o The parameters "config", "width", "height", "bitrate", and
MUST be specified when the direction attribute is sendrecv or "buffer" MUST be specified when the direction attribute is
sendonly. sendrecv or sendonly.
o The parameters "max-width", "max-height", "max-framerate", "max- o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate" and "max-buffer" MAY be specified in an offer or an bitrate", and "max-buffer" MAY be specified in an offer or an
answer, and their interpretation is as follows: answer, and their interpretation is as follows:
When the direction attribute is sendonly, the parameters describe When the direction attribute is sendonly, the parameters describe
the limits of the VC-1 bit stream that the sender is capable of 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 producing for the given profile and level, and for any lower level
of the same profile. of the same profile.
When the direction attribute is recvonly or sendrecv, the When the direction attribute is recvonly or sendrecv, the
parameters describe properties of the receiver implementation. If parameters describe properties of the receiver implementation. If
the value of a property is less than what is allowed by the level the value of a property is less than that allowed by the level of
of the VC-1 profile, then it SHALL be interpreted as a preferred 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 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 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 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 upper limit of the value that the receiver accepts for the given
profile and level, and for any lower level of the same profile. profile and level, and for any lower level of the same profile.
For example, if a recvonly or sendrecv offer specifies For example, if a recvonly or sendrecv offer specifies
"profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a "profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a
suggested bit rate, because all receiver implementations of Simple suggested bit rate, because all receiver implementations of Simple
profile, Low level, are required to support bit rates of up to 96 profile, Low level, are required to support bit rates of up to 96
kbps. Assuming that the offer is accepted, the answerer should kbps. Assuming that the offer is accepted, the answerer should
specify "bitrate=48000" in the answer, but any value up to 96000 specify "bitrate=48000" in the answer, but any value up to 96000
is allowed. But if the offer specifies "max-bitrate=200000", this is allowed. But if the offer specifies "max-bitrate=200000", this
means that the receiver implementation supports a maximum of 200 means that the receiver implementation supports a maximum of 200
kbps for the given profile and level (or lower level.) In this kbps for the given profile and level (or lower level). In this
case, the answerer is allowed to answer with a bitrate parameter case, the answerer is allowed to answer with a bitrate parameter
of up to 200000. of up to 200000.
o If an offerer wishes to have non-symmetrical capabilities between o If an offerer wishes to have non-symmetrical capabilities between
sending and receiving, e.g., use different levels in each sending and receiving, e.g., use different levels in each
direction, then the offerer has to offer different RTP sessions. direction, then the offerer has to offer different RTP sessions.
This can be done by specifiying different media lines declared as This can be done by specifying different media lines declared as
"recvonly" and "sendonly", respectively. "recvonly" and "sendonly", respectively.
For streams being delivered over multicast, the following rules apply For streams being delivered over multicast, the following rules apply
in addition: in addition:
o The "level" parameter specifies the highest level of the VC-1 o The "level" parameter specifies the highest level of the VC-1
profile used by the participants in the multicast session. The profile used by the participants in the multicast session. The
value of this parameter MUST NOT be changed by the answerer. value of this parameter MUST NOT be changed by the answerer.
Thus, a payload type can either be accepted unaltered or removed. Thus, a payload type can be either accepted unaltered or removed.
o The parameters "config", "bpic", "width", "height", "framerate", o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer" and "mode", specify properties of the VC-1 bit "bitrate", "buffer", and "mode", specify properties of the VC-1
stream that will be sent, and/or received, on the multicast bit stream that will be sent and/or received on the multicast
session. The parameters MAY be specified even if the direction session. The parameters MAY be specified, even if the direction
attribute is recvonly. attribute is recvonly.
The values of these parameters MUST NOT be changed by the The values of these parameters MUST NOT be changed by the
answerer. Thus, a payload type can either be accepted unaltered answerer. Thus, a payload type can be either accepted unaltered
or removed. or removed.
o The values of the parameters "max-width", "max-height", "max- o The values of the parameters "max-width", "max-height", "max-
framerate", "max-bitrate" and "max-buffer" MUST be supported by framerate", "max-bitrate", and "max-buffer" MUST be supported by
the answerer for all streams declared as sendrecv or recvonly. the answerer for all streams declared as sendrecv or recvonly.
Otherwise, one of the following actions MUST be performed: the Otherwise, one of the following actions MUST be performed: the
media format is removed, or the session rejected. media format is removed or the session is rejected.
6.4 Usage in Declarative Session Descriptions 6.4. Usage in Declarative Session Descriptions
When VC-1 is offered over RTP using SDP in a declarative style, as in When VC-1 is offered over RTP using SDP in a declarative style, as in
RTSP [12] or SAP [13], the following rules and limitations apply. RTSP [12] or SAP [13], the following rules and limitations apply:
o The parameters "profile" and "level" indicate only the properties o The parameters "profile" and "level" indicate only the properties
of the coded bit stream. They do not imply a limit on capabilties of the coded bit stream. They do not imply a limit on
supported by the sender. capabilities supported by the sender.
o The parameters "config", "width", "height", "bitrate" and "buffer" o The parameters "config", "width", "height", "bitrate", and
MUST be specified. "buffer" MUST be specified.
o The parameters "max-width", "max-height", "max-framerate", "max- o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate" and "max-buffer" MUST NOT be used. bitrate", and "max-buffer" MUST NOT be used.
An example of media representation in SDP is as follows (Simple An example of media representation in SDP is as follows (Simple
profile, Medium level): profile, Medium level):
m=video 49170 RTP/AVP 98 m=video 49170 RTP/AVP 98
a=rtpmap:98 vc1/90000 a=rtpmap:98 vc1/90000
a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000; a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000;
bitrate=384000;buffer=2000;config=4e291800 bitrate=384000;buffer=2000;config=4e291800
7. Security Considerations 7. Security Considerations
skipping to change at page 30, line 17 skipping to change at page 32, line 25
computational load. The attacker can inject pathological RTP packets computational load. The attacker can inject pathological RTP packets
into the stream that are complex to decode and that cause the into the stream that are complex to decode and that cause the
receiver to be overloaded. VC-1 is particularly vulnerable to such receiver to be overloaded. VC-1 is particularly vulnerable to such
attacks, because it is possible for an attacker to generate RTP attacks, because it is possible for an attacker to generate RTP
packets containing frames that affect the decoding process of many packets containing frames that affect the decoding process of many
future frames. Therefore, the usage of data origin authentication future frames. Therefore, the usage of data origin authentication
and data integrity protection of at least the RTP packet is and data integrity protection of at least the RTP packet is
RECOMMENDED; for example, with SRTP [11]. RECOMMENDED; for example, with SRTP [11].
Note that the appropriate mechanism to ensure confidentiality and Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is very dependent on the integrity of RTP packets and their payloads is dependent on the
application and on the transport and signaling protocols employed. application and on the transport and signaling protocols employed.
Thus, although SRTP is given as an example above, other possible Thus, although SRTP is given as an example above, other possible
choices exist. choices exist.
VC-1 bit streams can carry user-data, such as closed captioning VC-1 bit streams can carry user-data, such as closed captioning
information and content meta-data. The VC-1 specification does not information and content meta-data. The VC-1 specification does not
define how to interpret user-data. Identifiers for user-data are define how to interpret user-data. Identifiers for user-data are
required to be registered with SMPTE. It is conceivable for types of required to be registered with SMPTE. It is conceivable for types of
user-data to be defined to include programmatic content, such as user-data to be defined to include programmatic content, such as
scripts or commands that would be executed by the receiver. scripts or commands that would be executed by the receiver.
Depending on the type of user-data, it might be possible for a sender Depending on the type of user-data, it might be possible for a sender
to generate user-data in a non-compliant manner to crash the receiver to generate user-data in a non-compliant manner to crash the receiver
or make it temporarily unavailable. Senders that transport VC-1 bit or make it temporarily unavailable. Senders that transport VC-1 bit
streams SHOULD ensure that the user-data is compliant with the streams SHOULD ensure that the user-data is compliant with the
specification registered with SMPTE (see Annex F of [1].) Receivers specification registered with SMPTE (see Annex F of [1].) Receivers
SHOULD prevent malfunction in case of non-compliant user-data. SHOULD prevent malfunction in case of non-compliant user-data.
It is important to note that VC-1 streams can have very high It is important to note that VC-1 streams can have very high
bandwidth requirements (up to 135 Mbps for high-definition video.) bandwidth requirements (up to 135 Mbps for high-definition video).
This is sufficient to cause potential for denial-of-service if This causes a potential for denial-of-service if transmitted onto
transmitted onto many Internet paths. Therefore, users of this many Internet paths. Therefore, users of this payload format MUST
payload format MUST comply with the congestion control requirements comply with the congestion control requirements described in section
described in section 8. 8.
8. Congestion Control 8. Congestion Control
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[3], and with any applicable RTP profile; e.g., RFC 3551 [15]. [3], and with any applicable RTP profile; e.g., RFC 3551 [15].
If best-effort service is being used, users of this payload format If best-effort service is being used, users of this payload format
MUST monitor packet loss to ensure that the packet loss rate is MUST monitor packet loss to ensure that the packet loss rate is
within acceptable parameters. Packet loss is considered acceptable within acceptable parameters. Packet loss is considered acceptable
if a TCP flow across the same network path, and experiencing the same if a TCP flow across the same network path and experiencing the same
network conditions, would achieve an average throughput, measured on network conditions would achieve an average throughput, measured on a
a reasonable timescale, that is not less than the RTP flow is reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate or by congestion control mechanisms to adapt the transmission rate or by
arranging for a receiver to leave the session if the loss rate is arranging for a receiver to leave the session if the loss rate is
unacceptably high. unacceptably high.
The bit rate adaptation necessary for obeying the congestion control The bit rate adaptation necessary for obeying the congestion control
principle is easily achievable when real-time encoding is used. When principle is easily achievable when real-time encoding is used. When
pre-encoded content is being transmitted, bandwidth adaptation pre-encoded content is being transmitted, bandwidth adaptation
requires one or more of the following: requires one or more of the following:
- The availability of more than one coded representation of the same - The availability of more than one coded representation of the same
content at different bit rates. The switching between the content at different bit rates. The switching between the
different representations can normally be performed in the same different representations can normally be performed in the same
RTP session, by switching streams at random access point RTP session by switching streams at random access point
boundaries. boundaries.
- The existence of non-reference frames (e.g., B-frames) in the bit - The existence of non-reference frames (e.g., B-frames) in the bit
stream. Non-reference frames can be discarded by the transmitter stream. Non-reference frames can be discarded by the transmitter
prior to encapsulation in RTP. prior to encapsulation in RTP.
Only when non-downgradable parameters (such as the VC-1 "profile" Only when non-downgradable parameters (such as the VC-1 "profile"
parameter) are required to be changed does it become necessary to parameter) are required to be changed does it become necessary to
terminate and re-start the media stream. This may be accomplished by terminate and re-start the media stream. This may be accomplished by
using a different RTP payload type. using a different RTP payload type.
Regardless of the method used for bandwidth adaptation, the resulting Regardless of the method used for bandwidth adaptation, the resulting
bit stream MUST be compliant with the VC-1 specification [1]. For bit stream MUST be compliant with the VC-1 specification [1]. For
example, if non-reference frames are discarded, then the FRMCNT example, if non-reference frames are discarded, then the FRMCNT
syntax element (Simple and Main profile frames only) and the optional syntax element (Simple and Main profile frames only) and the optional
TFCNTR syntax element (Advanced profile frames only) must increment TFCNTR syntax element (Advanced profile frames only) must increment
as if no frames had been discarded. Because the TFCNTR syntax as if no frames had been discarded. Because the TFCNTR syntax
element counts the frames in the display order, which is different element counts the frames in the display order, which is different
from the order in which they are transmitted (the coded order), it from the order in which they are transmitted (the coded order), it
will require the transmitter to "look ahead", or buffer, of some will require the transmitter to "look ahead" or buffer some number of
number of frames. frames.
As another example, when switching between different representations As another example, when switching between different representations
of the same content, it may be necessary to signal a discontinuity by of the same content, it may be necessary to signal a discontinuity by
modifying the FRMCNT field, or if Advanced profile is used, by modifying the FRMCNT field, or if Advanced profile is used, by
setting the BROKEN_LINK flag in the entry-point header to 1. setting the BROKEN_LINK flag in the entry-point header to 1.
This payload format may also be used in networks that provide This payload format may also be used in networks that provide
quality-of-service guarantees. If enhanced service is being used, quality-of-service guarantees. If enhanced service is being used,
receivers SHOULD monitor packet loss to ensure that the service that receivers SHOULD monitor packet loss to ensure that the service that
was requested is actually being delivered. If it is not, then they was requested is actually being delivered. If it is not, then they
SHOULD assume that they are receiving best-effort service and behave SHOULD assume that they are receiving best-effort service and behave
accordingly. accordingly.
9. IANA Considerations 9. IANA Considerations
IANA is requested to register the media type "video/vc1" and the IANA has registered the media type "video/vc1" and the associated RTP
associated RTP payload format, as specified in section 6.1 of this payload format in the Media Types registry and in the RTP Payload
document, in the Media Types registry and in the RTP Payload Format Format MIME types registry, as specified in section 6.1.
MIME types registry.
10. References 10. References
10.1 Normative references 10.1. Normative References
[1] Society of Motion Picture and Television Engineers, "VC-1 [1] Society of Motion Picture and Television Engineers, "VC-1
Compressed Video Bitstream Format and Decoding Process", SMPTE Compressed Video Bitstream Format and Decoding Process", SMPTE
421M. 421M.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. [4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002. Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data [6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 3548, July 2003.
[7] Freed, N. and Klensin, J., "Media Type Specifications and
[7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload
Formats", RFC 3555, July 2003.
10.2 Informative references [8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
10.2. Informative References
[9] Srinivasan, S., Hsu, P., Holcomb, T., Mukerjee, K., Regunathan, [9] Srinivasan, S., Hsu, P., Holcomb, T., Mukerjee, K., Regunathan,
S.L., Lin, B., Liang, J., Lee, M., and J. Ribas-Corbera, "Windows S.L., Lin, B., Liang, J., Lee, M., and J. Ribas-Corbera,
Media Video 9: overview and applications", Signal Processing: "Windows Media Video 9: overview and applications", Signal
Image Communication, Volume 19, Issue 9, October 2004. Processing: Image Communication, Volume 19, Issue 9, October
2004.
[10]Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A [10]Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A
generalized hypothetical reference decoder for H.264/AVC", IEEE generalized hypothetical reference decoder for H.264/AVC", IEEE
Transactions on Circuits and Systems for Video Technology, August Transactions on Circuits and Systems for Video Technology,
2003. August 2003.
[11]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [11]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[12]Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming [12]Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998. Protocol (RTSP)", RFC 2326, April 1998.
[13]Handley, M., Perkins, C., and E. Whelan, "Session Announcement [13]Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[14]Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999. "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[15]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video [15]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003. Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
Author's Addresses Acknowledgements
Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar
Regunathan, Gary Sullivan, Stephan Wenger, and Magnus Westerlund for
providing detailed feedback on this document.
Author's Address
Anders Klemets Anders Klemets
Microsoft Corp. Microsoft Corp.
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: anderskl@microsoft.com
Acknowledgements EMail: Anders.Klemets@microsoft.com
Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar Full Copyright Statement
Regunathan, Gary Sullivan, Stephan Wenger and Magnus Westerlund for
providing detailed feedback on this document.
IPR Notices Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 33, line 47 skipping to change at page 36, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Full Copyright Statement Acknowledgement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an Funding for the RFC Editor function is provided by the IETF
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Administrative Support Activity (IASA).
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 203 change blocks. 
474 lines changed or deleted 520 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/