RTP Payload Format for BT.656 Video Encoding
Extracted elements (30)
Each RTP packet contains enough information to form a single scan line without reference to prior scan lines or prior frames, accommodating the unreliable, unordered delivery nature of RTP.
Fragmentation must occur on a sample-pair boundary to avoid splitting chrominance and luminance values across packets, giving 4-octet alignment for 8-bit and 5-octet alignment for 10-bit quantization.
SAV and EAV timing reference codes are removed from the payload, and no line blanking samples are included; the receiver is responsible for regenerating timing reference codes and inserting the correct number of line blanking samples.
Both 8-bit and 10-bit quantization types as defined by BT.601-5 are supported. A 10-bit sample is treated as having two extra bits of fixed-point precision; an 8-bit value of 190 corresponds to the 10-bit value 190.75 (binary 10111110.11).
The payload format requires 4:2:2 color subsampling, resulting in 720 luminance samples per scan line and 360 samples per chrominance channel for normal 4:3 aspect ratio images, totaling 1440 samples per scan line and approximately 20 MB/s of network bandwidth.
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.
An application sending 8-bit samples from a 10-bit device MUST drop the two least-significant bits.
Applications SHOULD attempt path MTU discovery and fragment scan lines into multiple packets no larger than the MTU. Fragmentation MUST occur on a sample-pair boundary.
For a 10-bit quantization payload, each pair of samples MUST be encoded into a 40-bit word (five octets) prior to transmission.
For receivers not receiving scan lines during the vertical interval, BT.656 vertical interval data MUST be generated by repeating the quad-sample sequence 0x80, 0x10, 0x80, 0x10 (true black level).
If a receiver is generating a BT.656-3 data stream directly from the RTP packet, the F and V bits MUST be copied from the payload header rather than being generated implicitly from the scan line number; in the event of conflict, F and V bits have precedence.
If frame blanking samples are provided, they MUST be copied without modification into the resultant BT.656-3 stream.
In the absence of frame blanking samples, the receiver MUST generate true black levels (quad-sample sequence 0x80, 0x10, 0x80, 0x10) to complete the correct number of scan lines per field.
Requests to extend the Type field MUST be vetted by IANA, and implementors SHOULD check the IANA repository for new Type field definitions.
Scan lines MUST be sent in sequential order; error concealment for missing scan lines or fragments is at the discretion of the receiver.
The Marker bit of the RTP header MUST be 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.
The payload format SHALL be Cb, Y, Cr, Y, in keeping with the 4:2:2 color subsampling of BT.656 and BT.601.
The RTP Timestamp SHOULD refer to the 'Ov' field synchronization point of the first field; the timestamp is based on a 90kHz clock and all scan line packets within the same frame share the same timestamp.
The scan offset for the first packet of a scan line MUST be set to zero.
The Type field MUST remain unchanged for all scan lines within the same frame, and the P bit (quantization size indicator) MUST also remain unchanged for all scan lines within the same frame.
The BT.656 RTP payload header is a fixed 4-octet header containing: F (1 bit, field indicator), V (1 bit, vertical interval flag), Type (4 bits, encoding type), P (1 bit, quantization size), Z (2 bits, reserved), Scan Line SL (12 bits), and Scan Offset SO (11 bits).
The Scan Line (SL) field is 12 bits wide, indicating the scan line encapsulated in the payload with valid values from 1 through 625 inclusive.
The Scan Offset (SO) field is 11 bits wide and indicates the sample-pair offset within the scan line for application-level fragmentation. For a scan line width of 720, the maximum scan offset is 359.
The Type field defines four encoding types: 0=NTSC (13.5MHz, 720 samples/line, 60 fields/s, 525 lines/frame), 1=PAL (13.5MHz, 720 samples/line, 50 fields/s, 625 lines/frame), 2=HD NTSC (18MHz, 1144 samples/line), 3=HD PAL (18MHz, 1152 samples/line). Further encodings require IANA assignment.
The 4-bit Type field in the BT.656 RTP payload header defines up to 16 encoding types, of which 4 are currently assigned and 12 are reserved. New type assignments require IANA review by a Designated Expert; applications must include requestor information, rationale, standards references, and any security implications.
Confidentiality of BT.656 media streams is achieved by encryption of RTP packets. Because the payload format is arranged end-to-end, encryption MAY be performed after encapsulation without conflict.
This payload type does not exhibit significant non-uniformity in receiver-side computational complexity for packet processing, and thus does not pose a potential denial-of-service threat.
For 10-bit quantization, each group of four samples (Cb, Y, Cr, Y) MUST be encoded into a 40-bit word (five octets) prior to transmission; sample order is identical to 8-bit quantization and octets are transmitted in network byte order.
For 8-bit quantization, payload data is arranged as interleaved Cb, Y, Cr, Y samples (4 octets per sample-pair), transmitted in network byte order. A full 720-sample line occupies 1440 octets.
The payload header bit layout within the 32-bit word is: F(bit 0), V(bit 1), Type(bits 2-5), P(bit 6), Z(bits 7-8), SL(bits 9-20), SO(bits 21-31).