Internet DRAFT - draft-gharai-hdtv-video
draft-gharai-hdtv-video
INTERNET-DRAFT Ismail Dalgic
<draft-gharai-hdtv-video-00.txt> 3Com
Ladan Gharai
USC/ISI
Allison Mankin
USC/ISI
David Richardson
University of Washington
Raymond Yow
3Com
March 8, 2000
RTP Payload Format for Uncompressed HDTV Video Streams
<draft-gharai-hdtv-video-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a packetization scheme for encapsulating
uncompressed HDTV as defined by SMPTE 274M and SMPTE 296M into a payload
format for the Real-Time Transport Protocol (RTP). SMPTE 274M and
draft-ietf-gharai-hdtv-video-00.txt [Page 1]
INTERNET-DRAFT March 8, 2000
SMPTE 296M define the analog and digital representation of HDTV with
image formats of 1920*1080 and 1280*720, respectively.
1. Introduction
The analog and digital representation of uncompressed HDTV are specified
in SMPTE 274M and SMPTE 296M [1,2]. These standards normatively
reference ITU-R BT.709 and follow the parameter values set forth in
ITU-R BT.709 for production and international program exchange. SMPTE
274M defines a family of scanning systems with an image format of
1920*1080 with progressive and interlaced scanning, while SMPTE 296M
standard defines systems with an image size of 1280*720 and only
progressive scanning.
Both standards define images with aspect ratios of 16:9, and define the
digital representation for RGB and YCbCr components. Both 8-bit and
10-bit quantization is supported. In the case of YCbCr components, Cb
and Cr components are subsampled horizontally by a factor of two (4:2:2
color encoding).
In this document we specify a packetization scheme for encapsulating the
digital representation of uncompressed HDTV as defined by SMPTE 274M and
SMPTE 296M into a payload format for RTP.
2. A Note on Compressed HDTV over RTP
HDTV is compressed using a subset of MPEG-2 [3] as its compression
scheme. This subset is fully described in document A/53 [4] of the
Advanced Television Standards Committee. The ATSC has also adopted the
MPEG-2 transport system (ISO/IEC 13818-1) [5]. Therefore:
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
for MPEG-2's transport system, where multiple fixed length (188 bytes)
MTS packets are aggregated into a single RTP packet.
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
MPEG-2 elementary streams. The additional restrictions of HDTV do not
have any implications for RTP packetization.
draft-ietf-gharai-hdtv-video-00.txt [Page 2]
INTERNET-DRAFT March 8, 2000
3. Payload Design
Each scan line of digital video is packetized into one or more
(depending on the current MTU) RTP packets. Only the active samples are
included in the RTP payload. From the two timing references, SAV and
EAV (start of active video and end of active video) only the field bit,
F, is included in the RTP payload header.
Scan lines are numbered consecutively. Only active scan lines are
included in the RTP payload. Transmissability of the inactive data
(including vertical blanking interval) in this payload is for future
study.
Scan line numbers are included in the RTP payload header. For SMPTE
296M, valid scan line numbers are from 26 through 745, inclusive. For
SMPTE 274M, progressive scanning valid scan lines are from scan line 42
through 1121, inclusive. For interlaced scanning, valid scan line
numbers for field one (F=0) are from 21 to 560 and valid scan line
numbers for the second field (F=1) are from 584 to 1123.
Cb and Cr values are subsampled by a factor of two horizontally and are
co-sited with even numbered Y samples. Therefore, Cb, Cr and Y samples
are arranged in following order:
Cb, Y, Cr, Y, Cb, Y, Cr, ...
where the first Cb, Y, Cr sequence refers to co-sited luminance and
color-difference samples, and the next Y belongs to the next luminance
sample. If a scan line must be fragmented, the fragment should always
start with a Cb value. In other words, fragmentation MUST only occur at
a Cb boundary.
4. RTP Packetization
The standard RTP header is followed by a 4 byte payload header, and the
payload data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft-ietf-gharai-hdtv-video-00.txt [Page 3]
INTERNET-DRAFT March 8, 2000
4.1. The RTP Header
In this specification, the terms "frame" and "image" are used
interchangeably, though "image" is the preferred term of the SMPTE
specifications.
The following fields of the RTP fixed header are used for HDTV
encapsulation:
Payload Type (PT): A dynamically allocated payload type field which
designates the payload as uncompressed HDTV.
Timestamp: A 90 kHz timestamp which denotes the display time of the
video frame to which the RTP packet belongs. All packets belonging to
the same video frame MUST have the same timestamp. Higher-rate
timestamps have been considered for related payload types (see the
minutes of the AVT Working Group, 46th IETF), but they would be for
multiple programs (if considered at all). For uncompressed HDTV, with
maximum frame rates of 60 per second (60i), the 90kHz standard RTP
timestamp suffices.
Marker bit (M): The Marker bit denotes the end of a video frame, and is
set to 1 for the last packet of the video frame and is otherwise set to
0 for all other packets.
4.2. Payload Header
The payload header is 4 bytes long and is arranged as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|Q| I |S| R | Z | Scan Line (SL) | Scan Offset (SO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field Identification (F): 1 bit
Identifies which field the scan line belongs to, for interlaced data.
F=0 identifies the the first field and F=1 the second field. For
progressive data (SMPTE 296M) F MUST always be set to zero. This bit
MUST remain unchanged for all scan lines within the same image.
Quantization (Q): 1 bit
Designates sample sizes. For 8-bit samples Q is set to 0 and for 10-bit
samples Q is set to 1. This bit MUST remain unchanged for all scan lines
within the same image.
draft-ietf-gharai-hdtv-video-00.txt [Page 4]
INTERNET-DRAFT March 8, 2000
Image Size (I): 2 bits
Identifies the image size and SMPTE standard which the data conforms to.
I=0 designates a 720*1280 image size (SMPTE 296M), and I=1 designates a
1080*1920 image size (SMPTE 274M). This bit MUST remain unchanged for
all scan lines within the same image. The remaining values of I are
reserved for future use.
Scanning (S): 1 bit
Designates progressive (S=1) or interlaced (S=0) scanning. For SMPTE
296M data only S=1 is a valid value. This bit MUST remain unchanged for
all scan lines within the same image.
Frame Rate (R): 3 bits
Designates frame rate of transferred data. Frames rates designated by
values of consecutive values of R (from 0 to 7) are: 60fps, 59.94fps,
50fps, 30fps, 29.97fps, 25fps, 24fps and 23.98fps. All of the above are
valid for SMPTE 274M (I=1), however for SMPTE 296M (or I=0) only R=0 and
R=1 are valid. These bits MUST remain unchanged for all scan lines
within the same image.
Zero (Z): 2 bits
For future use. Must be set to zero.
Scan Line (SL): 11 bits
Scan line number of encapsulated data. Successive RTP packets MAY
contains parts of the same scan line (with an incremented sequence
number, but the same timestamp). One RTP packet MUST NOT contain the
end of one scan line and the start of another. Valid values for SMPTE
296M (I=0) are 26-745. For SMPTE 274M (I=1) with progressive scanning
(S=1, F=0) valid scan line numbers are 42-1121, and with interlaced
scanning, field one (S=0, F=0) valid values are 21-560; for field two
(S=0, F=1), the valid values are 584-1123.
Scan Offset (SO): 11 bits
Sample number of the co-sited luminance sample where the scan line is
fragmented. Valid values for SMPTE 296M (I=0) are 2-1278 and for SMPTE
274M (I=1) 2-1918.
5. 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 any appropriate RTP profile. This implies that
confidentiality of the media streams is achieved by encryption. Because
the data compression used with this payload format is applied end-to-
draft-ietf-gharai-hdtv-video-00.txt [Page 5]
INTERNET-DRAFT March 8, 2000
end, encryption may be performed after compression so there is no
conflict between the two operations.
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 perhaps to be noted that the bandwidth of this payload is high
enough (1.5 Gbps without the RTP overhead) to cause potential for
denial-of-service if transmitted onto most currently available Internet
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
narrowly limited to suitably connected network endpoints and great care
taken with the scope of multicast transmissions. This potential threat
is hardly unique to the uncompressed HDTV payload, but the size of this
flow is larger than most like it.
6. IANA Considerations
[To be done]
7. To Do List
For consideration in the next revision of this document: should the
vertical blanking interval scan lines be transmissable? How should
ancillary data be handled? This follows RFC 2431 in extracting the
video data from the whole line, since there is otherwise a lot of extra
data, but this decision should be reconsidered in the light of ongoing
prototype implementations. Implementation experience will also be used
to consider loss recovery in a future revision.
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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 Soci- ety or
other Internet organizations, except as needed for the purpose of
draft-ietf-gharai-hdtv-video-00.txt [Page 6]
INTERNET-DRAFT March 8, 2000
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be fol- lowed,
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 MER- CHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
9. Authors' Addresses
Ismail Dalgic
Ismail_Dalgic@3com.com
Ladan Gharai
ladan@isi.edu
Allison Mankin
mankin@isi.edu
David Richardson
drr@u.washington.edu
Raymond Yow
Raymond_Yow@3com.com
10. Bibliography
[1] Society of Motion Picture and Television Engineers,
1920*1080 Scanning and Analog and Parallel Digital Interfaces
for Multiple Picture Rates, SMPTE 274M, 1998.
[2] Society of Motion Picture and Television Engineers,
1280*720 Scanning, Analog and Digital Representation and Analog
Interfaces, SMPTE 296M, 1998.
[3] ISO/IEC International Standard 13818-2; "Generic coding of
moving pictures and associated audio information: Video", 1996.
[4] ATSC Digital Television Standard Document A/53, September 1995,
http://www.atsc.org
draft-ietf-gharai-hdtv-video-00.txt [Page 7]
INTERNET-DRAFT March 8, 2000
[5] ISO/IEC International Standard 13818-1; "Generic coding of
moving pictures and associated audio information: Systems",1996.
[6] Schulzrinne, Casner, Frederick, Jacobson, "RTP: A transport
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.
[8] Schulzrinne, "RTP Profile for Audio and Video Conferences with
Minimal Control", RFC 1890, IETF, January 1996.
draft-ietf-gharai-hdtv-video-00.txt [Page 8]
