draft-ietf-avt-smpte292-video-05.txt   draft-ietf-avt-smpte292-video-06.txt 
INTERNET-DRAFT Ladan Gharai INTERNET-DRAFT Ladan Gharai
<draft-ietf-avt-smpte292-video-05.txt> USC/ISI <draft-ietf-avt-smpte292-video-06.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
May 30, 2002 June 30, 2002
RTP Payload Format for SMPTE 292M Video RTP Payload Format for SMPTE 292M Video
<draft-ietf-avt-smpte292-video-05.txt> <draft-ietf-avt-smpte292-video-06.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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This memo specifies a RTP payload format for encapsulating uncompressed This memo specifies a RTP payload format for encapsulating uncompressed
High Definition Television (HDTV) as defined by the Society of Motion High Definition Television (HDTV) as defined by the Society of Motion
Picture and Television Engineers standard, SMPTE 292M. SMPTE is the main Picture and Television Engineers standard, SMPTE 292M. SMPTE is the main
standardizing body in the motion imaging industry and the SMPTE 292M standardizing body in the motion imaging industry and the SMPTE 292M
standard defines a bit-serial digital interface for local area HDTV standard defines a bit-serial digital interface for local area HDTV
transport. transport.
1. Introduction 1. Introduction
[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.]
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 10bit words and etc.). SMPTE 292M stipulates that the source data be in 10bit words and
the total data rate be 1.485 Gbps or 1.485/1.001 Gbps. the total data rate be 1.485 Gbps or 1.485/1.001 Gbps.
A SMPTE 292M television line is divided into four parts, (figure 1): (1) The use of a dedicated serial interconnect is appropriate in a studio
start of active video timing reference (SAV); (2) digital active line; environment, but it is desirable to leverage the widespread availability
(3) end of active video timing reference (EAV); and (4) digital line of high bandwidth IP connectivity to allow efficient wide area delivery
blanking. A SMPTE 292M line may also carry horizontal ancillary data of SMPTE 292M format content. Accordingly, this memo defines an RTP
(H-ANC) or vertical ancillary data (V-ANC) instead of the blanking payload format for SMPTE 292M format video.
level, and likewise, ancillary data may transported instead of a digital
active line. 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
format should be tightly controlled and limited to private networks or
those networks that provide resource reservation and enhanced quality of
service.
A SMPTE 292M television line comprises two interleaved streams, one
containing the luminance (Y) samples, the other chrominance (CrCb)
values. Since chrominance is horizontally sub-sampled (4:2:2 coding) the
lengths of the two streams match. Each stream is divided into four
parts, (figure 1): (1) start of active video timing reference (SAV); (2)
digital active line; (3) end of active video timing reference (EAV); and
(4) digital line blanking. A SMPTE 292M line may also carry horizontal
ancillary data (H-ANC) or vertical ancillary data (V-ANC) instead of the
blanking level, and likewise, ancillary data may 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 0x000 0x000 0x3FF and an additional word (designated as XYZ in figure
2), carrying a number of flags. This includes an F flag which designate 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 which field (1 or 2) the line is transporting and also a V flag which
indicates field blanking. Table 1, further displays the code values in indicates field blanking. Table 1, further displays the code values in
SAV and EAV. After EAV, are two words LN1 and LN2 (Table 2), which SAV and EAV. After EAV, are two words LN1 and LN2 (Table 2), which
carry the 11bit line number for the SMPTE 292M line, immediately carry the 11bit line number for the SMPTE 292M line, immediately
following. The Cyclic Redundancy Check, CRC, is a two word value, shown following. The Cyclic Redundancy Check, CRC, is a two word value, shown
as CR0 and CR1 in figure 2. 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.
Table 1: Timing reference codes. 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: |
| F=0 during field 1; F=1 during field 2. | | F=0 during field 1; F=1 during field 2. |
| V=0 elsewhere; V=1 during field blanking. | | V=0 elsewhere; V=1 during field blanking. |
| H=0 in SAV; H=1 in EAV. | | H=0 in SAV; H=1 in EAV. |
| MSB=most significant bit; LSB=least significant bit.| | MSB=most significant bit; LSB=least significant bit.|
| P= protected bits defined in Table 2 of SMPTE 292M | | P= protected bits defined in Table 2 of SMPTE 292M |
+---------------------------------------------------------+ +---------------------------------------------------------+
Table 1: Timing reference codes.
Table 2: Line number data.
+---------------------------------------------------------+ +---------------------------------------------------------+
| (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 |
+---------------------------------------------------------+ +---------------------------------------------------------+
| LN0 R L6 L5 L4 L3 L2 L1 L0 R R | | LN0 R L6 L5 L4 L3 L2 L1 L0 R R |
| 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.
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 includes 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 This memo only addresses the transfer of uncompressed HDTV. Compressed
HDTV is a subset of MPEG-2 [6], which is fully described in 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 A/53 [7] of the Advanced Television Standards Committee. The ATSC has
skipping to change at page 4, line 16 skipping to change at page 4, line 42
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 3. 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) signals MUST NOT be fragmented across packets, as the SMPTE 292M (EAV+LN+CRC) signals MUST NOT be fragmented across packets, as the SMPTE
decoder uses the sync info in the scan lines to detect the start of scan 292M decoder uses them to detect the start of scan lines.
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
the packet. The end of a video frame is marked by the M bit in the RTP
header.
The payload header contains a 16bit extension to the standard 16 bit RTP information in the payload header pertains to the first data sample in
sequence number, thereby extending the sequence number to 32 bits and the packet. The end of a video frame (the packet containing the last
enabling RTP to accommodate HDTV's high data rates. At 1.485 Gbps, with sample before the EAV) is marked by the M bit in the RTP header.
packet sizes of at least one thousand octets, 32bits allows for an
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 HDTV's high data rates. At 1.485 Gbps,
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.
The payload header also carries the 11bit line number from the SMPTE The payload header also carries the 11bit 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 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).
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 8bits, 40bits and 80bits, respectively, and therefore are naturally of 8 bits, 40 bits and 80 bits, respectively, and therefore are
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
should be packetized such that these values are not fragmented across 2 should be packetized such that these values are not fragmented across 2
packets. However, with 10bit words this is a 60bit value which is not packets. However, with 10bit words this is a 60bit value which is not
octet aligned. To be both octet aligned, and adhere to ALF, an ALF unit octet aligned. To be both octet aligned, and adhere to ALF, an ALF unit
must represent 2 groups of 4 Pixels, thereby becoming octet aligned on a must represent 2 groups of 4 Pixels, thereby becoming octet aligned on a
15 octet boundary. This length is referred to as the pixel group or 15 octet boundary. This length is referred to as the pixel group or
pgroup, and it is conveyed in the SDP parameters. The table below, pgroup, and it is conveyed in the SDP parameters. Table 3 displays the
displays the pgroup value for 4:2:2 and 4:4:4 color samplings. pgroup value for 4:2:2 and 4:4:4 color samplings. Typical source formats
use 4:2:2 sampling, and require a pgroup of 5 octets, other values are
included for completeness.
When packetizing digital active line content, video data MUST NOT be The contents of the Digital Active Line SHOULD NOT be fragmented within
fragmented within a pgroup. This restraint only applies to active video a pgroup. A pgroup of 1 indicates that data may be split at any octet
data between the SAV and EAV timing signals. A pgroup of 1 indicates boundary (this is applicable to instances where the source format is not
that data may be split at any octet boundary. This is applicable to known). The SAV and EAV+LN+CRC fields MUST NOT be fragmented.
instances where the source format is not known.
Color 10bit +-------------------------------------------------------+
Subsampling Pixels words aligned on octet# pgroup | Color 10 bit |
+-----------+------+-------+------------------+-----+ |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.
4. RTP Packetization 4. 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. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ssrc | | ssrc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
4.1. The RTP Header 4.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: encapsulation (the other fields in the RTP header are used in their
usual manner):
Payload Type (PT): 7bits Payload Type (PT): 7bits
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
For a SMPTE 292M transport stream at 1.485 Gbps (or 1.485/1.001 For a SMPTE 292M transport stream at 1.485 Gbps (or 1.485/1.001
Gbps), the timestamp field contains a 148.5 MHz (or 148.5/1.001 Gbps), the timestamp field contains a 148.5 MHz (or 148.5/1.001
MHz) timestamp, respectively. This allows for a unique timestamp MHz) timestamp, respectively. This allows for a unique timestamp
for each 10bit word. for each 10bit word.
skipping to change at page 6, line 34 skipping to change at page 7, line 27
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 4.2. Payload Header
Sequence Number (high bits): 16bits Sequence Number (high bits): 16bits
The high order bits for the 32bit RTP sequence counter. The high order bits for the 32 bit RTP sequence counter, in network
byte order.
F: 1bit F: 1bit
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: 1bit V: 1bit
The V bit as defined in the SMPTE 292M timing signals (see The V bit as defined in the SMPTE 292M timing signals (see
Table 1). V=1 during field blanking, and V=0 else where. Table 1). V=1 during field blanking, and V=0 else where.
Z: 2bits Z: 2bits
skipping to change at page 7, line 9 skipping to change at page 8, line 9
Line No: 11bits Line No: 11bits
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 10bit word in the packet. to the line number of the first 10bit word in the packet.
5. RTCP Considerations 5. 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
kilobits/seconds. At 1.485 Gbps the reduced minimum interval computes to kilo bits/seconds. At 1.485 Gbps the reduced minimum interval computes
0.2ms or 4028 packets per second. to 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 other means of keeping track of these variables
should be used. should be used.
6. IANA Considerations 6. 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 or The RTP timestamp clock rate. The clock runs at either 148500000 Hz
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 148351000 MUST be used, and receivers MUST interpret this as
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 10bit words and octets. The RECOMMENDED grouping for aligning 10bit words and octets.
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 "draft-ietf-avt-smpte292-video-05". RTP as specified in RFC XXXX.
Security considerations: see draft "draft-ietf-avt-smpte292-video-05" Security considerations: see RFC XXXX section 8.
section 8.
Interoperability considerations: NONE Interoperability considerations: NONE
Published specification: SMPTE292M Published specification: SMPTE292M
draft-ietf-avt-smpte292-video-05 RFC XXXX
Applications which use this media type: Applications which use this media type:
Video communication. Video communication.
Additional information: None Additional information: None
Magic number(s): None Magic number(s): None
File extension(s): None File extension(s): None
skipping to change at page 9, line 46 skipping to change at page 10, line 43
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 10. Authors' Addresses
Ladan Gharai Ladan Gharai
ladan@isi.edu ladan@isi.edu
USC/ISI
3811 Fairfax Dr
Arlington, VA 22203-1695
Gary Goncher
ggoncher@tek.com
Colin Perkins Colin Perkins
csp@isi.edu csp@isi.edu
USC/ISI
3811 Fairfax Dr
Arlington, VA 22203-1695
Allison Mankin Allison Mankin
mankin@isi.edu mankin@isi.edu
USC/ISI USC Information Sciences Institute
3811 Fairfax Dr 3811 N. Fairfax Drive
Arlington, VA 22203-1695 Arlington, VA 22203-1695
Gary Goncher
ggoncher@tek.com
Tektronix, Inc.
P.O. Box 500, M/S 50-480
Beaverton, OR 97077
11. Acknowledgment 11. 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. contributions to the draft. We would also like to thank Chuck Harrison
for his input and for explaining the intricases of SMPTE 292M.
12. Bibliography 12. Bibliography
[1] Society of Motion Picture and Television Engineers, [1] Society of Motion Picture and Television Engineers,
Bit-Serial Digital Interface for High-Definition Television Bit-Serial Digital Interface for High-Definition Television
Systems, SMPTE 292M-1998. Systems, SMPTE 292M-1998.
[2] Society of Motion Picture and Television Engineers, [2] Society of Motion Picture and Television Engineers,
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.
 End of changes. 

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