diff options
Diffstat (limited to 'doc/rfc/rfc2431.txt')
| -rw-r--r-- | doc/rfc/rfc2431.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2431.txt b/doc/rfc/rfc2431.txt new file mode 100644 index 0000000..9a8d5f0 --- /dev/null +++ b/doc/rfc/rfc2431.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group D. Tynan +Request for Comments: 2431 Claddagh Films +Category: Standards Track October 1998 + + + RTP Payload Format for BT.656 Video Encoding + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document specifies the RTP payload format for encapsulating ITU + Recommendation BT.656-3 video streams in the Real-Time Transport + Protocol (RTP). Each RTP packet contains all or a portion of one + scan line as defined by ITU Recommendation BT.601-5, and includes + fragmentation, decoding and positioning information. + +1. Introduction + + This document describes a scheme to packetize uncompressed, studio- + quality video streams as defined by BT.656 for transport using RTP + [1]. A BT.656 video stream is defined by ITU-R Recommendation + BT.656-3 [2], as a means of interconnecting digital television + equipment operating on the 525-line or 625-line standards, and + complying with the 4:2:2 encoding parameters as defined in ITU-R + Recommendation BT.601-5 (formerly CCIR-601) [3], Part A. + + RTP is defined by the Internet Engineering Task Force (IETF) to + provide end-to-end network transport functions suitable for + applications transmitting real-time data over multicast or unicast + network services. The complete specification of RTP for a particular + application requires the RTP protocol document [1], a profile + specification document [4], and a payload format specification. This + document is intended to serve as the payload format specification for + studio-quality video streams. + + + + + + +Tynan Standards Track [Page 1] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [5]. + +2. Definitions + + For the purposes of this document, the following definitions apply: + + Y: An 8-bit or 10-bit coded "luminance" sample. Luminance in this + context refers to the BT.601-5 [3] definition which is not the same + as a true CIE luminance value. The value of "luminance" refers + specifically to video luma. However, in order to avoid confusion with + the BT.656 and BT.601 standards, the video luma value is referenced + in this document as luminance. Each value has 220 quantization + levels with the black level corresponding to level 16 and the peak + white level corresponding to 235. + + Cb, Cr: An 8-bit or 10-bit coded color-difference sample (as per + BT.601-5). Each color-difference value has 225 quantization levels + in the centre part of the quantization scale with a color-difference + of zero having an encoded value of 128. + + True Black: BT.601-5 defines a true black level as the quad-sample + sequence 0x80, 0x10, 0x80, 0x10, representing color-difference values + of 128 (0x80) and a luminance value of 16 (0x10). + + SAV, EAV: Video timing reference codes which appear at the start and + end of a BT.656 scan line. + +3. Payload Design + + ITU Recommendation BT.656-3 defines a schema for the digital + interconnection of television video signals in conjunction with + BT.601-5 which defines the digital representation of the original + analog signal. While BT.601-5 refers to images with or without color + subsampling, the interconnection standard (BT.656-3) specifically + requires 4:2:2 subsampling. This specification also requires 4:2:2 + subsampling such that the luminance stream occupies twice the + bandwidth of each of the two color-difference streams. For normal + 4:3 aspect ratio images, this results in 720 luminance samples per + scan line, and 360 samples of each of the two chrominance channels. + The total number of samples per scan line in this case is 1440. + While this payload format specification can accomodate various image + sizes and frame rates, only those in accordance with BT.601-5 are + currently supported. + + + + + + +Tynan Standards Track [Page 2] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + + Due to the lack of any form of video compression within the payload + and sampling-rate compliance with BT.601-5, the resultant video + stream can be considered "studio quality". However, such a stream + can require approximately 20 megabytes per second of network + bandwidth. In order to maximize packet size within a given MTU, and + to optimize scan line decoding, each video scan line is encoded + within one or more RTP packets. + + To allow for scan line synchronization, each packet includes certain + flag bits (as defined in BT.656-3) and a unique scan line number. + The SAV and EAV timing reference codes are removed. Furthermore, no + line blanking samples are included, so no ancillary data can be + included in the line blanking period. It is the responsibility of + the receiver to generate the timing reference codes, and to insert + the correct number of line blanking samples. + + Similarly, there is no requirement that the frame blanking samples be + provided. However, it is possible to include frame blanking samples + if such samples contain relevant information, such as a vertical- + interlace time code (VITC), or teletext data. In the absence of + frame blanking samples, the receiver MUST generate true black levels + as defined above, to complete the correct number of scan lines per + field. If frame blanking samples are provided, they MUST be copied + without modification into the resultant BT.656-3 stream. + + Scan lines MUST be sent in sequential order. Error concealment for + missing scan lines or fragments of scan lines is at the discretion of + the receiver. + + Both 8-bit and 10-bit quantization types as defined by BT.601-5 are + supported. 10-bit samples are considered to have two extra bits of + fixed-point precision such that a binary value of 10111110.11 + represents a sample value of 190.75. Using 8-bit quantization, this + would give a sample value of 190. An application receiving 8-bit + samples for a 10-bit device MUST consider the sample as reflecting + the most-significant 8 bits. The two least-significant bits SHOULD + be set to zero. Similarly, an application sending 8-bit samples from + a 10-bit device MUST drop the two least-significant bits. For a 10- + bit quantization payload, each pair of samples MUST be encoded into a + 40-bit word (five octets) prior to transmission, as specified in + Section 6. + + To allow for scan lines with octet lengths larger than the path + maximum transmission unit (MTU), a scan offset field is included in + the packet header. Applications SHOULD attempt path MTU discovery + [6] and fragment scan lines into multiple packets no larger than the + MTU. + + + + +Tynan Standards Track [Page 3] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + + Fragmentation MUST occur on a sample-pair boundary, such that the + chrominance and luminance values are not split across packets. For + 8-bit quantization this gives a four-octet alignment, and a five- + octet alignment for 10-bit quantization. As a result, the scan + offset refers not to the byte offset within the payload, but the + sample-pair offset. + +4. Usage of RTP + + Due to the unreliable nature of the RTP protocol, and the lack of an + orderly delivery mechanism, each packet contains enough information + to form a single scan line without reference to prior scan lines or + prior frames. In addition to the RTP header, a fixed length payload + header is included in each packet. This header is four octets in + length. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RTP Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Payload Data | + | . | + | . | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1. RTP Header usage + + Each RTP packet starts with a fixed RTP header. The following fields + of the RTP fixed header are used for BT.656-3 encapsulation: + + Marker bit (M): The Marker bit of the RTP header is set to 1 for the + last packet of a frame (or the last fragment of the last scan line if + fragmented), and set to 0 on all other packets. + + Payload Type (PT): The Payload Type indicates the use of the payload + format defined in this document. A profile MAY assign a payload type + value for this format either statically or dynamically as described + in RFC 1890 [4]. + + Timestamp: The RTP Timestamp encodes the sampling instant of the + video frame currently being rendered. All scan line packets within + the same frame will have the same timestamp. The timestamp SHOULD + refer to the 'Ov' field synchronization point of the first field. + For the payload format defined by this document, the RTP timestamp is + based on a 90kHz clock. + + + +Tynan Standards Track [Page 4] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + +5. Payload Header + + The payload header is a fixed four-octet header broken down as + follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |F|V| Type |P| Z | Scan Line (SL) | Scan Offset (SO) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + F: 1 bit + When 0, indicates the first field of a frame (line 4 through 265 + inclusive for Type=0 or 2, and line 1 through 312 inclusive for Type=1 + or 3). Any other scan line is considered a component of the second + field, and the F bit will be set to 1. This bit is copied directly + from the BT.656-compliant stream by the transmitter, and inserted into + the stream by the receiver. + + V: 1 bit + When 1, indicates that the scan line is part of the vertical interval. + Should always be 0 unless frame blanking data is sent. In which case, + the V bit SHOULD be set to 1 for scan lines which do not form an + integral part of the image. This bit is copied directly from the + BT.656-compliant stream by the transmitter, and inserted into the + stream by the receiver. For receivers which do not receive scan lines + during the vertical interval, BT.656 vertical interval data MUST be + generated by repeating the quad-sample sequence 0x80, 0x10, 0x80, + 0x10, representing a true black level. + + Type: 4 bits + This field indicates the type of frame encoding within the payload. + It MUST remain unchanged for all scan lines within the same frame. + Currently only four types of encoding are defined. These are as + follows; + + 0 - NTSC (13.5MHz sample rate; 720 samples per line; 60 fields + per second; 525 lines per frame) + + 1 - PAL (13.5MHz sample rate; 720 samples per line; 50 fields + per second; 625 lines per frame) + + 2 - High Definition NTSC (18MHz sample rate; 1144 samples per + line; 60 fields per second; 525 lines per frame) + + 3 - High Definition PAL (18MHz sample rate; 1152 samples per + line; 50 fields per second; 625 lines per frame) + + + + +Tynan Standards Track [Page 5] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + + Further encodings can only be defined through the Internet Assigned + Numbers Authority (IANA). For more information refer to Section 8, + "IANA Considerations". + + P: 1 bit + Indicates the required sample quantization size. When 0, the payload + is comprised of 8-bit samples. Otherwise, it carries 10-bit samples. + This bit MUST remain unchanged for all scan lines within the same + frame. + + Z: 2 bits + Reserved for future use. Must be set to zero by the transmitter and + ignored by the receiver. + + Scan Line (SL): 12 bits + Indicates the scan line encapsulated in the payload. Valid values + range from 1 through 625 inclusive. If no frame blanking data is + being transmitted, only scan lines 23 through 310 inclusive, and + lines 336 through 623 inclusive SHOULD be sent in the case of Type=1 + or 3. For 525/60 encoding (Type=0 or 2), scan lines 10 through 263 + inclusive and lines 273 through 525 SHOULD be transmitted. + + If a receiver is generating a BT.656-3 data stream directly from this + packet, the F and V bits MUST be copied from the header rather than + being generated implicitly from the scan line number. In the event + of a conflict, the F and V bits have precedence. + + Scan Offset (SO): 11 bits + Indicates the offset within the scan line for application-level + fragmentation. After doing PMTU discovery, if the path MTU is less + than the required size for one complete scan line, the data SHOULD be + fragmented such that a given RTP packet does not exceed the allowable + MTU. The offset for the first packet of a scan line MUST be set to + zero. The scan offset refers to the sample-pair offset within the + scan such that for a scan line width of 720, the maximum scan offset + is 359. + +6. Payload Format + + In keeping with the 4:2:2 color subsampling of BT.656 and BT.601, + each pair of color-difference samples will be intermixed with two + luminance samples. As per BT.656, the format for transmission SHALL + be Cb, Y, Cr, Y. The following is a representation of a 720 sample + packet with 8-bit quantization: + + + + + + + +Tynan Standards Track [Page 6] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cb0 | Y0 | Cr0 | Y1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cb1 | Y2 | Cr1 | Y3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . + . + . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cb359 | Y718 | Cr359 | Y719 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 1144 and 1152 sample packets SHOULD increase the packet size + accordingly while maintaining the sample order. + + For 10-bit quantization, each group of four samples MUST be encoded + into a 40-bit word (five octets) prior to transmission. The sample + order is identical to that for 8-bit quantization. The following is + a representation of a 720 sample packet with 10-bit quantization: + + 0 1 2 3 + 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 + +---------+---------+---------+---------+ + | Cb0 | Y0 | Cr0 | Y1 | + +---------+---------+---------+---------+ + | Cb1 | Y2 | Cr1 | Y3 | + +---------+---------+---------+---------+ + . + . + . + +---------+---------+---------+---------+ + | Cb359 | Y718 | Cr359 | Y719 | + +---------+---------+---------+---------+ + (Note that the word width is 40 bits) + +-------+-------+-------+-------+-------+ + Octets: | 0 | 1 | 2 | 3 | 4 | + +-------+-------+-------+-------+-------+ + + The octets shown in these diagrams are transmitted in network byte + order, that is, left-to-right as shown. + + + + + + + + + +Tynan Standards Track [Page 7] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + +7. Security Considerations + + RTP packets using the payload format defined in this specification + are subject to the security considerations discussed in the RTP + specification [1]. This implies that confidentiality of the media + streams is achieved by encryption. Because the payload format is + arranged end-to-end, encryption MAY be performed after encapsulation + so there is no conflict between the two operations. + + This payload type does not exhibit any significant non-uniformity in + the receiver side computational complexity for packet processing to + cause a potential denial-of-service threat. + +8. IANA Considerations + + The four encoding types defined by this document relate to specific + schema defined by ITU-R Recommendation BT.656-3. Future revisions of + the recommendation may create further encoding types which need to be + supported over RTP. The "Type" field is four bits wide allowing for a + total of up to sixteen possible encodings, with twelve currently + reserved for future use. Due to the small number of possible + encodings and given that it is very unlikely that future revisions of + BT.656 will introduce any new schema, requests to extend the Type + field MUST be vetted by the Internet Assigned Numbers Authority. + Furthermore, implementors SHOULD check the IANA repository for new + definitions of the Type field in order to comply with this document. + + Applications for a new Type value MUST be submitted to the IANA and + include the requestors name and contact information, the reason for + requesting a new Type and references to appropriate standards, such + as an updated version of ITU-R Recommendation BT.656. Furthermore, + in the unlikely event that the new Type will lessen the security of a + compliant implementation, such security risk MUST be detailed in the + application. The application will be reviewed by a Designated Expert + and if appropriate, a new Type will be assigned. This type will be + listed in the IANA repository for future implementations. + + + + + + + + + + + + + + + +Tynan Standards Track [Page 8] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + +9. References + + [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 1889, January 1996. + + [2] Interfaces for Digital Component Video Signals in 525-Line and + 625-Line Television Systems operating at the 4:2:2 Level of + Recommendation ITU-R BT.601 (Part A), ITU-R Recommendation + BT.656-3, 1995. + + [3] Studio Encoding Parameters of Digital Television for Standard + 4:3 and Wide-Screen 16:9 Aspect Ratios, ITU-R Recommendation + BT.601-5, 1995. + + [4] Schulzrinne, H., "RTP Profile for Audio and Video Conference + with Minimal Control", RFC 1890, January 1996. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + +10. Author's Address + + Dermot Tynan + Claddagh Films Limited + 3 White Oaks + Clybaun Road + Galway + Ireland + + EMail: dtynan@claddagh.ie + Phone: +353 91 529944 + + + + + + + + + + + + + + + + +Tynan Standards Track [Page 9] + +RFC 2431 RTP Payload Format for BT.656 October 1998 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Tynan Standards Track [Page 10] + |