draft-ietf-avt-uncomp-video-04.txt   draft-ietf-avt-uncomp-video-05.txt 
Internet Engineering Task Force AVT WG Internet Engineering Task Force AVT WG
INTERNET-DRAFT Ladan Gharai INTERNET-DRAFT Ladan Gharai
draft-ietf-avt-uncomp-video-04.txt USC/ISI draft-ietf-avt-uncomp-video-05.txt USC/ISI
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
26 October 2003 27 January 2004
RTP Payload Format for Uncompressed Video RTP Payload Format for Uncompressed Video
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 31 skipping to change at page 1, line 32
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This memo specifies a packetization scheme for encapsulating This memo specifies a packetization scheme for encapsulating
uncompressed video into a payload format for the Real-time uncompressed video into a payload format for the Real-time Transport
Transport Protocol, RTP. It supports a range of standard- and Protocol, RTP. It supports a range of standard- and high-definition
high-definition video formats, including common television video formats, including common television formats such as ITU
formats such as ITU BT.601, and standards from the Society of BT.601, and standards from the Society of Motion Picture and
Motion Picture and Television Engineers (SMPTE), such as SMPTE Television Engineers (SMPTE), such as SMPTE 274M and SMPTE 296M. The
274M and SMPTE 296M. The format is designed to be applicable format is designed to be applicable and extensible to new video
and extensible to new video formats as they are developed. formats as they are developed.
1. Introduction 1. Introduction
[Note to RFC Editor: All references to RFC XXXX are to be replaced [Note to RFC Editor: All references to RFC XXXX are to be replaced
with the RFC number of this memo, when published] with the RFC number of this memo, when published]
This memo defines a scheme to packetize uncompressed, studio-quality, This memo defines a scheme to packetize uncompressed, studio-quality,
video streams for transport using RTP [RTP]. It supports a range of video streams for transport using RTP [RTP]. It supports a range of
standard and high definition video formats, including ITU-R BT.601 standard and high definition video formats, including ITU-R BT.601
[601], SMPTE 274M [274] and SMPTE 296M [296]. [601], SMPTE 274M [274] and SMPTE 296M [296].
skipping to change at page 4, line 34 skipping to change at page 4, line 34
samples are only shared within the grouping. When packetizing digital samples are only shared within the grouping. When packetizing digital
active line content, video data MUST NOT be fragmented within a active line content, video data MUST NOT be fragmented within a
pgroup. pgroup.
Video content is almost always associated with additional information Video content is almost always associated with additional information
such as audio tracks, time code, etc. In professional digital video such as audio tracks, time code, etc. In professional digital video
applications this data is commonly embedded in non-active portions of applications this data is commonly embedded in non-active portions of
the video stream (horizontal and vertical blanking periods) so that the video stream (horizontal and vertical blanking periods) so that
precise and robust synchronization is maintained. This payload format precise and robust synchronization is maintained. This payload format
requires that applications using such synchronized ancillary data requires that applications using such synchronized ancillary data
MUST deliver it in separate RTP sessions which operate concurrently SHOULD deliver it in separate RTP sessions which operate concurrently
with the video session. The normal RTP mechanisms SHOULD be used to with the video session. The normal RTP mechanisms SHOULD be used to
synchronize the media. synchronize the media.
4. RTP Packetization 4. RTP Packetization
The standard RTP header is followed by a 2 octet payload header that The standard RTP header is followed by a 2 octet payload header that
extends the RTP Sequence Number, and by a 6 octet payload header for extends the RTP Sequence Number, and by a 6 octet payload header for
each line (or partial line) of video included. One or more lines, or each line (or partial line) of video included. One or more lines, or
partial lines, of video data follow. This format makes the payload partial lines, of video data follow. This format makes the payload
header 32 bit aligned in the common case, where one scan line (or header 32 bit aligned in the common case, where one scan line (or
skipping to change at page 6, line 9 skipping to change at page 6, line 9
For interlaced video, the timestamp denotes the sampling instant of For interlaced video, the timestamp denotes the sampling instant of
the field to which the RTP packet belongs. Packets MUST NOT the field to which the RTP packet belongs. Packets MUST NOT
include data from multiple fields, and all packets belonging to the include data from multiple fields, and all packets belonging to the
same field MUST have the same timestamp. Use of field timestamps, same field MUST have the same timestamp. Use of field timestamps,
rather than a frame timestamp and field indicator bit, is needed to rather than a frame timestamp and field indicator bit, is needed to
support reverse 3-2 pulldown. support reverse 3-2 pulldown.
A 90 kHz timestamp SHOULD be used in both cases. If the sampling A 90 kHz timestamp SHOULD be used in both cases. If the sampling
instant does not correspond to an integer value of the clock (as instant does not correspond to an integer value of the clock (as
may be the case when interleaving) the value SHALL be truncated to may be the case when interleaving) the value SHALL be truncated to
the next lowest integer, with no loss of information. the next lowest integer, with no ambiguity.
Marker bit (M): 1 bit Marker bit (M): 1 bit
If progressive scan video is being transmitted, the marker bit If progressive scan video is being transmitted, the marker bit
denotes the end of a video frame. If interlaced video is being denotes the end of a video frame. If interlaced video is being
transmitted, it denotes the end of the field. The marker bit MUST transmitted, it denotes the end of the field. The marker bit MUST
be set to 1 for the last packet of the video frame/field. It MUST be set to 1 for the last packet of the video frame/field. It MUST
be set to 0 for other packets. be set to 0 for other packets.
Sequence Number: 16 bits Sequence Number: 16 bits
skipping to change at page 9, line 42 skipping to change at page 9, line 42
line 4/5: line 4/5:
Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21 Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21
Y44-Y45-Y54-Y55-Cb22-Cr22 Y44-Y45-Y54-Y55-Cb22-Cr22
Figure 3: Packetization of progressive 4:2:0 YCbCr video Figure 3: Packetization of progressive 4:2:0 YCbCr video
For interlaced transport chrominance samples are transported with For interlaced transport chrominance samples are transported with
every other line. The first set of chrominance samples may be every other line. The first set of chrominance samples may be
transported with either the first line of the field 0, or the first transported with either the first line of the field 0, or the first
line of field 1. The example below illustrates the transport of line of field 1. The example below illustrates the transport of
chrominance samples starting with the first line of field 0. chrominance samples starting with the first line of field 0 (signaled
by the "top-field-first" MIME parameter).
field 0: field 0:
line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02 line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02
line 2: Y20-Y21 Y22-Y23 Y24-Y25 line 2: Y20-Y21 Y22-Y23 Y24-Y25
line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22 line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22
field 1: field 1:
line 1: Y10-Y11 Y12-Y13 Y14-Y15 line 1: Y10-Y11 Y12-Y13 Y14-Y15
line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12 line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12
line 5: Y50-Y51 Y52-Y53 Y54-Y55 line 5: Y50-Y51 Y52-Y53 Y54-Y55
Figure 4: Packetization of interlaced 4:2:0 YCbCr video with Figure 4: Packetization of interlaced 4:2:0 YCbCr video with
top-field-first. top-field-first.
Chrominance values may be sampled with different offsets relative to Chrominance values may be sampled with different offsets relative to
luminance values. For instance, in Figure 2, chrominance values are luminance values. For instance, in Figure 2, chrominance values are
sample at the same distance from neighboring luminance samples. It is sampled at the same distance from neighboring luminance samples. It
also possible for a chrominance sample to be co-sited with a is also possible for a chrominance sample to be co-sited with a
luminance sample, as in Figure 5: luminance sample, as in Figure 5:
line 0: Y00-C Y01 Y02-C Y03 Y04-C Y05 line 0: Y00-C Y01 Y02-C Y03 Y04-C Y05
line 1: Y10 Y11 Y12 Y13 Y14 Y15 line 1: Y10 Y11 Y12 Y13 Y14 Y15
line 2: Y20-C Y21 Y22-C Y23 Y24-C Y25 line 2: Y20-C Y21 Y22-C Y23 Y24-C Y25
line 3: Y30 Y31 Y32 Y33 Y34 Y35 line 3: Y30 Y31 Y32 Y33 Y34 Y35
line 4: Y40-C Y41 Y42-C Y43 Y44-C Y45 line 4: Y40-C Y41 Y42-C Y43 Y44-C Y45
line 5: Y50 Y51 Y52 Y53 Y54 Y55 line 5: Y50 Y51 Y52 Y53 Y54 Y55
Figure 5: Co-sited video sampling in 4:2:0 YCbCr video where C Figure 5: Co-sited video sampling in 4:2:0 YCbCr video where C
designates a CbCr pair designates a CbCr pair
In general chrominance values may be place in between luminance In general chrominance values may be placed between luminance samples
samples or co-sited. Positions can be designated by an integer or co-sited. Positions can be designated by an integer numbering
numbering system starting from left to right and top to bottom. The system starting from left to right and top to bottom. The following
following position matrices apply for 4:2:0, 4:2:2 and 4:1:1 video: position matrices apply for 4:2:0, 4:2:2 and 4:1:1 video:
line N: Y[0] [1] Y[2] Y[0] [1] Y[2] line N: Y[0] [1] Y[2] Y[0] [1] Y[2]
[3] [4] Y[5] [3] [4] [5] [3] [4] Y[5] [3] [4] [5]
line N+1: Y[6] [7] Y[8] Y[6] [7] Y[8] line N+1: Y[6] [7] Y[8] Y[6] [7] Y[8]
Figure 6: Chrominance position matrix for 4:2:0 YCbCr video Figure 6: Chrominance position matrix for 4:2:0 YCbCr video
line N: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3] line N: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3]
line N+1: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3] line N+1: Y[0] [1] Y[2] [3] Y[0] [1] Y[2] [3]
skipping to change at page 11, line 38 skipping to change at page 11, line 38
RTCP SHOULD be used as specified in RFC3550 [RTP]. It is to be noted RTCP SHOULD be used as specified in RFC3550 [RTP]. It is to be noted
that the sender's octet count in SR packets and the cumulative number that the sender's octet count in SR packets and the cumulative number
of packets lost will wrap around quickly for high data rate streams. of packets lost will wrap around quickly for high data rate streams.
This means these two fields may not accurately represent octet count This means these two fields may not accurately represent octet count
and number of packets lost since the beginning of transmission, as and number of packets lost since the beginning of transmission, as
defined in RFC 3550. Therefore for network monitoring purposes other defined in RFC 3550. Therefore for network monitoring purposes other
means of keeping track of these variables SHOULD be used. means of keeping track of these variables SHOULD be used.
6. IANA Considerations 6. IANA Considerations
The IANA is requested to register one new MIME subtype and associated The IANA is requested to register one new MIME subtype along with an
RTP Payload Format, as described in the following. associated RTP Payload Format, and to create two sub-parameter
registries, as described in the following.
6.1. MIME type registration 6.1. MIME type registration
MIME media type name: video MIME media type name: video
MIME subtype name: raw MIME subtype name: raw
Required parameters: Required parameters:
rate: The RTP timestamp clock rate. Applications using this payload rate: The RTP timestamp clock rate. Applications using this payload
skipping to change at page 12, line 42 skipping to change at page 12, line 42
source, by reference to an external specification. Valid values and source, by reference to an external specification. Valid values and
their specification are: their specification are:
BT601-5 ITU Recommendation BT.601-5 [601] BT601-5 ITU Recommendation BT.601-5 [601]
BT709-2 ITU Recommendation BT.709-2 [709] BT709-2 ITU Recommendation BT.709-2 [709]
SMPTE240M SMPTE standard 240M [240] SMPTE240M SMPTE standard 240M [240]
New values may be registered as described in section 6.2 of RFC New values may be registered as described in section 6.2 of RFC
XXXX. XXXX.
chroma-position: This 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 valuess
range from 0 to 8, as specified in Figures 6-8 of RFC XXXX. 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.
Optional parameters: Optional parameters:
Interlace: If this OPTIONAL parameter is present, it indicates that Interlace: If this OPTIONAL parameter is present, it indicates that
the video stream is interlaced. If absent, progressive scan is the video stream is interlaced. If absent, progressive scan is
implied. implied.
Top-field-first: If this OPTIONAL parameter is present, it Top-field-first: If this OPTIONAL parameter is present, it
indicates that chrominance samples are packetized starting with the indicates that chrominance samples are packetized starting with the
first line of field 0. Its absence implies that chrominance samples first line of field 0. Its absence implies that chrominance samples
are packetized starting with the first line of field 1. 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 XXXX.
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: Encoding considerations:
Uncompressed video can be transmitted with RTP as specified in RFC Uncompressed video can be transmitted with RTP as specified in RFC
XXXX. No file format is defined at this time. XXXX. No file format is defined at this time.
Security considerations: See section 9 of RFC XXXX. Security considerations: See section 9 of RFC XXXX.
Interoperability considerations: NONE. Interoperability considerations: NONE.
Published specification: RFC XXXX. Published specification: RFC XXXX.
skipping to change at page 14, line 12 skipping to change at page 14, line 13
available specification (the Specification Required policy of RFC available specification (the Specification Required policy of RFC
2434 [2434]). A new registration MUST define the packing order of 2434 [2434]). A new registration MUST define the packing order of
samples and a valid combinations of color and sub-sampling modes. samples and a valid combinations of color and sub-sampling modes.
New values of the "colorimetry" parameter MAY be registered with the New values of the "colorimetry" parameter MAY be registered with the
IANA provided they reference an RFC or other permanent and readily IANA provided they reference an RFC or other permanent and readily
available specification if colorimetric parameters and other available specification if colorimetric parameters and other
applicable transfer characteristics (the Specification Required applicable transfer characteristics (the Specification Required
policy of RFC 2434 [2434]). policy of RFC 2434 [2434]).
7. Mapping to SDP Parameters 7. Mapping MIME Parameters into SDP
Parameters are mapped to SDP [SDP] as in the following example: 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 m=video 30000 RTP/AVP 112
a=rtpmap:112 raw/90000 a=rtpmap:112 raw/90000
a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10; a=fmtp:112 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10;
colorimetry=BT.709-2; chroma-position=1 colorimetry=BT.709-2; chroma-position=1
In this example, a dynamic payload type 112 is used for uncompressed In this example, a dynamic payload type 112 is used for uncompressed
video. The RTP sampling clock is 90kHz. Note that the "a=fmtp:" line video. The RTP sampling clock is 90kHz. Note that the "a=fmtp:" line
has been wrapped to fit this page, and will be a single long line in has been wrapped to fit this page, and will be a single long line in
the SDP file. the SDP file.
8. Security Considerations 8. 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, and any appropriate RTP profile. This implies that specification [RTP] and any appropriate RTP profile. This implies
confidentiality of the media streams is achieved by encryption. that confidentiality of the media streams is achieved by encryption.
This payload type does not exhibit any significant non-uniformity in This payload type does not exhibit any significant non-uniformity in
the receiver side computational complexity for packet processing to the receiver side computational complexity for packet processing to
cause a potential denial-of-service threat. cause a potential denial-of-service threat.
It is important to be note that uncompressed video can have immense It is important to be note that uncompressed video can have immense
bandwidth requirements (up 270 Mbps for standard definition video, bandwidth requirements (up 270 Mbps for standard definition video,
and approximately 1 Gbps for high definition video). This is and approximately 1 Gbps for high definition video). This is
sufficient to cause potential for denial-of-service if transmitted sufficient to cause potential for denial-of-service if transmitted
onto most currently available Internet paths. onto most currently available Internet paths.
skipping to change at page 16, line 5 skipping to change at page 16, line 21
RFC 3497 defines a circuit emulation for the transport of SMPTE 292M 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 over RTP. It is very specific to SMPTE 292 and has been designed to
be interoperable with existing broadcast equipment with a constant be interoperable with existing broadcast equipment with a constant
rate of 1.485Gbps. rate of 1.485Gbps.
This memo defines a flexible native packetization scheme which can This memo defines a flexible native packetization scheme which can
packetize any uncompressed video, at varying data rates. In addition, packetize any uncompressed video, at varying data rates. In addition,
unlike RFC 3497, this memo only transports active video pixels (i.e. unlike RFC 3497, this memo only transports active video pixels (i.e.
horizontal and vertical blanking are not transported). horizontal and vertical blanking are not transported).
11. Full Copyright Statement 11. Acknowledgments
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
12. Acknowledgments
The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan The authors are grateful to Philippe Gentric, Chuck Harrison, Stephan
Wenger and Dave Singer for their feedback. Wenger and Dave Singer for their feedback.
This work is based upon work supported by the National Science This memo is based upon work supported by the U.S. National Science
Foundation (NSF) under Grant No. 0230738. Any opinions, findings and Foundation (NSF) under Grant No. 0230738. Any opinions, findings and
conclusions or recommendations expressed in this material are those conclusions or recommendations expressed in this material are those
of the authors and do not necessarily reflect the views of NSF. of the authors and do not necessarily reflect the views of NSF.
13. Authors' Addresses 12. Authors' Addresses
Ladan Gharai <ladan@isi.edu> Ladan Gharai <ladan@isi.edu>
USC Information Sciences Institute USC Information Sciences Institute
3811 N. Fairfax Drive, #200 3811 N. Fairfax Drive, #200
Arlington, VA 22203 Arlington, VA 22203
USA USA
Colin Perkins <csp@csperkins.org> Colin Perkins <csp@csperkins.org>
University of Glasgow University of Glasgow
Department of Computing Science Department of Computing Science
17 Lilybank Gardens 17 Lilybank Gardens
skipping to change at page 17, line 29 skipping to change at page 17, line 17
[RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, [RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
Internet Engineering Task Force, RFC 3550, July 2003. Internet Engineering Task Force, RFC 3550, July 2003.
[2119] S. Bradner, "Key words for use in RFCs to Indicate [2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
[2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA [2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", 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 Informative References
[274] Society of Motion Picture and Television Engineers, [274] Society of Motion Picture and Television Engineers,
"1920x1080 Scanning and Analog and Parallel Digital "1920x1080 Scanning and Analog and Parallel Digital
Interfaces for Multiple Picture Rates", SMPTE 274M-1998. Interfaces for Multiple Picture Rates", SMPTE 274M-1998.
[268] Society of Motion Picture and Television Engineers, [268] Society of Motion Picture and Television Engineers,
"File Format for Digital Moving Picture Exchange (DPX)", "File Format for Digital Moving Picture Exchange (DPX)",
SMPTE 268M-1994. (Currently under revision.) SMPTE 268M-1994. (Currently under revision.)
skipping to change at page 18, line 15 skipping to change at page 18, line 14
[SDP] M. Handley and V. Jacobson, "SDP: Session Description [SDP] M. Handley and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[BT656] D. Tynan, "RTP Payload Format for BT.656 Video Encoding", [BT656] D. Tynan, "RTP Payload Format for BT.656 Video Encoding",
Internet Engineering Task Force, RFC 2431, October 1998. Internet Engineering Task Force, RFC 2431, October 1998.
[292RTP] L. Gharai et al., "RTP Payload Format for SMPTE 292M Video", [292RTP] L. Gharai et al., "RTP Payload Format for SMPTE 292M Video",
RFC 3497, March 2003. RFC 3497, March 2003.
[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.
[656] International Telecommunication Union, "Interfaces for [656] International Telecommunication Union, "Interfaces for
Digital Component Video Signals in 525-line and 625-line Digital Component Video Signals in 525-line and 625-line
Television Systems Operating at the 4:2:2 Level of Television Systems Operating at the 4:2:2 Level of
Recommendation ITU-R BT.601 (Part A)", Recommendation Recommendation ITU-R BT.601 (Part A)", Recommendation
BT.656, April 1998. BT.656, April 1998.
[22028] ISO TC42 (Photography), Photography and graphic technology - [22028] ISO TC42 (Photography), Photography and graphic technology -
Extended colour encodings for digital image storage, Extended colour encodings for digital image storage,
manipulation and interchange - Part 1: Architecture and manipulation and interchange - Part 1: Architecture and
requirements, ISO/CD 22028-1, Work in Progress. requirements, ISO/CD 22028-1, Work in Progress.
[709] International Telecommunication Union, "Parameter Values for 13. IPR Notice
HDTV Standards for Production and International Programme
Exchange", Recommendation BT.709-2
[240] Society of Motion Picture and Television Engineers, The IETF takes no position regarding the validity or scope of any
"Television - Signal Parameters - 1125-Line High-Definition intellectual property or other rights that might be claimed to
Production", SMPTE 240M-1999. 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
14. Full Copyright Statement
Copyright (C) The Internet Society 2003. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
 End of changes. 23 change blocks. 
72 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/