draft-ietf-avt-rtp-vc1-04.txt   draft-ietf-avt-rtp-vc1-05.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft A. Klemets Internet Draft A. Klemets
Document: draft-ietf-avt-rtp-vc1-04.txt Microsoft Document: draft-ietf-avt-rtp-vc1-05.txt Microsoft
Expires: June 2006 December 2005 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 By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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............................5
3.2 Bit-stream Data Units in Advanced profile..................6 3.2 Bit-stream Data Units in Advanced profile.................6
3.3 Decoder initialization parameters..........................6 3.3 Decoder initialization parameters.........................6
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 ..............8
4.1 Access Units ..............................................8 4.1 Access Units .............................................8
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................................10
4.4 Random Access Points .....................................11 4.4 Random Access Points ....................................12
4.5 Removal of HRD parameters.................................12 4.5 Removal of HRD parameters................................12
4.6 Repeating the Sequence Layer header ......................12 4.6 Repeating the Sequence Layer header .....................13
4.7 Signaling of media type parameters........................13 4.7 Signaling of media type parameters.......................13
4.8 The "mode=1" media type parameter.........................13 4.8 The "mode=1" media type parameter........................14
4.9 The "mode=3" media type parameter.........................14 4.9 The "mode=3" media type parameter........................14
5. RTP Payload Format syntax.....................................14 5. RTP Payload Format syntax....................................15
5.1 RTP header usage..........................................14 5.1 RTP header usage.........................................15
5.2 AU header syntax..........................................15 5.2 AU header syntax.........................................16
5.3 AU Control field syntax...................................16 5.3 AU Control field syntax..................................17
6. RTP Payload format parameters.................................18 6. RTP Payload format parameters................................18
6.1 Media type Registration...................................18 6.1 Media type Registration..................................18
6.2 Mapping of media type parameters to SDP...................25 6.2 Mapping of media type parameters to SDP..................26
6.3 Usage with the SDP Offer/Answer Model.....................25 6.3 Usage with the SDP Offer/Answer Model....................26
6.4 Usage in Declarative Session Descriptions.................27 6.4 Usage in Declarative Session Descriptions................28
7. Security Considerations.......................................28 7. Security Considerations......................................29
8. IANA Considerations...........................................29 8. Congestion Control...........................................30
9. References....................................................29 9. IANA Considerations..........................................31
9.1 Normative references .....................................29 10. References..................................................31
9.2 Informative references....................................29 10.1 Normative references....................................31
10.2 Informative references..................................31
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, being suitable for low bit rate
skipping to change at page 3, line 27 skipping to change at page 3, line 28
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. 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: A picture that is coded using motion compensated
prediction from past and/or future reference fields or frames. A B- prediction from past and/or future reference fields or frames. A B-
picture cannot be used for predicting any other picture. picture cannot be used for predicting any other picture.
BI-picture: A B-picture that is coded using information only from
itself. 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): A unit of the compressed data which may
be parsed (i.e., syntax decoded) independently of other information be parsed (i.e., syntax decoded) independently of other information
at the same hierarchical level. A BDU can be, for example, a at the same hierarchical level. A BDU can be, for example, a
sequence layer header, an entry-point header, a frame, or a slice. 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): A BDU which has been encapsulated using the
encapsulation mechanism described in Annex E of SMPTE 421M [1], to encapsulation mechanism described in Annex E of SMPTE 421M [1], to
prevent emulation of the start code prefix in the bit stream. 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.
skipping to change at page 5, line 13 skipping to change at page 5, line 18
are encoded as a single unit. are encoded as a single unit.
start codes (SC): 32-bit codes embedded in that coded bit stream that start codes (SC): 32-bit codes embedded in that coded bit stream that
are unique, and identify the beginning of a BDU. Start codes consist are unique, and identify the beginning of a BDU. Start codes consist
of a unique three-byte Start Code Prefix (SCP), and a one-byte Start 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 and Main profiles are designed for relatively and Advanced. Simple profile is designed for low bit rates and for
low bit rate applications. For example, the maximum bit rate low complexity applications, such as playback of media on personal
supported by Simple profile is 384 kbps. Certain features that can digital assistants. The maximum bit rate supported by Simple profile
be used to achieve high compression efficiency, such as non-square is 384 kbps. Main profile is targets high bit rate applications,
pixels and support for interlaced pictures, are only included in such as streaming and TV over IP. Main profile supports B-pictures,
Advanced profile. which provide improved compression efficiency at the cost of higher
complexity.
The maximum bit rate supported by the Advanced profile is 135 Mbps, Certain features that can be used to achieve high compression
making it suitable for nearly lossless encoding of HDTV signals. efficiency, such as non-square pixels and support for interlaced
pictures, are only included in Advanced profile. The maximum bit
rate supported by the Advanced profile is 135 Mbps, making it
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 6, line 11 skipping to change at page 6, line 19
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 profiles
each I-picture is a random access point. 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, or as a B-picture. These terms are defined in section 2 of picture, BI-picture, or as a B-picture. These terms are defined in
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 only, each picture and slice is byte-aligned and In Advanced profile, each picture and slice is considered a Bit-
is considered a Bit-stream Data Unit (BDU). A BDU is defined as a stream Data Unit (BDU). A BDU is always byte-aligned and is defined
unit that can be parsed (i.e., syntax decoded) independently of other as a unit that can be parsed (i.e., syntax decoded) independently of
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. Note that of SMPTE 421M [1] for a complete list of Start Codes. Blocks and
blocks and macroblocks are not BDUs and thus do not have a Start Code macroblocks are not BDUs and thus do not have a Start Code and are
and are not necessarily byte-aligned. not necessarily byte-aligned.
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 which 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.
A sequence layer header is not defined for VC-1 Simple and Main The parameters apply to all entry-point segments until the next
profiles. For these profiles, decoder initialization parameters MUST occurrence of a sequence layer header in the coded bit stream.
be conveyed out-of-band from the coded bit stream. Section 4.7
specifies how the parameters are conveyed by this RTP payload format.
For Advanced profile, the parameters in the sequence layer header
apply to all entry-point segments until the next 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 dimensions of the coded pictures, the aspect profile level, the maximum dimensions of the coded pictures, the
ratio, interlace information, the frame rate and up to 31 leaky aspect ratio, interlace information, the frame rate and up to 31
bucket parameter sets for the Hypothetical Reference Decoder (HRD). leaky 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
profiles. For these profiles, decoder initialization parameters MUST
be conveyed out-of-band. The decoder initialization parameters for
Simple and Main profiles include the maximum dimensions of the coded
picture, and a leaky bucket parameter set for the HRD. Section 4.7
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].
The concept of an entry-point layer applies only to VC-1 Advanced For Simple and Main profiles, the current buffer fullness value for
profile. The presence of an entry-point header indicates a random the HRD leaky bucket is signaled using the BF syntax element in the
access point within the bit stream. The entry-point header specifies picture header of I-pictures and BI-pictures.
current buffer fullness values for the leaky buckets in the HRD. The
For Advanced profile, the entry-point header specifies current buffer
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. See Section 6.2 of SMPTE 421M [1] for the formal 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
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 are present in the coded bit stream. In the except if B-pictures or BI-pictures are present in the coded bit
latter case, the frames are transmitted such that the frames that the stream. A BI-picture is a special kind of B-picture, and in the
B-pictures depend on are transmitted first. This is referred to as remainder of this section the terms B-picture and B-frame also apply
the coded order of the frames. to BI-pictures and BI-frames, respectively.
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 first. This is referred to as the coded order of the
frames.
The rules for how a decoder converts frames from the coded order to The rules for how a decoder converts frames from the coded order to
the display order are stated in section 5.4 of SMPTE 421M [1]. In the display order are stated in section 5.4 of SMPTE 421M [1]. In
short, if B-pictures may be present in the coded bit stream, a short, if B-pictures may be present in the coded bit stream, a
hypothetical decoder implementation needs to buffer one additional hypothetical decoder implementation needs to buffer one additional
decoded frame. When an I-frame or a P-frame is received, the frame decoded frame. When an I-frame or a P-frame is received, the frame
can be decoded immediately but it is not displayed until the next I- can be decoded immediately but it is not displayed until the next I-
or P-frame is received. However, B-frames are displayed immediately. or P-frame is received. However, B-frames are displayed immediately.
Figure 1 illustrates the timing relationship between the capture of Figure 1 illustrates the timing relationship between the capture of
skipping to change at page 8, line 50 skipping to change at page 9, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+- .. +-+-+-+-+
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
that may be coded as separate pictures. The two pictures still
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 VC-
1 Advanced profile is used: 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 picture header and multiple header, an entry-point header, a frame (picture) header, a field
slices and the associated user-data. (However, all slices and header, and multiple slices and the associated user-data.
their corresponding macroblocks MUST belong to the same video (However, all slices and their corresponding macroblocks MUST
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
with a picture header, 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 begin with the start of a picture profiles, the AU payload MUST start at the beginning of a frame.
header.
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, such as at the start of a slice. boundary, 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
skipping to change at page 10, line 21 skipping to change at page 10, line 46
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
Video frames MUST be transmitted in the coded order. Coded order VC-1 video frames MUST be transmitted in the coded order. Coded
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. The RTP timestamp field MUST be set to the discussed in section 3.4. When a video frame consists of a single
presentation time of the video frame contained in the first AU in the picture, the presentation time of the frame is identical to the
RTP packet. The presentation time can be used as the timestamp field presentation time of the picture. When the VC-1 interlace coding
in the RTP header because it differs from the sampling instant of the mode is used, frames may contain two pictures, one for each field.
frame only by an arbitrary constant offset. In that case, the presentation time of a frame is the presentation
time of the field that is displayed first.
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
presentation time can be used as the timestamp field in the RTP
header because it differs from the sampling instant of the frame only
by an arbitrary constant offset.
If the video frame in an AU has a presentation time that differs from If the video frame in an AU has a presentation time that differs from
the RTP timestamp field, then the presentation time MUST be specified the RTP timestamp field, then the presentation time MUST be specified
using the PTS Delta field in the AU header. Since the RTP timestamp using the PTS Delta field in the AU header. Since the RTP timestamp
field must be identical to the presentation time of the first video field must be identical to the presentation time of the first video
frame, this can only happen if an RTP packet contains multiple AUs. frame, this can only happen if an RTP packet contains multiple AUs.
The syntax of the PTS Delta field is defined in section 5.2. The syntax of the PTS Delta field is defined in section 5.2.
The decode time of a VC-1 frame is always monotonically increasing The decode time of a VC-1 frame is always monotonically increasing
when the video frames are transmitted in the coded order. If B- when the video frames are transmitted in the coded order. If neither
pictures will not be present in the coded bit stream, then the decode B- nor BI-pictures are present in the coded bit stream, then the
time of a frame SHALL be equal to the presentation time of the frame. 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
remainder of this section the terms B-picture and B-frame also apply
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:
- Non-B frames: The decode time SHALL be equal to the presentation - Non-B frames: The decode time SHALL be equal to the presentation
time of the previous non-B frame in the coded order. time of the previous non-B frame in the coded order.
- B-frames: The decode time SHALL be equal to the presentation time - B-frames: The decode time SHALL be equal to the presentation time
of the B-frame. of the B-frame.
skipping to change at page 11, line 51 skipping to change at page 12, line 37
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 random
access point. 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 which 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 a 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
skipping to change at page 12, line 43 skipping to change at page 13, line 28
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 is case, it is RECOMMENDED
that the number of leaky bucket parameters in the sequence layer that the number of leaky bucket parameters in the sequence layer
header and the entry point headers be reduced to one, as described in header 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.
Note that any data in the VC-1 bit stream, including repeated copies Any data in the VC-1 bit stream, including repeated copies of the
of the sequence header itself, must be accounted for when computing sequence header itself, must be accounted for when computing the
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 about the HRD.) discussion about the HRD.)
Note that if the value of TFCNTRFLAG in the sequence layer header is If the value of TFCNTRFLAG in the sequence layer header is 1, each
1, each picture header contains a frame counter field (TFCNTR). Each picture header contains a frame counter field (TFCNTR). Each time
time the sequence layer header is inserted in the bit stream, the the sequence layer header is inserted in the bit stream, the value of
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 which 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
skipping to change at page 13, line 25 skipping to change at page 14, line 10
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], and 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 updating the SDP. done through out-of-band means, e.g., by a SIP [14] re-invite or
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.
Note that the sequence layer header specifies the VC-1 level, the The sequence layer header specifies the VC-1 level, the maximum size
maximum size of the coded pictures and optionally also the maximum of the coded pictures and optionally also the maximum frame rate.
frame rate. The media type parameters "level", "width", "height" and The media type parameters "level", "width", "height" and "framerate"
"framerate" specify upper limits for these parameters. Thus, the specify upper limits for these parameters. Thus, the sequence layer
sequence layer header MAY specify values that that are lower than the header MAY specify values that are lower than the values of the media
values of the media type parameters "level", "width", "height" or type parameters "level", "width", "height" or "framerate", but the
"framerate", but the sequence layer header MUST NOT exceed the values sequence layer header MUST NOT exceed the values of any of these
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 6.1.)
The "mode=1" parameter serves as a "hint" to the RTP receiver that The "mode=1" parameter serves as a "hint" to the RTP receiver that
all sequence layer headers in the bit stream will be identical. If all sequence layer headers in the bit stream will be identical. If
"mode=1" is signaled and a sequence layer header is present in the "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
skipping to change at page 16, line 7 skipping to change at page 16, line 43
|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 counter. The value of this field, MUST be incremented by 256 counter. The value of this field MUST be incremented by
1, each time an AU is transmitted where the RA bit in the AU 1 each time an AU is transmitted where the RA bit in the AU
Control field is set to 1. The initial value of this field Control field is set to 1. The initial value of this field
is undefined and MAY be chosen randomly. is 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 size of the AU header itself. The field MUST be included the size of the AU header itself. The field MUST be included
in each AU header in an RTP packet, except for the last AU in each AU header in an RTP packet, except for the last AU
header in the packet. If this field is not included, the header in the packet. If this field is not included, the
payload of the Access Unit SHALL be assumed to extend to the payload of the Access Unit SHALL be assumed to extend to the
skipping to change at page 17, line 21 skipping to change at page 18, line 4
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 MUST be set as follows: It MUST be set as follows:
0: The AU payload contains a fragment of a frame other than 0: The AU payload contains a fragment of a frame other than
the first or last fragment. 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 case of Simple and Main profiles, any I-picture is a the case of Simple and Main profiles, any I-picture is a
random access point. random 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.
Note that if entry-point headers are not transmitted at every If entry-point headers are not transmitted at every random
random access point, this MUST be indicated using the media access point, this MUST be indicated using the media type
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 in the previous AU. bit 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.
skipping to change at page 19, line 39 skipping to change at page 20, line 21
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 use
the encapsulation method defined in Annex E of SMPTE 421M the encapsulation method defined in Annex E of SMPTE 421M
[1]. [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 picture, in pixels. maximum horizontal size of the coded picture, in luma samples
(pixels in the luma picture.)
For Simple and Main profiles, the value SHALL be identical to
the actual horizontal size of the coded picture.
For Advanced profile, the value SHALL be greater than, or
equal to, the largest horizontal size of the coded picture.
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 picture in pixels. maximum vertical size of the coded picture in luma samples
(pixels in the luma picture.)
For Simple and Main profiles, the value SHALL be identical to
the actual vertical size of the coded picture.
For Advanced profile, the value SHALL be greater than, or
equal to, the largest vertical size of the coded picture.
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,
skipping to change at page 20, line 39 skipping to change at page 21, line 32
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
the receiver. For example, a receiver may choose to perform
additional post-processing on decoded frames only if the
frame rate is expected to be low. The parameter MUST NOT be
used for pacing of the rendering process, since the actual
frame rate may differ from the specified value.
If the parameter is not specified, it defaults to the maximum If the parameter is not specified, it defaults to the maximum
frame rate allowed by the specified profile and level. frame rate allowed by the specified profile and level.
bpic: bpic:
This parameter signals if B-pictures may be present when This parameter signals that B- and BI-pictures may be present
Advanced profile is used. If this parameter is present, and when Advanced profile is used. If this parameter is present,
B-pictures may be present in the coded bit stream, this and B- or BI-pictures may be present in the coded bit stream,
parameter MUST be equal to 1. this parameter MUST be equal to 1.
A value of 0 indicates that B-pictures SHALL NOT be present A value of 0 indicates that B- and BI-pictures SHALL NOT be
in the coded bit stream, even if the sequence layer header present in the coded bit stream, even if the sequence layer
changes. It is RECOMMENDED to include this parameter, with a header changes. It is RECOMMENDED to include this parameter,
value of 0, if no B-pictures will be included in the coded with a value of 0, if neither B- nor BI-pictures are included
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-pictures is profiles. (For Main profile, the presence of B- and BI-
indicated by the MAXBFRAMES field in STRUCT_C decoder pictures is indicated by the MAXBFRAMES field in STRUCT_C
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
skipping to change at page 22, line 36 skipping to change at page 23, line 36
the VC-1 profile than the one specified in the "level" the VC-1 profile than the one specified in the "level"
parameter, if the sender or receiver can support all the parameter, if the sender or receiver can support all the
properties of the higher level, except if specifying a higher properties of the higher level, except if specifying a higher
level is not allowed due to other restrictions. (As an level is not allowed due to other restrictions. (As an
example of such a restriction, in the SDP Offer/Answer model, example of such a restriction, in the SDP Offer/Answer model,
the value of the level parameter that can be used in an the value of the level parameter that can be used in an
Answer is limited by what was specified in the Offer.) 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 picture, in pixels. If the horizontal size for the coded picture, in luma samples
value is less than the maximum horizontal size allowed by the (pixels in the luma picture.) If the value is less than the
profile and level, then the value specifies the preferred maximum horizontal size allowed by the profile and level,
horizontal size. Otherwise, it specifies the maximum then the value specifies the preferred horizontal size.
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 picture, in pixels. If the value vertical size for the coded picture, in luma samples (pixels
is less than the maximum vertical size allowed by the profile in the luma picture.) If the value is less than the maximum
and level, then the value specifies the preferred vertical vertical size allowed by the profile and level, then the
size. Otherwise, it specifies the maximum vertical size that value specifies the preferred vertical size. Otherwise, it
is supported. specifies the maximum vertical 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 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,
skipping to change at page 29, line 5 skipping to change at page 30, line 5
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.
8. IANA Considerations It is important to note that VC-1 streams can have very high
bandwidth requirements (up to 135 Mbps for high-definition video.)
This is sufficient to cause potential for denial-of-service if
transmitted onto many Internet paths. Therefore, users of this
payload format MUST comply with the congestion control requirements
described in section 8.
8. Congestion Control
Congestion control for RTP SHALL be used in accordance with RFC 3550
[3], and with any applicable RTP profile; e.g., RFC 3551 [15].
If best-effort service is being used, users of this payload format
MUST monitor packet loss to ensure that the packet loss rate is
within acceptable parameters. Packet loss is considered acceptable
if a TCP flow across the same network path, and experiencing the same
network conditions, would achieve an average throughput, measured on
a reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or the
number of layers subscribed for a layered multicast session), or by
arranging for a receiver to leave the session if the loss rate is
unacceptably high.
The bit rate adaptation necessary for obeying the congestion control
principle is easily achievable when real-time encoding is used. When
pre-encoded content is being transmitted, bandwidth adaptation
requires one or more of the following:
- The availability of more than one coded representation of the same
content at different bit rates. The switching between the
different representations can normally be performed in the same
RTP session, by switching streams at random access point
boundaries.
- The existence of non-reference frames (e.g., B-frames) in the bit
stream. Non-reference frames can be discarded by the transmitter
prior to encapsulation in RTP. If the frames contain the TFCNTR
(Temporal Reference Frame Counter) syntax element, it will require
updating the TFCNTR fields of other frames to ensure that the
field remains continuous. Because TFCNTR counts the frames in the
display order, which is different from the order in which they are
transmitted (the coded order), it will require the transmitter to
"look ahead", or buffer, of some number of frames.
Only when non-downgradable parameters (such as the VC-1 "profile"
parameter) are required to be changed does it become necessary to
terminate and re-start the media stream. This may be accomplished by
using a different RTP payload type.
This payload format may also be used in networks that provide
quality-of-service guarantees. If enhanced service is being used,
receivers SHOULD monitor packet loss to ensure that the service that
was requested is actually being delivered. If it is not, then they
SHOULD assume that they are receiving best-effort service and behave
accordingly.
9. IANA Considerations
IANA is requested to register the media type "video/vc1" and the IANA is requested to register the media type "video/vc1" and the
associated RTP payload format, as specified in section 6.1 of this associated RTP payload format, as specified in section 6.1 of this
document, in the Media Types registry and in the RTP Payload Format document, in the Media Types registry and in the RTP Payload Format
MIME types registry. MIME types registry.
9. References 10. References
9.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", [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. 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 Klensin, J., "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 [8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload
Formats", RFC 3555, July 2003. Formats", RFC 3555, July 2003.
9.2 Informative references 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, "Windows
Media Video 9: overview and applications", Signal Processing: Media Video 9: overview and applications", Signal Processing:
Image Communication, Volume 19, Issue 9, October 2004. 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, August
2003. 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,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[15]Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
Author's Addresses Author's Addresses
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 Email: anderskl@microsoft.com
Acknowledgements Acknowledgements
Thanks to Shankar Regunathan, Gary Sullivan, Regis Crinon, Magnus Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar
Westerlund and Colin Perkins for providing detailed feedback on this Regunathan, Gary Sullivan, Stephan Wenger and Magnus Westerlund for
document. providing detailed feedback on this document.
IPR Notices IPR Notices
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
skipping to change at page 30, line 46 skipping to change at page 33, line 8
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 Full Copyright Statement
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 45 change blocks. 
145 lines changed or deleted 259 lines changed or added

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