value of this parameter MUST NOT be changed by the answerer.
Thus, a payload type can be either accepted unaltered or removed.
o The parameters "config", "bpic", "width", "height", "framerate",
"bitrate", "buffer", and "mode", specify properties of the VC-1
bit stream that will be sent and/or received on the multicast
session. The parameters MAY be specified, even if the direction
attribute is recvonly.
The values of these parameters MUST NOT be changed by the
answerer. Thus, a payload type can be either accepted unaltered
or removed.
o The values of the parameters "max-width", "max-height", "max-
framerate", "max-bitrate", and "max-buffer" MUST be supported by
the answerer for all streams declared as sendrecv or recvonly.
Otherwise, one of the following actions MUST be performed: the
media format is removed or the session is rejected.
6.4. Usage in Declarative Session Descriptions
When VC-1 is offered over RTP using SDP in a declarative style, as in
RTSP [12] or SAP [13], the following rules and limitations apply:
o The parameters "profile" and "level" indicate only the properties
of the coded bit stream. They do not imply a limit on
capabilities supported by the sender.
o The parameters "config", "width", "height", "bitrate", and
"buffer" MUST be specified.
o The parameters "max-width", "max-height", "max-framerate", "max-
bitrate", and "max-buffer" MUST NOT be used.
An example of media representation in SDP is as follows (Simple
profile, Medium level):
m=video 49170 RTP/AVP 98
a=rtpmap:98 vc1/90000
a=fmtp:98 profile=0;level=2;width=352;height=288;framerate=15000;
bitrate=384000;buffer=2000;config=4e291800
7. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [4], and in any appropriate RTP profile. This implies
that confidentiality of the media streams is achieved by encryption;
for example, through the application of SRTP [11].
A potential denial-of-service threat exists for data encodings using
compression techniques that have non-uniform receiver-end
computational load. The attacker can inject pathological RTP packets
into the stream that are complex to decode and that cause the
receiver to be overloaded. VC-1 is particularly vulnerable to such
attacks, because it is possible for an attacker to generate RTP
packets containing frames that affect the decoding process of many
future frames. Therefore, the usage of data origin authentication
and data integrity protection of at least the RTP packet is
RECOMMENDED; for example, with SRTP [11].
Note that the appropriate mechanism to ensure confidentiality and
integrity of RTP packets and their payloads is dependent on the
application and on the transport and signaling protocols employed.
Thus, although SRTP is given as an example above, other possible
choices exist.
VC-1 bit streams can carry user-data, such as closed captioning
information and content meta-data. The VC-1 specification does not
define how to interpret user-data. Identifiers for user-data are
required to be registered with SMPTE. It is conceivable for types of
user-data to be defined to include programmatic content, such as
scripts or commands that would be executed by the receiver.
Depending on the type of user-data, it might be possible for a sender
to generate user-data in a non-compliant manner to crash the receiver
or make it temporarily unavailable. Senders that transport VC-1 bit
streams SHOULD ensure that the user-data is compliant with the
specification registered with SMPTE (see Annex F of [1].) Receivers
SHOULD prevent malfunction in case of non-compliant user-data.
It is important to note that VC-1 streams can have very high
bandwidth requirements (up to 135 Mbps for high-definition video).
This causes a potential for denial-of-service if transmitted onto
many Internet paths. Therefore, users of this payload format MUST
comply with the congestion control requirements described in section
8.
8. Congestion Control
Congestion control for RTP SHALL be used in accordance with RFC 3550
[3], and with any applicable RTP profile; e.g., RFC 3551 [15].
If best-effort service is being used, users of this payload format
MUST monitor packet loss to ensure that the packet loss rate is
within acceptable parameters. Packet loss is considered acceptable
if a TCP flow across the same network path and experiencing the same
network conditions would achieve an average throughput, measured on a
reasonable timescale, that is not less than the RTP flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission rate or by
arranging for a receiver to leave the session if the loss rate is
unacceptably high.
The bit rate adaptation necessary for obeying the congestion control
principle is easily achievable when real-time encoding is used. When
pre-encoded content is being transmitted, bandwidth adaptation
requires one or more of the following:
- The availability of more than one coded representation of the same
content at different bit rates. The switching between the
different representations can normally be performed in the same
RTP session by switching streams at random access point
boundaries.
- The existence of non-reference frames (e.g., B-frames) in the bit
stream. Non-reference frames can be discarded by the transmitter
prior to encapsulation in RTP.
Only when non-downgradable parameters (such as the VC-1 "profile"
parameter) are required to be changed does it become necessary to
terminate and re-start the media stream. This may be accomplished by
using a different RTP payload type.
Regardless of the method used for bandwidth adaptation, the resulting
bit stream MUST be compliant with the VC-1 specification [1]. For
example, if non-reference frames are discarded, then the FRMCNT
syntax element (Simple and Main profile frames only) and the optional
TFCNTR syntax element (Advanced profile frames only) must increment
as if no frames had been discarded. Because the TFCNTR syntax
element counts the frames in the display order, which is different
from the order in which they are transmitted (the coded order), it
will require the transmitter to "look ahead" or buffer some number of
frames.
As another example, when switching between different representations
of the same content, it may be necessary to signal a discontinuity by
modifying the FRMCNT field, or if Advanced profile is used, by
setting the BROKEN_LINK flag in the entry-point header to 1.
This payload format may also be used in networks that provide
quality-of-service guarantees. If enhanced service is being used,
receivers SHOULD monitor packet loss to ensure that the service that
was requested is actually being delivered. If it is not, then they
SHOULD assume that they are receiving best-effort service and behave
accordingly.
9. IANA Considerations
IANA has registered the media type "video/vc1" and the associated RTP
payload format in the Media Types registry and in the RTP Payload
Format MIME types registry, as specified in section 6.1.
10. References
10.1. Normative References
[1] Society of Motion Picture and Television Engineers, "VC-1
Compressed Video Bitstream Format and Decoding Process", SMPTE
421M.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[6] Josefsson, S., Ed., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Casner, S. and P. Hoschka, "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003.
10.2. Informative References
[9] Srinivasan, S., Hsu, P., Holcomb, T., Mukerjee, K., Regunathan,
S.L., Lin, B., Liang, J., Lee, M., and J. Ribas-Corbera,
"Windows Media Video 9: overview and applications", Signal
Processing: Image Communication, Volume 19, Issue 9, October
2004.
[10] Ribas-Corbera, J., Chou, P.A., and S.L. Regunathan, "A
generalized hypothetical reference decoder for H.264/AVC", IEEE
Transactions on Circuits and Systems for Video Technology,
August 2003.
[11] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
[12] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
[13] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[14] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[15] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
Acknowledgements
Thanks to Regis Crinon, Miska Hannuksela, Colin Perkins, Shankar
Regunathan, Gary Sullivan, Stephan Wenger, and Magnus Westerlund for
providing detailed feedback on this document.
Author’s Address
Anders Klemets
Microsoft Corp.
1 Microsoft Way
Redmond, WA 98052
USA
EMail: Anders.Klemets@microsoft.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).