draft-ietf-avt-rtp-vc1-03.txt   draft-ietf-avt-rtp-vc1-04.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft A. Klemets Internet Draft A. Klemets
Document: draft-ietf-avt-rtp-vc1-03.txt Microsoft Document: draft-ietf-avt-rtp-vc1-04.txt Microsoft
Expires: June 2006 December 2005 Expires: June 2006 December 2005
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 2, line 4 skipping to change at page 2, line 4
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.........................................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...............................9 4.2 Fragmentation of VC-1 frames ..............................9
4.3 Time stamp considerations.................................10 4.3 Time stamp considerations.................................10
4.4 Random Access Points......................................11 4.4 Random Access Points .....................................11
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 ......................12
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.........................13
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.....................................14
5.1 RTP header usage..........................................14 5.1 RTP header usage..........................................14
5.2 AU header syntax..........................................15 5.2 AU header syntax..........................................15
5.3 AU Control field syntax...................................16 5.3 AU Control field syntax...................................16
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...................25
6.3 Usage with the SDP Offer/Answer Model.....................25 6.3 Usage with the SDP Offer/Answer Model.....................25
6.4 Usage in Declarative Session Descriptions.................27 6.4 Usage in Declarative Session Descriptions.................27
7. Security Considerations.......................................28 7. Security Considerations.......................................28
8. IANA Considerations...........................................29 8. IANA Considerations...........................................29
9. References....................................................29 9. References....................................................29
9.1 Normative references......................................29 9.1 Normative references .....................................29
9.2 Informative references....................................29 9.2 Informative references....................................29
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
Internet streaming applications to HDTV broadcast and Digital Cinema Internet streaming applications to HDTV broadcast and Digital Cinema
applications with nearly lossless coding. The overall performance of applications with nearly lossless coding. The overall performance of
VC-1 is such that bit rate savings of more than 50% are reported [8], VC-1 is such that bit rate savings of more than 50% are reported [9],
when compared against MPEG-2. See [8] for further details about how when compared against MPEG-2. See [9] for further details about how
VC-1 compares against other codecs, such as MPEG-4 and H.264/AVC. 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.) (In [9], VC-1 is referred to by its earlier name, VC-9.)
VC-1 is widely used for downloading and streaming of movies on the VC-1 is widely used for downloading and streaming of movies on the
Internet, in the form of Windows Media Video 9 (WMV-9) [8], because Internet, in the form of Windows Media Video 9 (WMV-9) [9], because
the WMV-9 codec is compliant with the VC-1 standard. VC-1 has also the WMV-9 codec is compliant with the VC-1 standard. VC-1 has also
recently been adopted as a mandatory compression format for the high- recently been adopted as a mandatory compression format for the high-
definition DVD formats HD DVD and Blu-ray. definition DVD formats HD DVD and Blu-ray.
SMPTE 421M defines the VC-1 bit stream syntax and specifies SMPTE 421M defines the VC-1 bit stream syntax and specifies
constraints that must be met by VC-1 conformant bit streams. SMPTE constraints that must be met by VC-1 conformant bit streams. SMPTE
421M also specifies the complete process required to decode the bit 421M also specifies the complete process required to decode the bit
stream. However, it does not specify the VC-1 compression algorithm, stream. However, it does not specify the VC-1 compression algorithm,
thus allowing for different ways to implement a VC-1 encoder. thus allowing for different ways to implement a VC-1 encoder.
skipping to change at page 7, line 26 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 [9]. theory of the HRD can be found in [10].
The concept of an entry-point layer applies only to 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.
skipping to change at page 12, line 12 skipping to change at page 12, line 12
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 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 (HDR_RATE) and a decoder buffer capacity transmission bit rate (HRD_RATE) and a decoder buffer capacity
(HRD_BUFFER). (See section 3.3 for additional discussion about the (HRD_BUFFER). (See section 3.3 for additional discussion about the
HRD.) HRD.)
If the actual peak transmission rate is known by the RTP sender, the If the actual peak transmission rate is known by the RTP sender, the
RTP sender MAY remove all leaky bucket parameter sets except for the RTP sender MAY remove all leaky bucket parameter sets except for the
one corresponding to the actual peak transmission rate. one corresponding to the actual peak transmission rate.
For each leaky bucket parameter set in the sequence layer header, For each leaky bucket parameter set in the sequence layer header,
there is also parameter in the entry-point header that specifies the there is also parameter in the entry-point header that specifies the
initial fullness (HRD_FULL) of the leaky bucket. initial fullness (HRD_FULL) of the leaky bucket.
skipping to change at page 18, line 17 skipping to change at page 18, line 17
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
This registration uses the template defined in [11] and follows RFC This registration uses the template defined in RFC 4288 [7] and
3555 [7]. follows RFC 3555 [8].
Type name: video Type name: video
Subtype name: vc1 Subtype name: vc1
Required parameters: Required parameters:
profile: profile:
The value is an integer identifying the VC-1 profile. The The value is an integer identifying the VC-1 profile. The
following values are defined: following values are defined:
skipping to change at page 26, line 43 skipping to change at page 26, line 43
When the direction attribute is sendonly, the parameters describe When the direction attribute is sendonly, the parameters describe
the limits of the VC-1 bit stream that the sender is capable of the limits of the VC-1 bit stream that the sender is capable of
producing for the given profile and level, and for any lower level producing for the given profile and level, and for any lower level
of the same profile. of the same profile.
When the direction attribute is recvonly or sendrecv, the When the direction attribute is recvonly or sendrecv, the
parameters describe properties of the receiver implementation. If parameters describe properties of the receiver implementation. If
the value of a property is less than what is allowed by the level the value of a property is less than what is allowed by the level
of the VC-1 profile, then it SHALL be interpreted as a preferred of the VC-1 profile, then it SHALL be interpreted as a preferred
value and the sender's VC-1 bit stream SHOULD not exceed it. If value and the sender's VC-1 bit stream SHOULD NOT exceed it. If
the value of a property is greater than what is allowed by the the value of a property is greater than what is allowed by the
level of the VC-1 profile, then it SHALL be interpreted as the level of the VC-1 profile, then it SHALL be interpreted as the
upper limit of the value that the receiver accepts for the given upper limit of the value that the receiver accepts for the given
profile and level, and for any lower level of the same profile. profile and level, and for any lower level of the same profile.
For example, if a recvonly or sendrecv offer specifies For example, if a recvonly or sendrecv offer specifies
"profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a "profile=0;level=1;max-bitrate=48000", then 48 kbps is merely a
suggested bit rate, because all receiver implementations of Simple suggested bit rate, because all receiver implementations of Simple
profile, Low level, are required to support bit rates of up to 96 profile, Low level, are required to support bit rates of up to 96
kbps. Assuming that the offer is accepted, the answerer should kbps. Assuming that the offer is accepted, the answerer should
skipping to change at page 28, line 22 skipping to change at page 28, line 22
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 [10]. for example, through the application of SRTP [11].
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 [10]. RECOMMENDED; for example, with SRTP [11].
Note that the appropriate mechanism to ensure confidentiality and Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is very dependent on the integrity of RTP packets and their payloads is 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.
VC-1 bit streams can carry user-data, such as closed captioning VC-1 bit streams can carry user-data, such as closed captioning
information and content meta-data. The VC-1 specification does not information and content meta-data. The VC-1 specification does not
define how to interpret user-data. Identifiers for user-data are define how to interpret user-data. Identifiers for user-data are
skipping to change at page 29, line 16 skipping to change at page 29, line 16
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 9. References
9.1 Normative references 9.1 Normative references
[1] Proposed SMPTE 421M, "VC-1 Compressed Video Bitstream Format and [1] Society of Motion Picture and Television Engineers, "VC-1
Decoding Process", www.smpte.org. Compressed Video Bitstream Format and Decoding Process", SMPTE
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] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload [7] Freed, N. and Klensin, J., "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload
Formats", RFC 3555, July 2003. Formats", RFC 3555, July 2003.
9.2 Informative references 9.2 Informative references
[8] 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.
[9] 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.
[10]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.
[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 [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.
Author's Addresses Author's Addresses
Anders Klemets Anders Klemets
Microsoft Corp. Microsoft Corp.
1 Microsoft Way 1 Microsoft Way
 End of changes. 21 change blocks. 
27 lines changed or deleted 28 lines changed or added

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