draft-ietf-avt-smpte292-video-06.txt | draft-ietf-avt-smpte292-video-07.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Ladan Gharai | INTERNET-DRAFT Ladan Gharai | |||
<draft-ietf-avt-smpte292-video-06.txt> USC/ISI | <draft-ietf-avt-smpte292-video-07.txt> USC/ISI | |||
Colin Perkins | Colin Perkins | |||
USC/ISI | USC/ISI | |||
Gary Goncher | Gary Goncher | |||
Tektronix | Tektronix | |||
Allison Mankin | Allison Mankin | |||
USC/ISI | USC/ISI | |||
June 30, 2002 | August 14, 2002 | |||
RTP Payload Format for SMPTE 292M Video | RTP Payload Format for SMPTE 292M Video | |||
<draft-ietf-avt-smpte292-video-06.txt> | <draft-ietf-avt-smpte292-video-07.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 14 ¶ | skipping to change at page 2, line 14 ¶ | |||
1. Introduction | 1. Introduction | |||
[Note to RFC Editor: All "RFC XXXX" in the IANA considerations section | [Note to RFC Editor: All "RFC XXXX" in the IANA considerations section | |||
should be filled in with the RFC number of this memo, when published.] | should be filled in with the RFC number of this memo, when published.] | |||
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 High Definition Television (HDTV) | of interchange for uncompressed High Definition Television (HDTV) | |||
between various types of video equipment (cameras, encoders, VTRs, | between various types of video equipment (cameras, encoders, VTRs, | |||
etc.). SMPTE 292M stipulates that the source data be in 10 bit words and | etc.). SMPTE 292M stipulates that the source data be in 10 bit words and | |||
the total data rate be 1.485 Gbps or 1.485/1.001 Gbps. | the total data rate be either 1.485 Gbps or 1.485/1.001 Gbps. | |||
The use of a dedicated serial interconnect is appropriate in a studio | The use of a dedicated serial interconnect is appropriate in a studio | |||
environment, but it is desirable to leverage the widespread availability | environment, but it is desirable to leverage the widespread availability | |||
of high bandwidth IP connectivity to allow efficient wide area delivery | of high bandwidth IP connectivity to allow efficient wide area delivery | |||
of SMPTE 292M format content. Accordingly, this memo defines an RTP | of SMPTE 292M format content. Accordingly, this memo defines an RTP | |||
payload format for SMPTE 292M format video. | payload format for SMPTE 292M format video. | |||
It is to be noted that SMPTE 292M streams have a constant high bit rate | It is to be noted that SMPTE 292M streams have a constant high bit rate | |||
and are not congestion controlled. Accordingly, use of this payload | and are not congestion controlled. Accordingly, use of this payload | |||
format should be tightly controlled and limited to private networks or | format should be tightly controlled and limited to private networks or | |||
those networks that provide resource reservation and enhanced quality of | those networks that provide resource reservation and enhanced quality of | |||
service. | service. | |||
This memo only addresses the transfer of uncompressed HDTV. Compressed | ||||
HDTV is a subset of MPEG-2 [6], which is fully described in document | ||||
A/53 [7] of the Advanced Television Standards Committee. The ATSC has | ||||
also adopted the MPEG-2 transport system (ISO/IEC 13818-1)[8]. | ||||
Therefore RFC 2250 [9] sufficiently describes transport for compressed | ||||
HDTV over RTP. | ||||
2. Overview of SMPTE 292M | ||||
A SMPTE 292M television line comprises two interleaved streams, one | A SMPTE 292M television line comprises two interleaved streams, one | |||
containing the luminance (Y) samples, the other chrominance (CrCb) | containing the luminance (Y) samples, the other chrominance (CrCb) | |||
values. Since chrominance is horizontally sub-sampled (4:2:2 coding) the | values. Since chrominance is horizontally sub-sampled (4:2:2 coding) the | |||
lengths of the two streams match. Each stream is divided into four | lengths of the two streams match (see Figure 3 of SMPTE 292M[1]). In | |||
parts, (figure 1): (1) start of active video timing reference (SAV); (2) | addition to being the same length the streams also have identical | |||
digital active line; (3) end of active video timing reference (EAV); and | structures: each stream is divided into four parts, (figure 1): (1) | |||
(4) digital line blanking. A SMPTE 292M line may also carry horizontal | start of active video timing reference (SAV); (2) digital active line; | |||
ancillary data (H-ANC) or vertical ancillary data (V-ANC) instead of the | (3) end of active video timing reference (EAV); and (4) digital line | |||
blanking level, and likewise, ancillary data may transported instead of | blanking. A SMPTE 292M line may also carry horizontal ancillary data | |||
a digital active line. | (H-ANC) or vertical ancillary data (V-ANC) instead of the blanking | |||
level, and likewise, ancillary data may be transported instead of a | ||||
digital active line. | ||||
The EAV and SAV are made up of three 10 bit words, with constant values | The EAV and SAV are made up of three 10 bit words, with constant values | |||
of 0x000 0x000 0x3FF and an additional word (designated as XYZ in figure | of 0x3FF 0x000 0x000 and an additional word (designated as XYZ in | |||
2), carrying a number of flags. This includes an F flag which designate | figure 2), carrying a number of flags. This includes an F flag which | |||
which field (1 or 2) the line is transporting and also a V flag which | designate which field (1 or 2) the line is transporting and also a V | |||
indicates field blanking. Table 1, further displays the code values in | flag which indicates field blanking. Table 1, further displays the code | |||
SAV and EAV. After EAV, are two words LN1 and LN2 (Table 2), which | values in SAV and EAV. After EAV, are two words LN0 and LN1 (Table 2), | |||
carry the 11 bit line number for the SMPTE 292M line, immediately | which carry the 11 bit line number for the SMPTE 292M line. The Cyclic | |||
following. The Cyclic Redundancy Check, CRC, is a two word value, shown | Redundancy Check, CRC, is also a two word value, shown as CR0 and CR1 in | |||
as CR0 and CR1 in figure 2. | figure 2. | |||
+------------+-----------------------+-----+---------------------+ | +------------+-----------------------+-----+---------------------+ | |||
| | Digital Line Blanking | | Digital Active Line | | | | Digital Line Blanking | | Digital Active Line | | |||
| EAV+LN+CRC | (Blanking level or | SAV | (Active Picture or | | | EAV+LN+CRC | (Blanking level or | SAV | (Active Picture or | | |||
| | Ancillary Data) | | Ancillary Data) | | | | Ancillary Data) | | Ancillary Data) | | |||
+------------+-----------------------+-----+---------------------+ | +------------+-----------------------+-----+---------------------+ | |||
Figure 1. The SMPTE 292M line format. | Figure 1. The SMPTE 292M line format. | |||
0 20 40 60 80 0 20 40 | 0 20 40 60 80 0 20 40 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | |||
|3FF| 0 | 0 |XYZ|LN1|LN2|CR0|CR1| |3FF| 0 | 0 |XYZ| | |3FF| 0 | 0 |XYZ|LN1|LN2|CR0|CR1| |3FF| 0 | 0 |XYZ| | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | |||
<---- EAV -----> <- LN-> <- CRC-> <----- SAV -----> | <---- EAV -----> <- LN-> <- CRC-> <----- SAV -----> | |||
Figure 2. Timing reference format. | Figure 2. Timing reference format. | |||
The complete SMPTE 292M stream comprises the sample interleaving of | ||||
luminance and chrominance streams, including SAV, EAV and the other | ||||
headers (see Figure 3 of SMPTE 292M [1]). Since the two streams are | ||||
representing the same video line, their line number, field number and | ||||
blanking fields will match. | ||||
+---------------------------------------------------------+ | +---------------------------------------------------------+ | |||
| (MSB) (LSB) | | | (MSB) (LSB) | | |||
| Word 9 8 7 6 5 4 3 2 1 0 | | | Word 9 8 7 6 5 4 3 2 1 0 | | |||
+---------------------------------------------------------+ | +---------------------------------------------------------+ | |||
| 3FF 1 1 1 1 1 1 1 1 1 1 | | | 3FF 1 1 1 1 1 1 1 1 1 1 | | |||
| 000 0 0 0 0 0 0 0 0 0 0 | | | 000 0 0 0 0 0 0 0 0 0 0 | | |||
| 000 0 0 0 0 0 0 0 0 0 0 | | | 000 0 0 0 0 0 0 0 0 0 0 | | |||
| XYZ 1 F V H P P P P P P | | | XYZ 1 F V H P P P P P P | | |||
+---------------------------------------------------------+ | +---------------------------------------------------------+ | |||
| NOTES: | | | NOTES: | | |||
skipping to change at page 4, line 20 ¶ | skipping to change at page 4, line 20 ¶ | |||
| LN1 R R R R L10 L9 L8 L7 R R | | | LN1 R R R R L10 L9 L8 L7 R R | | |||
+---------------------------------------------------------+ | +---------------------------------------------------------+ | |||
| NOTES: | | | NOTES: | | |||
| LN0 - L10 - line number in binary code. | | | LN0 - L10 - line number in binary code. | | |||
| R = reserved, set to "0". | | | R = reserved, set to "0". | | |||
+---------------------------------------------------------+ | +---------------------------------------------------------+ | |||
Table 2: Line number data. | Table 2: Line number data. | |||
The number of words and format for active lines and line blanking is | The number of words and format for active lines and line blanking is | |||
defined by source format documents. Currently, source video formats | defined by source format documents. Currently, source video formats | |||
transfered by SMPTE 292M includes SMPTE 260M, 295M, 274M and 296M[2-5]. | transfered by SMPTE 292M include SMPTE 260M, 295M, 274M and 296M[2-5]. | |||
In this memo we specify how to transfer SMPTE 292M over RTP, | In this memo we specify how to transfer SMPTE 292M over RTP, | |||
irrespective of the source format. | irrespective of the source format. | |||
This memo only addresses the transfer of uncompressed HDTV. Compressed | 3. Conventions Used in this Document | |||
HDTV is a subset of MPEG-2 [6], which is fully described in document | ||||
A/53 [7] of the Advanced Television Standards Committee. The ATSC has | ||||
also adopted the MPEG-2 transport system (ISO/IEC 13818-1)[8]. | ||||
Therefore RFC 2250 [9] sufficiently describes transport for compressed | ||||
HDTV over RTP. | ||||
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[10]. | document are to be interpreted as described in RFC 2119[10]. | |||
3. Payload Design | 4. Payload Design | |||
Each SMPTE 292M data line is packetized into one or more RTP packets. | Each SMPTE 292M data line is packetized into one or more RTP packets. | |||
This includes all timing signals, blanking levels, active lines and/or | This includes all timing signals, blanking levels, active lines and/or | |||
ancillary data. Start of active video (SAV) and end of active video | ancillary data. Start of active video (SAV) and end of active video | |||
(EAV+LN+CRC) signals MUST NOT be fragmented across packets, as the SMPTE | (EAV+LN+CRC) signals MUST NOT be fragmented across packets, as the SMPTE | |||
292M decoder uses them to detect the start of scan lines. | 292M decoder uses them to detect the start of scan lines. | |||
The standard RTP header is followed by a 4 octet payload header. All | The standard RTP header is followed by a 4 octet payload header. All | |||
information in the payload header pertains to the first data sample in | information in the payload header pertains to the first data sample in | |||
the packet. The end of a video frame (the packet containing the last | the packet. The end of a video frame (the packet containing the last | |||
sample before the EAV) is marked by the M bit in the RTP header. | sample before the EAV) is marked by the M bit in the RTP header. | |||
The payload header contains a 16 bit extension to the standard 16 bit | The payload header contains a 16 bit extension to the standard 16 bit | |||
RTP sequence number, thereby extending the sequence number to 32 bits | RTP sequence number, thereby extending the sequence number to 32 bits | |||
and enabling RTP to accommodate HDTV's high data rates. At 1.485 Gbps, | and enabling RTP to accommodate HDTV's high data rates. At 1.485 Gbps, | |||
with packet sizes of at least one thousand octets, 32 bits allows for an | with packet sizes of at least one thousand octets, 32 bits allows for an | |||
approximate 6 hour period before the sequence number wraps around. | approximate 6 hour period before the sequence number wraps around. Given | |||
the same assumptions, the standard 16 bit RTP sequence number wraps | ||||
around in less than a second (336 milliseconds) which is clearly not | ||||
sufficient for the purpose of detecting loss and out of order packets. | ||||
A 148.5 MHz (or 148.5/1.001 MHz) time-stamp is used as the RTP | ||||
timestamp. This allows the 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 296M). With this timestamp, the location of | ||||
the first byte of each packet can be uniquely identified in the SMPTE | ||||
292M stream. At 148.5 MHz the 32 bit timestamp wraps around in 21 | ||||
seconds. | ||||
The payload header also carries the 11 bit line number from the SMPTE | The payload header also carries the 11 bit line number from the SMPTE | |||
292M timing signals. This provides more information at the application | 292M timing signals. This provides more information at the application | |||
level and adds a level of resiliency, in case the packet containing the | level and adds a level of resiliency, in case the packet containing the | |||
EAV is lost. | EAV is lost. | |||
A 148.5 MHz (or 148.5/1.001 MHz) time-stamp is used as the RTP | ||||
timestamp. This allows the 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 296M). | ||||
The bit length of both timing signals, SAV and EAV+LN+CRC, are multiples | The bit length of both timing signals, SAV and EAV+LN+CRC, are multiples | |||
of 8 bits, 40 bits and 80 bits, respectively, and therefore are | of 8 bits, 40 bits and 80 bits, respectively, and therefore are | |||
naturally octet aligned. | naturally octet aligned. | |||
For the video content it is desirable for the video to both octet align | For the video content it is desirable for the video to both octet align | |||
when packetized and also adhere to the principles of application level | when packetized and also adhere to the principles of application level | |||
framing, also known as ALF [11]. For YCrCb video, the ALF principle | framing, also known as ALF [11]. For YCrCb video, the ALF principle | |||
translates into not fragmenting related luminance and chrominance values | translates into not fragmenting related luminance and chrominance values | |||
across packets. For example with the 4:2:0 color subsampling a 4 pixel | across packets. For example with the 4:2:0 color subsampling a 4 pixel | |||
group is represented by 6 values, Y1 Y2 Y3 Y4 Cr Cb, and video content | group is represented by 6 values, Y1 Y2 Y3 Y4 Cr Cb, and video content | |||
skipping to change at page 6, line 17 ¶ | skipping to change at page 6, line 17 ¶ | |||
|Subsampling Pixels words aligned on octet# pgroup| | |Subsampling Pixels words aligned on octet# pgroup| | |||
+-----------+-------+--------+-------------------+------+ | +-----------+-------+--------+-------------------+------+ | |||
| 4:2:0 | 4 | 6*10 | 2*60/8 = 15 | 15 | | | 4:2:0 | 4 | 6*10 | 2*60/8 = 15 | 15 | | |||
+-----------+-------+--------+-------------------+------+ | +-----------+-------+--------+-------------------+------+ | |||
| 4:2:2 | 2 | 4*10 | 40/8 = 5 | 5 | | | 4:2:2 | 2 | 4*10 | 40/8 = 5 | 5 | | |||
+-----------+-------+--------+-------------------+------+ | +-----------+-------+--------+-------------------+------+ | |||
| 4:4:4 | 1 | 3*10 | 4*30/8 = 15 | 15 | | | 4:4:4 | 1 | 3*10 | 4*30/8 = 15 | 15 | | |||
+-----------+-------+--------+-------------------+------+ | +-----------+-------+--------+-------------------+------+ | |||
Table 3. Color subsampling and pgroups. | Table 3. Color subsampling and pgroups. | |||
4. RTP Packetization | 5. RTP Packetization | |||
The standard RTP header is followed by a 4 octet payload header, and the | The standard RTP header is followed by a 4 octet payload header, and the | |||
payload data, as shown in Figure 4. | payload data, as shown in Figure 4. | |||
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# (low bits) | | | V |P|X| CC |M| PT | sequence# (low bits) | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| time stamp | | | time stamp | | |||
skipping to change at page 6, line 40 ¶ | skipping to change at page 6, line 40 ¶ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| sequence# (high bits) |F|V| Z | line no | | | sequence# (high bits) |F|V| Z | line no | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
: SMPTE 292M data : | : SMPTE 292M data : | |||
: : | : : | |||
| | | | | | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
Figure 4: RTP Packet showing SMPTE 292M headers and payload | Figure 4: RTP Packet showing SMPTE 292M headers and payload | |||
4.1. The RTP Header | 5.1. The RTP Header | |||
The following fields of the RTP fixed header are used for SMPTE 292M | The following fields of the RTP fixed header are used for SMPTE 292M | |||
encapsulation (the other fields in the RTP header are used in their | encapsulation (the other fields in the RTP header are used in their | |||
usual manner): | usual manner): | |||
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 SMPTE 292M. | payload as SMPTE 292M. | |||
Timestamp: 32 bits | Timestamp: 32 bits | |||
skipping to change at page 7, line 24 ¶ | skipping to change at page 7, line 24 ¶ | |||
The Marker bit denotes the end of a video frame, and is set to 1 | 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 the last packet of the video frame and is otherwise set to 0 | |||
for all other packets. | for all other packets. | |||
Sequence Number (low bits): 16 bits | Sequence Number (low bits): 16 bits | |||
The low order bits for RTP sequence counter. The standard 16 bit | The low order bits for RTP sequence counter. The standard 16 bit | |||
RTP sequence number is augmented with another 16 bits in the | RTP sequence number is augmented with another 16 bits in the | |||
payload header in order to accommodate the 1.485 Gbps data rate of | payload header in order to accommodate the 1.485 Gbps data rate of | |||
SMPTE 292M. | SMPTE 292M. | |||
4.2. Payload Header | 5.2. Payload Header | |||
Sequence Number (high bits): 16 bits | Sequence Number (high bits): 16 bits | |||
The high order bits for the 32 bit RTP sequence counter, in network | The high order bits for the 32 bit RTP sequence counter, in network | |||
byte order. | byte order. | |||
F: 1 bit | F: 1 bit | |||
The F bit as defined in the SMPTE 292M timing signals (see | The F bit as defined in the SMPTE 292M timing signals (see | |||
Table 1). F=1 identifies field 2 and F=0 identifies field 1. | Table 1). F=1 identifies field 2 and F=0 identifies field 1. | |||
V: 1 bit | V: 1 bit | |||
skipping to change at page 8, line 5 ¶ | skipping to change at page 8, line 5 ¶ | |||
Z: 2 bits | Z: 2 bits | |||
SHOULD be set to zero by the sender and MUST be ignored by | SHOULD be set to zero by the sender and MUST be ignored by | |||
receivers. | receivers. | |||
Line No: 11 bits | Line No: 11 bits | |||
The line number of the source data format, extracted from the | The line number of the source data format, extracted from the | |||
SMPTE 292M stream (see Table 2). The line number MUST correspond | SMPTE 292M stream (see Table 2). The line number MUST correspond | |||
to the line number of the first 10 bit word in the packet. | to the line number of the first 10 bit word in the packet. | |||
5. RTCP Considerations | 6. RTCP Considerations | |||
RFC1889 recommends transmission of RTCP packets every 5 seconds or at a | RFC1889 recommends transmission of RTCP packets every 5 seconds or at a | |||
reduced minimum in seconds of 360 divided by the session bandwidth in | reduced minimum in seconds of 360 divided by the session bandwidth in | |||
kilo bits/seconds. At 1.485 Gbps the reduced minimum interval computes | kilobits/second. At 1.485 Gbps the reduced minimum interval computes to | |||
to 0.2ms or 4028 packets per second. | 0.2ms or 4028 packets per second. | |||
It should be noted that the sender's octet count in SR packets wraps | It should be noted that the sender's octet count in SR packets wraps | |||
around in 23 seconds, and that the cumulative number of packets lost | around in 23 seconds, and that the cumulative number of packets lost | |||
wraps around in 93 seconds. This means these two fields cannot | wraps around in 93 seconds. This means these two fields cannot | |||
accurately represent octet count and number of packets lost since the | accurately represent octet count and number of packets lost since the | |||
beginning of transmission, as defined in RFC1889. Therefore for network | beginning of transmission, as defined in RFC1889. Therefore for network | |||
monitoring purposes other means of keeping track of these variables | monitoring purposes or any other application which requires the sender's | |||
should be used. | octet count and the cumulative number of packets lost since the | |||
beginning of transmission, the application itself must keep track of the | ||||
number of rollovers of these fields via a counter. | ||||
6. IANA Considerations | 7. IANA Considerations | |||
This document defines a new RTP payload format and associated MIME type, | This document defines a new RTP payload format and associated MIME type, | |||
SMPTE292M. The MIME registration form for SMPTE 292M video is enclosed | SMPTE292M. The MIME registration form for SMPTE 292M video is enclosed | |||
below: | below: | |||
MIME media type name: video | MIME media type name: video | |||
MIME subtype name: SMPTE292M | MIME subtype name: SMPTE292M | |||
Required parameters: rate | Required parameters: rate | |||
The RTP timestamp clock rate. The clock runs at either 148500000 Hz | The RTP timestamp clock rate. The clock runs at either 148500000 Hz | |||
or 148500000/1.001 Hz. If the latter rate is used a timestamp of | or 148500000/1.001 Hz. If the latter rate is used a timestamp of | |||
148351000 MUST be used, and receivers MUST interpret this as | 148351648 MUST be used, and receivers MUST interpret this as | |||
148500000/1.001 Hz. | 148500000/1.001 Hz. | |||
Optional parameters: pgroup | Optional parameters: pgroup | |||
The RECOMMENDED grouping for aligning 10 bit words and octets. | The RECOMMENDED grouping for aligning 10 bit words and octets. | |||
Defaults to 1 octet, if not present. | Defaults to 1 octet, if not present. | |||
Encoding considerations: SMPTE292M video can be transmitted with | Encoding considerations: SMPTE292M video can be transmitted with | |||
RTP as specified in RFC XXXX. | RTP as specified in RFC XXXX. | |||
Security considerations: see RFC XXXX section 8. | Security considerations: see RFC XXXX section 8. | |||
skipping to change at page 9, line 22 ¶ | skipping to change at page 9, line 25 ¶ | |||
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> | |||
IETF AVT working group. | IETF AVT working group. | |||
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 | 8. Mapping to SDP Parameters | |||
Parameters are mapped to SDP [12] as follows: | Parameters are mapped to SDP [12] as follows: | |||
m=video 30000 RTP/AVP 111 | m=video 30000 RTP/AVP 111 | |||
a=rtpmap:111 SMPTE292M/148500000 | a=rtpmap:111 SMPTE292M/148500000 | |||
a=fmtp:111 pgroup=5 | a=fmtp:111 pgroup=5 | |||
In this example, a dynamic payload type 111 is used for SMPTE292M. The | In this example, a dynamic payload type 111 is used for SMPTE292M. The | |||
RTP timestamp is 148500000 Hz and the SDP parameter pgroup, indicates | RTP timestamp is 148500000 Hz and the SDP parameter pgroup, indicates | |||
that for video data after the SAV signal, must be packetized in | that for video data after the SAV signal, must be packetized in | |||
multiples of 5 octets. | multiples of 5 octets. | |||
8. Security Considerations | 9. 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 perhaps to be noted that the bandwidth of this payload is high | It is perhaps to be noted that the bandwidth of this payload is high | |||
enough (1.485 Gbps without the RTP overhead) to cause potential for | enough (1.485 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. Given that congestion control is not possible for SMPTE 292M over | |||
control mechanism for flows of this sort, use of the payload should be | RTP flows, use of the payload should be narrowly limited to suitably | |||
narrowly limited to suitably connected network endpoints, or to networks | connected network endpoints, or to networks where QoS guarantees are | |||
where QoS guarantees are available, and great care taken with the scope | available, and great care taken with the scope of multicast | |||
of multicast transmissions. This potential threat is common to all high | transmissions. This potential threat is common to all high bit rate | |||
bit rate applications without congestion control. | applications without congestion control. | |||
9. Full Copyright Statement | 10. Full Copyright Statement | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | Copyright (C) The Internet Society (2002). 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. | |||
skipping to change at page 10, line 38 ¶ | skipping to change at page 10, line 41 ¶ | |||
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." | |||
10. Authors' Addresses | 11. Authors' Addresses | |||
Ladan Gharai | Ladan Gharai | |||
ladan@isi.edu | ladan@isi.edu | |||
Colin Perkins | Colin Perkins | |||
csp@isi.edu | csp@isi.edu | |||
Allison Mankin | Allison Mankin | |||
mankin@isi.edu | mankin@isi.edu | |||
USC Information Sciences Institute | USC Information Sciences Institute | |||
3811 N. Fairfax Drive | 3811 N. Fairfax Drive | |||
Arlington, VA 22203-1695 | Arlington, VA 22203-1695 | |||
Gary Goncher | Gary Goncher | |||
ggoncher@tek.com | ggoncher@tek.com | |||
Tektronix, Inc. | Tektronix, Inc. | |||
P.O. Box 500, M/S 50-480 | P.O. Box 500, M/S 50-480 | |||
skipping to change at page 11, line 14 ¶ | skipping to change at page 11, line 16 ¶ | |||
USC Information Sciences Institute | USC Information Sciences Institute | |||
3811 N. Fairfax Drive | 3811 N. Fairfax Drive | |||
Arlington, VA 22203-1695 | Arlington, VA 22203-1695 | |||
Gary Goncher | Gary Goncher | |||
ggoncher@tek.com | ggoncher@tek.com | |||
Tektronix, Inc. | Tektronix, Inc. | |||
P.O. Box 500, M/S 50-480 | P.O. Box 500, M/S 50-480 | |||
Beaverton, OR 97077 | Beaverton, OR 97077 | |||
11. Acknowledgment | 12. Acknowledgment | |||
We would like to thank David Richardson for his insightful comments and | We would like to thank David Richardson for his insightful comments and | |||
contributions to the draft. We would also like to thank Chuck Harrison | contributions to the draft. We would also like to thank Chuck Harrison | |||
for his input and for explaining the intricases of SMPTE 292M. | for his input and for explaining the intricacies of SMPTE 292M. | |||
12. Bibliography | 13. 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, | |||
Digital Representation and Bit-Parallel Interface - 1125/60 | Digital Representation and Bit-Parallel Interface - 1125/60 | |||
High-Definition Production System, SMPTE 260M-1999. | High-Definition Production System, SMPTE 260M-1999. | |||
[3] Society of Motion Picture and Television Engineers, | [3] Society of Motion Picture and Television Engineers, | |||
End of changes. 31 change blocks. | ||||
65 lines changed or deleted | 71 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/ |