represent octet count and number of packets lost since the beginning
of transmission, as defined in RFC 3550. Therefore, for network
monitoring purposes, other means of keeping track of these variables
SHOULD be used.
6. IANA Considerations
The IANA has registered one new MIME subtype along with an associated
RTP Payload Format, and has created two sub-parameter registries, as
described in the following.
6.1. MIME type registration
MIME media type name: video
MIME subtype name: raw
Required parameters:
rate: The RTP timestamp clock rate. Applications using this
payload format SHOULD use a value of 90000.
sampling: Determines the color (sub-)sampling mode of the video
stream. Currently defined values are RGB, RGBA, BGR, BGRA,
YCbCr-4:4:4, YCbCr-4:2:2, YCbCr-4:2:0, and YCbCr-4:1:1. New values
may be registered as described in section 6.2 of RFC 4175.
width: Determines the number of pixels per line. This is an
integer between 1 and 32767.
height: Determines the number of lines per frame. This is an
integer between 1 and 32767.
depth: Determines the number of bits per sample. This is an
integer with typical values including 8, 10, 12, and 16.
colorimetry: This parameter defines the set of colorimetric
specifications and other transfer characteristics for the video
source, by reference to an external specification. Valid values
and their specification are:
BT601-5 ITU Recommendation BT.601-5 [601]
BT709-2 ITU Recommendation BT.709-2 [709]
SMPTE240M SMPTE standard 240M [240]
New values may be registered as described in section 6.2 of RFC
4175.
Optional parameters:
Interlace: If this OPTIONAL parameter is present, it indicates that
the video stream is interlaced. If absent, progressive scan is
implied.
Top-field-first: If this OPTIONAL parameter is present, it
indicates that chrominance samples are packetized starting with the
first line of field 0. Its absence implies that chrominance
samples are packetized starting with the first line of field 1.
chroma-position: This OPTIONAL parameter defines the position of
chrominance samples relative to luminance samples. It is either a
single integer or a comma separated pair of integers. Integer
values range from 0 to 8, as specified in Figures 6-8 of RFC 4175.
A single integer implies that Cb and Cr are co-sited. A comma
separated pair of integers designates the locations of Cb and Cr
samples, respectively. In its absence, a single value of zero is
assumed for color-subsampled video (chroma-position=0).
gamma: An OPTIONAL floating point gamma correction value.
Encoding considerations:
Uncompressed video is only transmitted over RTP as specified in RFC
4175. No file format media type has been defined to go with this
transmission media type at this time.
Security considerations: See section 9 of RFC 4175.
Interoperability considerations: NONE.
Published specification: RFC 4175.
Applications which use this media type: Video communication.
Additional information: None
Person & email address to contact for further information:
Ladan Gharai <ladan@isi.edu>
IETF Audio/Video Transport working group.
Intended usage: COMMON
Author: Ladan Gharai <ladan@isi.edu>
Change controller: IETF AVT Working Group
delegated from the IESG
6.2. Parameter Registration
New values of the "sampling" parameter MAY be registered with the
IANA provided they reference an RFC or other permanent and readily
available specification (the Specification Required policy of RFC
2434 [2434]). A new registration MUST define the packing order of
samples and a valid combinations of color and sub-sampling modes.
New values of the "colorimetry" parameter MAY be registered with the
IANA provided they reference an RFC or other permanent and readily
available specification if colorimetric parameters and other
applicable transfer characteristics (the Specification Required
policy of RFC 2434 [2434]).
7. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[SDP], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions transporting uncompressed video, the mapping
is as follows:
- The MIME type ("video") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP "a=rtpmap" as
the encoding name.
- Remaining parameters go in the SDP "a=fmtp" attribute by copying
them directly from the MIME media type string as a semicolon-
separated list of parameter=value pairs.
A sample SDP mapping for uncompressed video is as follows:
m=video 30000 RTP/AVP 112
a=rtpmap:112 raw/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
colorimetry=BT.709-2; chroma-position=1
In this example, a dynamic payload type 112 is used for uncompressed
video. The RTP sampling clock is 90 kHz. Note that the "a=fmtp:"
line has been wrapped to fit this page, and will be a single long
line in the SDP file.
8. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [RTP] and any appropriate RTP profile. This implies
that confidentiality of the media streams is achieved by encryption.
This payload type does not exhibit any significant non-uniformity in
the receiver side computational complexity for packet processing to
cause a potential denial-of-service threat.
It is important to note that uncompressed video can have immense
bandwidth requirements (up to 270 Mbps for standard-definition video,
and approximately 1 Gbps for high-definition video). This is
sufficient to cause potential for denial-of-service if transmitted
onto most currently available Internet paths.
Accordingly, 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 the number of layers subscribed for a layered multicast
session), or by arranging for a receiver to leave the session if the
loss rate is unacceptably high.
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. Relation to RFC 2431
In comparison with RFC 2431, this memo specifies support for a wider
variety of uncompressed video, in terms of frame size, color sub-
sampling and sample sizes. Although [BT656] can transport up to 4096
scan lines and 2048 pixels per line, our payload type can support up
to 32768 scan lines and pixels per line. Also, RFC 2431 only address
4:2:2 YCbCr data, while this memo covers YCbCr, RGB, RGBA, BGR, BGRA,
and most common color sub-sampling schemes. Given the variety of
video types that we cover, this memo also assumes out-of-band
signaling for sample size and data types (RFC 2431 uses in band
signaling).
10. Relation to RFC 3497
RFC 3497 [292RTP] specifies a RTP payload format for encapsulating
SMPTE 292M video. The SMPTE 292M standard defines a bit-serial
digital interface for local area High-Definition Television (HDTV)
transport. As a transport medium, SMPTE 292M utilizes 10-bit words
and a fixed 1.485 Gbps (and 1.485/1.001 Gbps) data rate. SMPTE 292M
is typically used in the broadcast industry for the transport of
other video formats such as SMPTE 260M, SMPTE 295M, SMPTE 274M, and
SMPTE 296M.
RFC 3497 defines a circuit emulation for the transport of SMPTE 292M
over RTP. It is very specific to SMPTE 292 and has been designed to
be interoperable with existing broadcast equipment with a constant
rate of 1.485 Gbps.
This memo defines a flexible native packetization scheme that can
packetize any uncompressed video, at varying data rates. In
addition, unlike RFC 3497, this memo only transports active video
pixels (i.e., horizontal and vertical blanking are not transported).
11. Acknowledgements
The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan
Wenger, and Dave Singer for their feedback.
This memo is based upon work supported by the U.S. National Science
Foundation (NSF) under Grant No. 0230738. Any opinions, findings,
and conclusions or recommendations expressed in this material are
those of the authors and do not necessarily reflect the views of NSF.
Normative References
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD
64, RFC 3550, July 2003.
[2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[601] International Telecommunication Union, "Studio encoding
parameters of digital television for standard 4:3 and wide
screen 16:9 aspect ratios", Recommendation BT.601, October
1995.
[709] International Telecommunication Union, "Parameter Values for
HDTV Standards for Production and International Programme
Exchange", Recommendation BT.709-2
[240] Society of Motion Picture and Television Engineers,
"Television - Signal Parameters - 1125-Line High-Definition
Production", SMPTE 240M-1999.
Informative References
[274] Society of Motion Picture and Television Engineers,
"1920x1080 Scanning and Analog and Parallel Digital
Interfaces for Multiple Picture Rates", SMPTE 274M-1998.
[296] Society of Motion Picture and Television Engineers,
"1280x720 Scanning, Analog and Digital Representation and
Analog Interfaces", SMPTE 296M-1998.
[372] Society of Motion Picture and Television Engineers, "Dual
Link 292M Interface for 1920 x 1080 Picture Raster", SMPTE
372M-2002.
[ALF] Clark, D. D., and Tennenhouse, D. L., "Architectural
Considerations for a New Generation of Protocols", In
Proceedings of SIGCOMM ’90 (Philadelphia, PA, Sept. 1990),
ACM.
[SDP] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[BT656] Tynan, D., "RTP Payload Format for BT.656 Video Encoding",
RFC 2431, October 1998.
[292RTP] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP
Payload Format for Society of Motion Picture and Television
Engineers (SMPTE) 292M Video", RFC 3497, March 2003.
[656] International Telecommunication Union, "Interfaces for
Digital Component Video Signals in 525-line and 625-line
Television Systems Operating at the 4:2:2 Level of
Recommendation ITU-R BT.601 (Part A)", Recommendation
BT.656, April 1998.
Authors’ Addresses
Ladan Gharai
USC Information Sciences Institute
3811 N. Fairfax Drive, #200
Arlington, VA 22203
USA
EMail: ladan@isi.edu
Colin Perkins
University of Glasgow
Department of Computing Science
17 Lilybank Gardens
Glasgow G12 8QQ
United Kingdom
EMail: csp@csperkins.org
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 currently provided by the
Internet Society.