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
which field (1 or 2) the line is transporting and also a V flag which figure 2), carrying a number of flags. This includes an F flag which
indicates field blanking. Table 1, further displays the code values in designate which field (1 or 2) the line is transporting and also a V
SAV and EAV. After EAV, are two words LN1 and LN2 (Table 2), which flag which indicates field blanking. Table 1, further displays the code
carry the 11 bit line number for the SMPTE 292M line, immediately values in SAV and EAV. After EAV, are two words LN0 and LN1 (Table 2),
following. The Cyclic Redundancy Check, CRC, is a two word value, shown which carry the 11 bit line number for the SMPTE 292M line. The Cyclic
as CR0 and CR1 in figure 2. Redundancy Check, CRC, is also a two word value, shown as CR0 and CR1 in
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.
The payload header also carries the 11 bit line number from the SMPTE approximate 6 hour period before the sequence number wraps around. Given
292M timing signals. This provides more information at the application the same assumptions, the standard 16 bit RTP sequence number wraps
level and adds a level of resiliency, in case the packet containing the around in less than a second (336 milliseconds) which is clearly not
EAV is lost. 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 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 timestamp. This allows the receiver to reconstruct the timing of the
SMPTE 292M stream, without knowledge of the exact type of source format SMPTE 292M stream, without knowledge of the exact type of source format
(e.g. SMPTE 274M or SMPTE 296M). (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
292M timing signals. This provides more information at the application
level and adds a level of resiliency, in case the packet containing the
EAV is lost.
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
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.
skipping to change at page 9, line 47 skipping to change at page 10, line 4
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
RTP flows, use of the payload should be narrowly limited to suitably
control mechanism for flows of this sort, use of the payload should be connected network endpoints, or to networks where QoS guarantees are
narrowly limited to suitably connected network endpoints, or to networks available, and great care taken with the scope of multicast
where QoS guarantees are available, and great care taken with the scope transmissions. This potential threat is common to all high bit rate
of multicast transmissions. This potential threat is common to all high applications without congestion control.
bit rate 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 39 skipping to change at page 10, line 42
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. 

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