draft-ietf-avt-rtp-vc1-01.txt   draft-ietf-avt-rtp-vc1-02.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft A. Klemets Internet Draft A. Klemets
Document: draft-ietf-avt-rtp-vc1-01.txt Microsoft Document: draft-ietf-avt-rtp-vc1-02.txt Microsoft
Expires: April 2006 October 2005 Expires: May 2006 November 2005
RTP Payload Format for Video Codec 1 (VC-1) RTP Payload Format for Video Codec 1 (VC-1)
IPR Notice 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.
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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.
Distribution of this document is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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 proposed Codec 1 (VC-1) compressed bit streams, as defined by the Society of
Society of Motion Picture and Television Engineers (SMPTE) standard, Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.
SMPTE 421M. SMPTE is the main standardizing body in the motion SMPTE is the main standardizing body in the motion imaging industry
imaging industry and the proposed SMPTE 421M standard defines a and the SMPTE 421M standard defines a compressed video bit stream
compressed video bit stream format and decoding process for format and decoding process for television.
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...............................................4 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..................5 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.........................................7
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...............................8 4.2 Fragmentation of VC-1 frames...............................9
4.3 Time stamp considerations..................................9 4.3 Time stamp considerations.................................10
4.4 Random Access Points......................................10 4.4 Random Access Points......................................11
4.5 Removal of HRD parameters.................................10 4.5 Removal of HRD parameters.................................11
4.6 Repeating the Sequence Layer header.......................11 4.6 Repeating the Sequence Layer header.......................12
4.7 Signaling of MIME format parameters.......................11 4.7 Signaling of MIME format parameters.......................12
4.8 MIME "mode=1" parameter...................................12 4.8 MIME "mode=1" parameter...................................13
4.9 MIME "mode=3" parameter...................................12 4.9 MIME "mode=3" parameter...................................13
5. RTP Payload Format syntax.....................................13 5. RTP Payload Format syntax.....................................14
5.1 RTP header usage..........................................13 5.1 RTP header usage..........................................14
5.2 AU header syntax..........................................13 5.2 AU header syntax..........................................15
5.3 AU Control field syntax...................................14 5.3 AU Control field syntax...................................16
6. RTP Payload format parameters.................................16 6. RTP Payload format parameters.................................17
6.1 Media Type Registration...................................16 6.1 Media Type Registration...................................17
6.2 Mapping of MIME parameters to SDP.........................19 6.2 Mapping of MIME parameters to SDP.........................24
7. Security Considerations.......................................20 6.3 Usage with the SDP Offer/Answer Model.....................25
8. IANA Considerations...........................................21 6.4 Usage in Declarative Session Descriptions.................27
9. References....................................................21 7. Security Considerations.......................................28
9.1 Normative references......................................21 8. IANA Considerations...........................................28
9.2 Informative references....................................21 9. References....................................................28
9.1 Normative references......................................28
9.2 Informative references....................................29
1. Introduction 1. Introduction
The bit stream syntax for compressed video in Video Codec 1 (VC-1) This memo specifies an RTP payload format for the video coding
format is defined by SMPTE 421M [1]. SMPTE 421M also specifies standard Video Codec 1, also known as VC-1. The specification for
constraints that must be met by VC-1 conformant bit streams, and it the VC-1 bit stream format and decoding process is published by the
specifies the complete process required to decode the bit stream. Society of Motion Picture and Television Engineers (SMPTE) as SMPTE
However, it does not specify the VC-1 compression algorithm, thus 421M [1].
allowing for different ways to implement a VC-1 encoder.
VC-1 has a broad applicability, being suitable for low bit rate
Internet streaming applications to HDTV broadcast and Digital Cinema
applications with nearly lossless coding. The overall performance of
VC-1 is such that bit rate savings of more than 50% are reported [8],
when compared against MPEG-2. See [8] for further details about how
VC-1 compares against other codecs, such as MPEG-4 and H.264/AVC.
(In [8], VC-1 is referred to by its earlier name, VC-9.)
VC-1 is widely used for downloading and streaming of movies on the
Internet, in the form of Windows Media Video 9 (WMV-9) [8], because
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-
definition DVD formats HD DVD and Blu-ray.
SMPTE 421M defines the VC-1 bit stream syntax and specifies
constraints that must be met by VC-1 conformant bit streams. SMPTE
421M also specifies the complete process required to decode the bit
stream. However, it does not specify the VC-1 compression algorithm,
thus allowing for different ways to implement 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, the 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.
The Advanced profile is designed for broadcast applications, such as Advanced profile is designed for broadcast applications, such as
digital TV, HD DVD or HDTV. The 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. 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 MIME and the RTP payload format for VC-1, and section 6 defines the MIME and
SDP parameters for VC-1. See section 7 for security considerations. SDP parameters for VC-1. See section 7 for security considerations.
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.
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
skipping to change at page 4, line 48 skipping to change at page 5, line 13
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. The Simple and Main profiles are designed for and Advanced. Simple and Main profiles are designed for relatively
relatively low bit rate applications. For example, the maximum bit low bit rate applications. For example, the maximum bit rate
rate supported by the Simple profile is 384 kbps. To help achieve supported by Simple profile is 384 kbps. Certain features that can
high compression efficiency, certain features such as non-square be used to achieve high compression efficiency, such as non-square
pixels and support for interlaced pictures, are only included in the pixels and support for interlaced pictures, are only included in
Advanced profile. Advanced profile.
The maximum bit rate supported by the Advanced profile is 135 Mbps, The maximum bit rate supported by the Advanced profile is 135 Mbps,
making it suitable for nearly lossless encoding of HDTV signals. making it suitable for nearly lossless encoding of HDTV signals.
Only the Advanced profile supports carrying user-data (meta-data) in- Only Advanced profile supports carrying user-data (meta-data) in-band
band with the compressed bit stream. The user-data can be used for with the compressed bit stream. The user-data can be used for closed
closed captioning support, for example. captioning support, for example.
Of the three profiles, only the 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. The of parameters in a profile, such as the bit rate or buffer size. VC-
VC-1 Simple profile has two levels, the Main profile has three, and 1 Simple profile has two levels, Main profile has three, and Advanced
the Advanced profile has five levels. See Annex D of SMPTE 421M [1] profile has five levels. See Annex D of SMPTE 421M [1] for a
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 the 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 the 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 the Advanced The entry-point and slice layers are only present in Advanced
profile. In the Advanced profile, the start of each entry-point profile. In Advanced profile, the start of each entry-point layer
layer segment indicates a random access point. In the Simple and segment indicates a random access point. In Simple and Main profiles
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, BI-picture, or as a B-picture. These terms are defined in picture, or as a B-picture. These terms are defined in section 2 of
section 2 of this document and in section 4.12 of SMPTE 421M [1]. 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 the Advanced profile only, each picture and slice is byte-aligned In Advanced profile only, each picture and slice is byte-aligned and
and is considered a Bit-stream Data Unit (BDU). A BDU is defined as is considered a Bit-stream Data Unit (BDU). A BDU is defined as a
a unit that can be parsed (i.e., syntax decoded) independently of unit that can be parsed (i.e., syntax decoded) independently of other
other information in the same layer. 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. Note that
blocks and macroblocks are not BDUs and thus do not have a Start Code blocks and macroblocks are not BDUs and thus do not have a Start Code
and are not necessarily byte-aligned. and are 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
skipping to change at page 6, line 26 skipping to change at page 6, line 42
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 the 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. These parameters that are necessary to initialize the VC-1 decoder.
parameters apply to all entry-point segments until the next
occurrence of a sequence layer header in the coded bit stream. 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 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 dimensions of the coded pictures, 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.
Each leaky bucket parameter set for the HRD specifies a peak Each leaky bucket parameter set for the HRD specifies a peak
skipping to change at page 6, line 52 skipping to change at page 7, line 26
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 [7]. theory of the HRD can be found in [9].
The concept of an entry-point layer applies only to the VC-1 Advanced The concept of an entry-point layer applies only to VC-1 Advanced
profile. The presence of an entry-point header indicates a random profile. The presence of an entry-point header indicates a random
access point within the bit stream. The entry-point header specifies access point within the bit stream. The entry-point header specifies
current buffer fullness values for the leaky buckets in the HRD. The current buffer fullness values for the leaky buckets in the HRD. The
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. See Section 6.2 of SMPTE 421M [1] for the formal
specification of the entry-point header. specification of the entry-point header.
Neither a sequence layer header nor an entry-point header is defined
for the VC-1 Simple and Main profiles. For these profiles, decoder
initialization parameters MUST be conveyed out-of-band from the coded
bit stream. Section 4.7 of this document specifies how the
parameters are conveyed by this RTP payload format.
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 the presence of B-pictures has been indicated in the except if B-pictures are present in the coded bit stream. In the
decoder initialization parameters. In the latter case, the frames latter case, the frames are transmitted such that the frames that the
are reordered by the VC-1 encoder such that the frames that the B- B-pictures depend on are transmitted first. This is referred to as
pictures depend on are transmitted first. This is referred to as the the coded order of the frames.
coded order of the frames.
When the presence of B-pictures has been indicated, the decoder is The rules for how a decoder converts frames from the coded order to
required to buffer one picture. When an I-picture or a P-picture is the display order are stated in section 5.4 of SMPTE 421M [1]. In
received, the picture is not displayed until the next I- or P-picture short, if B-pictures may be present in the coded bit stream, a
is received. However, B-pictures are displayed immediately. These hypothetical decoder implementation needs to buffer one additional
rules are stated in section 5.4 in SMPTE 421M [1]. 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-
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
frames, their coded order, and the display order of the decoded frames, their coded order, and the display order of the decoded
frames. The figure shows that the display of frame P4 is delayed frames, when B-pictures are present in the coded bit stream. The
until frame P5 is received, while frames B2 and B3 are displayed figure shows that the display of frame P4 is delayed until frame P7
immediately. is received, while frames B2 and B3 are displayed immediately.
Capture: |I0 P1 B2 B3 P4 ... Capture: |I0 P1 B2 B3 P4 B5 B6 P7 B8 B9 ...
| |
Coded order: | I0 P1 P4 B2 B3 P5 ... Coded order: | I0 P1 P4 B2 B3 P7 B5 B6 ...
| |
Display order: | I0 P1 B2 B3 P4 ... Display order: | I0 P1 B2 B3 P4 B5 B6 ...
| |
|+---+---+---+---+---+---+---+------> time |+---+---+---+---+---+---+---+---+---+--> time
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9
Figure 1. Frame reordering when B-pictures are indicated. Figure 1. Frame reordering when B-pictures are present.
If B-pictures are not present, the coded order and the display order
are identical, and frames can then be displayed without 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), as defined in this section. Figure 2 shows the Access Unit (AU). An Access Unit is defined as the AU header
layout of an RTP packet with multiple AUs. (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
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.
Access Units MUST be byte-aligned. Each Access Unit MUST start with Each Access Unit MUST start with the AU header defined in section
the AU header defined in section 5.2, and is followed by a variable 5.2. The AU payload MUST contain data belonging to exactly one VC-1
length payload. 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
The AU payload MUST contain data belonging to exactly one VC-1 frame. be fragmented across multiple AUs (see section 4.2.)
The following rules apply to the contents of each AU payload when the The following rules apply to the contents of each AU payload when VC-
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 frame header and multiple slices header, an entry-point header, a picture header and multiple
and the associated user-data. (However, all slices and their slices and the associated user-data. (However, all slices and
corresponding macroblocks MUST belong to the same video frame.) their corresponding macroblocks MUST 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.
If the data in an AU (EBDUs in the case of Advanced profile and frame When VC-1 Simple or Main profiles are used, the AU payload MUST start
in the case of Simple and Main) does not end at an octet boundary, up with a picture header, except when the AU payload contains a
to 7 zero-valued padding bits MUST be added to achieve octet- fragmented frame. Section 4.2 describes how to handle fragmented
alignment. frames.
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
Main) does not end at an octet boundary, up to 7 zero-valued padding
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 frame. profiles, the AU payload MUST begin with the start of a picture
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 the Advanced profile, and are However, slices are only defined for Advanced profile, and are not
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. possible to continue a fragmented frame at an EBDU boundary.
If a RTP packet contains an AU with the last fragment of a frame, In the case of Simple and Main profiles, since the blocks and
macroblocks are not byte-aligned, the fragmentation boundary may be
chosen arbitrarily.
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 used, each fragment of a If the PTS Delta field in the AU header is present, each fragment of
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 used, each fragment of a frame MUST have the same in the AU header is present, each fragment of a frame MUST have the
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 Video frames MUST be transmitted in the coded order. Coded order
implies that no frames are dependent on subsequent frames, as 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. The RTP timestamp field MUST be set to the
presentation time of the video frame contained in the first AU in the presentation time of the video frame contained in the first AU in the
RTP packet. The presentation time is equivalent to the sampling RTP packet. The presentation time can be used as the timestamp field
instant of the frame. in the RTP header because it differs from the sampling instant of the
frame only by an arbitrary constant offset.
Each AU header may optionally specify the decode time of video frame Each AU header MAY specify the decode time of video frame contained
contained in the AU. If the decode time is not specified, the RTP in the AU. If B-pictures will not be present in the coded bit
receiver can approximate it by the frame's presentation time, after stream, then the decode time of a frame MUST be equal to the
taking frame reordering into account. Frame reordering can be presentation time of the frame.
handled by an algorithm similar to the one illustrated in Figure 1 in
section 3.4. The algorithm requires buffering of only one frame.
Knowing if the stream will contain B-pictures helps the decoder If B-pictures may be present in the coded bit stream, then the decode
allocate resources more efficiently, as the encoder will not reorder time of non-B frames MUST be equal to the presentation time of the
any frames. In that case, the buffering of one frame as described in previous non-B frame in the coded order. The decode time of B-frames
section 3.4 is not necessary. Avoiding this buffer reduces the end- MUST be equal to the presentation time of the B-frame.
to-end delay, which may be important for interactive applications.
For Advanced profile, B-pictures are assumed to be present by
default. If the coded bit stream never contains B-pictures, this can
be indicated using the "bpic" MIME parameter defined in section 6.1.
For Simple and Main profiles, the presence of B-pictures is indicated As an example, consider Figure 1 in section 3.4. The decode time of
by a non-zero value for the MAXBFRAMES field in STRUCT_C decoder non-B frame P4 is 4 time units, which is equal to the presentation
initialization parameter. STRUCT_C conveyed in the MIME "config" time of the previous non-B frame in the coded order, which is P1. On
parameter, which is defined in section 6.1. the other hand, the decode time of B-frame B2 is 5 time units, which
is identical to its presentation time.
Knowing if the stream will contain B-pictures may help the receiver
allocate resources more efficiently and can reduce delay, as an
absence of B-pictures in the stream implies that no reordering
of frames will be needed between the decoding process and the display
of the decoded frames. This may be important for interactive
applications.
The receiver MUST assume that the coded bit stream may contain B-
pictures in the following cases:
- Advanced profile: If the value of the "bpic" MIME parameter
defined in section 6.1 is 1, or if the "bpic" parameter is not
specified.
- Main profile: If the MAXBFRAMES field in STRUCT_C decoder
initialization parameter has a non-zero value. STRUCT_C is
conveyed in the MIME "config" parameter, which is defined in
section 6.1.
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 points
into the coded bit stream. The 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 a 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 for every random access point. For additional value is incremented (modulo 256) for every random access point. For
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 a 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 the Advanced profile may include up to The sequence layer header of Advanced profile may include up to 31
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 (HDR_RATE) and a decoder buffer capacity transmission bit rate (HDR_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,
skipping to change at page 11, line 34 skipping to change at page 12, line 38
Note that any data in the VC-1 bit stream, including repeated copies Note that any data in the VC-1 bit stream, including repeated copies
of the sequence header itself, must be accounted for when computing of the sequence header itself, must be accounted for when computing
the leaky bucket parameter for the HRD. (See section 3.3 for a the 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 Note that if the value of TFCNTRFLAG in the sequence layer header is
1, each picture header contains a frame counter field (TFCNTR). Each 1, each picture header contains a frame counter field (TFCNTR). Each
time the sequence layer header is inserted in the bit stream, the time the sequence layer header is inserted in the bit stream, the
value of this counter MUST be reset. value of this counter MUST be reset.
To allow the RTP receiver to detect that a 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 MIME format parameters 4.7 Signaling of MIME format 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 MIME parameters specified in section 6.1. Section in SDP using the MIME parameters specified in section 6.1. Section
6.2 specifies how to map the MIME parameters to SDP. 6.2 specifies how to map the MIME parameters to SDP.
When the Advanced profile is used, the decoder initialization When Advanced profile is used, the decoder initialization parameters
parameters MAY be changed by inserting a new sequence layer header or MAY be changed by inserting a new sequence layer header or an entry-
an entry-point header in the coded bit stream. point header in the coded bit stream.
Note that the sequence layer header specifies the encoding level, the When Simple or Main profiles are used, it is not possible to change
maximum size of the coded pictures and possibly also the frame rate. the decoder initialization parameters through the coded bit stream
itself. Any changes to the decoder initialization parameters would
have to be done through out-of-band means, e.g., by updating the SDP
[5].
Thus, if the sequence layer header changes, the new header supersedes Note that the sequence layer header specifies the encoding level, the
the values of the MIME parameters "level", "width", "height" and maximum size of the coded pictures and possibly also the maximum
"framerate". frame rate. Thus, if the sequence layer header changes, the new
header supersedes the values of the MIME parameters "level", "width",
"height" and "framerate".
4.8 MIME "mode=1" parameter 4.8 MIME "mode=1" parameter
In certain applications using the Advanced profile, the sequence In certain applications using Advanced profile, the sequence layer
layer header never changes. This MAY be signaled with the MIME header never changes. This MAY be signaled with the MIME parameter
parameter "mode=1". (The "mode" parameter is defined in section 6.1.) "mode=1". (The "mode" parameter is defined in section 6.1.) The
The "mode=1" parameter serves as a "hint" to the RTP receiver that "mode=1" parameter serves as a "hint" to the RTP receiver that all
all sequence layer headers in the bit stream will be identical. If 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
header specified by the MIME "config" parameter. header specified by the MIME "config" 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 sender MAY remove it from the bit stream. Note, however, that if
that if the value of TFCNTRFLAG in the sequence layer header is 1, that if the value of TFCNTRFLAG in the sequence layer header is 1,
each picture header contains a frame counter field (TFCNTR). This each picture header contains a frame counter field (TFCNTR). This
field is reset each time the sequence layer header occurs in the bit field is reset each time the sequence layer header occurs in the bit
stream. If the RTP sender chooses to remove the sequence layer stream. If the RTP sender chooses to remove the sequence layer
header, then it MUST ensure that the resulting bit stream is still header, then it MUST ensure that the resulting bit stream is still
compliant with the VC-1 specification (e.g., by adjusting the TFCNTR compliant with the VC-1 specification (e.g., by adjusting the TFCNTR
field, if necessary.) field, if necessary.)
4.9 MIME "mode=3" parameter 4.9 MIME "mode=3" parameter
In certain applications using the 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 MIME parameter "mode=3". The same rules apply to signaled with the MIME parameter "mode=3". The same rules apply to
"mode=3" as for "mode=1", described in section 4.8. Additionally, if "mode=3" as for "mode=1", described in section 4.8. Additionally, if
"mode=3" is signaled, then the RTP sender MAY "compress" the coded "mode=3" is signaled, then the RTP sender MAY "compress" the coded
bit stream by not including sequence layer headers and entry-point bit stream by not including sequence layer headers and entry-point
headers in the RTP packets. 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 re-
inserting the entry-point headers prior to delivering the coded bit inserting the entry-point headers prior to delivering the coded bit
stream to the VC-1 decoder. The sequence layer header does not need stream to the VC-1 decoder. The sequence layer header does not need
skipping to change at page 13, line 27 skipping to change at page 14, line 37
| timestamp | | timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier | | synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers | | contributing source (CSRC) identifiers |
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. RTP header according to RFC 3550 Figure 3. RTP header according to RFC 3550
With the exception of the fields listed below, the RTP header fields The fields of the fixed RTP header have their usual meaning, which is
are used as defined in RFC 3550 and by the RTP profile in use. defined in RFC 3550 and by the RTP profile in use, with the following
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 containing a complete VC-1 frame, or the last fragment Unit containing a complete VC-1 frame, or the last fragment
of a VC-1 frame. of a VC-1 frame.
Payload type (PT): 7 bits Payload type (PT): 7 bits
This document does not assign a RTP payload type for this RTP This document does not assign an RTP payload type for this
payload format. The assignment of a payload type has to be RTP payload format. The assignment of a payload type has to
performed either through the RTP profile used or in a dynamic be performed either through the RTP profile used or in a
way. dynamic way.
Sequence Number: 16 bits
The RTP receiver can use the sequence number field to recover
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.)
When VC-1 frames have been fragmented across RTP packets, the
RTP receiver can use the sequence number field to ensure that
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 90 kHz clock rate MUST be used. A clock rate of 90 kHz, or higher, MUST be 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. The structure of the AU header RA Count field and 3 optional fields. All fields MUST be written in
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
skipping to change at page 14, line 32 skipping to change at page 15, line 52
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. header in the packet.
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 in the RTP header of this RTP packet. The PTS timestamp field in the RTP header of this RTP packet. The
Delta field MUST use the same clock rate as the timestamp PTS Delta field MUST use the same clock rate as the timestamp
field in the RTP header. field in the RTP header.
This field SHOULD NOT be included in the first AU header in This field SHOULD NOT be included in the first AU header in
the RTP packet, because the RTP timestamp field specifies the the RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU. presentation time of the frame in the first AU.
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 2's complement offset (delta) from the timestamp in the RTP a 2's complement offset (delta) between the presentation time
header of this RTP packet. The DTS Delta field MUST use the and the decode time. Note that if the presentation time is
same clock rate as the timestamp field in the RTP header. larger than the decode time, this results in a value for the
DTS Delta field that is greater than zero. The DTS Delta
field MUST use the same clock rate as the timestamp field in
the RTP header.
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 |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
skipping to change at page 16, line 15 skipping to change at page 17, line 37
header includes the DTS Delta field. header 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
The media subtype for VC-1 is allocated from the standards tree. The This registration uses the template defined in [11] and follows RFC
top-level media type under which this payload format is registered is 3555 [7].
'video'.
The receiver MUST ignore any unrecognized parameter.
Media type: video Type name: video
Media subtype: vc1 Subtype name: vc1
Required parameters: Required parameters:
profile: profile:
The value is a decimal number indicating the VC-1 profile. The value is an integer identifying the VC-1 profile. The
The following values are defined: following values are defined:
0: Simple profile. 0: Simple profile.
1: Main profile. 1: Main profile.
3: Advanced profile. 3: Advanced profile.
If the profile parameter is used to indicate properties of a
coded bit stream, it indicates the VC-1 encoding profile that
a decoder has to support in order to comply with [1] when it
decodes the bit stream.
If the profile parameter is used for capability exchange or
in a session setup procedure, it indicates the VC-1 profile
that codec supports.
level:
The value is an integer specifying the level of the VC-1
profile.
For Advanced profile, valid values are 0 to 4, which
correspond to levels L0 to L4, respectively. For Simple and
Main profiles, the following values are defined:
1: Low Level
2: Medium Level
3: High Level (only valid for Main profile)
If the level parameter is used to indicate properties of a
coded bit stream, it indicates the level of the VC-1 profile
that a decoder has to support in order to comply with [1]
when it decodes the bit stream. Note that when Advanced
profile is used, this parameter may only apply while the
sequence layer header specified in the config parameter is in
use.
If the level parameter is used for capability exchange or in
a session setup procedure, it indicates the highest level of
the VC-1 profile that codec supports. See section 6.3 for
specific rules for how this parameter is used with the SDP
Offer/Answer model.
Optional parameters:
config: config:
The value is a base16 [5] (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 multiple of 8 bits, in the
last octet up to 7 zero-valued padding bits MUST be added to last octet up to 7 zero-valued padding bits MUST be added to
achieve octet alignment. achieve octet alignment.
For the 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 the Advanced profile, the decoder initialization For Advanced profile, the decoder initialization parameters
parameters are a sequence layer header directly followed by are a sequence layer header directly followed by an entry-
an entry-point header. The two headers MUST be in EBDU point header. The two headers MUST be in EBDU format,
format, meaning that they must include their Start Codes and meaning that they must include their Start Codes and must use
must use the encapsulation method defined in Annex E of SMPTE the encapsulation method defined in Annex E of SMPTE 421M
421M [1]. [1].
This parameter MUST NOT be used to indicate codec
capabilities in any capability exchange procedure.
width: width:
The value is a decimal number specifying the maximum The value is an integer greater than zero, specifying the
horizontal size of the coded picture in pixels. maximum horizontal size of the coded picture, in pixels.
If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the profile and level.
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
height: height:
The value is a decimal number specifying the maximum vertical The value is an integer greater than zero, specifying the
size of the coded picture in pixels. maximum vertical size of the coded picture in pixels.
If this parameter is not specified, it defaults to the
maximum vertical size allowed by the profile and level.
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
bitrate: bitrate:
The value is a decimal number specifying the peak The value is an integer greater than zero, specifying the
transmission rate of the coded bit stream. The number does peak transmission rate of the coded bit stream in bits per
not include RTP overhead. second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers,
Note: When Advanced profile is used, this parameter only or any of the RTP, UDP or IP headers.
applies while the sequence layer header specified in the
config parameter is in use.
buffer: If this parameter is not specified, it defaults to the
The value is a decimal number specifying the leaky bucket maximum bit rate allowed by the profile and level. (See the
size, B, in milliseconds, required to contain a stream values for "RMax" in Annex D of SMPTE 421M [1].)
transmitted at the transmission rate specified by the bitrate
parameter. This parameter is defined in the hypothetical
reference decoder model for VC-1, in Annex C of SMPTE 421M
[1].
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
Optional parameters: buffer:
The value is an integer specifying the leaky bucket size, B,
in milliseconds, required to contain a stream transmitted at
the transmission rate specified by the bitrate parameter.
This parameter is defined in the hypothetical reference
decoder model for VC-1, in Annex C of SMPTE 421M [1].
level: Note that this parameter relates to the codec bit stream
The value is a decimal number specifying the level of the only, and does not account for any buffering time that may be
encoding profile. required to compensate for jitter in the network.
For Advanced profile, valid values are 0 to 4, which
correspond to levels L0 to L4, respectively. For Simple and
Main profiles, the following values are defined:
1: Low Level
2: Medium Level
3: High Level (only valid for Main profile)
This parameter does not have a default value. If this parameter is not specified, it defaults to the
maximum buffer size allowed by the profile and level. (See
the values for "BMax" and "RMax" in Annex D of SMPTE 421M
[1].)
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
framerate: framerate:
The value is a decimal number specifying the number of frames The value is an integer greater than zero, specifying the
per second, multiplied by 1000. For example, 29.97 frames maximum number of frames per second in the coded bit stream,
per second is represented as 29970. multiplied by 1000 and rounded to the nearest integer value.
For example, 30000/1001 (approximately 29.97) frames per
second is represented as 29970.
This parameter does not have a default value. If the If the parameter is not specified, it defaults to the maximum
parameter is not specified, the frame rate can be determined frame rate allowed by the profile and level.
from the level of the encoding profile, if it is known.
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
bpic: bpic:
This parameter signals if B-pictures may be present when the This parameter signals if B-pictures may be present when
Advanced profile is used. If this parameter is present, and Advanced profile is used. If this parameter is present, and
B-pictures may be present in the coded bit stream, this B-pictures may be present in the coded bit stream, this
parameter MUST be equal to 1. parameter MUST be equal to 1.
If B-pictures will never be present in the coded bit stream, If B-pictures will never be present in the coded bit stream,
even if the sequence layer header changes, this parameter even if the sequence layer header changes, this parameter
SHOULD be present and its value SHOULD be equal to 0. SHOULD be present and its value SHOULD be equal to 0.
If this parameter is not specified, a value of 1 MUST be This parameter MUST not be used with Simple and Main
assumed. profiles. (For Main profile, the presence of B-pictures is
indicated by the MAXBFRAMES field in STRUCT_C decoder
initialization parameter.)
For Advanced profile, if this parameter is not specified, a
value of 1 MUST be assumed.
mode: mode:
The value is a decimal number specifying the use of the The value is an integer specifying the use of the sequence
sequence layer header and the entry-point header. This layer header and the entry-point header. This parameter is
parameter is only used for Advanced profile. The following only defined for Advanced profile. The following values are
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 RTP
packets. packets.
1: The sequence layer header specified in the config 1: The sequence layer header specified in the config
parameter never changes. parameter never changes.
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. Entry-point specified in the config parameter never change. Entry-point
headers MAY not be included in the Access Units. Each Access headers MAY not be included in the Access Units. Each Access
Unit that has the RA bit set to 1 contains a random access Unit that has the RA bit set to 1 contains a random access
point even if an entry-point header is not included in the point even if an entry-point header is not included in the
Access Unit. If an entry-point header is not included at a Access Unit. If an entry-point header is not included at a
random access point, then the RTP receiver MUST insert the random access point, then the RTP receiver MUST insert the
entry-point header into the VC-1 bit stream prior to entry-point header into the VC-1 bit stream prior to
delivering the bit stream to the VC-1 decoder. delivering the bit stream to the VC-1 decoder.
If the mode parameter is not specified, a value of 0 MUST be If the mode parameter is not specified, a value of 0 MUST be
assumed. The mode parameter SHOULD be specified if modes 1 assumed. The mode parameter SHOULD be specified if modes 1
or 3 apply to the VC-1 bit stream. or 3 apply to the VC-1 bit stream.
max-width, max-height, max-bitrate, max-buffer, max-framerate:
These parameters are defined for use in a capability exchange
procedure. The parameters do not specify properties of the
coded bit stream, but rather upper limits or preferred values
for the "width", "height", "bitrate", "buffer" and
"framerate" parameters. Section 6.3 provides specific rules
for these parameters are used with the SDP Offer/Answer
model.
Any of the max-width, max-height, max-bitrate, max-buffer and
max-framerate parameters MAY be used to indicate capabilities
that exceed the required capabilities of the signaled profile
and level. In that case, the parameter MUST be interpreted
as the maximum value that can be supported for that
capability.
If any of the parameters specifies a capability that is less
than the required capabilities of the signaled profile and
level, then the parameter SHOULD be interpreted as a
preferred value for that capability.
When more than one parameter from the set (max-width, max-
height, max-bitrate, max-buffer and max-framerate) is
present, all signaled capabilities MUST be supported
simultaneously.
A sender or receiver MUST NOT use these parameters to
indicate capabilities that meet the requirements of a higher
level of the VC-1 profile than the one specified in the
"level" parameter, if the sender or receiver can support all
the properties of the higher level, except if specifying a
higher level is not allowed due to other restrictions. (As
an example of such a restriction, in the SDP Offer/Answer
model, the value of the level parameter that can be used in
an Answer is limited by what was specified in the Offer.)
max-width:
The value is an integer greater than zero, specifying a
horizontal size for the coded picture, in pixels. If the
value is less than the maximum horizontal size allowed by the
profile and level, then the value specifies the preferred
horizontal size. Otherwise, it specifies the maximum
horizontal size that is supported.
If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the profile and level.
max-height:
The value is an integer greater than zero, specifying a
vertical size for the coded picture, in pixels. If the value
is less than the maximum vertical size allowed by the profile
and level, then the value specifies the preferred vertical
size. Otherwise, it specifies the maximum vertical size that
is supported.
If this parameter is not specified, it defaults to the
maximum vertical size allowed by the profile and level.
max-bitrate:
The value is an integer greater than zero, specifying a peak
transmission rate for the coded bit stream in bits per
second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP or IP headers.
If the value is less than the maximum bit rate allowed by the
profile and level, then the value specifies the preferred bit
rate. Otherwise, it specifies the maximum bit rate that is
supported.
If this parameter is not specified, it defaults to the
maximum bit rate allowed by the profile and level. (See the
values for "RMax" in Annex D of SMPTE 421M [1].)
max-buffer:
The value is an integer specifying a leaky bucket size, B, in
milliseconds, required to contain a stream transmitted at the
transmission rate specified by the max-bitrate parameter.
This parameter is defined in the hypothetical reference
decoder model for VC-1, in Annex C of SMPTE 421M [1].
Note that this parameter relates to the codec bit stream
only, and does not account for any buffering time that may be
required to compensate for jitter in the network.
If the value is less than the maximum leaky bucket size
allowed by the max-bitrate parameter and the profile and
level, then the value specifies the preferred leaky bucket
size. Otherwise, it specifies the maximum leaky bucket size
that is supported for the bit rate specified by the max-
bitrate parameter.
If this parameter is not specified, it defaults to the
maximum buffer size allowed by the profile and level. (See
the values for "BMax" and "RMax" in Annex D of SMPTE 421M
[1].)
max-framerate:
The value is an integer greater than zero, specifying a
number of frames per second for the coded bit stream. The
value is the frame rate multiplied by 1000 and rounded to the
nearest integer value. For example, 30000/1001
(approximately 29.97) frames per second is represented as
29970.
If the value is less than the maximum frame rate allowed by
the profile and level, then the value specifies the preferred
frame rate. Otherwise, it specifies the maximum frame rate
that is supported.
If the parameter is not specified, it defaults to the maximum
frame rate allowed by the 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 this document. See Section 7 of this document.
Interoperability considerations: Interoperability considerations:
None. None.
Published specification: Published specification:
skipping to change at page 20, line 7 skipping to change at page 24, line 42
IETF Audio/Video Transport Working Group delegated from the IETF Audio/Video Transport Working Group delegated from the
IESG. IESG.
6.2 Mapping of MIME parameters to SDP 6.2 Mapping of MIME 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 media o The media name in the "m=" line of SDP MUST be video (the type
type). 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
media subtype). 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 at least 90000.
o The REQUIRED parameters "profile", "config", "width", "height", o The REQUIRED parameters "profile" and "level" MUST be included in
"bitrate" and "buffer" MUST be included in the "a=fmtp" line of the "a=fmtp" line of SDP.
SDP.
These parameters are expressed as a MIME media type string, in the These parameters are expressed as a MIME media type string, in the
form of a semicolon separated list of parameter=value pairs. form of a semicolon separated list of parameter=value pairs.
o The OPTIONAL parameters "level", "framerate", "bpic" and "mode", o The OPTIONAL parameters "config", "width", "height", "bitrate",
when present, MUST be included in the "a=fmtp" line of SDP. "buffer", "framerate", "bpic", "mode", "max-width", "max-height",
"max-bitrate", "max-buffer" and "max-framerate", when present,
MUST be included in the "a=fmtp" line of SDP.
These parameters are expressed as a MIME media type string, in the These parameters are expressed as a MIME media type string, in the
form of a semicolon separated list of parameter=value pairs: form of a semicolon 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
When VC-1 is offered over RTP using SDP in an Offer/Answer model [5]
for negotiation for unicast usage, the following rules and
limitations apply:
o The "profile" parameter MUST be used symmetrically, i.e., the
answerer MUST either maintain the parameter or remove the media
format (payload type) completely if the offered encoding profile
is not supported.
o The "level" parameter describes the level of the VC-1 profile of
the coded bit stream that the offerer or answerer is sending for
this media format configuration, when the direction attribute is
sendonly or sendrecv. If the direction attribute is sendrecv or
recvonly, the parameter also specifies the highest level of the
VC-1 profile that the receiver implementation accepts.
The answerer MUST NOT specify a numerically higher level in the
answer than what was specified in the offer, regardless of the
direction attribute.
If an offer specifies the recvonly direction attribute, the
answerer MAY specify a level that is lower than what was specified
in the offer, i.e., the level parameter can be "downgraded".
If the offer specifies the sendonly direction attribute, the level
parameter cannot be downgraded by the answerer. In this case, the
answerer MUST either maintain the level parameter or remove the
media format (payload type) completely if the level is not
supported.
If the offer specifies the sendrecv direction attribute, or if the
direction attribute is unspecified, the answerer MAY specify a
level that is lower than what was specified in the offer. Note
that the level parameter specified in the answer applies to the
coded bit stream that will be sent by the answerer, and the
offerer will still use the level parameter that it specified in
the offer.
o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer" and "mode", describe the properties of the VC-
1 bit stream that the offerer or answerer is sending for this
media format configuration.
In the case of unicast usage and when the direction attribute in
the offer or answer is recvonly, the interpretation of these
parameters is undefined and they MUST NOT be used.
o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate" and "max-buffer" MAY be specified in an offer or an
answer, and their interpretation is as follows:
When the direction attribute is sendonly, the parameters describe
the limits of the VC-1 bit stream that the sender is capable of
producing for the given profile and level, or any lower level of
the same profile.
When the direction attribute is recvonly or sendrecv, the
parameters describe properties of the receiver implementation. If
the value of a property is less than what is allowed by the level
of the VC-1 profile, then it SHOULD be interpreted only as a
preferred value suggested by the sender. If the value of a
property is greater than what is allowed by the level of the VC-1
profile, then it MUST be interpreted by the sender as an upper
limit of what the receiver accepts for the given profile and
level, and any lower level of the same profile.
For example, if a recvonly or sendrecv offer specifies
"profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a
suggested bit rate, because all receiver implementations of Simple
profile, Low Level, are required to support bit rates of up to 96
kbps. But if the offer specifies "max-bitrate=200000", this means
that the receiver implementation supports a maximum of 200 kbps
for the given profile and level (or lower level.)
o If an offerer wishes to have non-symmetrical capabilities between
sending and receiving, e.g., use different levels in each
direction, then the offerer has to offer different RTP sessions.
This can be done by specifiying different media lines declared as
"recvonly" and "sendonly", respectively.
For streams being delivered over multicast, the following rules apply
in addition:
o The "level" parameter specifies the highest level of the VC-1
profile of the bit stream that will be sent, and/or received, on
the multicast session. The value of this parameter MUST NOT be
changed by the answerer. Thus, a payload type can either be
accepted unaltered or removed.
o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer" and "mode", specify properties of the VC-1 bit
stream that will be sent, and/or received, on the multicast
session. The parameters MAY be specified even if the direction
attribute is recvonly.
The values of these parameters MUST NOT be changed by the
answerer. Thus, a payload type can either be accepted unaltered
or removed.
o The values of the parameters "max-width", "max-height", "max-
framerate", "max-bitrate" and "max-buffer" MUST be supported by
the answerer for all streams declared as sendrecv or recvonly.
Otherwise, one of the following actions MUST be performed: the
media format is removed, or the session rejected.
6.4 Usage in Declarative Session Descriptions
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.
o The parameters "profile" and "level" indicate only the properties
of the coded bit stream. They do not imply a limit on capabilties
supported by the sender.
o The parameters "config", "width", "height", "bitrate" and "buffer"
MUST be specified.
o The parameters "max-width", "max-height", "max-framerate", "max-
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
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [4], and in any appropriate RTP profile. This implies specification [4], and in any appropriate RTP profile. This implies
that confidentiality of the media streams is achieved by encryption; that confidentiality of the media streams is achieved by encryption;
for example, through the application of SRTP [6]. for example, through the application of SRTP [10].
A potential denial-of-service threat exists for data encodings using A potential denial-of-service threat exists for data encodings using
compression techniques that have non-uniform receiver-end compression techniques that have non-uniform receiver-end
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 [6]. RECOMMENDED; for example, with SRTP [10].
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 very 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.
8. IANA Considerations 8. IANA Considerations
IANA is requested to register the media subtype name "vc1" for the IANA is requested to register the MIME type "video/vc1" and the
media type "video" as specified in section 6.1 of this document. associated RTP payload format, as specified in section 6.1 of this
document, in the Media Types registry and in the RTP Payload Format
MIME types registry.
9. References 9. References
9.1 Normative references 9.1 Normative references
[1] Proposed SMPTE 421M, "VC-1 Compressed Video Bitstream Format and [1] Proposed SMPTE 421M, "VC-1 Compressed Video Bitstream Format and
Decoding Process", www.smpte.org. Decoding Process", www.smpte.org.
[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] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data [5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003. Encodings", RFC 3548, July 2003.
[7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload
Formats", RFC 3555, July 2003.
9.2 Informative references 9.2 Informative references
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [8] Srinivasan, S., Hsu, P., Holcomb, T., Mukerjee, K., Regunathan,
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC S.L., Lin, B., Liang, J., Lee, M., and J. Ribas-Corbera, "Windows
3711, March 2004. Media Video 9: overview and applications", Signal Processing:
[7] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A Image Communication, Volume 19, Issue 9, October 2004.
[9] 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.
[10]Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[11]Freed, N. and Klensin, J., "Media Type Specifications and
Registration Procedures", Work in Progress, July 2005.
[12]Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[13]Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
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 for pointing out errors in the initial Thanks to Shankar Regunathan, Gary Sullivan, Regis Crinon, Magnus
draft of this document. Westerlund and Colin Perkins for 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
 End of changes. 98 change blocks. 
262 lines changed or deleted 627 lines changed or added

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