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