draft-ietf-avt-uncomp-video-01.txt | draft-ietf-avt-uncomp-video-02.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-01.txt Colin Perkins | draft-ietf-avt-uncomp-video-02.txt Colin Perkins | |||
USC/ISI | USC/ISI | |||
3 November 2002 | 27 February 2003 | |||
Expires: May 2003 | Expires: August 2003 | |||
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 all | This document is an Internet-Draft and is in full conformance with all | |||
provisions of Section 10 of RFC2026. | provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering Task | |||
Force (IETF), its areas, and its working groups. Note that other groups | Force (IETF), its areas, and its working groups. Note that other groups | |||
skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 7 ¶ | |||
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 Protocol, RTP. It supports a range of standard- and | Transport Protocol, RTP. It supports a range of standard- and | |||
high-definition video formats, including common television | high-definition video formats, including common television | |||
formats such as ITU BT.601, SMPTE 274M and SMPTE 296M. The | formats such as ITU BT.601, SMPTE 274M and SMPTE 296M. The | |||
format is designed to be extensible as new video formats are | format is designed to be extensible as new video formats are | |||
developed. | developed. | |||
1. Introduction | 1. Introduction | |||
[Note to RFC Editor: All references to RFC XXXX are to be replaced 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]. | |||
Formats for uncompressed standard definition television are defined by | Formats for uncompressed standard definition television are defined by | |||
ITU Recommendation BT.601 [601] along with bit-serial and parallel | ITU Recommendation BT.601 [601] along with bit-serial and parallel | |||
interfaces in Recommendation BT.656 [656]. These formats allow both 625 | interfaces in Recommendation BT.656 [656]. These formats allow both 625 | |||
line and 525 line operation, with 720 samples per digital active line, | line and 525 line operation, with 720 samples per digital active line, | |||
4:2:2 color sub-sampling, and 8- or 10-bit digital representation. | 4:2:2 color sub-sampling, and 8- or 10-bit digital representation. | |||
The representation of uncompressed high definition television is | The representation of uncompressed high definition television is | |||
specified in SMPTE standards 274M [274] and 296M [296]. SMPTE 274M | specified in SMPTE standards 274M [274] and 296M [296]. SMPTE 274M | |||
defines a family of scanning systems with an image format of 1920x1080 | defines a family of scanning systems with an image format of 1920x1080 | |||
pixels with progressive and interlaced scanning, while SMPTE 296M | pixels with progressive and interlaced scanning, while SMPTE 296M | |||
standard defines systems with an image size of 1280x720 pixels and only | standard defines systems with an image size of 1280x720 pixels and only | |||
progressive scanning. In progressive scanning, scan lines are displayed | progressive scanning. In progressive scanning, scan lines are displayed | |||
in sequence from top to bottom of a full frame. In interlaced scanning, | in sequence from top to bottom of a full frame. In interlaced scanning, | |||
a frame is divided into its odd and even scan lines (called a field) and | a frame is divided into its odd and even scan lines (called fields) and | |||
the two fields are displayed in succession. | the two fields are displayed in succession. | |||
SMPTE 274M and 296M define images with aspect ratios of 16:9, and define | SMPTE 274M and 296M define images with aspect ratios of 16:9, and define | |||
the digital representation for RGB and YCbCr components. In the case of | the digital representation for RGB and YCbCr components. In the case of | |||
YCbCr components, the Cb and Cr components are horizontally sub-sampled | YCbCr components, the Cb and Cr components are horizontally sub-sampled | |||
by a factor of two (4:2:2 color encoding). | by a factor of two (4:2:2 color encoding). | |||
Although these formats differ in their details, they are structurally | Although these formats differ in their details, they are structurally | |||
very similar. This memo specifies a payload format to encapsulate these, | very similar. This memo specifies a payload format to encapsulate these, | |||
and other similar, video formats for transport within RTP. | and other similar, video formats for transport within RTP. | |||
2. Conventions Used in this Document | 2. Conventions Used in this Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119[2119]. | document are to be interpreted as described in RFC 2119[2119]. | |||
3. Applicability Statement | 3. Payload Design | |||
This RTP payload format is designed to transport uncompressed, studio | ||||
quality, video streams. Such content can be very high bandwidth and, by | ||||
definition, is not congestion controlled. The intended use of this | ||||
format is within a production facility or on a suitably connected | ||||
private network that is specifically engineered to support this content. | ||||
This format is NOT RECOMMENDED for use on public network links, unless | ||||
those links support appropriate quality of service guarantees. See also | ||||
Section 10 "Security Considerations". | ||||
4. Payload Design | ||||
Each scan line of digital video is packetized into one or more | Each scan line of digital video is packetized into one or more | |||
(depending on the current MTU) RTP packets. A single RTP packet MAY also | (depending on the network MTU) RTP packets. A single RTP packet MAY also | |||
contain data for more than one scan line. Only the active samples are | contain data for more than one scan line. Only the active samples are | |||
included in the RTP payload, inactive samples and the contents of | included in the RTP payload, inactive samples and the contents of | |||
horizontal and vertical blanking SHOULD NOT be transported. Scan line | horizontal and vertical blanking SHOULD NOT be transported. Scan line | |||
numbers are included in the RTP payload header, along with a field | numbers are included in the RTP payload header, along with a field | |||
identifier for interlaced video. | identifier for interlaced video. | |||
For SMPTE 296M format video, valid scan line numbers are from 26 | For SMPTE 296M format video, valid scan line numbers are from 26 | |||
through 745, inclusive. For progressive scan SMPTE 274M format | through 745, inclusive. For progressive scan SMPTE 274M format | |||
video, valid scan lines are from scan line 42 through 1121 | video, valid scan lines are from scan line 42 through 1121 | |||
inclusive. For interlaced scan, valid scan line numbers for field | inclusive. For interlaced scan, valid scan line numbers for field | |||
one (F=0) are from 21 to 560 and valid scan line numbers for the | one (F=0) are from 21 to 560 and valid scan line numbers for the | |||
second field (F=1) are from 584 to 1123. For ITU-R BT.601 format | second field (F=1) are from 584 to 1123. For ITU-R BT.601 format | |||
video, the blanking intervals defined in BT.656 are used: for 625 | video, the blanking intervals defined in BT.656 are used: for 625 | |||
line video, lines 24 to 310 of field one (F=0) and 337 to 623 of | line video, lines 24 to 310 of field one (F=0) and 337 to 623 of | |||
the second field (F=1) are valid; for 525 line video, lines 21 to | the second field (F=1) are valid; for 525 line video, lines 21 to | |||
263 of the first field, and 284 to 525 of the second field are | 263 of the first field, and 284 to 525 of the second field are | |||
valid. Other formats (e.g. [372]) may define different ranges of | valid. Other formats (e.g. [372]) may define different ranges of | |||
active lines. | active lines. | |||
The payload header contains a 16 bit extension to the standard 16 bit | ||||
RTP sequence number, thereby extending the sequence number to 32 bits | ||||
and enabling RTP to accommodate high data rates. This is necessary as | ||||
the 16 bit RTP sequence number will roll-over very quickly for high data | ||||
rates. For example, for a 1 Gbps video stream with packet sizes of at | ||||
least one thousand octets, the standard RTP packet will roll-over in 0.5 | ||||
seconds, which can be a problem for detecting loss and out of order | ||||
packets particularly in instances where the round trip time is greater | ||||
than half a second. The extended 32 bit number allows for a longer wrap- | ||||
around time of approximately nine hours. | ||||
It is desirable for the video to be both octet aligned when packetized, | It is desirable for the video to be both octet aligned when packetized, | |||
and to adhere to the principles of application level framing [ALF] by | and to adhere to the principles of application level framing [ALF] by | |||
ensuring that the samples relating to a single pixel are not fragmented | ensuring that the samples relating to a single pixel are not fragmented | |||
across two packets. | across two packets. | |||
Samples may be transfered as 8, 10, 12 or 16 bit values. For 10 bit and | Samples may be transfered as 8, 10, 12 or 16 bit values. For 10 bit and | |||
12 bit payloads, care must be taken to pack an appropriate number of | 12 bit payloads, care must be taken to pack an appropriate number of | |||
samples per packet, such that the payload is also octet aligned. For RGB | samples per packet, such that the payload is also octet aligned. For RGB | |||
video, it is desirable that the samples corresponding to a single pixel | video, it is desirable that the samples corresponding to a single pixel | |||
are not fragmented across packets. Similarly, for YCrCb video, it is | are not fragmented across packets. Similarly, for YCrCb video, it is | |||
desirable that luminance and chrominance values are not fragmented | desirable that luminance and chrominance values are not fragmented | |||
across packets. | across packets. | |||
For example, in YCrCb video with 4:2:0 color subsampling, each group of | For example, in YCrCb video with 4:1:1 color subsampling, each group of | |||
4 pixels is represented by 6 values, Y1 Y2 Y3 Y4 Cr Cb. These should be | 4 pixels is represented by 6 values, Y1 Y2 Y3 Y4 Cr Cb. These should be | |||
packetized such that these values are not fragmented across a packet | packetized such that these values are not fragmented across a packet | |||
boundary. With 10 bit words this is a 60 bit value which is not octet | boundary. With 10 bit words this is a 60 bit value which is not octet | |||
aligned. To be both octet aligned, and appropriately framed, pixels must | aligned. To be both octet aligned, and appropriately framed, pixels must | |||
be framed in 2 groups of 4, thereby becoming octet aligned on a 15 octet | be framed in 2 groups of 4 pixels, thereby becoming octet aligned on a | |||
boundary. This length is referred to as the pixel group ("pgroup"), and | 15 octet boundary. This length is referred to as the pixel group | |||
it is conveyed in the SDP parameters. Tables 1 to 4 display the pgroup | ("pgroup"), and it is conveyed in the SDP parameters. Tables 1 to 4 | |||
values for a range of color samplings and word lengths. | display the pgroup values, in octets, for a range of color samplings and | |||
word lengths. | ||||
10 bit words | ||||
Color -------------------------------- | ||||
Subsampling Pixels #words octet alignment pgroup | ||||
+-----------+------+ +------+---------------+-------+ | ||||
|monochrome | 4 | | 4x10 | 40/8 = 5 | 5 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:0 | 4 | | 6x10 | 2x60/8 = 15 | 15 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:2 | 2 | | 4x10 | 40/8 = 5 | 5 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4 | 1 | | 3x10 | 4x30/8 = 15 | 15 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4:4 | 1 | | 4x10 | 40/8 = 5 | 5 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
Table 1: pgroup values for 10 bit sampling | ||||
8 bit words | ||||
Color -------------------------------- | ||||
Subsampling Pixels #words octet alignment pgroup | ||||
+-----------+------+ +------+---------------+-------+ | ||||
|monochrome | 1 | | 1x8 | 8/8 = 1 | 1 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:0 | 4 | | 6x8 | 6x8/8 = 6 | 6 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:2 | 2 | | 4x8 | 4x8/8 = 8 | 4 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4 | 1 | | 3x8 | 3x8/8 = 3 | 3 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4:4 | 1 | | 4x8 | 4x8/8 = 4 | 4 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
Table 2: pgroup values for 8 bit sampling | ||||
12 bit words | ||||
Color -------------------------------- | ||||
Subsampling Pixels #words octet alignment pgroup | ||||
+-----------+------+ +------+---------------+-------+ | ||||
|monochrome | 2 | | 2x12 | 2x12/8 = 3 | 3 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:0 | 4 | | 6x12 | 72/8 = 9 | 9 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:2 | 2 | | 4x12 | 48/8 = 6 | 6 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4 | 2 | | 6x12 | 2x36/8 = 9 | 9 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4:4 | 1 | | 4x12 | 48/8 = 6 | 6 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
Table 3: pgroup values for 12 bit sampling | ||||
16 bit words | ||||
Color -------------------------------- | ||||
Subsampling Pixels #words octet alignment pgroup | ||||
+-----------+------+ +------+---------------+-------+ | ||||
|monochrome | 1 | | 1x16 | 16/8 = 2 | 2 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:0 | 4 | | 6x16 | 6x16/8 = 12 | 12 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:2:2 | 2 | | 4x16 | 4x16/8 = 8 | 8 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4 | 1 | | 3x16 | 3x16/8 = 6 | 6 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
| 4:4:4:4 | 1 | | 4x16 | 4x16/8 = 8 | 8 | | ||||
+-----------+------+ +------+---------------+-------+ | ||||
Table 4: pgroup values for 16 bit sampling | ||||
When packetizing digital active line content, video data MUST NOT be | When packetizing digital active line content, video data MUST NOT be | |||
fragmented within a pgroup. | fragmented within a 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 embedde d in non-video portions of | applications this data is commonly embedded in non-active portions of | |||
the data 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 | |||
envisions that applications requiring such synchronized ancillary data | requires that applications using such synchronized ancillary data MUST | |||
should deliver it in separate RTP sessions which operate concurrently | deliver it in separate RTP sessions which operate concurrently with the | |||
with the video session. The normal RTP mechanisms SHOULD be used to | video session. The normal RTP mechanisms SHOULD be used to synchronize | |||
synchronize the media. | the media. | |||
5. RTP Packetization | 8 bit words | |||
Color ---------------------------------------- | ||||
Subsampling Pixels #words octet alignment #samples pgroup | ||||
octets | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
|monochrome | 1 |P/I| | 1x8 | 8/8 = 1 | 1 | 1 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:1:1 | 4 |P/I| | 6x8 | 6x8/8 = 6 | 6 | 6 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:2:0 | 4 | P | | 6x8 | 6x8/8 = 6 | 6 | 6 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:2:0 | 4 | I | | 4x8 | 4x8/8 = 6 | 4 | 4 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:2:2 | 2 |P/I| | 4x8 | 4x8/8 = 8 | 4 | 4 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:4:4 | 1 |P/I| | 3x8 | 3x8/8 = 3 | 3 | 3 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:4:4:4 | 1 |P/I| | 4x8 | 4x8/8 = 4 | 4 | 4 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
Table 1: pgroup values for 8 bit sampling | ||||
10 bit words | ||||
Color ---------------------------------------- | ||||
Subsampling Pixels #words octet alignment #samples pgroup | ||||
octets | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
|monochrome | 4 |P/I| | 4x10 | 40/8 = 5 | 4 | 5 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:1:1 | 4 |P/I| | 6x10 | 2x60/8 = 15 | 12 | 15 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:2:0 | 4 | P | | 6x10 | 2x60/8 = 15 | 12 | 15 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:2:0 | 4 | I | | 4x10 | 40/8 = 5 | 4 | 5 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:2:2 | 2 |P/I| | 4x10 | 40/8 = 5 | 4 | 5 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:4:4 | 1 |P/I| | 3x10 | 4x30/8 = 15 | 12 | 15 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
| 4:4:4:4 | 1 |P/I| | 4x10 | 40/8 = 5 | 4 | 5 | | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
Table 2: pgroup values for 10 bit sampling | ||||
The standard RTP header is followed by an 8 octet payload header for | 12 bit words | |||
Color ---------------------------------------- | ||||
Subsampling Pixels #words octet alignment #samples pgroup | ||||
octets | ||||
+-----------+------+---+ +------+---------------+---------------+ | ||||
|monochrome | 2 |P/I| | 2x12 | 2x12/8 = 3 | 2 | 3 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:1:1 | 4 |P/I| | 6x12 | 72/8 = 9 | 6 | 9 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:2:0 | 4 | P | | 6x12 | 72/8 = 9 | 6 | 9 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:2:0 | 4 | I | | 4x12 | 48/8 = 6 | 4 | 6 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:2:2 | 2 |P/I| | 4x12 | 48/8 = 6 | 4 | 6 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:4:4 | 2 |P/I| | 6x12 | 2x36/8 = 9 | 6 | 9 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:4:4:4 | 1 |P/I| | 4x12 | 48/8 = 6 | 4 | 6 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
Table 3: pgroup values for 12 bit sampling | ||||
16 bit words | ||||
Color -------------------------------------- | ||||
Subsampling Pixels #words octet alignment samples pgroup | ||||
octets | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
|monochrome | 1 |P/I| | 1x16 | 16/8 = 2 | 1 | 2 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:1:1 | 4 |P/I| | 6x16 | 6x16/8 = 12 | 6 | 12 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:2:0 | 4 | P | | 6x16 | 6x16/8 = 12 | 6 | 12 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:2:0 | 4 | I | | 4x16 | 4x16/8 = 8 | 4 | 8 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:2:2 | 2 |P/I| | 4x16 | 4x16/8 = 8 | 4 | 8 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:4:4 | 1 |P/I| | 3x16 | 3x16/8 = 6 | 3 | 6 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
| 4:4:4:4 | 1 |P/I| | 4x16 | 4x16/8 = 8 | 4 | 8 | | ||||
+-----------+------+---+ +------+---------------+-------+-------+ | ||||
Table 4: pgroup values for 16 bit sampling | ||||
4. RTP Packetization | ||||
The standard RTP header is followed by a 4 octet payload header that | ||||
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 payload data follow. For example, if two lines of | partial lines, of video data follow. This format makes the payload | |||
video are encapsulated, the payload format will be as shown in Figure 1. | header 32 bit aligned in the common case, where one scan line (fragment) | |||
of video is included in each RTP packet. | ||||
For example, if two lines of video are encapsulated, the payload format | ||||
will be as shown in Figure 1. | ||||
0 1 2 3 | 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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| V |P|X| CC |M| PT | Sequence No | | | V |P|X| CC |M| PT | Sequence Number | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Time Stamp | | | Time Stamp | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| SSRC | | | SSRC | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Scan Line No | Scan Offset | | | Extended Sequence Number | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Length |F|C| Z | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Scan Line No | Scan Offset | | |F| Scan Line No |C| Scan Offset | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Length |F|C| Z | | | Length |F| Scan Line No | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
|C| Scan Offset | . | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . | ||||
. . | . . | |||
. Two (partial) lines of video data . | . Two (partial) lines of video data . | |||
. . | . . | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 1: RTP Payload Format showing two (partial) lines of video | Figure 1: RTP Payload Format showing two (partial) lines of video | |||
5.1. The RTP Header | 4.1. The RTP Header | |||
The fields of the fixed RTP header have their usual meaning, with the | The fields of the fixed RTP header have their usual meaning, with the | |||
following additional notes: | following additional notes: | |||
Payload Type (PT): 7 bits | Payload Type (PT): 7 bits | |||
A dynamically allocated payload type field which designates the | A dynamically allocated payload type field which designates the | |||
payload as uncompressed video. | payload as uncompressed video. | |||
Timestamp: 32 bits | Timestamp: 32 bits | |||
A 90 kHz timestamp MUST be used to denote the sampling instant of | ||||
the video frame to which the RTP packet belongs. Packets MUST NOT | ||||
include data from multiple frames, and all packets belonging to the | ||||
same frame MUST have the same timestamp. | ||||
TBD: Consider whether the two fields of interlaced video MAY have | For progressive scan video, the timestamp denotes the sampling | |||
distinct timestamps. In some ways this is more "natural" for true | instant of the frame to which the RTP packet belongs. Packets MUST | |||
interlaced video and distinguishes it from "progressive segmented | NOT include data from multiple frames, and all packets belonging to | |||
frame" (PsF) mode in which the two fields really do refer to the | the same frame MUST have the same timestamp. | |||
same time instant. | ||||
For interlaced video, the timestamp denotes the sampling instant of | ||||
the field to which the RTP packet belongs. Packets MUST NOT | ||||
include data from multiple fields, and all packets belonging to the | ||||
same field MUST have the same timestamp. Use of field timestamps, | ||||
rather than a frame timestamp and and field indicator bit, is | ||||
needed to support reverse 3-2 pulldown. | ||||
A 90 kHz timestamp MUST be used in both cases. If the sampling | ||||
instant does not correspond to an integer value of the clock (as | ||||
may be the case when interleaving, the value SHALL be truncated to | ||||
the next lowest integer). | ||||
Marker bit (M): 1 bit | Marker bit (M): 1 bit | |||
The Marker bit denotes the end of a video frame, and MUST be set to | The Marker bit denotes the end of a video frame, and MUST be set to | |||
1 for the last packet of the video frame. It MUST be set to 0 for | 1 for the last packet of the video frame. It MUST be set to 0 for | |||
other packets. | other packets. | |||
5.2. Payload Header | Sequence Number: 16 bits | |||
Scan Line No : 16 bits | The low order bits for RTP sequence number. The standard 16 bit | |||
sequence number is augmented with another 16 bits in the payload | ||||
header, in order avoid problems due to wrap-around when operating | ||||
at high rate rates. | ||||
Scan line number of encapsulated data in network byte order. | 4.2. Payload Header | |||
Extended Sequence Number : 16 bits | ||||
The high order bits of the extended 32 bit sequence number, in | ||||
network byte order. | ||||
Scan Line No : 15 bits | ||||
Scan line number of encapsulated data, in network byte order. | ||||
Successive RTP packets MAY contains parts of the same scan line | Successive RTP packets MAY contains parts of the same scan line | |||
(with an incremented RTP sequence number, but the same timestamp), | (with an incremented RTP sequence number, but the same timestamp), | |||
if it is necessary to fragment a line. | if it is necessary to fragment a line. | |||
Scan Offset : 16 bits | Scan Offset : 15 bits | |||
Scan offset of the first sample in the payload data. If YCrCb | Scan offset of the first sample in the payload data. If YCrCb | |||
format data is being transported, this is the offset of the co- | format data is being transported, this is the offset of the co- | |||
sited luminance sample and if RGB format data is being transported | sited luminance sample and if RGB format data is being transported | |||
it is the offset of the red sample. The value is in network byte | it is the offset of the red sample. The value is in network byte | |||
order, and the offset has a value of zero if the first sample in | order, and the offset has a value of zero if the first sample in | |||
the payload corresponds to the start of the line. | the payload corresponds to the start of the line. | |||
Length: 16 bits | Length: 16 bits | |||
Number of octets of data included. This MUST be a multiple of the | Number of octets of data included from this scan line, in network | |||
pgroup value. | byte order. This MUST be a multiple of the pgroup value. | |||
Field Identification (F): 1 bit | Field Identification (F): 1 bit | |||
Identifies which field the scan line belongs to, for interlaced | Identifies which field the scan line belongs to, for interlaced | |||
data. F=0 identifies the the first field and F=1 the second field. | data. F=0 identifies the the first field and F=1 the second field. | |||
For progressive scan data (e.g. SMPTE 296M format video), F MUST | For progressive scan data (e.g. SMPTE 296M format video), F MUST | |||
always be set to zero. | always be set to zero. | |||
Continuation (more lines) bit (C): 1 bit | Continuation (more lines) bit (C): 1 bit | |||
Determines if an additional payload header follows the current | Determines if an additional scan line header follows the current | |||
header in the RTP packet. Set to 1 if an additional header follows, | scan line header in the RTP packet. Set to 1 if an additional | |||
implying that the RTP packet is carrying data for more than one | header follows, implying that the RTP packet is carrying data for | |||
scan line. Set to 0 otherwise. | more than one scan line. Set to 0 otherwise. An unlimited number | |||
of scan lines MAY be included, up to the path MTU limit. The only | ||||
Reserved (Z): 14 bits | way to determine the number of scan lines included per packet is to | |||
parse the payload headers. | ||||
These bits SHOULD be set to zero by the sender and MUST be ignored | ||||
by receivers. | ||||
5.3. Payload Data | 4.3. Payload Data | |||
Depending on the video format, each RTP packet can include either a | Depending on the video format, each RTP packet can include either a | |||
single complete scan line, a single fragment of a scan line, or one (or | single complete scan line, a single fragment of a scan line, or one (or | |||
more) complete scan lines plus a fragment of a scan line. Every scan | more) complete scan lines plus a fragment of a scan line. Every scan | |||
line or scan line fragment MUST begin at an octet boundary in the | line or scan line fragment MUST begin at an octet boundary in the | |||
payload data. | payload data. Scan lines SHOULD be fragmented so that the resulting RTP | |||
packet is smaller than the path MTU. | ||||
It is possible that the scan line length is not evenly divisible by the | ||||
number of pixels in a pgroup, so the final pixel data of a scan line | ||||
does not align to either an octet or pgroup boundary. Nonetheless the | ||||
payload MUST contain a whole number of pgroups; the sender MUST fill the | ||||
remaining bits of the final pgroup with zero and the receiver MUST | ||||
ignore the fill data. (In effect, the trailing edge of the image is | ||||
black-filled to a pgroup boundary.) | ||||
If the video is in YUV format, the packing of samples into the payload | If the video is in YUV format, the packing of samples into the payload | |||
depends on the color sub-sampling used. For RGB format video, there is a | depends on the color sub-sampling used. For RGB format video, there is a | |||
single packing scheme. | single packing scheme. | |||
For RGB format video, samples are packed in order Red-Green-Blue. All | For RGB format video, samples are packed in order Red-Green-Blue. All | |||
samples are the same bit size, which may be 8, 10, 12, or 16 bits. If 8 | samples are the same bit size, which may be 8, 10, 12, or 16 bits. If 8 | |||
bit samples are used, the pgroup is 3 octets. If 10 bit samples are | bit samples are used, the pgroup is 3 octets. If 10 bit samples are | |||
used, samples from adjacent pixels are packed with no padding, and the | used, samples from adjacent pixels are packed with no padding, and the | |||
pgroup is 15 octets (4 pixels). Refer to Tables 1 thru 4. | pgroup is 15 octets (4 pixels). Refer to Tables 1 thru 4. | |||
For RGBA format video, samples are packed in order Red-Green-Blue-Alpha. | For RGBA format video, samples are packed in order Red-Green-Blue-Alpha. | |||
All samples are the same bit size, which may be 8, 10, 12, or 16 bits. | All samples are the same bit size, which may be 8, 10, 12, or 16 bits. | |||
Refer to Tables 1 thru 4. | For pgroups refer to Tables 1 thru 4. | |||
For YUV 4:4:4 format video, samples are packed in order Cb-Y-Cr. Each | For YUV 4:4:4 format video, samples are packed in order Cb-Y-Cr for both | |||
sample is either an 8 bit or a 10 bit value. If 8 bit samples are used, | interlaced and progressive frames. Each sample is either an 8, 10, 12 or | |||
the pgroup is 3 octets. If 10 bit samples are used, samples from | 16 bit value. For relevant pgroups refer to Tables 1 to 4. | |||
adjacent pixels are packed with no padding, and the pgroup is 15 octets | ||||
(4 pixels). | ||||
For YUV 4:2:2 format video, the Cb and Cr components are horizontally | For YUV 4:2:2 format video, the Cb and Cr components are horizontally | |||
sub-sampled by a factor of two (each Cb and Cr samples corresponds to | sub-sampled by a factor of two (each Cb and Cr samples corresponds to | |||
two Y components). Samples are packed in order Cb0-Y0-Cr0-Y1. If 8 bit | two Y components). Samples are packed in order Cb0-Y0-Cr0-Y1 for both | |||
samples are used, the pgroup is 4 octets. If 10 bit samples are used, | interlaced and progressive scan lines. Samples are either an 8, 10, 12 | |||
the pgroup is 5 octets. | or 16 bit value. For relevant pgroups refer to Tables 1 to 4. | |||
(tbd: YUV 4:2:0 format video) | For YUV 4:1:1 format video, the Cb and Cr components are horizontally | |||
sub-sampled by a factor of four (each Cb and Cr sample corresponds to | ||||
four Y components). Samples are packed in order Cb0-Y0-Y1-Cr0-Y2-Y3 for | ||||
both interlaced and progressive scan lines. Samples are either an 8, 10, | ||||
12 or 16 bit value. For relevant pgroups refer to Tables 1 to 4. | ||||
It is possible that the scan line length is not evenly divisible by the | For YUV 4:2:0 video, the Cb and Cr components are sub-sampled by a | |||
number of pixels in a pgroup, so the final pixel data of a scan line | factor of two both horizontally and vertically. Therefore chrominance | |||
does not align to either an octet or pgroup boundary. Nonetheless the | values are shared between certain adjacent lines. Figure 2 illustrates | |||
payload MUST contain a whole number of pgroups; the sender MUST fill the | the composition of luminance and chrominance values for 6x6 pixel grid | |||
remaining bits of the final pgroup with zero and the receiver MUST | in 4:2:0 YUV video. | |||
ignore the fill data. (In effect, the trailing edge of the image is | ||||
black-filled to a pgroup boundary.) | ||||
6. Required Parameters | line 0: Y00 Y01 Y02 Y03 Y04 Y05 | |||
Cb00 Cr00 Cb01 Cr01 Cb02 Cr02 | ||||
line 1: Y10 Y11 Y12 Y13 Y14 Y15 | ||||
(tbd) | line 2: Y20 Y21 Y22 Y23 Y24 Y25 | |||
Cb10 Cr10 Cb11 Cr11 Cb12 Cr12 | ||||
line 3: Y30 Y31 Y32 Y33 Y34 Y35 | ||||
Parameters are: color mode (RGB/YUV), color sub-sampling | line 4: Y40 Y41 Y42 Y43 Y44 Y45 | |||
(4:4:4, 4:2:2, 4:2:0), lines per frame, pixels per line, bits | Cb20 Cr20 Cb21 Cr21 Cb22 Cr22 | |||
per sample and scan mode (progressive or interlaced). Propose | line 5: Y50 Y51 Y52 Y53 Y54 Y55 | |||
to map these to SDP a=fmtp: values. | Figure 2: Chrominance and luminance compostion in 4:2:0 YUV video. | |||
Optional parameters are: colorimetry (primaries, whitepoint, | Transport of progressive scan 4:2:0 YUV video entails the transport of | |||
reference medium), transfer function (log, gamma, toe | two scan lines together such that: | |||
treatment, black offset), image orientation, capture temporal | ||||
mode (field integration, frame integration, spot scan, | ||||
pushbroom scan). [286], [22028] | ||||
7. RTCP Considerations | line 0,1: | |||
Y00-Y01-Y10-Y11-Cb00-Cr00 Y02-Y03-Y12-Y13-Cb01-Cr01 | ||||
Y04-Y05-Y14-Y15-Cb02-Cr02 | ||||
RFC1889 recommends transmission of RTCP packets every 5 seconds or at a | line 2,3: | |||
reduced minimum in seconds of 360 divided by the session bandwidth in | Y20-Y21-Y30-Y31-Cb10-Cr10 Y22-Y23-Y32-Y33-Cb11-Cr11 | |||
kilobits/seconds. At the 1.485 Gbps (uncompressed HDTV rate) the reduced | Y24-Y25-Y34-Y35-Cb12-Cr12 | |||
minimum interval computes to 0.2ms or 4028 packets per second. | ||||
It should be noted that the sender's octet count in SR packets wraps | line 4,5: | |||
around in 23 seconds, and that the cumulative number of packets lost | Y40-Y41-Y50-Y51-Cb20-Cr20 Y42-Y43-Y52-Y53-Cb21-Cr21 | |||
wraps around in 93 seconds. This means these two fields cannot | Y44-Y45-Y54-Y55-Cb22-Cr22 | |||
accurately represent octet count and number of packets lost since the | ||||
beginning of transmission, as defined in RFC 1889. Therefore for network | ||||
monitoring purposes other means of keeping track of these variables | ||||
SHOULD be used. | ||||
8. IANA Considerations | For interlaced transportm chrominance values are transported with every | |||
other line: | ||||
This memo defines a new RTP payload format and associated MIME type. | field 0: | |||
The MIME registration form is enclosed below: | line 0: Y00-Y01-Cb00-Cr00 Y02-Y03-Cb01-Cr01 Y04-Y05-Cb02-Cr02 | |||
line 2: Y20-Y21 Y22-Y23 Y24-Y25 | ||||
line 4: Y40-Y41-Cb20-Cr20 Y42-Y43-Cb21-Cr21 Y44-Y45-Cb22-Cr22 | ||||
MIME media type name: video | field 1: | |||
line 1: Y10-Y11 Y12-Y13 Y14-Y15 | ||||
line 3: Y30-Y31-Cb10-Cr10 Y32-Y33-Cb11 Cr11 Y34-Y35-Cb12-Cr12 | ||||
line 5: Y50-Y51 Y52-Y53 Y54-Y55 | ||||
MIME subtype name: raw | 5. RTCP Considerations | |||
Required parameters: rate | RTCP SHOULD be used as specified in RFC1889 [RTP], which specifies two | |||
limits on the RTCP packet rate: RTCP bandwidth should be limited to 5% | ||||
of the data rate, and the minimum for the average of the randomized | ||||
intervals between RTCP packets should be 5 seconds. Considering the | ||||
high data rate of many uncompressed video formats, the minimum interval | ||||
is the governing factor in many cases. | ||||
Optional parameters: (tbd) | It should be noted 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. This means these two fields may not accurately | ||||
represent octet count and number of packets lost since the beginning of | ||||
transmission, as defined in RFC 1889. Therefore for network monitoring | ||||
purposes other means of keeping track of these variables SHOULD be used. | ||||
Encoding considerations: Uncompressed video can be transmitted with | 6. IANA Considerations | |||
RTP as specified in RFC XXXX | ||||
Security considerations: See section 9 of RFC XXXX | 6.1. MIME type registration | |||
Interoperability considerations: NONE | MIME media type name: video | |||
Published specification: RFC XXXX | MIME subtype name: raw | |||
Applications which use this media type: Video communication. | Required parameters: | |||
Additional information: None | rate: The RTP timestamp clock rate. Applications using this payload | |||
format MUST be 90000 for this format. | ||||
Magic number(s): None | pgroup: The number of octets per the pixel group. See section 3 of | |||
RFC XXXX. | ||||
File extension(s): None | color-mode: Determines the color mode of the video stream. Valid | |||
values for this parameter are: RGB, RGBA, and YUV. | ||||
Macintosh File Type Code(s): None | sub-sampling: Determines the type of color sub-sampling of the | |||
video stream. Valid values are: mono, 4:1:1, 4:2:0, 4:2:2, 4:4:4 | ||||
and 4:4:4:4. | ||||
Person & email address to contact for further information: | width: Determines the number of pixels per line. This is an integer | |||
Ladan Gharai <ladan@isi.edu> | between 1 and 32767. | |||
IETF AVT working group. | ||||
Intended usage: COMMON | height: Determines the number of lines per frame. This is an | |||
integer between 1 and 32767. | ||||
Author/Change controller: | depth: Determines the number of bits per samples. This is a decimal | |||
Ladan Gharai <ladan@isi.edu> | integer; typical values include 8, 10, 12, and 16. | |||
9. Mapping to SDP Parameters | colorimetry: This parameter defines the set of colorimetric | |||
specfications and other transfer characteristics for the video | ||||
source, by reference to an external specification. Valid values and | ||||
their specification are: | ||||
Parameters are mapped to SDP [SDP] as follows: | BT601-5 ITU Recommendation BT.601-5 [601] | |||
BT709-2 ITU Recommendation BT.709-2 [709] | ||||
SMPTE240M SMPTE standard 240M [240M] | ||||
NTSC The NTSC specification [NTSC] | ||||
PAL The PAL specificaiton [PAL] | ||||
m=video 30000 RTP/AVP 111 | New values may be registered as described in section 6.2 of RFC | |||
a=rtpmap:111 raw/90000 | XXXX. | |||
a=fmtp:111 (tbd) | ||||
Optional parameters: | ||||
Interlace: If this optional parameter is present it indicates that | ||||
the video stream is interlaced. If absent, progressive scan is | ||||
implied. | ||||
Encoding considerations: Uncompressed video can be transmitted with RTP | ||||
as specified in RFC XXXX. No file format is defined at this time. | ||||
Security considerations: See section 9 of RFC XXXX. | ||||
Interoperability considerations: NONE. | ||||
Published specification: RFC XXXX. | ||||
Applications which use this media type: Video communication. | ||||
Additional information: None | ||||
Magic number(s): None | ||||
File extension(s): None | ||||
Macintosh File Type Code(s): None | ||||
Person & email address to contact for further information: | ||||
Ladan Gharai <ladan@isi.edu> | ||||
IETF Audio/Video Transport working group. | ||||
Intended usage: COMMON | ||||
Author/Change controller: Ladan Gharai <ladan@isi.edu> | ||||
6.2. Parameter Registration | ||||
New values of the "colorimetry" 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]). | ||||
7. Mapping to SDP Parameters | ||||
Parameters are mapped to SDP [SDP] as in the following example: | ||||
m=video 30000 RTP/AVP 112 | ||||
a=rtpmap:112 raw/90000 | ||||
a=fmtp:112 color-mode=YUV; sub-sampling=4:2:2; width=1280; height=720; | ||||
depth=10; colorimetry=BT.709-2 | ||||
In this example, a dynamic payload type 111 is used for uncompressed | In this example, a dynamic payload type 111 is used for uncompressed | |||
video. The RTP sampling clock is 90kHz. | 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 the | ||||
SDP file. | ||||
10. 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 | |||
potential denial-of-service threat. | 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 (270 Mbps for standard definition video, and | bandwidth requirements (up 270 Mbps for standard definition video, and | |||
approximately 1 Gbps for high definition video), and is not congestion | approximately 1 Gbps for high definition video). This is sufficient to | |||
controlled. This is sufficient to cause potential for denial-of-service | cause potential for denial-of-service if transmitted onto most currently | |||
if transmitted onto most currently available Internet paths. Use of the | available Internet paths. | |||
payload format defined here MUST be narrowly limited to suitably | ||||
connected private networks, or to networks where quality of service | ||||
guarantees are available. This potential threat is common to all high | ||||
rate applications without congestion control. | ||||
11. Relation to RFC 2431 | Accordingly, if best-effort service is being used, users of this payload | |||
format SHOULD 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 which 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 | In comparison with RFC 2431 this memo specifies support for a wider | |||
variety of uncompressed video, in terms of frame size, color subsampling | variety of uncompressed video, in terms of frame size, color subsampling | |||
and sample sizes. While [BT656] can transport up to 4096 scan lines and | and sample sizes. While [BT656] can transport up to 4096 scan lines and | |||
2048 pixels per line, our payload type can support up to 64k scan lines | 2048 pixels per line, our payload type can support up to 64k scan lines | |||
and pixels per line. Also, RFC 2431 only address 4:2:2 YUV data, while | and pixels per line. Also, RFC 2431 only address 4:2:2 YUV data, while | |||
this memo covers YUV and RGB and most common color subsampling schemes. | this memo covers YUV and RGB and most common color subsampling schemes. | |||
Given the variety of video types that we cover, this memo also assumes | 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 | out-of-band signaling for sample size and data types (RFC 2431 uses in | |||
band signaling). | band signaling). | |||
12. Full Copyright Statement | 10. Relation to RFC YYYY | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | (tbd) | |||
Relation [292RTP] | ||||
11. Full Copyright Statement | ||||
Copyright (C) The Internet Society (2003). 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 | |||
on all such copies and derivative works. | on all such copies and derivative works. | |||
However, this document itself may not be modified in any way, such as by | 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 | removing the copyright notice or references to the Internet Society or | |||
skipping to change at page 12, line 32 ¶ | skipping to change at page 16, line 4 ¶ | |||
The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
This document and the information contained herein is provided on an "AS | This document and the information contained herein is provided on an "AS | |||
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 MERCHANTABILITY OR | INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR | |||
FITNESS FOR A PARTICULAR PURPOSE." | FITNESS FOR A PARTICULAR PURPOSE." | |||
12. Acknowledgements | ||||
13. Acknowledgements | ||||
The authors are grateful to Philippe Gentric and Chuck Harrison for | The authors are grateful to Philippe Gentric and Chuck Harrison for | |||
their feedback. | their feedback. | |||
14. Authors' Addresses | 13. Authors' Addresses | |||
Ladan Gharai <ladan@isi.edu> | Ladan Gharai <ladan@isi.edu> | |||
Colin Perkins <csp@csperkins.org> | Colin Perkins <csp@csperkins.org> | |||
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 | |||
Bibliography | ||||
Normative References | ||||
[RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, | ||||
"RTP: A Transport Protocol for Real-Time Applications", | ||||
Internet Engineering Task Force, RFC 1889, January 1996. | ||||
[2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement | ||||
Levels", RFC 2119. | ||||
[2434] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA | ||||
Considerations Section in RFCs", RFC 2434, October 1998. | ||||
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 Interfaces | 1920x1080 Scanning and Analog and Parallel Digital Interfaces | |||
for Multiple Picture Rates, SMPTE 274M-1998. | 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.) | |||
[296] Society of Motion Picture and Television Engineers, | [296] Society of Motion Picture and Television Engineers, | |||
1280x720 Scanning, Analog and Digital Representation and Analog | 1280x720 Scanning, Analog and Digital Representation and Analog | |||
Interfaces, SMPTE 296M-1998. | Interfaces, SMPTE 296M-1998. | |||
[372] Society of Motion Picture and Television Engineers, | [372] Society of Motion Picture and Television Engineers, | |||
Dual Link 292M Interface for 1920 x 1080 Picture Raster, | Dual Link 292M Interface for 1920 x 1080 Picture Raster, | |||
SMPTE 372M-2002. | SMPTE 372M-2002. | |||
[2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement | ||||
Levels", RFC 2119. | ||||
[ALF] Clark, D. D., and Tennenhouse, D. L., "Architectural | [ALF] Clark, D. D., and Tennenhouse, D. L., "Architectural | |||
Considerations for a New Generation of Protocols", In | Considerations for a New Generation of Protocols", In | |||
Proceedings of SIGCOMM '90 (Philadelphia, PA, Sept. 1990), ACM. | Proceedings of SIGCOMM '90 (Philadelphia, PA, Sept. 1990), ACM. | |||
[SDP] M. Handley and V. Jacobson, "SDP: Session Description Protocol", | [SDP] M. Handley and V. Jacobson, "SDP: Session Description Protocol", | |||
RFC 2327, April 1998. | 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. | |||
[RTP] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, | ||||
"RTP: A Transport Protocol for Real-Time Applications", | ||||
Internet Engineering Task Force, RFC 1889, January 1996. | ||||
[292RTP] L. Gharai et al., "RTP Payload Format for SMPTE 292M Video", | [292RTP] L. Gharai et al., "RTP Payload Format for SMPTE 292M Video", | |||
Internet Draft, draft-ietf-avt-smpte292-video-07.txt, | Internet Draft, draft-ietf-avt-smpte292-video-07.txt, | |||
Work in progress. | Work in progress. | |||
[601] International Telecommunication Union, "Studio encoding | [601] International Telecommunication Union, "Studio encoding | |||
parameters of digital television for standard 4:3 and wide | parameters of digital television for standard 4:3 and wide | |||
screen 16:9 aspect ratios", Recommendation BT.601, October 1995. | screen 16:9 aspect ratios", Recommendation BT.601, October 1995. | |||
[656] International Telecommunication Union, "Interfaces for Digital | [656] International Telecommunication Union, "Interfaces for Digital | |||
Component Video Signals in 525-line and 625-line Television | Component Video Signals in 525-line and 625-line Television | |||
Systems Operating at the 4:2:2 Level of Recommendation ITU-R | Systems Operating at the 4:2:2 Level of Recommendation ITU-R | |||
BT.601 (Part A)", Recommendation BT.656, April 1998. | BT.601 (Part A)", Recommendation 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] ITU Recommendation BT.709-2 | ||||
[240M] SMPTE Standard 240M | ||||
[NTSC] (tbd) | ||||
[PAL] (tbd) | ||||
End of changes. 76 change blocks. | ||||
220 lines changed or deleted | 375 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |