RTP Payload Format for VC-2 HQ Profile Video

This memo specifies an RTP payload format for the video coding standard SMPTE ST 2042-1:2012 also known as VC-2 The VC-2 codec is a wavelet-based codec intended primarily for professional video use with high bit-rates and only low levels of compression. It has been designed to be low-complexity, and potentially have a very low latency through both encoder and decoder: with some choices of parameters this latency may be as low as a few lines of video. The low level of complexity in the VC-2 codec allows for this low latency operation but also means that it lacks many of the more powerful compression techniques used in other codecs. As such it is suitable for low compression ratios that produce coded data rates around half to a quarter of that of uncompressed video, at a similar visual quality. The primary use for VC-2 is likely to be in professional video production environments.

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.

The VC-2 specification defines a VC-2 stream as being composed of one or more sequences. Each sequence is independently decodable, containing all of the needed parameters and metadata for configuring the decoder. Each Sequence consists of a series of 13-octet Parse Info headers and variable length Data Units. The Sequence begins and ends with a Parse Info header and each Data Unit is preceded by a Parse Info Header. Data Units come in a variety of types, the most important being the Sequence Header, which contains configuration data needed by the decoder, and several types of Coded Picture, which contain the coded data for the pictures themselves. Each picture represents a frame in a progressively scanned video sequence or a field in an interlaced video sequence. The first Data Unit in a Sequence as produced by an encoder is always a Sequence Header, but sequences can be joined in the middle, so this should not be assumed. The High Quality (HQ) profile for VC-2 restricts the types of parse info headers which may appear in the Sequence to only: Sequence Headers, High Quality Pictures, Auxiliary Data, Padding Data, and End of Sequence. At time of writing there is currently no definition for the use of Auxiliary Data in VC-2, and Padding Data is required to be ignored by all receivers. Each High Quality Picture data unit contains a set of parameters for the picture followed by a series of coded Slices, each representing a rectangular region of the transformed picture. Slices within a picture may vary in coded length, but all represent the same shape and size of rectangle in the picture.

Since there is no definition for the use of Auxiliary Data Units and Padding Data Units are defined by the VC-2 spec to be ignored by all decoders this specification only covers the transport of Sequence Headers, High Quality Pictures, and (optionally) End of Sequence headers. Since Sequence Headers and End of Sequence Headers are always small they can easily be encapsulated in a single RTP packet each, but since High Quality Pictures are usually much larger than the MTU of most networks they require fragmentation into multiple packets. For this reason this document defines four types of RTP packets in a VC-2 media stream: one which carries the VC-2 Sequence Header, one which carries the picture fragment containing the VC-2 Transform Parameters for a Picture, one which carries a picture fragment containing VC-2 Coded Slices for a picture, and one which signals the end of a VC-2 Sequence. These four packet-types can be distinguished by the fact that they use different codes in the "PC" field, except for the two types of packet fragment which both use the same value in PC but have different values in the "No. of slices" field. The choices of PC codes is explained in more detail in a following informative section.

The fields of the RTP header have the following additional notes on their useage: The marker bit MUST be set on any packet which contains the final slice in a coded picture and MUST NOT be set otherwise. A dynamically allocated payload type field that designates the payload as VC-2 coded video. Because the data rate of VC-2 coded streams can often be very high, in the order of gigabits rather than megabits per second, the standard 16-bit RTP sequence number can cycle very quickly. For this reason the sequence number is extneded to 32-bits, and this field MUST holds the low-order 16-bits of this value. If the packet contains transform parameters or coded slice data for a coded picture then the timestamp corresponds to the sampling instant of the coded picture. A 90kHz clock SHOULD be used. A single RTP packet MUST NOT contain coded data for more than one coded picture, so there is no ambiguity here. A sequence header packet SHOULD have the same timestamp as the next picture which will follow it in the stream. An End of Sequence packet SHOULD have the same timestamp as the previous picture which appeared in the stream. The remaining RTP header fields are used as specified in RTP.

The fields of the extended headers are defined as follows: MUST Contain the high-order 16-bits of the 32-bit packet sequence number, a number which increments with each packet. This is needed since the high data rates of VC2 sequences mean that it is highly likely that the 16-bit sequence number will roll-over too frequently to be of use for stream synchronisation. SHOULD be set to 1 if the packet contains coded picture paramaters or slice data from a field in an interlaced frame, and to 0 otherwise. SHOULD be set to 1 if the packet contains coded picture paramaters or slice data from the second field of an interlaced frame, and to 0 otherwise. Contains a Parse Code which MUST be the value indicated for the type of data in the packet. MUST contain the Picture Number for the coded picture this packet contains data for, as described in Section 12.1 of the VC-2 specification. The sender MUST send at least one transform parameters packet for each coded picture and MAY include more than one as long as they contain identical data. The sender MUST NOT send a packet from a new picture until all the coded data from the current picture has been sendt. If the receiver does not receive a transform parameters packet for a picture then it MAY assume that the parameters are unchanged since the last picture, or MAY discard the picture. MUST contain the Slice Prefix Bytes value for the coded picture this packet contains data for, as described in Section 12.3.4 of the VC-2 specification. In the VC-2 specification this value is not restricted to 16 bits, but in practice this is unlikely to ever be too large. MUST contain the Slice Size Scaler value for the coded picture this packet contains data for, as described in Section 12.3.4 of the VC-2 specification. In the VC-2 specification this value is not restricted to 16 bits, but in practice this is unlikely to ever be too large. Contains the number of bytes of data contained in the coded payload section of this packet. Contains the number of coded slices contained in this packet, which MUST be 0 for a packet containing transform parameters. In a packet containing coded slices this number MUST be the number of whole slices contained in the packet, and the packet MUST NOT contain any partial slices. Indicates the X coordinate of the first slice in this packet, in slices, starting from the top left corner of the picture. Indicates the Y coordinate of the first slice in this packet, in slices, starting from the top left corner of the picture.

