RTP Payload Format for VC-2 High Quality (HQ) Profile
Extracted elements (28)
Expected data rates for VC-2 RTP sessions are likely in the gigabits-per-second range. On a correctly provisioned closed network this is manageable, but there is always risk of data leaking onto the open internet, making congestion control compliance especially important.
The sequence number is extended to 32 bits because VC-2 Streams can operate at gigabits per second, at which point the standard 16-bit RTP sequence number cycles too quickly to be useful for stream synchronization.
This payload format uses only HQ Picture Fragments (PC=0xEC), not HQ Pictures (PC=0xE8), because Fragments are specifically designed to facilitate transmission via packet-based protocols such as RTP. High Quality Pictures can be transported by converting them into an equivalent set of Fragments sized to fit within the network MTU.
A 90kHz clock SHOULD be used for the RTP Timestamp field. A single RTP packet MUST NOT contain coded data for more than one coded picture.
A Sequence MUST NOT contain Parse Info Headers with Parse Codes other than 0x00, 0x10, 0x20, 0x30, or 0xEC. Every HQ Picture Fragment MUST be no longer than 65535 bytes and MUST use Slice Prefix Bytes and Slice Size Scaler values no greater than 65535.
Because VC-2 data rates are often in the gigabits per second range, the 16-bit RTP sequence number is extended to 32 bits. The RTP Sequence Number field MUST hold the low-order 16 bits, and the Extended Sequence Number field in the payload header MUST contain the high-order 16 bits.
Congestion control for RTP SHALL be used per RFC 3550. When best-effort service is used, senders MUST monitor packet loss to ensure it remains within acceptable parameters. Applications MUST comply with RTP Circuit Breakers (RFC 8083).
Each RTP packet MUST carry data corresponding to a single Parse Info Header and its Data Unit. A single packet MAY NOT contain data from more than one Parse Info Header or Data Unit, and a single Parse Info Header/Data Unit pair MUST NOT be split across more than one packet. The sole exception is Auxiliary Data, which MAY be split across multiple packets using B and E flags.
Every HQ Picture Fragment SHOULD be small enough that the RTP packet carrying it fits within the network MTU. Fragments that are too large can generally be split into smaller Fragments unless an individual slice exceeds the MTU.
No. of Slices MUST be 0 in a Transform Parameters packet. In a Coded Slices packet, No. of Slices MUST be the number of whole slices contained, and the packet MUST NOT contain any partial slices.
The I bit MUST be set to 1 if the packet contains coded picture parameters or slice data from a field in an interlaced frame, and 0 for progressive frame data. The F bit MUST be set to 1 for the second field of an interlaced frame, and 0 for the first field or any progressive frame data.
The Marker bit (M) MUST be set on any packet that contains the final slice in a coded picture and MUST NOT be set otherwise.
The sender MUST send at least one Transform Parameters packet for each coded picture and MUST NOT send a packet from a new picture until all coded data from the current picture has been sent.
A VC-2 Stream consists of one or more independently decodable Sequences, each composed of 13-octet Parse Info Headers followed by variable-length Data Units. The HQ profile restricts Parse Codes to Sequence Headers (0x00), End of Sequence (0x10), Auxiliary Data (0x20), Padding Data (0x30), and HQ Picture Fragment (0xEC).
FEC layering priority (from RFC 5109) for VC-2 streams, in descending order: (1) Sequence Headers, (2) Fragments with Transform Parameters, (3) Fragments with Coded Slices, (4) Auxiliary Data and End of Sequence, (5) Padding. It is RECOMMENDED that one FEC layer protects Sequence Headers and a second protects all Fragments.
If a receiver receives Coded Slices packets for a picture but no Transform Parameters packet, it MAY assume parameters are unchanged from the last picture (risking malformed pictures) or MAY discard the picture (resulting in dropped frames). The choice is implementation-dependent.
Reassembly requires prepending a VC-2 Parse Info Header (Figure 8) to each reconstructed Data Unit. Receivers MAY combine all Fragment Data Units (PC=0xEC) with the same picture number into a single Picture Data Unit (PC=0xE8); this conversion MUST be done if compliance with VC-2 major versions 1 or 2 is required.
SDP mapping: the type name 'video' goes in the 'm=' line, subtype 'vc2' goes in 'a=rtpmap' followed by the rate, and required/optional parameters are included in 'a=fmtp' as semicolon-separated parameter=value pairs. All parameters are declarative; version and level are specified in decimal.
Six packet types are defined, distinguished by Parse Code: Sequence Header (0x00), End of Sequence (0x10), Auxiliary Data (0x20), Padding Data (0x30), HQ Picture Fragment — Transform Parameters (0xEC, No. of Slices=0), and HQ Picture Fragment — Coded Slices (0xEC, No. of Slices>0). LD Picture (0xC8) and HQ Picture (0xE8) are NOT valid in this payload format.
The media type 'video/vc2' is defined with required parameters 'rate' (RTP clock rate, SHOULD be 90000) and 'profile' (must be 'HQ'). Optional parameters include 'version' (must be '3' for HQ Fragment streams) and 'level' (any integer).
IANA has registered 'video/vc2' in the 'RTP Payload Format Media Types' registry per RFC 4855. This is the sole IANA action defined in this document.
RTP packets using this payload format are subject to standard RTP security considerations (RFC 3550, RFC 3551, RFC 3711, etc.). Applications SHOULD use one or more appropriate strong security mechanisms. The payload format itself does not exhibit significant non-uniformity in receiver-side computational complexity, so pathological data is unlikely to cause denial-of-service.
To avoid buffer overruns, the receiver MUST consider both the reported Fragment Length field and the actual received size of a packet containing slice data. Transmitters decoding variable-length coded headers to extract VC-2 bitstream data before assembling packets are also potentially subject to buffer overruns if not implemented carefully.
The Auxiliary Data packet (PC=0x20) payload header contains: Extended Sequence Number (16 bits), B flag (1 bit, first byte of unit), E flag (1 bit, last byte of unit), Reserved (6 bits), PC=0x20 (8 bits), Data Length (32 bits), followed by the uncoded payload data.
The Coded Slices Fragment packet (PC=0xEC, No. of Slices>0) adds the same payload header as Transform Parameters plus two additional 16-bit fields: Slice Offset X and Slice Offset Y (both in slice coordinates from top-left), followed by the Coded Slices.
The Sequence Header packet (PC=0x00) adds a 4-octet payload header after the RTP header: a 16-bit Extended Sequence Number, an 8-bit Reserved field, and PC=0x00, followed by the variable-length coded Sequence Header data.
The Transform Parameters Fragment packet (PC=0xEC, No. of Slices=0) adds a payload header containing: Extended Sequence Number (16 bits), Reserved/I/F flags (8 bits), PC=0xEC (8 bits), Picture Number (32 bits), Slice Prefix Bytes (16 bits), Slice Size Scaler (16 bits), Fragment Length (16 bits), and No. of Slices=0 (16 bits), followed by variable-length coded Transform Parameters.
The VC-2 Parse Info Header (Figure 8) used during reassembly is 13 octets: a 4-byte sync word (0x42 0x42 0x43 0x44), a 1-byte Parse Code, a 4-byte Next Parse Offset, and a 4-byte Prev Parse Offset.