draft-ietf-avt-rtp-vc1-00.txt   draft-ietf-avt-rtp-vc1-01.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft A. Klemets Internet Draft A. Klemets
Document: draft-ietf-avt-rtp-vc1-00.txt Microsoft Document: draft-ietf-avt-rtp-vc1-01.txt Microsoft
Expires: February 2006 August 2005 Expires: April 2006 October 2005
RTP Payload Format for Video Codec 1 (VC-1) RTP Payload Format for Video Codec 1 (VC-1)
IPR Notice IPR Notice
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 19 skipping to change at page 2, line 19
2. Definitions and abbreviations..................................3 2. Definitions and abbreviations..................................3
3. Overview of VC-1...............................................4 3. Overview of VC-1...............................................4
3.1 VC-1 bit stream layering model.............................5 3.1 VC-1 bit stream layering model.............................5
3.2 Bit-stream Data Units in Advanced profile..................5 3.2 Bit-stream Data Units in Advanced profile..................5
3.3 Decoder initialization parameters..........................6 3.3 Decoder initialization parameters..........................6
3.4 Ordering of frames.........................................7 3.4 Ordering of frames.........................................7
4. Encapsulation of VC-1 format bit streams in RTP................8 4. Encapsulation of VC-1 format bit streams in RTP................8
4.1 Access Units...............................................8 4.1 Access Units...............................................8
4.2 Fragmentation of VC-1 frames...............................8 4.2 Fragmentation of VC-1 frames...............................8
4.3 Time stamp considerations..................................9 4.3 Time stamp considerations..................................9
4.4 Signaling of MIME format parameters.......................10 4.4 Random Access Points......................................10
5. RTP Payload Format syntax.....................................12 4.5 Removal of HRD parameters.................................10
5.1 RTP header usage..........................................12 4.6 Repeating the Sequence Layer header.......................11
5.2 AU header syntax..........................................12 4.7 Signaling of MIME format parameters.......................11
5.3 AU Control field syntax...................................13 4.8 MIME "mode=1" parameter...................................12
6. RTP Payload format parameters.................................15 4.9 MIME "mode=3" parameter...................................12
6.1 Media Type Registration...................................15 5. RTP Payload Format syntax.....................................13
6.2 Mapping of MIME parameters to SDP.........................18 5.1 RTP header usage..........................................13
7. Security Considerations.......................................19 5.2 AU header syntax..........................................13
8. IANA Considerations...........................................20 5.3 AU Control field syntax...................................14
9. References....................................................20 6. RTP Payload format parameters.................................16
9.1 Normative references......................................20 6.1 Media Type Registration...................................16
9.2 Informative references....................................20 6.2 Mapping of MIME parameters to SDP.........................19
7. Security Considerations.......................................20
8. IANA Considerations...........................................21
9. References....................................................21
9.1 Normative references......................................21
9.2 Informative references....................................21
1. Introduction 1. Introduction
The bit stream syntax for compressed video in Video Codec 1 (VC-1) The bit stream syntax for compressed video in Video Codec 1 (VC-1)
format is defined by SMPTE 421M [1]. SMPTE 421M also specifies format is defined by SMPTE 421M [1]. SMPTE 421M also specifies
constraints that must be met by VC-1 conformant bit streams, and it constraints that must be met by VC-1 conformant bit streams, and it
specifies the complete process required to decode the bit stream. specifies the complete process required to decode the bit stream.
However, it does not specify the VC-1 compression algorithm, thus However, it does not specify the VC-1 compression algorithm, thus
allowing for different ways to implement a VC-1 encoder. allowing for different ways to implement a VC-1 encoder.
skipping to change at page 3, line 28 skipping to change at page 3, line 30
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
at the same hierarchical level. A BDU can be, for example, a at the same hierarchical level. A BDU can be, for example, a
sequence layer header, an entry-point segment header, a frame, or a sequence layer header, an entry-point header, a frame, or a slice.
slice.
Encapsulated BDU (EBDU): A BDU which has been encapsulated using the Encapsulated BDU (EBDU): A BDU which has been encapsulated using the
encapsulation mechanism described in Annex E of SMPTE 421M [1], to encapsulation mechanism described in Annex E of SMPTE 421M [1], to
prevent emulation of the start code prefix in the bit stream. prevent emulation of the start code prefix in the bit stream.
Entry-point: A point in the bit stream that offers random access. Entry-point: A point in the bit stream that offers random access.
frame: A frame contains lines of spatial information of a video frame: A frame contains lines of spatial information of a video
signal. For progressive video, these lines contain samples starting signal. For progressive video, these lines contain samples starting
from one time instant and continuing through successive lines to the from one time instant and continuing through successive lines to the
skipping to change at page 5, line 53 skipping to change at page 6, line 6
section 2 of this document and in section 4.12 of SMPTE 421M [1]. section 2 of this document and in section 4.12 of SMPTE 421M [1].
3.2 Bit-stream Data Units in Advanced profile 3.2 Bit-stream Data Units in Advanced profile
In the Advanced profile only, each picture and slice is byte-aligned In the Advanced profile only, each picture and slice is byte-aligned
and is considered a Bit-stream Data Unit (BDU). A BDU is defined as and is considered a Bit-stream Data Unit (BDU). A BDU is defined as
a unit that can be parsed (i.e., syntax decoded) independently of a unit that can be parsed (i.e., syntax decoded) independently of
other information in the same layer. other information in the same layer.
The beginning of a BDU is signaled by an identifier called Start Code The beginning of a BDU is signaled by an identifier called Start Code
(SC). Sequence layer headers and entry-point segment headers are (SC). Sequence layer headers and entry-point headers are also BDUs
also BDUs and thus can be easily identified by their Start Codes. and thus can be easily identified by their Start Codes. See Annex E
See Annex E of SMPTE 421M [1] for a complete list of Start Codes. of SMPTE 421M [1] for a complete list of Start Codes. Note that
Note that blocks and macroblocks are not BDUs and thus do not have a blocks and macroblocks are not BDUs and thus do not have a Start Code
Start Code and are not necessarily byte-aligned. and are not necessarily byte-aligned.
The Start Code consists of four bytes. The first three bytes are The Start Code consists of four bytes. The first three bytes are
0x00, 0x00 and 0x01. The fourth byte is called the Start Code Suffix 0x00, 0x00 and 0x01. The fourth byte is called the Start Code Suffix
(SCS) and it is used to indicate the type of BDU that follows the (SCS) and it is used to indicate the type of BDU that follows the
Start Code. For example, the SCS of a sequence layer header (0x0F) Start Code. For example, the SCS of a sequence layer header (0x0F)
is different from the SCS of an entry-point segment header (0x0E). is different from the SCS of an entry-point header (0x0E). The Start
The Start Code is always byte-aligned and is transmitted in network Code is always byte-aligned and is transmitted in network byte order.
byte order.
To prevent accidental emulation of the Start Code in the coded bit To prevent accidental emulation of the Start Code in the coded bit
stream, SMPTE 421M defines an encapsulation mechanism that uses byte stream, SMPTE 421M defines an encapsulation mechanism that uses byte
stuffing. A BDU which has been encapsulated by this mechanism is stuffing. A BDU which has been encapsulated by this mechanism is
referred to as an Encapsulated BDU, or EBDU. referred to as an Encapsulated BDU, or EBDU.
3.3 Decoder initialization parameters 3.3 Decoder initialization parameters
In the VC-1 Advanced profile, the sequence layer header contains In the VC-1 Advanced profile, the sequence layer header contains
parameters that are necessary to initialize the VC-1 decoder. These parameters that are necessary to initialize the VC-1 decoder. These
parameters apply to all entry-point segments until the next parameters apply to all entry-point segments until the next
occurrence of a sequence layer header in the coded bit stream. occurrence of a sequence layer header in the coded bit stream.
The parameters in the sequence layer header include, among other The parameters in the sequence layer header include the Advanced
things, the Advanced profile level, the dimensions of the coded profile level, the dimensions of the coded pictures, the aspect
pictures, the aspect ratio, interlace information, the frame rate and ratio, interlace information, the frame rate and up to 31 leaky
up to 31 leaky bucket parameter sets for the Hypothetical Reference bucket parameter sets for the Hypothetical Reference Decoder (HRD).
Decoder (HRD).
Section 6.1 of SMPTE 421M [1] provides the formal specification of Section 6.1 of SMPTE 421M [1] provides the formal specification of
the sequence layer header. the sequence layer header.
Each leaky bucket parameter set for the HRD specifies a peak Each leaky bucket parameter set for the HRD specifies a peak
transmission bit rate and a decoder buffer capacity. The coded bit transmission bit rate and a decoder buffer capacity. The coded bit
stream is restricted by these parameters. The HRD model does not stream is restricted by these parameters. The HRD model does not
mandate buffering by the decoder. Its purpose is to limit the mandate buffering by the decoder. Its purpose is to limit the
encoder's bit rate fluctuations according to a basic buffering model, encoder's bit rate fluctuations according to a basic buffering model,
so that the resources necessary to decode the bit stream are so that the resources necessary to decode the bit stream are
predictable. The HRD has a constant-delay mode and a variable-delay predictable. The HRD has a constant-delay mode and a variable-delay
mode. The constant-delay mode is appropriate for broadcast and mode. The constant-delay mode is appropriate for broadcast and
streaming applications, while the variable-delay mode is designed for streaming applications, while the variable-delay mode is designed for
video conferencing applications. video conferencing applications.
Annex C of SMPTE 421M [1] specifies the usage of the hypothetical Annex C of SMPTE 421M [1] specifies the usage of the hypothetical
reference decoder for VC-1 bit streams. A general description of the reference decoder for VC-1 bit streams. A general description of the
theory of the HRD can be found in [6]. theory of the HRD can be found in [7].
The concept of an entry-point layer applies only to the VC-1 Advanced The concept of an entry-point layer applies only to the VC-1 Advanced
profile. The presence of an entry-point segment header indicates a profile. The presence of an entry-point header indicates a random
random access point within the bit stream. The entry-point segment access point within the bit stream. The entry-point header specifies
header specifies current buffer fullness values for the leaky buckets current buffer fullness values for the leaky buckets in the HRD. The
in the HRD. The header also specifies coding control parameters that header also specifies coding control parameters that are in effect
are in effect until the occurrence of the next entry-point segment until the occurrence of the next entry-point header in the bit
header in the bit stream. See Section 6.2 of SMPTE 421M [1] for the stream. See Section 6.2 of SMPTE 421M [1] for the formal
formal specification of the entry-point segment header. specification of the entry-point header.
Neither a sequence layer header nor an entry-point segment header is Neither a sequence layer header nor an entry-point header is defined
defined for the VC-1 Simple and Main profiles. For these profiles, for the VC-1 Simple and Main profiles. For these profiles, decoder
decoder initialization parameters MUST be conveyed out-of-band from initialization parameters MUST be conveyed out-of-band from the coded
the coded bit stream. Section 4.4 of this document specifies how the bit stream. Section 4.7 of this document specifies how the
parameters are conveyed by this RTP payload format. parameters are conveyed by this RTP payload format.
3.4 Ordering of frames 3.4 Ordering of frames
Frames are transmitted in the same order in which they are captured, Frames are transmitted in the same order in which they are captured,
except if the presence of B-pictures has been indicated in the except if the presence of B-pictures has been indicated in the
decoder initialization parameters. In the latter case, the frames decoder initialization parameters. In the latter case, the frames
are reordered by the VC-1 encoder such that the frames that the B- are reordered by the VC-1 encoder such that the frames that the B-
pictures depend on are transmitted first. This is referred to as the pictures depend on are transmitted first. This is referred to as the
coded order of the frames. coded order of the frames.
skipping to change at page 8, line 35 skipping to change at page 8, line 35
The AU payload MUST contain data belonging to exactly one VC-1 frame. The AU payload MUST contain data belonging to exactly one VC-1 frame.
The following rules apply to the contents of each AU payload when the The following rules apply to the contents of each AU payload when the
VC-1 Advanced profile is used: VC-1 Advanced profile is used:
- The AU payload MUST contain VC-1 bit stream data in EBDU format - The AU payload MUST contain VC-1 bit stream data in EBDU format
(i.e., the bit stream must use the byte-stuffing encapsulation (i.e., the bit stream must use the byte-stuffing encapsulation
mode defined in Annex E of SMPTE 421M [1].) mode defined in Annex E of SMPTE 421M [1].)
- The AU payload MAY contain multiple EBDUs, e.g., a sequence layer - The AU payload MAY contain multiple EBDUs, e.g., a sequence layer
header, an entry-point segment header, a frame header and multiple header, an entry-point header, a frame header and multiple slices
slices and the associated user-data. (However, all slices and and the associated user-data. (However, all slices and their
their corresponding macroblocks MUST belong to the same video corresponding macroblocks MUST belong to the same video frame.)
frame.)
- The AU payload MUST start at an EBDU boundary, except when the AU - The AU payload MUST start at an EBDU boundary, except when the AU
payload contains a fragmented frame, in which case the rules in payload contains a fragmented frame, in which case the rules in
section 4.2 apply. section 4.2 apply.
If the data in an AU (EBDUs in the case of Advanced profile and frame 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 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- to 7 zero-valued padding bits MUST be added to achieve octet-
alignment. alignment.
skipping to change at page 9, line 35 skipping to change at page 9, line 35
If the PTS Delta field in the AU header is used, each fragment of a If the PTS Delta field in the AU header is used, each fragment of a
frame MUST have the same presentation time. If the DTS Delta field frame MUST have the same presentation time. If the DTS Delta field
in the AU header is used, each fragment of a frame MUST have the same in the AU header is used, each fragment of a frame MUST have the same
decode time. decode time.
4.3 Time stamp considerations 4.3 Time stamp considerations
Video frames MUST be transmitted in the coded order. Coded order Video frames MUST be transmitted in the coded order. Coded order
implies that no frames are dependent on subsequent frames, as implies that no frames are dependent on subsequent frames, as
discussed in section 3.4. The RTP timestamp field MUST be set to the discussed in section 3.4. The RTP timestamp field MUST be set to the
decode time of the video frame contained in the first AU in the RTP presentation time of the video frame contained in the first AU in the
packet. The decode time is equivalent to the sampling instant of the RTP packet. The presentation time is equivalent to the sampling
frame, except when the codec initialization parameters indicate that instant of the frame.
the VC-1 bit stream contains B-pictures. When the presence of B-
pictures has been indicated, the encoder may reorder frames, as
explained in section 3.4 of this document and in section 5.4 of SMPTE
421M [1].
The VC-1 bit stream does not carry any time stamps other than an
optional Temporal Frame Reference Counter field, which, if it is
present, can be used to calculate the decode time of a frame.
However, the RTP sender may have access to different externally
provided time stamps depending on the method used to ingest the VC-1
bit stream. For example, if VC-1 is encapsulated in MPEG-2 Transport
Stream, each frame is assigned a presentation time (PTS) and
optionally also a decode time (DTS). If a VC-1 bit stream is stored
in an ASF file, only the decode time of each video frame is
available.
If only presentation time information is available, the RTP sender Each AU header may optionally specify the decode time of video frame
can approximate the decode time of a frame by its presentation time, contained in the AU. If the decode time is not specified, the RTP
after taking frame reordering into account. Frame reordering can be receiver can approximate it by the frame's presentation time, after
taking frame reordering into account. Frame reordering can be
handled by an algorithm similar to the one illustrated in Figure 1 in handled by an algorithm similar to the one illustrated in Figure 1 in
section 3.4. The algorithm requires buffering of only one frame. section 3.4. The algorithm requires buffering of only one frame.
If only decode time information is available, determining the
presentation time of a P-frame requires buffering, or looking ahead,
to the first frame that does not depend on the P-frame. Using the
coded order sequence in Figure 1 as an example, the RTP sender cannot
determine presentation time of frame P4 until it has seen frame P5.
This would be a more complicated and costly procedure than to
estimate a decode time from the presentation time. Hence, this RTP
payload format defines that the RTP timestamp field must represent
the decode time of the frame.
Knowing if the stream will contain B-pictures helps the decoder Knowing if the stream will contain B-pictures helps the decoder
allocate resources more efficiently, as the encoder will not reorder allocate resources more efficiently, as the encoder will not reorder
any frames. In that case, the buffering of one frame as described in any frames. In that case, the buffering of one frame as described in
section 3.4 is not necessary. Avoiding this buffer reduces the end- section 3.4 is not necessary. Avoiding this buffer reduces the end-
to-end delay, which may be important for interactive applications. to-end delay, which may be important for interactive applications.
For Advanced profile, B-pictures are assumed to be present by For Advanced profile, B-pictures are assumed to be present by
default. If the coded bit stream never contains B-pictures, this can default. If the coded bit stream never contains B-pictures, this can
be indicated using the "bpic" MIME parameter defined in section 6.1. be indicated using the "bpic" MIME parameter defined in section 6.1.
For Simple and Main profiles, the presence of B-pictures is indicated For Simple and Main profiles, the presence of B-pictures is indicated
by a non-zero value for the MAXBFRAMES field in STRUCT_C decoder by a non-zero value for the MAXBFRAMES field in STRUCT_C decoder
initialization parameter. STRUCT_C conveyed in the MIME "config" initialization parameter. STRUCT_C conveyed in the MIME "config"
parameter, which is defined in section 6.1. parameter, which is defined in section 6.1.
4.4 Signaling of MIME format parameters 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 points
into the coded bit stream. The Simple and Main profiles do not have
entry-point headers, so for those profiles each I-picture is a random
access point.
To allow the RTP receiver to detect that a RTP packet which 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 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 a 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 the 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 (HDR_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 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 is 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.
Note that 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.)
Note that 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 a RTP packet which 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 MIME format parameters
When this RTP payload format is used with SDP, the decoder When this RTP payload format is used with SDP, the decoder
initialization parameters described in section 3.3 MUST be signaled initialization parameters described in section 3.3 MUST be signaled
in SDP using the MIME parameters specified in section 6.1. Section in SDP using the MIME parameters specified in section 6.1. Section
6.2 specifies how to map the MIME parameters to SDP. 6.2 specifies how to map the MIME parameters to SDP.
When the Advanced profile is used, the decoder initialization When the Advanced profile is used, the decoder initialization
parameters MAY be changed by inserting a new sequence layer header or parameters MAY be changed by inserting a new sequence layer header or
an entry-point segment header in the coded bit stream. an entry-point header in the coded bit stream.
Note that the sequence layer header specifies the encoding level, the Note that the sequence layer header specifies the encoding level, the
maximum size of the coded pictures and possibly also the frame rate. maximum size of the coded pictures and possibly also the frame rate.
Thus, if the sequence layer header changes, the new header supersedes Thus, if the sequence layer header changes, the new header supersedes
the values of the MIME parameters "level", "width", "height" and the values of the MIME parameters "level", "width", "height" and
"framerate". "framerate".
To improve robustness against loss of RTP packets, it is RECOMMENDED 4.8 MIME "mode=1" parameter
that if the sequence layer header changes, it should be repeated
frequently in the bit stream. Note that any data in the VC-1 bit
stream, including the sequence header itself, must be accounted for
when computing the leaky bucket parameters for the HRD. (See section
3.3 for a discussion about the HRD.)
The Seq Count field in the Access Unit header is used to track In certain applications using the Advanced profile, the sequence
changes to the sequence layer header. A value of 0 is reserved for layer header never changes. This MAY be signaled with the MIME
the case when the most recent sequence layer header of the bit stream parameter "mode=1". (The "mode" parameter is defined in section 6.1.)
is identical to the sequence layer header in the MIME "config" The "mode=1" parameter serves as a "hint" to the RTP receiver that
parameter (defined in section 6.1.) 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 MIME "config" parameter.
If the RTP sender cannot determine the most recent sequence layer Since the sequence layer header never changes in "mode=1", the RTP
header, or if it is different form the sequence layer header in the sender MAY remove it from the bit stream. Note, however, that if
MIME "config" parameter, a non-zero value MUST be used for the Seq that if the value of TFCNTRFLAG in the sequence layer header is 1,
Count field. 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.)
When the RTP sender transmits an AU containing a sequence layer 4.9 MIME "mode=3" parameter
header that is different from the previous sequence layer header, the
value of the Seq Count field MUST be incremented. The Seq Count
field of all subsequent AU headers MUST be set to this new value
until the sequence layer header changes again.
In certain applications, the sequence layer header never changes. In certain applications using the Advanced profile, both the sequence
This MAY be signaled with the MIME parameter "mode=1" or "mode=3", as layer header and the entry-point header never change. This MAY be
appropriate. (See the definition of the "mode" parameter in section signaled with the MIME parameter "mode=3". The same rules apply to
6.1.) If "mode=1" or "mode=3" is signaled and a sequence layer "mode=3" as for "mode=1", described in section 4.8. Additionally, if
header is present in the coded bit stream, it MUST be identical to "mode=3" is signaled, then the RTP sender MAY "compress" the coded
the sequence layer header specified by the MIME "config" parameter. bit stream by not including sequence layer headers and entry-point
headers in the RTP packets.
The entry-point segment header contains information that is needed by The RTP receiver MUST "decompress" the coded bit stream by re-
the decoder to decode the frames in that segment. This means that in inserting the entry-point headers prior to delivering the coded bit
the event of lost RTP packets the decoder may be unable to decode stream to the VC-1 decoder. The sequence layer header does not need
frames until the next entry-point segment header is received. Access to be decompressed by the receiver, since it never changes.
Units that contain an entry-point segment header MUST have the RA bit
in AU header set to 1. (The RA bit is defined in section 5.3.)
In certain applications, the entry-point segment header never If "mode=3" is signaled and the RTP receiver receives a complete AU
changes. This MUST be signaled with the MIME parameter "mode=2" or or the first fragment of an AU, and the RA bit is set to 1 but the AU
"mode=3", as appropriate. In this case, any entry-point segment does not begin with an entry-point header, then this indicates that
headers that are present in the bit stream MAY be removed by the RTP entry-point header has been "compressed". In that case, the RTP
sender. If "mode=2" or "mode=3" is signaled and an entry-point receiver MUST insert an entry-point header at the beginning of the
segment header is present in the coded bit stream, it MUST be AU. When inserting the entry-point header, the RTP receiver MUST use
identical to the entry-point segment header specified by the MIME the one that was specified by the MIME "config" parameter.
"config" 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 12, line 42 skipping to change at page 13, line 42
Unit containing a complete VC-1 frame, or the last fragment Unit containing a complete VC-1 frame, or the last fragment
of a VC-1 frame. of a VC-1 frame.
Payload type (PT): 7 bits Payload type (PT): 7 bits
This document does not assign a RTP payload type for this RTP This document does not assign a RTP payload type for this RTP
payload format. The assignment of a payload type has to be payload format. The assignment of a payload type has to be
performed either through the RTP profile used or in a dynamic performed either through the RTP profile used or in a dynamic
way. way.
Timestamp: 32 bits Timestamp: 32 bits
The RTP timestamp is set to the decode time of the VC-1 frame The RTP timestamp is set to the presentation time of the VC-1
in the first Access Unit. frame in the first Access Unit.
A 90 kHz clock rate MUST be used. A 90 kHz clock rate 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, and 4 The Access Unit header consists of a one-byte AU Control field, the
optional fields. The structure of the AU header is illustrated in RA Count field and 3 optional fields. The structure of the AU header
is illustrated in
Figure 4. Figure 4.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AU | Seq | PTS | DTS | AUP | |AU | RA | AUP | PTS | DTS |
|Control| Count | Delta | Delta | Len | |Control| Count | Len | Delta | Delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Structure of AU header. Figure 4. Structure of AU header.
AU Control: 8 bits AU Control: 8 bits
The usage of the AU Control field is defined in section 5.3. The usage of the AU Control field is defined in section 5.3.
Seq Count: 8 bits RA Count: 8 bits
Sequence Layer Counter. This field is a binary modulo 256 Random Access Point Counter. This field is a binary modulo
counter. The value of this field, if present, MUST be 256 counter. The value of this field, MUST be incremented by
incremented by 1, each time an AU containing a new sequence 1, each time an AU is transmitted where the RA bit in the AU
layer header is transmitted. The value 0 is reserved for the Control field is set to 1. The initial value of this field
case when the RTP sender knows that the current sequence is undefined and MAY be chosen randomly.
layer header is identical to the sequence layer header in the
MIME "config" parameter (defined in section 6.1) and MUST NOT AUP Len: 16 bits
be used for any other purpose. Access Unit Payload Length. Specifies the size, in bytes, of
If this field is not present, a value of 0 MUST be assumed. 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.
PTS Delta: 32 bits PTS Delta: 32 bits
Presentation time delta. Specifies the presentation time of Presentation time delta. Specifies the presentation time of
the frame as a 2's complement offset (delta) from the the frame as a 2's complement offset (delta) from the
timestamp in the RTP header of this RTP packet. The PTS timestamp in the RTP header of this RTP packet. The PTS
Delta field MUST use the same clock rate as the timestamp 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
the RTP packet, because the RTP timestamp field specifies the
presentation time of the frame in the first AU.
DTS Delta: 32 bits DTS Delta: 32 bits
Decode time delta. Specifies the decode time of the frame as Decode time delta. Specifies the decode time of the frame as
a 2's complement offset (delta) from the timestamp in the RTP a 2's complement offset (delta) from the timestamp in the RTP
header of this RTP packet. The DTS Delta field MUST use the header of this RTP packet. The DTS Delta field MUST use the
same clock rate as the timestamp field in the RTP header. 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
decode time of the frame in the first AU.
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.
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 | SC | PT | DT | LP | R | | FRAG | RA | SL | LP | PT | DT | R |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
Figure 5. Syntax of AU Control field. Figure 5. Syntax of AU Control field.
FRAG: 2 bits FRAG: 2 bits
Fragmentation Information. This field indicates if the AU Fragmentation Information. This field indicates if the AU
payload contains a complete frame or a fragment of a frame. payload contains a complete frame or a fragment of a frame.
It MUST be set as follows: It MUST be set as follows:
0: The AU payload contains a fragment of a frame other than 0: The AU payload contains a fragment of a frame other than
the first or last fragment. the first or last fragment.
1: The AU payload contains the first fragment of a frame. 1: The AU payload contains the first fragment of a frame.
2: The AU payload contains the last fragment of a frame. 2: The AU payload contains the last fragment of a frame.
3: The AU payload contains a complete frame (not fragmented.) 3: The AU payload contains a complete frame (not fragmented.)
SC: 1 bit
Sequence Layer Counter present. This bit MUST be set to 1 if
the AU header includes the Seq Count field. The bit MUST be
0 for Simple and Main profile bit streams.
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 segment header is a random access point. entry-point header is a random access point.
Note that if entry-point segment headers are not transmitted Note that if entry-point headers are not transmitted at every
at every random access point, this MUST be indicated using random access point, this MUST be indicated using the MIME
the MIME parameter "mode=2" or "mode=3", as appropriate. 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 PT: 1 bit
PTS Delta Present. This bit MUST be set to 1 if the AU PTS Delta Present. This bit MUST be set to 1 if the AU
header includes the PTS Delta field. header includes the PTS Delta field.
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.
LP: 1 bit
Length Present. This bit MUST be set to 1 if the AU header
includes the AUP Len field.
R: 1 bit R: 1 bit
Reserved. This bit MUST be set to 0 and MUST be ignored by Reserved. This bit MUST be set to 0 and MUST be ignored by
receivers. receivers.
6. RTP Payload format parameters 6. RTP Payload format parameters
6.1 Media Type Registration 6.1 Media Type Registration
The media subtype for VC-1 is allocated from the standards tree. The The media subtype for VC-1 is allocated from the standards tree. The
top-level media type under which this payload format is registered is top-level media type under which this payload format is registered is
skipping to change at page 15, line 29 skipping to change at page 16, line 35
Required parameters: Required parameters:
profile: profile:
The value is a decimal number indicating the VC-1 profile. The value is a decimal number indicating the VC-1 profile.
The following values are defined: The following values are defined:
0: Simple profile. 0: Simple profile.
1: Main profile. 1: Main profile.
3: Advanced profile. 3: Advanced profile.
config: config:
The value is a hexadecimal representation of an octet string The value is a base16 [5] (hexadecimal) representation of an
that expresses the decoder initialization parameters. octet string that expresses the decoder initialization
Decoder initialization parameters are mapped onto the parameters. Decoder initialization parameters are mapped
hexadecimal octet string in an MSB-first basis. The first onto the base16 octet string in an MSB-first basis. The
bit of the decoder initialization parameters MUST be located first bit of the decoder initialization parameters MUST be
at the MSB of the first octet. If the decoder initialization located at the MSB of the first octet. If the decoder
parameters are not multiple of 8 bits, in the last octet up initialization parameters are not multiple of 8 bits, in the
to 7 zero-valued padding bits MUST be added to achieve octet last octet up to 7 zero-valued padding bits MUST be added to
alignment. achieve octet alignment.
For the Simple and Main profiles, the decoder initialization For the Simple and Main profiles, the decoder initialization
parameters are STRUCT_C, as defined in Annex J of SMPTE 421M parameters are STRUCT_C, as defined in Annex J of SMPTE 421M
[1]. [1].
For the Advanced profile, the decoder initialization For the Advanced profile, the decoder initialization
parameters are a sequence layer header directly followed by parameters are a sequence layer header directly followed by
an entry-point segment header. The two headers MUST be in an entry-point header. The two headers MUST be in EBDU
EBDU format, meaning that they must include their Start Codes format, meaning that they must include their Start Codes and
and must use the encapsulation method defined in Annex E of must use the encapsulation method defined in Annex E of SMPTE
SMPTE 421M [1]. 421M [1].
width: width:
The value is a decimal number specifying the maximum The value is a decimal number specifying the maximum
horizontal size of the coded picture in pixels. horizontal size of the coded picture in pixels.
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
height: height:
skipping to change at page 16, line 50 skipping to change at page 18, line 7
level: level:
The value is a decimal number specifying the level of the The value is a decimal number specifying the level of the
encoding profile. encoding 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)
This parameter does not have a default value.
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
framerate: framerate:
The value is a decimal number specifying the number of frames The value is a decimal number specifying the number of frames
per second, multiplied by 1000. For example, 29.97 frames per second, multiplied by 1000. For example, 29.97 frames
per second is represented as 29970. per second is represented as 29970.
This parameter does not have a default value. If the
parameter is not specified, the frame rate can be determined
from the level of the encoding profile, if it is known.
Note: When Advanced profile is used, this parameter only Note: When Advanced profile is used, this parameter only
applies while the sequence layer header specified in the applies while the sequence layer header specified in the
config parameter is in use. config parameter is in use.
bpic: bpic:
This parameter signals if B-pictures may be present when the This parameter signals if B-pictures may be present when the
Advanced profile is used. If this parameter is present, and Advanced profile is used. If this parameter is present, and
B-pictures may be present in the coded bit stream, this B-pictures may be present in the coded bit stream, this
parameter MUST be equal to 1. parameter MUST be equal to 1.
If B-pictures will never be present in the coded bit stream, If B-pictures will never be present in the coded bit stream,
even if the sequence layer header changes, this parameter even if the sequence layer header changes, this parameter
SHOULD be present and its value SHOULD be equal to 0. SHOULD be present and its value SHOULD be equal to 0.
If this parameter is not specified, a value of 1 MUST be If this parameter is not specified, a value of 1 MUST be
assumed. assumed.
mode: mode:
The value is a decimal number specifying the use of the The value is a decimal number specifying the use of the
sequence layer header and the entry-point segment header. sequence layer header and the entry-point header. This
This parameter is only used for Advanced profile. The parameter is only used for Advanced profile. The following
following values are defined: values are defined:
0: Both the sequence layer header and the entry-point segment 0: Both the sequence layer header and the entry-point header
header may change, and changed headers will be included in may change, and changed headers will be included in the RTP
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.
2: The entry-point segment header specified in the config 3: The sequence layer header and the entry-point header
parameter never changes. Entry-point segment headers MAY not specified in the config parameter never change. Entry-point
be included in the RTP packets. Each Access Unit that has headers MAY not be included in the Access Units. Each Access
the RA bit set to 1 contains a random access point even if an Unit that has the RA bit set to 1 contains a random access
entry-point segment header is not included in the RTP packet. point even if an entry-point header is not included in the
3: Modes 1 and 2 combined. 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 MUST be
assumed. The mode parameter SHOULD be specified if any of assumed. The mode parameter SHOULD be specified if modes 1
the modes 1-3 apply to the VC-1 bit stream. or 3 apply to the VC-1 bit stream.
Encoding considerations: Encoding considerations:
This media type is framed and contains binary data. This This media type is framed and contains binary data.
media type depends on RTP framing, and hence is only defined
for transfer via RTP [3].
Security considerations: Security considerations:
See Section 7 of this document. See Section 7 of this document.
Interoperability considerations: Interoperability considerations:
None. None.
Published specification: Published specification:
This payload format specification. This payload format specification.
skipping to change at page 19, line 35 skipping to change at page 20, line 48
a=rtpmap:98 VC1/90000 a=rtpmap:98 VC1/90000
a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000; a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000;
bitrate=384000;buffer=2000;config=4e291800 bitrate=384000;buffer=2000;config=4e291800
7. Security Considerations 7. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [4], and in any appropriate RTP profile. This implies specification [4], and in any appropriate RTP profile. This implies
that confidentiality of the media streams is achieved by encryption; that confidentiality of the media streams is achieved by encryption;
for example, through the application of SRTP [5]. for example, through the application of SRTP [6].
A potential denial-of-service threat exists for data encodings using A potential denial-of-service threat exists for data encodings using
compression techniques that have non-uniform receiver-end compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological RTP packets computational load. The attacker can inject pathological RTP packets
into the stream that are complex to decode and that cause the into the stream that are complex to decode and that cause the
receiver to be overloaded. VC-1 is particularly vulnerable to such receiver to be overloaded. VC-1 is particularly vulnerable to such
attacks, because it is possible for an attacker to generate RTP attacks, because it is possible for an attacker to generate RTP
packets containing frames that affect the decoding process of many packets containing frames that affect the decoding process of many
future frames. Therefore, the usage of data origin authentication future frames. Therefore, the usage of data origin authentication
and data integrity protection of at least the RTP packet is and data integrity protection of at least the RTP packet is
RECOMMENDED; for example, with SRTP [5]. RECOMMENDED; for example, with SRTP [6].
Note that the appropriate mechanism to ensure confidentiality and Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is very dependent on the integrity of RTP packets and their payloads is very dependent on the
application and on the transport and signaling protocols employed. application and on the transport and signaling protocols employed.
Thus, although SRTP is given as an example above, other possible Thus, although SRTP is given as an example above, other possible
choices exist. choices exist.
8. IANA Considerations 8. IANA Considerations
IANA is requested to register the media subtype name "vc1" for the IANA is requested to register the media subtype name "vc1" for the
skipping to change at page 20, line 23 skipping to change at page 21, line 36
[1] Proposed SMPTE 421M, "VC-1 Compressed Video Bitstream Format and [1] Proposed SMPTE 421M, "VC-1 Compressed Video Bitstream Format and
Decoding Process", www.smpte.org. Decoding Process", www.smpte.org.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, "RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003. RFC 3550, July 2003.
[4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", [4] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. RFC 2327, April 1998.
[5] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
9.2 Informative references 9.2 Informative references
[5] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004. 3711, March 2004.
[6] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A [7] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A
generalized hypothetical reference decoder for H.264/AVC", IEEE generalized hypothetical reference decoder for H.264/AVC", IEEE
Transactions on Circuits and Systems for Video Technology, August Transactions on Circuits and Systems for Video Technology, August
2003. 2003.
Author's Addresses Author's Addresses
Anders Klemets Anders Klemets
Microsoft Corp. Microsoft Corp.
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: anderskl@microsoft.com Email: anderskl@microsoft.com
Acknowledgements Acknowledgements
Thanks to Shankar Regunathan for pointing out errors in the initial Thanks to Shankar Regunathan for pointing out errors in the initial
draft of this document. draft of this document.
 End of changes. 47 change blocks. 
193 lines changed or deleted 258 lines changed or added

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