draft-ietf-avt-rtp-vc1-05.txt   draft-ietf-avt-rtp-vc1-06.txt 
Internet Engineering Task Force Internet Engineering Task Force
Internet Draft A. Klemets Internet Draft A. Klemets
Document: draft-ietf-avt-rtp-vc1-05.txt Microsoft Document: draft-ietf-avt-rtp-vc1-06.txt Microsoft
Expires: July 2006 January 2006 Expires: July 2006 January 2006
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 1, line 48 skipping to change at page 1, line 48
This memo specifies an RTP payload format for encapsulating Video This memo specifies an RTP payload format for encapsulating Video
Codec 1 (VC-1) compressed bit streams, as defined by the Society of Codec 1 (VC-1) compressed bit streams, as defined by the Society of
Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M. Motion Picture and Television Engineers (SMPTE) standard, SMPTE 421M.
SMPTE is the main standardizing body in the motion imaging industry SMPTE is the main standardizing body in the motion imaging industry
and the SMPTE 421M standard defines a compressed video bit stream and the SMPTE 421M standard defines a compressed video bit stream
format and decoding process for television. format and decoding process for television.
Table of Contents Table of Contents
1. Introduction..................................................2 1. Introduction...................................................2
1.1 Conventions used in this document.........................3 1.1 Conventions used in this document..........................3
2. Definitions and abbreviations.................................3 2. Definitions and abbreviations..................................3
3. Overview of VC-1 .............................................5 3. Overview of VC-1...............................................5
3.1 VC-1 bit stream layering model............................5 3.1 VC-1 bit stream layering model.............................5
3.2 Bit-stream Data Units in Advanced profile.................6 3.2 Bit-stream Data Units in Advanced profile..................6
3.3 Decoder initialization parameters.........................6 3.3 Decoder initialization parameters..........................6
3.4 Ordering of frames........................................8 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 ............................10 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 ....................................12 4.4 Random Access Points......................................12
4.5 Removal of HRD parameters................................12 4.5 Removal of HRD parameters.................................13
4.6 Repeating the Sequence Layer header .....................13 4.6 Repeating the Sequence Layer header.......................13
4.7 Signaling of media type parameters.......................13 4.7 Signaling of media type parameters........................14
4.8 The "mode=1" media type parameter........................14 4.8 The "mode=1" media type parameter.........................15
4.9 The "mode=3" media type parameter........................14 4.9 The "mode=3" media type parameter.........................15
5. RTP Payload Format syntax....................................15 5. RTP Payload Format syntax.....................................15
5.1 RTP header usage.........................................15 5.1 RTP header usage..........................................15
5.2 AU header syntax.........................................16 5.2 AU header syntax..........................................16
5.3 AU Control field syntax..................................17 5.3 AU Control field syntax...................................18
6. RTP Payload format parameters................................18 6. RTP Payload format parameters.................................19
6.1 Media type Registration..................................18 6.1 Media type Registration...................................19
6.2 Mapping of media type parameters to SDP..................26 6.2 Mapping of media type parameters to SDP...................26
6.3 Usage with the SDP Offer/Answer Model....................26 6.3 Usage with the SDP Offer/Answer Model.....................27
6.4 Usage in Declarative Session Descriptions................28 6.4 Usage in Declarative Session Descriptions.................29
7. Security Considerations......................................29 7. Security Considerations.......................................29
8. Congestion Control...........................................30 8. Congestion Control............................................30
9. IANA Considerations..........................................31 9. IANA Considerations...........................................32
10. References..................................................31 10. References...................................................32
10.1 Normative references....................................31 10.1 Normative references.....................................32
10.2 Informative references..................................31 10.2 Informative references...................................32
1. Introduction 1. Introduction
This memo specifies an RTP payload format for the video coding This memo specifies an RTP payload format for the video coding
standard Video Codec 1, also known as VC-1. The specification for standard Video Codec 1, also known as VC-1. The specification for
the VC-1 bit stream format and decoding process is published by the the VC-1 bit stream format and decoding process is published by the
Society of Motion Picture and Television Engineers (SMPTE) as SMPTE Society of Motion Picture and Television Engineers (SMPTE) as SMPTE
421M [1]. 421M [1].
VC-1 has a broad applicability, being suitable for low bit rate VC-1 has a broad applicability, being suitable for low bit rate
skipping to change at page 7, line 9 skipping to change at page 7, line 9
3.3 Decoder initialization parameters 3.3 Decoder initialization parameters
In VC-1 Advanced profile, the sequence layer header contains In VC-1 Advanced profile, the sequence layer header contains
parameters that are necessary to initialize the VC-1 decoder. parameters that are necessary to initialize the VC-1 decoder.
The parameters apply to all entry-point segments until the next The 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 the Advanced The parameters in the sequence layer header include the Advanced
profile level, the maximum dimensions of the coded pictures, the profile level, the maximum dimensions of the coded frames, the aspect
aspect ratio, interlace information, the frame rate and up to 31 ratio, interlace information, the frame rate and up to 31 leaky
leaky bucket parameter sets for the Hypothetical Reference Decoder bucket parameter sets for the Hypothetical Reference Decoder (HRD).
(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.
A sequence layer header is not defined for VC-1 Simple and Main A sequence layer header is not defined for VC-1 Simple and Main
profiles. For these profiles, decoder initialization parameters MUST profiles. For these profiles, decoder initialization parameters MUST
be conveyed out-of-band. The decoder initialization parameters for be conveyed out-of-band. The decoder initialization parameters for
Simple and Main profiles include the maximum dimensions of the coded Simple and Main profiles include the maximum dimensions of the coded
picture, and a leaky bucket parameter set for the HRD. Section 4.7 frames, and a leaky bucket parameter set for the HRD. Section 4.7
specifies how the parameters are conveyed by this RTP payload format. specifies how the parameters are conveyed by this RTP payload format.
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
skipping to change at page 11, line 29 skipping to change at page 11, line 25
when the video frames are transmitted in the coded order. If neither when the video frames are transmitted in the coded order. If neither
B- nor BI-pictures are present in the coded bit stream, then the B- nor BI-pictures are present in the coded bit stream, then the
decode time of a frame SHALL be equal to the presentation time of the decode time of a frame SHALL be equal to the presentation time of the
frame. A BI-picture is a special kind of B-picture, and in the frame. A BI-picture is a special kind of B-picture, and in the
remainder of this section the terms B-picture and B-frame also apply remainder of this section the terms B-picture and B-frame also apply
to BI-pictures and BI-frames, respectively. to BI-pictures and BI-frames, respectively.
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
times of frames are determined as follows: times of frames are determined as follows:
- Non-B frames: The decode time SHALL be equal to the presentation - B-frames:
time of the previous non-B frame in the coded order. The decode time SHALL be equal to the presentation time of the B-
frame.
- B-frames: The decode time SHALL be equal to the presentation time - First non-B frame in the coded order:
of the B-frame. The decode time SHALL be at least one frame period less than the
decode time of the next frame in the coded order. A frame period
is defined as the inverse of the frame rate used in the coded bit
stream (e.g., 100 milliseconds if the frame rate is 10 frames per
seconds.) For bit streams with a variable frame rate, the maximum
frame rate SHALL determine the frame period. If the maximum frame
is not specified, the maximum frame rate allowed by the profile
and level SHALL be used.
As an example, consider Figure 1 in section 3.4. The decode time of - Non-B frames (other than the first frame in the coded order):
non-B frame P4 is 4 time units, which is equal to the presentation The decode time SHALL be equal to the presentation time of the
time of the previous non-B frame in the coded order, which is P1. On previous non-B frame in the coded order.
the other hand, the decode time of B-frame B2 is 5 time units, which
is identical to its presentation time. As an example, consider Figure 1 in section 3.4. To determine the
decode time of the first frame, I0, one must first determine the
decode time of the next frame, P1. Because P1 is a non-B frame, its
decode time is equal to the presentation time of I0, which is 3 time
units. Thus, the decode time of I0 must be at least one frame period
less than 3. In this example, the frame period is 1, because one
frame is displayed every time unit. Consequently, the decode time of
I0 is chosen as 2 time units. The decode time of the third frame in
the coded order, P4, is 4, because it must be equal to the
presentation time of the previous non-B frame in the coded order, P1.
On the other hand, the decode time of B-frame B2 is 5 time units,
which is identical to its presentation time.
If the decode time of a video frame differs from its presentation If the decode time of a video frame differs from its presentation
time, then the decode time MUST be specified using the DTS Delta 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 field in the AU header. The syntax of the DTS Delta field is defined
in section 5.2. in section 5.2.
Receivers are not required to use the DTS Delta field. However,
possible uses include buffer management and pacing of frames prior to
decoding. If RTP packets are lost, it is possible to use the DTS
Delta field to determine if the sequence of lost RTP packets
contained reference frames or only B-frames. This can be done by
comparing the decode and presentation times of the first frame
received after the lost sequence against the presentation time of the
last reference frame received prior to the lost sequence.
Knowing if the stream will contain B-pictures may help the receiver 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 SHALL 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:
skipping to change at page 14, line 18 skipping to change at page 14, line 43
the decoder initialization parameters through the coded bit stream. the decoder initialization parameters through the coded bit stream.
Any changes to the decoder initialization parameters would have to be Any changes to the decoder initialization parameters would have to be
done through out-of-band means, e.g., by a SIP [14] re-invite or done through out-of-band means, e.g., by a SIP [14] re-invite or
similar means that convey an updated session description. similar means that convey an updated session description.
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.
The sequence layer header specifies the VC-1 level, the maximum size The sequence layer header specifies the VC-1 level, the maximum size
of the coded pictures and optionally also the maximum frame rate. of the coded frames and optionally also the maximum frame rate. The
The media type parameters "level", "width", "height" and "framerate" media type parameters "level", "width", "height" and "framerate"
specify upper limits for these parameters. Thus, the sequence layer specify upper limits for these parameters. Thus, the sequence layer
header MAY specify values that are lower than the values of the media header MAY specify values that are lower than the values of the media
type parameters "level", "width", "height" or "framerate", but the type parameters "level", "width", "height" or "framerate", but the
sequence layer header MUST NOT exceed the values of any of these sequence layer header MUST NOT exceed the values of any of these
media type parameters. media type parameters.
4.8 The "mode=1" media type 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 media type header never changes. This MAY be signaled with the media type
skipping to change at page 20, line 21 skipping to change at page 20, line 50
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].
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 luma samples maximum horizontal size of the coded frames, in luma samples
(pixels in the luma picture.) (pixels in the luma picture.)
For Simple and Main profiles, the value SHALL be identical to For Simple and Main profiles, the value SHALL be identical to
the actual horizontal size of the coded picture. the actual horizontal size of the coded frames.
For Advanced profile, the value SHALL be greater than, or For Advanced profile, the value SHALL be greater than, or
equal to, the largest horizontal size of the coded picture. equal to, the largest horizontal size of the coded frames.
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 specified profile and maximum horizontal size allowed by the specified profile and
level. level.
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 luma samples maximum vertical size of the coded frames, in luma samples
(pixels in the luma picture.) (pixels in a progressively coded luma picture.)
For Simple and Main profiles, the value SHALL be identical to For Simple and Main profiles, the value SHALL be identical to
the actual vertical size of the coded picture. the actual vertical size of the coded frames.
For Advanced profile, the value SHALL be greater than, or For Advanced profile, the value SHALL be greater than, or
equal to, the largest vertical size of the coded picture. equal to, the largest vertical size of the coded frames.
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 specified profile and maximum vertical size allowed by the specified profile and
level. level.
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,
skipping to change at page 22, line 45 skipping to change at page 23, line 26
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 of RFC XXXX provides "framerate" parameters. Section 6.3 of RFC XXXX provides
specific rules for these parameters are used with the SDP specific rules for these parameters are used with the SDP
Offer/Answer model. Offer/Answer model.
Receivers that signal support for a given profile and level Receivers that signal support for a given profile and level
MUST support the maximum values for these parameters for that MUST support the maximum values for these parameters for that
profile and level. For example, a receiver that indicates profile and level. For example, a receiver that indicates
support for Main profile, Low level, must support a width of support for Main profile, Low level, must support a width of
352 pixels and height of 288 pixels, even if this requires 352 luma samples and a height of 288 luma samples, even if
scaling the image to fit the resolution of a smaller display this requires scaling the image to fit the resolution of a
device. smaller display device.
A receiver MAY use any of the max-width, max-height, max- A receiver MAY use any of the max-width, max-height, max-
bitrate, max-buffer and max-framerate parameters to indicate bitrate, max-buffer and max-framerate parameters to indicate
preferred capabilities. For example, a receiver may choose preferred capabilities. For example, a receiver may choose
to specify values for max-width and max-height that match the to specify values for max-width and max-height that match the
resolution of its display device, since a bit stream encoded resolution of its display device, since a bit stream encoded
using those parameters would not need to be rescaled. using those parameters would not need to be rescaled.
If any of the max-width, max-height, max-bitrate, max-buffer If any of the max-width, max-height, max-bitrate, max-buffer
and max-framerate parameters signal a capability that is less and max-framerate parameters signal a capability that is less
skipping to change at page 23, line 36 skipping to change at page 24, line 17
the VC-1 profile than the one specified in the "level" the VC-1 profile than the one specified in the "level"
parameter, if the sender or receiver can support all the parameter, if the sender or receiver can support all the
properties of the higher level, except if specifying a higher properties of the higher level, except if specifying a higher
level is not allowed due to other restrictions. (As an level is not allowed due to other restrictions. (As an
example of such a restriction, in the SDP Offer/Answer model, example of such a restriction, in the SDP Offer/Answer model,
the value of the level parameter that can be used in an the value of the level parameter that can be used in 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 luma samples horizontal size for the coded frames, in luma samples (pixels
(pixels in the luma picture.) If the value is less than the in the luma picture.) If the value is less than the maximum
maximum horizontal size allowed by the profile and level, horizontal size allowed by the profile and level, then the
then the value specifies the preferred horizontal size. value specifies the preferred horizontal size. Otherwise, it
Otherwise, it specifies the maximum horizontal size that is specifies the maximum horizontal size 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 horizontal size allowed by the specified profile and maximum horizontal size allowed by the specified profile and
level. 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 luma samples (pixels vertical size for the coded frames, in luma samples (pixels
in the luma picture.) If the value is less than the maximum in a progressively coded luma picture.) If the value is less
vertical size allowed by the profile and level, then the than the maximum vertical size allowed by the profile and
value specifies the preferred vertical size. Otherwise, it level, then the value specifies the preferred vertical size.
specifies the maximum vertical size that is supported. Otherwise, it specifies the maximum vertical 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 vertical size allowed by the specified profile and maximum vertical size allowed by the specified profile and
level. 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,
skipping to change at page 30, line 24 skipping to change at page 31, line 5
Congestion control for RTP SHALL be used in accordance with RFC 3550 Congestion control for RTP SHALL be used in accordance with RFC 3550
[3], and with any applicable RTP profile; e.g., RFC 3551 [15]. [3], and with any applicable RTP profile; e.g., RFC 3551 [15].
If best-effort service is being used, users of this payload format If best-effort service is being used, users of this payload format
MUST monitor packet loss to ensure that the packet loss rate is MUST monitor packet loss to ensure that the packet loss rate is
within acceptable parameters. Packet loss is considered acceptable within acceptable parameters. Packet loss is considered acceptable
if a TCP flow across the same network path, and experiencing the same if a TCP flow across the same network path, and experiencing the same
network conditions, would achieve an average throughput, measured on network conditions, would achieve an average throughput, measured on
a reasonable timescale, that is not less than the RTP flow is a reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate (or the congestion control mechanisms to adapt the transmission rate or by
number of layers subscribed for a layered multicast session), or by
arranging for a receiver to leave the session if the loss rate is arranging for a receiver to leave the session if the loss rate is
unacceptably high. unacceptably high.
The bit rate adaptation necessary for obeying the congestion control The bit rate adaptation necessary for obeying the congestion control
principle is easily achievable when real-time encoding is used. When principle is easily achievable when real-time encoding is used. When
pre-encoded content is being transmitted, bandwidth adaptation pre-encoded content is being transmitted, bandwidth adaptation
requires one or more of the following: requires one or more of the following:
- The availability of more than one coded representation of the same - The availability of more than one coded representation of the same
content at different bit rates. The switching between the content at different bit rates. The switching between the
different representations can normally be performed in the same different representations can normally be performed in the same
RTP session, by switching streams at random access point RTP session, by switching streams at random access point
boundaries. boundaries.
- The existence of non-reference frames (e.g., B-frames) in the bit - The existence of non-reference frames (e.g., B-frames) in the bit
stream. Non-reference frames can be discarded by the transmitter stream. Non-reference frames can be discarded by the transmitter
prior to encapsulation in RTP. If the frames contain the TFCNTR prior to encapsulation in RTP.
(Temporal Reference Frame Counter) syntax element, it will require
updating the TFCNTR fields of other frames to ensure that the
field remains continuous. Because TFCNTR counts the frames in the
display order, which is different from the order in which they are
transmitted (the coded order), it will require the transmitter to
"look ahead", or buffer, of some number of frames.
Only when non-downgradable parameters (such as the VC-1 "profile" Only when non-downgradable parameters (such as the VC-1 "profile"
parameter) are required to be changed does it become necessary to parameter) are required to be changed does it become necessary to
terminate and re-start the media stream. This may be accomplished by terminate and re-start the media stream. This may be accomplished by
using a different RTP payload type. using a different RTP payload type.
Regardless of the method used for bandwidth adaptation, the resulting
bit stream MUST be compliant with the VC-1 specification [1]. For
example, if non-reference frames are discarded, then the FRMCNT
syntax element (Simple and Main profile frames only) and the optional
TFCNTR syntax element (Advanced profile frames only) must increment
as if no frames had been discarded. Because the TFCNTR syntax
element counts the frames in the display order, which is different
from the order in which they are transmitted (the coded order), it
will require the transmitter to "look ahead", or buffer, of some
number of frames.
As another example, when switching between different representations
of the same content, it may be necessary to signal a discontinuity by
modifying the FRMCNT field, or if Advanced profile is used, by
setting the BROKEN_LINK flag in the entry-point header to 1.
This payload format may also be used in networks that provide This payload format may also be used in networks that provide
quality-of-service guarantees. If enhanced service is being used, quality-of-service guarantees. If enhanced service is being used,
receivers SHOULD monitor packet loss to ensure that the service that receivers SHOULD monitor packet loss to ensure that the service that
was requested is actually being delivered. If it is not, then they was requested is actually being delivered. If it is not, then they
SHOULD assume that they are receiving best-effort service and behave SHOULD assume that they are receiving best-effort service and behave
accordingly. accordingly.
9. IANA Considerations 9. IANA Considerations
IANA is requested to register the media type "video/vc1" and the IANA is requested to register the media type "video/vc1" and the
 End of changes. 22 change blocks. 
81 lines changed or deleted 117 lines changed or added

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