draft-ietf-avt-smpte292-video-01.txt   draft-ietf-avt-smpte292-video-02.txt 
INTERNET-DRAFT Ladan Gharai INTERNET-DRAFT Ladan Gharai
<draft-ietf-avt-smpte292-video-01.txt> USC/ISI <draft-ietf-avt-smpte292-video-02.txt> USC/ISI
Gary Goncher Gary Goncher
Tektronix Tektronix
Colin Perkins Colin Perkins
USC/ISI USC/ISI
David Richardson David Richardson
University of Washington University of Washington
Allison Mankin Allison Mankin
USC/ISI USC/ISI
Nov 24, 2000 March 2, 2001
RTP Payload Format for SMPTE 292M RTP Payload Format for SMPTE 292M
<draft-ietf-avt-smpte292-video-01.txt> <draft-ietf-avt-smpte292-video-02.txt>
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-
Drafts. Drafts.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
the Real-Time Transport Protocol (RTP). The RTP packet counter is the Real-Time Transport Protocol (RTP). The RTP packet counter is
extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate. extended to 32 bits to accommodate SMPTE 292M's 1.485Gb/s data rate.
1. Introduction 1. Introduction
The serial digital interface, SMPTE 292M[1], defines a universal medium The serial digital interface, SMPTE 292M[1], defines a universal medium
of interchange for uncompressed HDTV between various types of video of interchange for uncompressed HDTV between various types of video
equipment (camera's, encoders, VTRs, ...) at data rates of 1.485Gb/s equipment (camera's, encoders, VTRs, ...) at data rates of 1.485Gb/s
(and 1.485/1.001 Gb/s). Source formats transfered by SMPTE 292M are (and 1.485/1.001 Gb/s). Source formats transfered by SMPTE 292M are
SMPTE 260M, 295M, 274M and 296M. Source data for these formats are SMPTE 260M, 295M, 274M and 296M[2-5]. Source data for these formats are
10-bit words, sampled at 4:2:2. In this memo we specify how to 10-bit words, sampled at 4:2:2. In this memo we specify how to
transfer SMPTE 292M over RTP. transfer SMPTE 292M over RTP.
This memo only addresses the transfer of uncompressed HDTV. Compressed This memo only addresses the transfer of uncompressed HDTV. Compressed
HDTV is a subset of MPEG-2 [3], which is fully described in document HDTV is a subset of MPEG-2 [6], which is fully described in document
A/53 [4] of the Advanced Television Standards Committee. The ATSC has A/53 [7] of the Advanced Television Standards Committee. The ATSC has
also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [5]. also adopted the MPEG-2 transport system (ISO/IEC 13818-1) [8].
Therefore: Therefore:
1. The HDTV transport system is a compatible subset of the MPEG-2 1. The HDTV transport system is a compatible subset of the MPEG-2
transport system. Section 2 of RFC 2250 [7] describes the RTP payload transport system. Section 2 of RFC 2250 [9] describes the RTP payload
for MPEG-2's transport system, where multiple fixed length (188 bytes) for MPEG-2's transport system, where multiple fixed length (188 bytes)
MTS packets are aggregated into a single RTP packet. MTS packets are aggregated into a single RTP packet.
2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional 2. Compressed HDTV is a subset of MPEG-2 MP@HL with some additional
restrictions. Section 3 of RFC 2250 describes a packetization scheme for restrictions. Section 3 of RFC 2250 describes a packetization scheme for
MPEG-2 elementary streams. The additional restrictions of HDTV do not MPEG-2 elementary streams. The additional restrictions of HDTV do not
have any implications for RTP packetization. have any implications for RTP packetization.
2. Conventions Used in this Document 2. Conventions Used in this Document
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Each video frame of SMPTE 292M is packetized into a number of constant Each video frame of SMPTE 292M is packetized into a number of constant
size RTP packets. All active, vertical blanking and timing information size RTP packets. All active, vertical blanking and timing information
is packetized. The end of a frame is marked by the M bit in the RTP is packetized. The end of a frame is marked by the M bit in the RTP
header. A single packet may contain data for two consecutive scan header. A single packet may contain data for two consecutive scan
lines. The SMPTE 292M decoder uses the sync info in the scan lines to lines. The SMPTE 292M decoder uses the sync info in the scan lines to
detect the start of scan lines. detect the start of scan lines.
A single packet may also contain information from adjacent scan lines in A single packet may also contain information from adjacent scan lines in
two consecutive frames, or by agreement between sender and receiver the two consecutive frames, or by agreement between sender and receiver the
last packet of a video frame may be padded to the full length of all last packet of a video frame may be padded to the full length of all
292M RTP packets, in which case a new will frame start in a new packet. 292M RTP packets, in which case a new frame will start in a new packet.
The standard 16 bit RTP sequence counter is extended to 32 bits to The standard 16 bit RTP sequence counter is extended to 32 bits to
accommodate HDTV's high data rates. At 1.485Gb/s, with packet sizes of accommodate HDTV's high data rates. At 1.485Gb/s, with packet sizes of
at least 1kByte, 32bits allows for an approximate 6 hour period before at least 1kByte, 32bits allows for an approximate 6 hour period before
the sequence counter wraps around. the sequence counter wraps around.
A 10Mhz timestamp is used as the RTP header's timestamp. This allows the A 10Mhz timestamp is used as the RTP header's timestamp. This allows the
receiver to reconstruct the timing of the SMPTE 292M stream, without receiver to reconstruct the timing of the SMPTE 292M stream, without
knowledge of the exact type of source format (e.g. SMPTE 274M or SMPTE knowledge of the exact type of source format (e.g. SMPTE 274M or SMPTE
296M). 296M).
skipping to change at page 6, line 20 skipping to change at page 6, line 20
MIME media type name: video MIME media type name: video
MIME subtype name: SMPTE 292M MIME subtype name: SMPTE 292M
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: SMPTE 292M video can be transmitted with Encoding considerations: SMPTE 292M video can be transmitted with
RTP as specified in "draft-ietf-avt-smpte292-video-01". RTP as specified in "draft-ietf-avt-smpte292-video-02".
Security considerations: None Security considerations: None
Interoperability considerations: NONE Interoperability considerations: NONE
Published specification: SMPTE 292M Published specification: SMPTE 292M
draft-ietf-avt-smpte292-video-01 draft-ietf-avt-smpte292-video-02
Applications which use this media type: Applications which use this media type:
Video communication. Video communication.
Additional information: None Additional information: None
Magic number(s): None Magic number(s): None
File extension(s): DV File extension(s): DV
skipping to change at page 6, line 50 skipping to change at page 6, line 50
Person & email address to contact for further information: Person & email address to contact for further information:
Ladan Gharai <ladan@isi.edu> Ladan Gharai <ladan@isi.edu>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Author/Change controller:
Ladan Gharai <ladan@isi.edu> Ladan Gharai <ladan@isi.edu>
7. Mapping to SDP Parameters 7. Mapping to SDP Parameters
Parameters are mapped to SDP [9] as follows: Parameters are mapped to SDP [12] as follows:
m=video 23456 RTP/AVP 111 m=video 30000 RTP/AVP 111
a=rtpmap:111 SMPTE 292M/10000000 a=rtpmap:111 SMPTE 292M/10000000
a=fmtp:111 length=1400 a=fmtp:111 length=560
In this example, a dynamic payload type 111 is assumed for SMPTE 292M, In this example, a dynamic payload type 111 is assumed for SMPTE292M.
with packet sizes of 1400bytes. The length field indicates the number of video samples in each packet,
560, which means the payload length is 1400bytes.
8. Security Considerations 8. Security Considerations
RTP packets using the payload format defined in this specification are RTP packets using the payload format defined in this specification are
subject to the security considerations discussed in the RTP subject to the security considerations discussed in the RTP
specification, and any appropriate RTP profile. This implies that specification, and any appropriate RTP profile. This implies that
confidentiality of the media streams is achieved by encryption. confidentiality of the media streams is achieved by encryption.
This payload type does not exhibit any significant non-uniformity in the This payload type does not exhibit any significant non-uniformity in the
receiver side computational complexity for packet processing to cause a receiver side computational complexity for packet processing to cause a
skipping to change at page 7, line 34 skipping to change at page 7, line 35
enough (1.5 Gbps without the RTP overhead) to cause potential for enough (1.5 Gbps without the RTP overhead) to cause potential for
denial-of-service if transmitted onto most currently available Internet denial-of-service if transmitted onto most currently available Internet
paths. In the absence from the standards track of a suitable congestion paths. In the absence from the standards track of a suitable congestion
control mechanism for flows of this sort, use of the payload should be control mechanism for flows of this sort, use of the payload should be
narrowly limited to suitably connected network endpoints and great care narrowly limited to suitably connected network endpoints and great care
taken with the scope of multicast transmissions. This potential threat taken with the scope of multicast transmissions. This potential threat
is common to all high bit rate applications. is common to all high bit rate applications.
9. IANA Considerations 9. IANA Considerations
See Section 6. See section 6.
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
skipping to change at page 8, line 25 skipping to change at page 8, line 26
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE." FITNESS FOR A PARTICULAR PURPOSE."
11. Authors' Addresses 11. Authors' Addresses
Ladan Gharai Ladan Gharai
ladan@isi.edu ladan@isi.edu
USC/ISI
4350 Fairfax Dr
Arlington, VA 22203-1695
Gary Goncher Gary Goncher
ggoncher@tek.com ggoncher@tek.com
Colin Perkins Colin Perkins
csp@isi.edu csp@isi.edu
USC/ISI
4350 Fairfax Dr
Arlington, VA 22203-1695
David Richardson David Richardson
drr@u.washington.edu drr@u.washington.edu
Allison Mankin Allison Mankin
mankin@isi.edu mankin@isi.edu
USC/ISI
4350 Fairfax Dr
Arlington, VA 22203-1695
12. Bibliography 12. Bibliography
[1] Society of Motion Picture and Television Engineers, [1] Society of Motion Picture and Television Engineers,
Bit-Serial Digital Interface for High-Definition Television Bit-Serial Digital Interface for High-Definition Television
Systems, SMPTE 292M, 1998. Systems, SMPTE 292M, 1998.
[2] Society of Motion Picture and Television Engineers, [2] Society of Motion Picture and Television Engineers,
1280*720 Scanning, Analog and Digital Representation and Analog Digital Representation and Bit-Parallel Interface - 1125/60
High-Definition Production System, SMPTE 260M, 1992.
[3] Society of Motion Picture and Television Engineers,
1920x1080 50Hz, Scanning and Interface, SMPTE 295M, 1997.
[4] Society of Motion Picture and Television Engineers,
1920x1080 Scanning and Analog and Parallel Digital Interfaces
for Multiple Picture Rates, SMPTE 272M.
[5] Society of Motion Picture and Television Engineers,
1280x720 Scanning, Analog and Digital Representation and Analog
Interfaces, SMPTE 296M, 1998. Interfaces, SMPTE 296M, 1998.
[3] ISO/IEC International Standard 13818-2; "Generic coding of [6] ISO/IEC International Standard 13818-2; "Generic coding of
moving pictures and associated audio information: Video", 1996. moving pictures and associated audio information: Video", 1996.
[4] ATSC Digital Television Standard Document A/53, September 1995, [7] ATSC Digital Television Standard Document A/53, September 1995,
http://www.atsc.org http://www.atsc.org
[5] ISO/IEC International Standard 13818-1; "Generic coding of [8] ISO/IEC International Standard 13818-1; "Generic coding of
moving pictures and associated audio information: Systems",1996. moving pictures and associated audio information: Systems",1996.
[6] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport [9] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for
protocol for real time Applications", RFC 1889, IETF,
January 1996.
[7] Hoffman, Fernando, Goyal, Civanlar, "RTP Payload Format for
MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998. MPEG1/MPEG2 Video", RFC 2250, IETF, January 1998.
[8] Schulzrinne, "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, IETF, January 1996.
[9] M. Handley and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[10] IETF RFC 2119, "Key words for use in RFCs to Indicate [10] IETF RFC 2119, "Key words for use in RFCs to Indicate
Requirement Levels". Requirement Levels".
[11] D. Tynan, "RTP Payload Format for BT.656 Video Encoding", [11] D. Tynan, "RTP Payload Format for BT.656 Video Encoding",
RFC 2431, October 1998. RFC 2431, October 1998.
[12] M. Handley and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998.
[13] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport
protocol for real time Applications", RFC 1889, IETF,
January 1996.
[14] Schulzrinne, "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, IETF, January 1996.
 End of changes. 

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