draft-ietf-avt-rtp-vc1-02.txt   draft-ietf-avt-rtp-vc1-03.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft A. Klemets Internet Draft A. Klemets
Document: draft-ietf-avt-rtp-vc1-02.txt Microsoft Document: draft-ietf-avt-rtp-vc1-03.txt Microsoft
Expires: May 2006 November 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 14 skipping to change at page 2, line 14
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.................................11 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 MIME format parameters.......................12 4.7 Signaling of media type parameters........................13
4.8 MIME "mode=1" parameter...................................13 4.8 The "mode=1" media type parameter.........................13
4.9 MIME "mode=3" parameter...................................13 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.................................17 6. RTP Payload format parameters.................................18
6.1 Media Type Registration...................................17 6.1 Media type Registration...................................18
6.2 Mapping of MIME parameters to SDP.........................24 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...........................................28 8. IANA Considerations...........................................29
9. References....................................................28 9. References....................................................29
9.1 Normative references......................................28 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].
skipping to change at page 3, line 25 skipping to change at page 3, line 25
it. Depending on the application in which VC-1 is used, some it. Depending on the application in which VC-1 is used, some
profiles may be more suitable than others. For example, Simple profiles may be more suitable than others. For example, Simple
profile is designed for low bit rate Internet streaming and for profile is designed for low bit rate Internet streaming and for
playback on devices that can only handle low complexity decoding. playback on devices that can only handle low complexity decoding.
Advanced profile is designed for broadcast applications, such as Advanced profile is designed for broadcast applications, such as
digital TV, HD DVD or HDTV. Advanced profile is the only VC-1 digital TV, HD DVD or HDTV. Advanced profile is the only VC-1
profile that supports interlaced video frames and non-square pixels. profile that supports interlaced video frames and non-square pixels.
Section 2 defines the abbreviations used in this document. Section 3 Section 2 defines the abbreviations used in this document. Section 3
provides a more detailed overview of VC-1. Sections 4 and 5 define provides a more detailed overview of VC-1. Sections 4 and 5 define
the RTP payload format for VC-1, and section 6 defines the MIME and the RTP payload format for VC-1, and section 6 defines the media type
SDP parameters for VC-1. See section 7 for security considerations. and SDP parameters for VC-1. See section 7 for security
considerations.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2]. document are to be interpreted as described in BCP 14, RFC 2119 [2].
2. 2. Definitions and abbreviations
Definitions and abbreviations
This document uses the definitions in SMPTE 421M [1]. For This document uses the definitions in SMPTE 421M [1]. For
convenience, the following terms from SMPTE 421M are restated here: convenience, the following terms from SMPTE 421M are restated here:
B-picture: A picture that is coded using motion compensated B-picture: A picture that is coded using motion compensated
prediction from past and/or future reference fields or frames. A B- prediction from past and/or future reference fields or frames. A B-
picture cannot be used for predicting any other picture. picture cannot be used for predicting any other picture.
Bit-stream data unit (BDU): A unit of the compressed data which may Bit-stream data unit (BDU): A unit of the compressed data which may
be parsed (i.e., syntax decoded) independently of other information be parsed (i.e., syntax decoded) independently of other information
skipping to change at page 9, line 51 skipping to change at page 9, line 51
profiles, the AU payload MUST begin with the start of a picture profiles, the AU payload MUST begin with the start of a picture
header. header.
If Advanced profile is used, AU payloads that contain a fragment of a If Advanced profile is used, AU payloads that contain a fragment of a
frame other than the first fragment, SHOULD start at an EBDU frame other than the first fragment, SHOULD start at an EBDU
boundary, such as at the start of a slice. boundary, such as at the start of a slice.
However, slices are only defined for Advanced profile, and are not However, slices are only defined for Advanced profile, and are not
always used. Blocks and macroblocks are not BDUs (have no Start always used. Blocks and macroblocks are not BDUs (have no Start
Code) and are not byte-aligned. Therefore, it may not always be Code) and are not byte-aligned. Therefore, it may not always be
possible to continue a fragmented frame at an EBDU boundary. 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 In the case of Simple and Main profiles, since the blocks and
macroblocks are not byte-aligned, the fragmentation boundary may be macroblocks are not byte-aligned, the fragmentation boundary may be
chosen arbitrarily. chosen arbitrarily.
If an RTP packet contains an AU with the last fragment of a frame, If an RTP packet contains an AU with the last fragment of a frame,
additional AUs SHOULD NOT be included in the RTP packet. additional AUs SHOULD NOT be included in the RTP packet.
If the PTS Delta field in the AU header is present, each fragment of If the PTS Delta field in the AU header is present, each fragment of
a frame MUST have the same presentation time. If the DTS Delta field a frame MUST have the same presentation time. If the DTS Delta field
skipping to change at page 10, line 27 skipping to change at page 10, line 29
4.3 Time stamp considerations 4.3 Time stamp considerations
Video frames MUST be transmitted in the coded order. Coded order Video frames MUST be transmitted in the coded order. Coded order
implies that no frames are dependent on subsequent frames, as implies that no frames are dependent on subsequent frames, as
discussed in section 3.4. The RTP timestamp field MUST be set to the discussed in section 3.4. The RTP timestamp field MUST be set to the
presentation time of the video frame contained in the first AU in the presentation time of the video frame contained in the first AU in the
RTP packet. The presentation time can be used as the timestamp field 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 in the RTP header because it differs from the sampling instant of the
frame only by an arbitrary constant offset. frame only by an arbitrary constant offset.
Each AU header MAY specify the decode time of video frame contained If the video frame in an AU has a presentation time that differs from
in the AU. If B-pictures will not be present in the coded bit the RTP timestamp field, then the presentation time MUST be specified
stream, then the decode time of a frame MUST be equal to the using the PTS Delta field in the AU header. Since the RTP timestamp
presentation time of the frame. 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 B-
pictures will not be present in the coded bit stream, then the decode
time of a frame SHALL be equal to the presentation time of the frame.
If B-pictures may be present in the coded bit stream, then the decode If B-pictures may be present in the coded bit stream, then the decode
time of non-B frames MUST be equal to the presentation time of the times of frames are determined as follows:
previous non-B frame in the coded order. The decode time of B-frames
MUST be equal to the presentation time of the B-frame. - Non-B frames: The decode time SHALL be equal to the presentation
time of the previous non-B frame in the coded order.
- B-frames: The decode time SHALL be equal to the presentation time
of the B-frame.
As an example, consider Figure 1 in section 3.4. The decode time of As an example, consider Figure 1 in section 3.4. The decode time of
non-B frame P4 is 4 time units, which is equal to the presentation non-B frame P4 is 4 time units, which is equal to the presentation
time of the previous non-B frame in the coded order, which is P1. On time of the previous non-B frame in the coded order, which is P1. On
the other hand, the decode time of B-frame B2 is 5 time units, which the other hand, the decode time of B-frame B2 is 5 time units, which
is identical to its presentation time. is identical to its presentation time.
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.
Knowing if the stream will contain B-pictures may help the receiver Knowing if the stream will contain B-pictures may help the receiver
allocate resources more efficiently and can reduce delay, as an allocate resources more efficiently and can reduce delay, as an
absence of B-pictures in the stream implies that no reordering absence of B-pictures in the stream implies that no reordering
of frames will be needed between the decoding process and the display of frames will be needed between the decoding process and the display
of the decoded frames. This may be important for interactive of the decoded frames. This may be important for interactive
applications. applications.
The receiver MUST assume that the coded bit stream may contain B- The receiver SHALL assume that the coded bit stream may contain B-
pictures in the following cases: pictures in the following cases:
- Advanced profile: If the value of the "bpic" MIME parameter - 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 defined in section 6.1 is 1, or if the "bpic" parameter is not
specified. specified.
- Main profile: If the MAXBFRAMES field in STRUCT_C decoder - Main profile: If the MAXBFRAMES field in STRUCT_C decoder
initialization parameter has a non-zero value. STRUCT_C is initialization parameter has a non-zero value. STRUCT_C is
conveyed in the MIME "config" parameter, which is defined in conveyed in the "config" media type parameter, which is defined in
section 6.1. section 6.1.
Simple profile does not use B-pictures. Simple profile does not use B-pictures.
4.4 Random Access Points 4.4 Random Access Points
The entry-point header contains information that is needed by the The entry-point header contains information that is needed by the
decoder to decode the frames in that entry-point segment. This means decoder to decode the frames in that entry-point segment. This means
that in the event of lost RTP packets the decoder may be unable to that in the event of lost RTP packets the decoder may be unable to
decode frames until the next entry-point header is received. decode frames until the next entry-point header is received.
skipping to change at page 12, line 45 skipping to change at page 13, line 12
time the sequence layer header is inserted in the bit stream, the time the sequence layer header is inserted in the bit stream, the
value of this counter MUST be reset. value of this counter MUST be reset.
To allow the RTP receiver to detect that an RTP packet which was lost To allow the RTP receiver to detect that an RTP packet which was lost
contained a new sequence layer header, the AU Control field defines a contained a new sequence layer header, the AU Control field defines a
bit called the "SL" flag. This bit is toggled when a sequence layer bit called the "SL" flag. This bit is toggled when a sequence layer
header is transmitted, but only if that header is different from the header is transmitted, but only if that header is different from the
most recently transmitted sequence layer header. The SL bit is most recently transmitted sequence layer header. The SL bit is
defined in section 5.3. defined in section 5.3.
4.7 Signaling of MIME format parameters 4.7 Signaling of media type parameters
When this RTP payload format is used with SDP, the decoder When this RTP payload format is used with SDP, the decoder
initialization parameters described in section 3.3 MUST be signaled initialization parameters described in section 3.3 MUST be signaled
in SDP using the MIME parameters specified in section 6.1. Section in SDP using the media type parameters specified in section 6.1.
6.2 specifies how to map the MIME parameters to SDP. Section 6.2 specifies how to map the media type parameters to SDP
[5], and section 6.3 defines rules specific to the SDP Offer/Answer
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 updating the SDP.
When Advanced profile is used, the decoder initialization parameters When Advanced profile is used, the decoder initialization parameters
MAY be changed by inserting a new sequence layer header or an entry- MAY be changed by inserting a new sequence layer header or an entry-
point header in the coded bit stream. point header in the coded bit stream.
When Simple or Main profiles are used, it is not possible to change Note that the sequence layer header specifies the VC-1 level, the
the decoder initialization parameters through the coded bit stream maximum size of the coded pictures and optionally also the maximum
itself. Any changes to the decoder initialization parameters would frame rate. The media type parameters "level", "width", "height" and
have to be done through out-of-band means, e.g., by updating the SDP "framerate" specify upper limits for these parameters. Thus, the
[5]. sequence layer header MAY specify values that that are lower than the
values of the media type parameters "level", "width", "height" or
Note that the sequence layer header specifies the encoding level, the "framerate", but the sequence layer header MUST NOT exceed the values
maximum size of the coded pictures and possibly also the maximum of any of these media type parameters.
frame rate. Thus, if the sequence layer header changes, the new
header supersedes the values of the MIME parameters "level", "width",
"height" and "framerate".
4.8 MIME "mode=1" parameter 4.8 The "mode=1" media type parameter
In certain applications using Advanced profile, the sequence layer In certain applications using Advanced profile, the sequence layer
header never changes. This MAY be signaled with the MIME parameter header never changes. This MAY be signaled with the media type
"mode=1". (The "mode" parameter is defined in section 6.1.) The parameter "mode=1". (The "mode" parameter is defined in section 6.1.)
"mode=1" parameter serves as a "hint" to the RTP receiver that all The "mode=1" parameter serves as a "hint" to the RTP receiver that
sequence layer headers in the bit stream will be identical. If all sequence layer headers in the bit stream will be identical. If
"mode=1" is signaled and a sequence layer header is present in the "mode=1" is signaled and a sequence layer header is present in the
coded bit stream, then it MUST be identical to the sequence layer coded bit stream, then it MUST be identical to the sequence layer
header specified by the MIME "config" parameter. header specified by the "config" media type parameter.
Since the sequence layer header never changes in "mode=1", the RTP Since the sequence layer header never changes in "mode=1", the RTP
sender MAY remove it from the bit stream. Note, however, that if sender MAY remove it from the bit stream. Note, however, that if the
that if the value of TFCNTRFLAG in the sequence layer header is 1, value of TFCNTRFLAG in the sequence layer header is 1, each picture
each picture header contains a frame counter field (TFCNTR). This header contains a frame counter field (TFCNTR). This field is reset
field is reset each time the sequence layer header occurs in the bit each time the sequence layer header occurs in the bit stream. If the
stream. If the RTP sender chooses to remove the sequence layer RTP sender chooses to remove the sequence layer header, then it MUST
header, then it MUST ensure that the resulting bit stream is still ensure that the resulting bit stream is still compliant with the VC-1
compliant with the VC-1 specification (e.g., by adjusting the TFCNTR specification (e.g., by adjusting the TFCNTR field, if necessary.)
field, if necessary.)
4.9 MIME "mode=3" parameter 4.9 The "mode=3" media type parameter
In certain applications using Advanced profile, both the sequence In certain applications using Advanced profile, both the sequence
layer header and the entry-point header never change. This MAY be layer header and the entry-point header never change. This MAY be
signaled with the MIME parameter "mode=3". The same rules apply to signaled with the media type parameter "mode=3". The same rules
"mode=3" as for "mode=1", described in section 4.8. Additionally, if apply to "mode=3" as for "mode=1", described in section 4.8.
"mode=3" is signaled, then the RTP sender MAY "compress" the coded Additionally, if "mode=3" is signaled, then the RTP sender MAY
bit stream by not including sequence layer headers and entry-point "compress" the coded bit stream by not including sequence layer
headers in the RTP packets. headers and entry-point headers in the RTP packets.
The RTP receiver MUST "decompress" the coded bit stream by re- The RTP receiver MUST "decompress" the coded bit stream by re-
inserting the entry-point headers prior to delivering the coded bit inserting the entry-point headers prior to delivering the coded bit
stream to the VC-1 decoder. The sequence layer header does not need stream to the VC-1 decoder. The sequence layer header does not need
to be decompressed by the receiver, since it never changes. to be decompressed by the receiver, since it never changes.
If "mode=3" is signaled and the RTP receiver receives a complete AU If "mode=3" is signaled and the RTP receiver receives a complete AU
or the first fragment of an AU, and the RA bit is set to 1 but the AU or the first fragment of an AU, and the RA bit is set to 1 but the AU
does not begin with an entry-point header, then this indicates that does not begin with an entry-point header, then this indicates that
entry-point header has been "compressed". In that case, the RTP entry-point header has been "compressed". In that case, the RTP
receiver MUST insert an entry-point header at the beginning of the receiver MUST insert an entry-point header at the beginning of the
AU. When inserting the entry-point header, the RTP receiver MUST use AU. When inserting the entry-point header, the RTP receiver MUST use
the one that was specified by the MIME "config" parameter. the one that was specified by the "config" media type parameter.
5. RTP Payload Format syntax 5. RTP Payload Format syntax
5.1 RTP header usage 5.1 RTP header usage
The format of the RTP header is specified in RFC 3550 [3] and is The format of the RTP header is specified in RFC 3550 [3] and is
reprinted in Figure 3 for convenience. reprinted in Figure 3 for convenience.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 15, line 16 skipping to change at page 15, line 32
The RTP receiver can use the sequence number field to recover The RTP receiver can use the sequence number field to recover
the coded order of the VC-1 frames. (A typical VC-1 decoder the coded order of the VC-1 frames. (A typical VC-1 decoder
will require the VC-1 frames to be delivered in coded order.) will require the VC-1 frames to be delivered in coded order.)
When VC-1 frames have been fragmented across RTP packets, the When VC-1 frames have been fragmented across RTP packets, the
RTP receiver can use the sequence number field to ensure that RTP receiver can use the sequence number field to ensure that
no fragment is missing. no fragment is missing.
Timestamp: 32 bits Timestamp: 32 bits
The RTP timestamp is set to the presentation time of the VC-1 The RTP timestamp is set to the presentation time of the VC-1
frame in the first Access Unit. frame in the first Access Unit.
A clock rate of 90 kHz, or higher, MUST be used. A clock rate of 90 kHz MUST be used.
5.2 AU header syntax 5.2 AU header syntax
The Access Unit header consists of a one-byte AU Control field, the The Access Unit header consists of a one-byte AU Control field, the
RA Count field and 3 optional fields. All fields MUST be written in RA Count field and 3 optional fields. All fields MUST be written in
network byte order. The structure of the AU header is illustrated in network byte order. The structure of the AU header is illustrated in
Figure 4. Figure 4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | RA | AUP | PTS | DTS | |AU | RA | AUP | PTS | DTS |
skipping to change at page 15, line 47 skipping to change at page 16, line 17
256 counter. The value of this field, MUST be incremented by 256 counter. The value of this field, MUST be incremented by
1, each time an AU is transmitted where the RA bit in the AU 1, each time an AU is transmitted where the RA bit in the AU
Control field is set to 1. The initial value of this field Control field is set to 1. The initial value of this field
is undefined and MAY be chosen randomly. is undefined and MAY be chosen randomly.
AUP Len: 16 bits AUP Len: 16 bits
Access Unit Payload Length. Specifies the size, in bytes, of Access Unit Payload Length. Specifies the size, in bytes, of
the payload of the Access Unit. The field does not include the payload of the Access Unit. The field does not include
the size of the AU header itself. The field MUST be included the size of the AU header itself. The field MUST be included
in each AU header in an RTP packet, except for the last AU in each AU header in an RTP packet, except for the last AU
header in the packet. 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 PTS Delta: 32 bits
Presentation time delta. Specifies the presentation time of Presentation time delta. Specifies the presentation time of
the frame as a 2's complement offset (delta) from the the frame as a 2's complement offset (delta) from the
timestamp field in the RTP header of this RTP packet. The timestamp field in the RTP header of this RTP packet. The
PTS Delta field MUST use the same clock rate as the timestamp PTS Delta field MUST use the same clock rate as the timestamp
field in the RTP header. field in the RTP header.
This field SHOULD NOT be included in the first AU header in This field SHOULD NOT be included in the first AU header in
the RTP packet, because the RTP timestamp field specifies the the RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU. presentation time of the frame in the first AU. If this
field is not included, the presentation time of the frame
SHALL be assumed to be specified by the timestamp field in
the RTP header.
DTS Delta: 32 bits DTS Delta: 32 bits
Decode time delta. Specifies the decode time of the frame as Decode time delta. Specifies the decode time of the frame as
a 2's complement offset (delta) between the presentation time a 2's complement offset (delta) between the presentation time
and the decode time. Note that if the presentation time is and the decode time. Note that if the presentation time is
larger than the decode time, this results in a value for the larger than the decode time, this results in a value for the
DTS Delta field that is greater than zero. The DTS Delta DTS Delta field that is greater than zero. The DTS Delta
field MUST use the same clock rate as the timestamp field in field MUST use the same clock rate as the timestamp field in
the RTP header. 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 5.3 AU Control field syntax
The structure of the 8-bit AU Control field is shown in Figure 5. The structure of the 8-bit AU Control field is shown in Figure 5.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| FRAG | RA | SL | LP | PT | DT | R | | FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
skipping to change at page 16, line 48 skipping to change at page 17, line 30
3: The AU payload contains a complete frame (not fragmented.) 3: The AU payload contains a complete frame (not fragmented.)
RA: 1 bit RA: 1 bit
Random Access Point indicator. This bit MUST be set to 1 if Random Access Point indicator. This bit MUST be set to 1 if
the AU contains a frame that is a random access point. In the AU contains a frame that is a random access point. In
the case of Simple and Main profiles, any I-picture is a the case of Simple and Main profiles, any I-picture is a
random access point. random access point.
In the case of Advanced profile, the first frame after an In the case of Advanced profile, the first frame after an
entry-point header is a random access point. entry-point header is a random access point.
Note that if entry-point headers are not transmitted at every Note that if entry-point headers are not transmitted at every
random access point, this MUST be indicated using the MIME random access point, this MUST be indicated using the media
parameter "mode=3". type parameter "mode=3".
SL: 1 bit SL: 1 bit
Sequence Layer Counter. This bit MUST be toggled, i.e., Sequence Layer Counter. This bit MUST be toggled, i.e.,
changed from 0 to 1 or from 1 to 0, if the AU contains a changed from 0 to 1 or from 1 to 0, if the AU contains a
sequence layer header and if it is different from the most sequence layer header and if it is different from the most
recently transmitted sequence layer header. Otherwise, the recently transmitted sequence layer header. Otherwise, the
value of this bit must be identical to the value of the SL value of this bit must be identical to the value of the SL
bit in the previous AU. bit in the previous AU.
The initial value of this bit is undefined and MAY be chosen The initial value of this bit is undefined and MAY be chosen
randomly. randomly.
skipping to change at page 17, line 35 skipping to change at page 18, line 15
DT: 1 bit DT: 1 bit
DTS Delta Present. This bit MUST be set to 1 if the AU DTS Delta Present. This bit MUST be set to 1 if the AU
header 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 [11] and follows RFC
3555 [7]. 3555 [7].
Type name: video Type name: video
Subtype name: vc1 Subtype name: vc1
Required parameters: Required parameters:
profile: profile:
The value is an integer identifying the VC-1 profile. The The value is an integer identifying the VC-1 profile. The
following values are defined: following values are defined:
0: Simple profile. 0: Simple profile.
1: Main profile. 1: Main profile.
3: Advanced profile. 3: Advanced profile.
If the profile parameter is used to indicate properties of a If the profile parameter is used to indicate properties of a
coded bit stream, it indicates the VC-1 encoding profile that coded bit stream, it indicates the VC-1 profile that a
a decoder has to support in order to comply with [1] when it decoder has to support when it decodes the bit stream.
decodes the bit stream.
If the profile parameter is used for capability exchange or If the profile parameter is used for capability exchange or
in a session setup procedure, it indicates the VC-1 profile in a session setup procedure, it indicates the VC-1 profile
that codec supports. that the codec supports.
level: level:
The value is an integer specifying the level of the VC-1 The value is an integer specifying the level of the VC-1
profile. profile.
For Advanced profile, valid values are 0 to 4, which For Advanced profile, valid values are 0 to 4, which
correspond to levels L0 to L4, respectively. For Simple and correspond to levels L0 to L4, respectively. For Simple and
Main profiles, the following values are defined: Main profiles, the following values are defined:
1: Low Level 1: Low Level
2: Medium Level 2: Medium Level
3: High Level (only valid for Main profile) 3: High Level (only valid for Main profile)
If the level parameter is used to indicate properties of a If the level parameter is used to indicate properties of a
coded bit stream, it indicates the level of the VC-1 profile coded bit stream, it indicates the highest level of the VC-1
that a decoder has to support in order to comply with [1] profile that a decoder has to support when it decodes the bit
when it decodes the bit stream. Note that when Advanced stream. Note that support for a level implies support for
profile is used, this parameter may only apply while the all numerically lower levels of the given profile.
sequence layer header specified in the config parameter is in
use.
If the level parameter is used for capability exchange or in If the level parameter is used for capability exchange or in
a session setup procedure, it indicates the highest level of a session setup procedure, it indicates the highest level of
the VC-1 profile that codec supports. See section 6.3 for the VC-1 profile that the codec supports. See section 6.3 of
specific rules for how this parameter is used with the SDP RFC XXXX for specific rules for how this parameter is used
Offer/Answer model. with the SDP Offer/Answer model.
Optional parameters: Optional parameters:
config: config:
The value is a base16 [6] (hexadecimal) representation of an The value is a base16 [6] (hexadecimal) representation of an
octet string that expresses the decoder initialization octet string that expresses the decoder initialization
parameters. Decoder initialization parameters are mapped parameters. Decoder initialization parameters are mapped
onto the base16 octet string in an MSB-first basis. The onto the base16 octet string in an MSB-first basis. The
first bit of the decoder initialization parameters MUST be first bit of the decoder initialization parameters MUST be
located at the MSB of the first octet. If the decoder located at the MSB of the first octet. If the decoder
skipping to change at page 19, line 12 skipping to change at page 19, line 37
parameters are STRUCT_C, as defined in Annex J of SMPTE 421M parameters are STRUCT_C, as defined in Annex J of SMPTE 421M
[1]. [1].
For Advanced profile, the decoder initialization parameters For Advanced profile, the decoder initialization parameters
are a sequence layer header directly followed by an entry- are a sequence layer header directly followed by an entry-
point header. The two headers MUST be in EBDU format, point header. The two headers MUST be in EBDU format,
meaning that they must include their Start Codes and must use meaning that they must include their Start Codes and must use
the encapsulation method defined in Annex E of SMPTE 421M the encapsulation method defined in Annex E of SMPTE 421M
[1]. [1].
This parameter MUST NOT be used to indicate codec
capabilities in any capability exchange procedure.
width: width:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
maximum horizontal size of the coded picture, in pixels. maximum horizontal size of the coded picture, in pixels.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the profile and level. maximum horizontal size allowed by the specified profile and
level.
Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the
config parameter is in use.
height: height:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
maximum vertical size of the coded picture in pixels. maximum vertical size of the coded picture in pixels.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum vertical size allowed by the profile and level. maximum vertical size allowed by the specified profile and
level.
Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the
config parameter is in use.
bitrate: bitrate:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
peak transmission rate of the coded bit stream in bits per peak transmission rate of the coded bit stream in bits per
second. The number does not include the overhead caused by second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers, RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP or IP headers. or any of the RTP, UDP or IP headers.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum bit rate allowed by the profile and level. (See the maximum bit rate allowed by the specified profile and level.
values for "RMax" in Annex D of SMPTE 421M [1].) (See the values for "RMax" in Annex D of SMPTE 421M [1].)
Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the
config parameter is in use.
buffer: buffer:
The value is an integer specifying the leaky bucket size, B, The value is an integer specifying the leaky bucket size, B,
in milliseconds, required to contain a stream transmitted at in milliseconds, required to contain a stream transmitted at
the transmission rate specified by the bitrate parameter. the transmission rate specified by the bitrate parameter.
This parameter is defined in the hypothetical reference This parameter is defined in the hypothetical reference
decoder model for VC-1, in Annex C of SMPTE 421M [1]. decoder model for VC-1, in Annex C of SMPTE 421M [1].
Note that this parameter relates to the codec bit stream Note that this parameter relates to the codec bit stream
only, and does not account for any buffering time that may be only, and does not account for any buffering time that may be
required to compensate for jitter in the network. required to compensate for jitter in the network.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum buffer size allowed by the profile and level. (See maximum buffer size allowed by the specified profile and
the values for "BMax" and "RMax" in Annex D of SMPTE 421M level. (See the values for "BMax" and "RMax" in Annex D of
[1].) SMPTE 421M [1].)
Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the
config parameter is in use.
framerate: framerate:
The value is an integer greater than zero, specifying the The value is an integer greater than zero, specifying the
maximum number of frames per second in the coded bit stream, maximum number of frames per second in the coded bit stream,
multiplied by 1000 and rounded to the nearest integer value. multiplied by 1000 and rounded to the nearest integer value.
For example, 30000/1001 (approximately 29.97) frames per For example, 30000/1001 (approximately 29.97) frames per
second is represented as 29970. second is represented as 29970.
If the parameter is not specified, it defaults to the maximum If the parameter is not specified, it defaults to the maximum
frame rate allowed by the profile and level. frame rate allowed by the specified profile and level.
Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the
config parameter is in use.
bpic: bpic:
This parameter signals if B-pictures may be present when This parameter signals if B-pictures may be present when
Advanced profile is used. If this parameter is present, and Advanced profile is used. If this parameter is present, and
B-pictures may be present in the coded bit stream, this B-pictures may be present in the coded bit stream, this
parameter MUST be equal to 1. parameter MUST be equal to 1.
If B-pictures will never be present in the coded bit stream, A value of 0 indicates that B-pictures SHALL NOT be present
even if the sequence layer header changes, this parameter in the coded bit stream, even if the sequence layer header
SHOULD be present and its value SHOULD be equal to 0. changes. It is RECOMMENDED to include this parameter, with a
value of 0, if no B-pictures will be included in the coded
bit stream.
This parameter MUST not be used with Simple and Main This parameter MUST NOT be used with Simple and Main
profiles. (For Main profile, the presence of B-pictures is profiles. (For Main profile, the presence of B-pictures is
indicated by the MAXBFRAMES field in STRUCT_C decoder indicated by the MAXBFRAMES field in STRUCT_C decoder
initialization parameter.) initialization parameter.)
For Advanced profile, if this parameter is not specified, a For Advanced profile, if this parameter is not specified, a
value of 1 MUST be assumed. value of 1 SHALL be assumed.
mode: mode:
The value is an integer specifying the use of the sequence The value is an integer specifying the use of the sequence
layer header and the entry-point header. This parameter is layer header and the entry-point header. This parameter is
only defined for Advanced profile. The following values are only defined for Advanced profile. The following values are
defined: defined:
0: Both the sequence layer header and the entry-point header 0: Both the sequence layer header and the entry-point header
may change, and changed headers will be included in the RTP may change, and changed headers will be included in the RTP
packets. packets.
1: The sequence layer header specified in the config 1: The sequence layer header specified in the config
parameter never changes. parameter never changes. The rules in section 4.8 of RFC
XXXX MUST be followed.
3: The sequence layer header and the entry-point header 3: The sequence layer header and the entry-point header
specified in the config parameter never change. Entry-point specified in the config parameter never change. The rules in
headers MAY not be included in the Access Units. Each Access section 4.9 of RFC XXXX MUST be followed.
Unit that has the RA bit set to 1 contains a random access
point even if an entry-point header is not included in the
Access Unit. If an entry-point header is not included at a
random access point, then the RTP receiver MUST insert the
entry-point header into the VC-1 bit stream prior to
delivering the bit stream to the VC-1 decoder.
If the mode parameter is not specified, a value of 0 MUST be If the mode parameter is not specified, a value of 0 SHALL be
assumed. The mode parameter SHOULD be specified if modes 1 assumed. The mode parameter SHOULD be specified if modes 1
or 3 apply to the VC-1 bit stream. or 3 apply to the VC-1 bit stream.
max-width, max-height, max-bitrate, max-buffer, max-framerate: max-width, max-height, max-bitrate, max-buffer, max-framerate:
These parameters are defined for use in a capability exchange These parameters are defined for use in a capability exchange
procedure. The parameters do not specify properties of the procedure. The parameters do not signal properties of the
coded bit stream, but rather upper limits or preferred values coded bit stream, but rather upper limits or preferred values
for the "width", "height", "bitrate", "buffer" and for the "width", "height", "bitrate", "buffer" and
"framerate" parameters. Section 6.3 provides specific rules "framerate" parameters. Section 6.3 of RFC XXXX provides
for these parameters are used with the SDP Offer/Answer specific rules for these parameters are used with the SDP
model. Offer/Answer model.
Any of the max-width, max-height, max-bitrate, max-buffer and Receivers that signal support for a given profile and level
max-framerate parameters MAY be used to indicate capabilities 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 pixels and height of 288 pixels, 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 that exceed the required capabilities of the signaled profile
and level. In that case, the parameter MUST be interpreted and level. In that case, the parameter SHALL be interpreted
as the maximum value that can be supported for that as the maximum value that can be supported for that
capability. capability.
If any of the parameters specifies a capability that is less
than the required capabilities of the signaled profile and
level, then the parameter SHOULD be interpreted as a
preferred value for that capability.
When more than one parameter from the set (max-width, max- When more than one parameter from the set (max-width, max-
height, max-bitrate, max-buffer and max-framerate) is height, max-bitrate, max-buffer and max-framerate) is
present, all signaled capabilities MUST be supported present, all signaled capabilities MUST be supported
simultaneously. simultaneously.
A sender or receiver MUST NOT use these parameters to A sender or receiver MUST NOT use these parameters to signal
indicate capabilities that meet the requirements of a higher capabilities that meet the requirements of a higher level of
level of the VC-1 profile than the one specified in the the VC-1 profile than the one specified in the "level"
"level" parameter, if the sender or receiver can support all parameter, if the sender or receiver can support all the
the properties of the higher level, except if specifying a properties of the higher level, except if specifying a higher
higher level is not allowed due to other restrictions. (As level is not allowed due to other restrictions. (As an
an example of such a restriction, in the SDP Offer/Answer example of such a restriction, in the SDP Offer/Answer model,
model, the value of the level parameter that can be used in the value of the level parameter that can be used in an
an Answer is limited by what was specified in the Offer.) Answer is limited by what was specified in the Offer.)
max-width: max-width:
The value is an integer greater than zero, specifying a The value is an integer greater than zero, specifying a
horizontal size for the coded picture, in pixels. If the horizontal size for the coded picture, in pixels. If the
value is less than the maximum horizontal size allowed by the value is less than the maximum horizontal size allowed by the
profile and level, then the value specifies the preferred profile and level, then the value specifies the preferred
horizontal size. Otherwise, it specifies the maximum horizontal size. Otherwise, it specifies the maximum
horizontal size that is supported. horizontal size that is supported.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum horizontal size allowed by the profile and level. maximum horizontal size allowed by the specified profile and
level.
max-height: max-height:
The value is an integer greater than zero, specifying a The value is an integer greater than zero, specifying a
vertical size for the coded picture, in pixels. If the value vertical size for the coded picture, in pixels. If the value
is less than the maximum vertical size allowed by the profile is less than the maximum vertical size allowed by the profile
and level, then the value specifies the preferred vertical and level, then the value specifies the preferred vertical
size. Otherwise, it specifies the maximum vertical size that size. Otherwise, it specifies the maximum vertical size that
is supported. is supported.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum vertical size allowed by the profile and level. maximum vertical size allowed by the specified profile and
level.
max-bitrate: max-bitrate:
The value is an integer greater than zero, specifying a peak The value is an integer greater than zero, specifying a peak
transmission rate for the coded bit stream in bits per transmission rate for the coded bit stream in bits per
second. The number does not include the overhead caused by second. The number does not include the overhead caused by
RTP encapsulation, i.e., it does not include the AU headers, RTP encapsulation, i.e., it does not include the AU headers,
or any of the RTP, UDP or IP headers. or any of the RTP, UDP or IP headers.
If the value is less than the maximum bit rate allowed by the If the value is less than the maximum bit rate allowed by the
profile and level, then the value specifies the preferred bit profile and level, then the value specifies the preferred bit
rate. Otherwise, it specifies the maximum bit rate that is rate. Otherwise, it specifies the maximum bit rate that is
supported. supported.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum bit rate allowed by the profile and level. (See the maximum bit rate allowed by the specified profile and level.
values for "RMax" in Annex D of SMPTE 421M [1].) (See the values for "RMax" in Annex D of SMPTE 421M [1].)
max-buffer: max-buffer:
The value is an integer specifying a leaky bucket size, B, in The value is an integer specifying a leaky bucket size, B, in
milliseconds, required to contain a stream transmitted at the milliseconds, required to contain a stream transmitted at the
transmission rate specified by the max-bitrate parameter. transmission rate specified by the max-bitrate parameter.
This parameter is defined in the hypothetical reference This parameter is defined in the hypothetical reference
decoder model for VC-1, in Annex C of SMPTE 421M [1]. decoder model for VC-1, in Annex C of SMPTE 421M [1].
Note that this parameter relates to the codec bit stream Note that this parameter relates to the codec bit stream
only, and does not account for any buffering time that may be only, and does not account for any buffering time that may be
required to compensate for jitter in the network. required to compensate for jitter in the network.
If the value is less than the maximum leaky bucket size If the value is less than the maximum leaky bucket size
allowed by the max-bitrate parameter and the profile and allowed by the max-bitrate parameter and the profile and
level, then the value specifies the preferred leaky bucket level, then the value specifies the preferred leaky bucket
size. Otherwise, it specifies the maximum leaky bucket size size. Otherwise, it specifies the maximum leaky bucket size
that is supported for the bit rate specified by the max- that is supported for the bit rate specified by the max-
bitrate parameter. bitrate parameter.
If this parameter is not specified, it defaults to the If this parameter is not specified, it defaults to the
maximum buffer size allowed by the profile and level. (See maximum buffer size allowed by the specified profile and
the values for "BMax" and "RMax" in Annex D of SMPTE 421M level. (See the values for "BMax" and "RMax" in Annex D of
[1].) SMPTE 421M [1].)
max-framerate: max-framerate:
The value is an integer greater than zero, specifying a The value is an integer greater than zero, specifying a
number of frames per second for the coded bit stream. The number of frames per second for the coded bit stream. The
value is the frame rate multiplied by 1000 and rounded to the value is the frame rate multiplied by 1000 and rounded to the
nearest integer value. For example, 30000/1001 nearest integer value. For example, 30000/1001
(approximately 29.97) frames per second is represented as (approximately 29.97) frames per second is represented as
29970. 29970.
If the value is less than the maximum frame rate allowed by If the value is less than the maximum frame rate allowed by
the profile and level, then the value specifies the preferred the profile and level, then the value specifies the preferred
frame rate. Otherwise, it specifies the maximum frame rate frame rate. Otherwise, it specifies the maximum frame rate
that is supported. that is supported.
If the parameter is not specified, it defaults to the maximum If the parameter is not specified, it defaults to the maximum
frame rate allowed by the profile and level. frame rate allowed by the specified profile and level.
Encoding considerations: Encoding considerations:
This media type is framed and contains binary data. This media type is framed and contains binary data.
Security considerations: Security considerations:
See Section 7 of this document. See Section 7 of RFC XXXX.
Interoperability considerations: Interoperability considerations:
None. None.
Published specification: Published specification:
This payload format specification. RFC XXXX.
Applications which use this media type: Applications which use this media type:
Multimedia streaming and conferencing tools. Multimedia streaming and conferencing tools.
Additional Information: Additional Information:
None. None.
Person & email address to contact for further information: Person & email address to contact for further information:
Anders Klemets <anderskl@microsoft.com> Anders Klemets <anderskl@microsoft.com>
IETF AVT working group. IETF AVT working group.
skipping to change at page 24, line 35 skipping to change at page 25, line 5
This media type depends on RTP framing, and hence is only This media type depends on RTP framing, and hence is only
defined for transfer via RTP [3]. defined for transfer via RTP [3].
Authors: Authors:
Anders Klemets Anders Klemets
Change controller: Change controller:
IETF Audio/Video Transport Working Group delegated from the IETF Audio/Video Transport Working Group delegated from the
IESG. IESG.
6.2 Mapping of MIME parameters to SDP 6.2 Mapping of media type parameters to SDP
The information carried in the media type specification has a The information carried in the media type specification has a
specific mapping to fields in the Session Description Protocol (SDP) specific mapping to fields in the Session Description Protocol (SDP)
[4]. If SDP is used to specify sessions using this payload format, [4]. If SDP is used to specify sessions using this payload format,
the mapping is done as follows: the mapping is done as follows:
o The media name in the "m=" line of SDP MUST be video (the type o The media name in the "m=" line of SDP MUST be video (the type
name). name).
o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the o The encoding name in the "a=rtpmap" line of SDP MUST be vc1 (the
subtype name). subtype name).
o The clock rate in the "a=rtpmap" line MUST be at least 90000. o The clock rate in the "a=rtpmap" line MUST be 90000.
o The REQUIRED parameters "profile" and "level" MUST be included in o The REQUIRED parameters "profile" and "level" MUST be included in
the "a=fmtp" line of SDP. the "a=fmtp" line of SDP.
These parameters are expressed as a MIME media type string, in the These parameters are expressed in the form of a semicolon
form of a semicolon separated list of parameter=value pairs. separated list of parameter=value pairs.
o The OPTIONAL parameters "config", "width", "height", "bitrate", o The OPTIONAL parameters "config", "width", "height", "bitrate",
"buffer", "framerate", "bpic", "mode", "max-width", "max-height", "buffer", "framerate", "bpic", "mode", "max-width", "max-height",
"max-bitrate", "max-buffer" and "max-framerate", when present, "max-bitrate", "max-buffer" and "max-framerate", when present,
MUST be included in the "a=fmtp" line of SDP. MUST be included in the "a=fmtp" line of SDP.
These parameters are expressed as a MIME media type string, in the These parameters are expressed in the form of a semicolon
form of a semicolon separated list of parameter=value pairs: separated list of parameter=value pairs:
a=fmtp:<dynamic payload type> <parameter a=fmtp:<dynamic payload type> <parameter
name>=<value>[,<value>][; <parameter name>=<value>] name>=<value>[,<value>][; <parameter name>=<value>]
o Any unknown parameters to the device that uses the SDP MUST be o Any unknown parameters to the device that uses the SDP MUST be
ignored. For example, parameters defined in later specifications ignored. For example, parameters defined in later specifications
MAY be copied into the SDP and MUST be ignored by receivers that MAY be copied into the SDP and MUST be ignored by receivers that
do not understand them. do not understand them.
6.3 Usage with the SDP Offer/Answer Model 6.3 Usage with the SDP Offer/Answer Model
When VC-1 is offered over RTP using SDP in an Offer/Answer model [5] When VC-1 is offered over RTP using SDP in an Offer/Answer model [5]
for negotiation for unicast usage, the following rules and for negotiation for unicast usage, the following rules and
limitations apply: limitations apply:
o The "profile" parameter MUST be used symmetrically, i.e., the o The "profile" parameter MUST be used symmetrically, i.e., the
answerer MUST either maintain the parameter or remove the media answerer MUST either maintain the parameter or remove the media
format (payload type) completely if the offered encoding profile format (payload type) completely if the offered VC-1 profile is
is not supported. not supported.
o The "level" parameter describes the level of the VC-1 profile of o The "level" parameter specifies the highest level of the VC-1
the coded bit stream that the offerer or answerer is sending for profile supported by the codec.
this media format configuration, when the direction attribute is
sendonly or sendrecv. If the direction attribute is sendrecv or
recvonly, the parameter also specifies the highest level of the
VC-1 profile that the receiver implementation accepts.
The answerer MUST NOT specify a numerically higher level in the The answerer MUST NOT specify a numerically higher level in the
answer than what was specified in the offer, regardless of the answer than what was specified in the offer. The answerer MAY
direction attribute. specify a level that is lower than what was specified in the
offer, i.e., the level parameter can be "downgraded".
If an offer specifies the recvonly direction attribute, the
answerer MAY specify a level that is lower than what was specified
in the offer, i.e., the level parameter can be "downgraded".
If the offer specifies the sendonly direction attribute, the level
parameter cannot be downgraded by the answerer. In this case, the
answerer MUST either maintain the level parameter or remove the
media format (payload type) completely if the level is not
supported.
If the offer specifies the sendrecv direction attribute, or if the If the offer specifies the sendrecv or sendonly direction
direction attribute is unspecified, the answerer MAY specify a attribute, and the answer downgrades the level parameter, this may
level that is lower than what was specified in the offer. Note require a new offer to specify an updated "config" parameter. If
that the level parameter specified in the answer applies to the the "config" parameter cannot be used with the level specified in
coded bit stream that will be sent by the answerer, and the the answer, then the offerer MUST initiate another Offer/Answer
offerer will still use the level parameter that it specified in round, or not use media format (payload type).
the offer.
o The parameters "config", "bpic", "width", "height", "framerate", o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer" and "mode", describe the properties of the VC- "bitrate", "buffer" and "mode", describe the properties of the VC-
1 bit stream that the offerer or answerer is sending for this 1 bit stream that the offerer or answerer is sending for this
media format configuration. media format configuration.
In the case of unicast usage and when the direction attribute in In the case of unicast usage and when the direction attribute in
the offer or answer is recvonly, the interpretation of these the offer or answer is recvonly, the interpretation of these
parameters is undefined and they MUST NOT be used. parameters is undefined and they MUST NOT be used.
o The parameters "config", "width", "height", "bitrate" and "buffer"
MUST be specified when the direction attribute is sendrecv or
sendonly.
o The parameters "max-width", "max-height", "max-framerate", "max- o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate" and "max-buffer" MAY be specified in an offer or an bitrate" and "max-buffer" MAY be specified in an offer or an
answer, and their interpretation is as follows: answer, and their interpretation is as follows:
When the direction attribute is sendonly, the parameters describe When the direction attribute is sendonly, the parameters describe
the limits of the VC-1 bit stream that the sender is capable of the limits of the VC-1 bit stream that the sender is capable of
producing for the given profile and level, or any lower level of producing for the given profile and level, and for any lower level
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 SHOULD be interpreted only as a of the VC-1 profile, then it SHALL be interpreted as a preferred
preferred value suggested by the sender. If the value of a value and the sender's VC-1 bit stream SHOULD not exceed it. If
property is greater than what is allowed by the level of the VC-1 the value of a property is greater than what is allowed by the
profile, then it MUST be interpreted by the sender as an upper level of the VC-1 profile, then it SHALL be interpreted as the
limit of what the receiver accepts for the given profile and upper limit of the value that the receiver accepts for the given
level, and 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. But if the offer specifies "max-bitrate=200000", this means kbps. Assuming that the offer is accepted, the answerer should
that the receiver implementation supports a maximum of 200 kbps specify "bitrate=48000" in the answer, but any value up to 96000
for the given profile and level (or lower level.) 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 o If an offerer wishes to have non-symmetrical capabilities between
sending and receiving, e.g., use different levels in each sending and receiving, e.g., use different levels in each
direction, then the offerer has to offer different RTP sessions. direction, then the offerer has to offer different RTP sessions.
This can be done by specifiying different media lines declared as This can be done by specifiying different media lines declared as
"recvonly" and "sendonly", respectively. "recvonly" and "sendonly", respectively.
For streams being delivered over multicast, the following rules apply For streams being delivered over multicast, the following rules apply
in addition: in addition:
o The "level" parameter specifies the highest level of the VC-1 o The "level" parameter specifies the highest level of the VC-1
profile of the bit stream that will be sent, and/or received, on profile used by the participants in the multicast session. The
the multicast session. The value of this parameter MUST NOT be value of this parameter MUST NOT be changed by the answerer.
changed by the answerer. Thus, a payload type can either be Thus, a payload type can either be accepted unaltered or removed.
accepted unaltered or removed.
o The parameters "config", "bpic", "width", "height", "framerate", o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer" and "mode", specify properties of the VC-1 bit "bitrate", "buffer" and "mode", specify properties of the VC-1 bit
stream that will be sent, and/or received, on the multicast stream that will be sent, and/or received, on the multicast
session. The parameters MAY be specified even if the direction session. The parameters MAY be specified even if the direction
attribute is recvonly. attribute is recvonly.
The values of these parameters MUST NOT be changed by the The values of these parameters MUST NOT be changed by the
answerer. Thus, a payload type can either be accepted unaltered answerer. Thus, a payload type can either be accepted unaltered
or removed. or removed.
skipping to change at page 28, line 30 skipping to change at page 28, line 41
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 [10].
Note that the appropriate mechanism to ensure confidentiality and Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is very dependent on the integrity of RTP packets and their payloads is very dependent on the
application and on the transport and signaling protocols employed. application and on the transport and signaling protocols employed.
Thus, although SRTP is given as an example above, other possible Thus, although SRTP is given as an example above, other possible
choices exist. choices exist.
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.
8. IANA Considerations 8. IANA Considerations
IANA is requested to register the MIME 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] Proposed SMPTE 421M, "VC-1 Compressed Video Bitstream Format and
Decoding Process", www.smpte.org. Decoding Process", www.smpte.org.
 End of changes. 75 change blocks. 
209 lines changed or deleted 237 lines changed or added

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