The "PC" field in the packets is used to carry the Parse Code which identifies the type of content in the packet. For Sequence Header and End of Sequence packets this code matches the value of the Parse Code used to identify those data units in a VC-2 stream, as defined in the VC-2 specification, and each packet contains the entire such data unit. For coded picture data, however, this is not possible because VC-2 coded picture data units are too large to fit conveniently into a packet on most transports. Rather than use the Parse Code for the picture, even though only a fragment of it is present, it was decided to create a new parse code which would indicate a fragment of a picture. In compliance with the VC-2 specification this new choice of Parse Code preserves the meaning of all the bits given meanings in Section 10.4.1.1 of the VC-2 specification, but sets an additional bit, bit 2, which was reserved for future expansion in that specification. In this adaptation approach bit 2 now takes on the meaning of "Picture Fragment".

For the Sequence Header packet type (PC = 0x00) the payload data MUST be the coded sequence header exactly as it appears in the VC-2 Sequence. For the Transform Parameters packet type (PC = 0xEC and No. Slices = 0) the payload data MUST be all the data which appears in the VC-2 High Quality Picture Data Unit after the end of the Parse Info Header but before the start of the first coded slice. For the Picture Fragment packet type (PC = 0xEC and No. Slices > 0) the payload data MUST be a specified number of coded slices in the same order that they appear in the VC-2 stream. Which slices appear in the packet is identified using the Slice Offset X and Slice Offset Y fields in the payload header. For the End of Sequence packet type (PC = 0x10) there is no payload data.

To reassemble the data in the RTP packets into a valid VC-2 sequence the receiver SHOULD: Take the data from each packet with a Parse Code of 0x00 and prepend a valid VC-2 Parse Info header with the same parse code to it. The resulting sequence header parse info header and data unit MUST be included in the output stream before any coded pictures which followed it in the RTP stream unless an identical sequence header has already been included, and MAY be repeated at any point that results in a valid VC-2 stream. Take the data from each packet with a Parse Code of 0xEC and No. of Slices set to 0 (which together indicates that this packet contains the transform parameters for a coded picture) and prepend a valid VC-2 Parse Info header followed by the picture number to it with the parse code 0xE8, then take the data from each subsequent packet with parse code 0xEC and the same picture number and append it to the end of this data unit. When all the packets for a particular picture have been received (which is indicated by the marker bit) the picture MUST be included in the output stream, although a copy of the most recent Sequence Header MAY be included immediately before it (and MUST be so if not alrerady included in the current sequence). Once a data unit has been assembled, whether a Sequence Header or a Coded Picture, the next parse offset and previous parse offset values in its parse info header should be filled with the offset between the start of the header and the start of the next or previous. An End of Sequence parse info header MAY be inserted when a packet with parse code set to 0x10 is encountered, or at any other time that is allowed in a valid VC-2 stream. After an End of Sequence parse info header is included in the output stream either the stream must end or it MUST be followed by a Sequence Header indicating the start of a new sequence.

Congestion control for RTP SHALL be used in accordance with RFC 3550, and with any applicable RTP profile; e.g., RFC 3551. An additional requirement if best-effort service is being used is: users of this payload format MUST monitor packet loss to ensure that the packet loss rate is within acceptable parameters. Circuit Breakers is an update to RTP that defines criteria for when one is required to stop sending RTP Packet Streams. The circuit breakers is to be implemented and followed.

This RTP payload format is identified using the video/vc2 media type which is registered in accordance with RFC 4855 and using the template of RFC 6838.

Type name: video Subtype name: vc2 Required parameters: rate: The RTP timestamp clock rate. Applications using this payload format SHOULD use a value of 90000. profile: The VC-2 profile in use, the only currently allowed value is "HQ". Optional parameters: N/A Encoding considerations: This media type is framed and binary, see section 4.8 in RFC6838. Security considerations: Please see security consideration in RFCXXXX Interoperability considerations: N/A Published specification: "VC-2 Video Compression", SMPTE Standard ST 2042-1 Applications that use this media type: Video Communication. Additional information: N/A Person & email address to contact for further information: james.barrett@bbc.co.uk Intended usage: COMMON Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [RFC3550]. Transport within other framing protocols is not defined at this time. Author: Change controller: IETF Payload working group delegated from the IESG. Provisional registration? (standards tree only): No (Any other information that the author deems interesting may be added below this line.)

The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855.

All parameters are declarative.

This memo requests that IANA registers video/vc2 as specified in . The media type is also requested to be added to the IANA registry for "RTP Payload Format MIME types" (http://www.iana.org/assignments/rtp-parameters).

RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification , and in any applicable RTP profile such as RTP/AVP, RTP/AVPF, RTP/SAVP or RTP/SAVPF. However, as "Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution" discusses, it is not an RTP payload format's responsibility to discuss or mandate what solutions are used to meet the basic security goals like confidentiality, integrity and source authenticity for RTP in general. This responsibility lays on anyone using RTP in an application. They can find guidance on available security mechanisms and important considerations in Options for Securing RTP Sessions. Applications SHOULD use one or more appropriate strong security mechanisms. The rest of this security consideration section discusses the security impacting properties of the payload format itself. This RTP payload format and its media decoder do not exhibit any significant non-uniformity in the receiver-side computational complexity for packet processing, and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological data. Nor does the RTP payload format contain any active content.

Note to RFC Editor: This section may be removed after carrying out all the instructions of this section. RFCXXXX is to be replaced by the RFC number this specification receives when published.