| Payload Working Group | J. Weaver |
| Internet-Draft | BBC |
| Intended status: Standards Track | August 29, 2018 |
| Expires: March 2, 2019 |
RTP Payload Format for VC-2 HQ Profile Video
draft-ietf-payload-rtp-vc2hq-08
This memo describes an RTP Payload format for the High Quality (HQ) profile of Society of Motion Picture and Television Engineers Standard ST 2042-1 known as VC-2. This document describes the transport of HQ Profile VC-2 in RTP packets and has applications for low-complexity, high-bandwidth streaming of both lossless and lossy compressed video.
The HQ profile of VC-2 is intended for low latency video compression (with latency potentially on the order of lines of video) at high data rates (with compression ratios on the order of 2:1 or 4:1).
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 2, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This memo specifies an RTP payload format for the video coding standard Society of Motion Picture and Television Engineers ST 2042-1:2017 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", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
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, and the type of a Data Unit is signaled in the proceding Parse Info Header. The most important types are 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 (and hence also the types of Data Unit) to only:
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.
Each High Quality Fragment data unit contains either a set of parameters for a picture or it contains a series of coded Slices. Fragments carry the same data as pictures, but broken up into smaller units to facilitate transmission via packet-based protocols such as RTP.
This payload format only makes use of fragments, not pictures.
In this specification each RTP packet is used to carry data corresponding to a single Parse Info Header and its following data unit (if it has one). A single packet MAY NOT contain data from more than one Parse Info header or data unit. A single Parse Info Header and Data Unit pair MUST NOT be split accross more than one packet, the sole exception to this rule is that an Auxiliary Data Unit MAY be split between multiple packets, using the B and E flags to indicate start and end.
This specification only covers the transport of Sequence Headers (together with their accompanying data unit), High Quality Fragments (together with their accompanying data unit), Auxiliary Data (together with their accompanying data unit), and (optionally) End Sequence Headers and Padding Data (for which no data unit it carried).
High Quality Pictures can be transported by converting them into an equivalent set of High Quality Fragments. The size of fragments should be chosen so as to fit within the MTU of the network in use.
For this reason this document defines six types of RTP packets in a VC-2 media stream:
These six packet-types can be distinguished by the fact that they use different codes in the "PC (Parse Code)" field, except for the two types of picture 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable Length Coded Sequence Header .
. .
+---------------------------------------------------------------+
Figure 1: RTP Payload Format For Sequence Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Variable Length Coded Transform Parameters .
. .
+---------------------------------------------------------------+
Figure 2: RTP Payload Format For Transform Parameters Fragment
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved |I|F| PC = 0xEC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Picture Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Prefix Bytes | Slice Size Scaler |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Fragment Length | No. of Slices |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Slice Offset X | Slice Offset Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Coded Slices .
. .
+---------------------------------------------------------------+
Figure 3: RTP Payload Format For Fragment Containing Slices
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number | Reserved | PC = 0x10 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 4: RTP Payload Format For End of Sequence
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Uncoded Payload Data .
. .
+---------------------------------------------------------------+
Figure 5: RTP Payload Format For Auxiliary Data
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|X| CC |M| PT | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+---------------------------------------------------------------+
Figure 6: RTP Payload Format For Padding Data
All fields in the headers longer than a single bit are interpreted as unsigned integers in network byte order.
The fields of the RTP header have the following additional notes on their useage:
The remaining RTP header fields are used as specified in RTP.
The fields of the extended headers are defined as follows:
The "PC" field in the packets is used to carry the Parse Code which identifies the type of content in the packet. This code matches the value of the Parse Code used to identify each data unit in a VC-2 stream, as defined in the VC-2 specification, and each packet contains the entire data unit.
The table below lists all of the parse codes currently allowed in a VC-2 Sequence. The final column indicates whether the code in question can be present in a stream transmitted using this specification.
+----------+-----------+---------------------+---------------+
| PC (hex) | Binary | Description | Valid |
+----------+-----------+---------------------+---------------+
| 0x00 | 0000 0000 | Sequence Header | Yes |
| 0x10 | 0001 0000 | End of Sequence | Yes |
| 0x20 | 0010 0000 | Auxiliary Data | Yes |
| 0x30 | 0011 0000 | Padding Data | Yes |
+----------+-----------+---------------------+---------------+
| 0xC8 | 1100 1000 | LD Picture | No |
| 0xE8 | 1110 1000 | HQ Picture | No |
| 0xEC | 1110 1100 | HQ Picture Fragment | Yes |
+----------+-----------+---------------------+---------------+
Figure 7: Parse Codes and Meanings
There are some constraints which a Sequence needs to conform to in order to be transmissible with this specification.
If a Sequence intended for tranmission does not conform to these restrictions then it MAY be possible to simply convert it into a form that does by splitting pictures and/or large fragments into suitably sized fragments. This can be done provided that the following (weaker) constraints are met:
Sending a Stream which does not meet the above requirements via this mechanism is not possible unless the stream is re-encoded by a VC-2 Encoder so as to meet them.
In addition every Auxiliary Data Unit SHOULD be small enough that a single RTP packet carrying it will fit within the network MTU size. Since there is currently no specification for the format of Auxiliary Data in VC-2 the mechanism for ensuring this with an encoder implementation that includes Auxiliary Data Units will be dependent upon the implementation's use for them.
When encoding VC-2 video intended to be transported via RTP a VC-2 profile and level which ensures these requirements are met SHOULD be used.
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 the variable length coded transform parameters. This MUST NOT include the fragment header (since all data in the picture header is already included in the packet header).
For the Auxiliary Data packet type (PC = 0x20) the payload data MUST be a portion of the auxiliary data bytes contained in the Auxiliary data unit being being transmitted. The B flag MUST be set on the packet which contains the first byte, the E flag MUST be set on the packet which contains the last byte, the bytes MUST be included in order, and the packets MUST have contiguous sequence numbers.
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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x42 | 0x42 | 0x43 | 0x44 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parse Code | Next Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prev Parse Offset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
Figure 8: VC-2 Parse Info Header
To reassemble the data in the RTP packets into a valid VC-2 Sequence the receiver SHOULD:
VC-2 provides no underlying protection against data loss, so it may be useful to employ forward error correction to the stream. A mechanism for doing this to a generic RTP stream is specified in RFC5109. If making use of this mechanism to provide multi-level protection then the packets SHOULD be assigned to layers based upon their packet type, with the packet types in order of importance being:
It is RECOMMENDED that if multi-level protection is to be used then one layer will protect all Sequence Header packets, and a second will protect Sequence Headers and all Fragments. If desired a third layer MAY protect Auxiliary Data and End of Sequence packets. Padding data SHOULD NOT be protected by FEC.
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, and applications implementing this standard MUST comply with it. RFC 8085 provides additional information on the best practices for applying congestion control to UDP streams.
In particular it should be noted that the expected data rate for RTP sessions which use this profile is likely to be in the range of gigabits per second. If used on a closed network which has been correctly provisioned for the expected data rates this might not pose a problem, but there is always the risk of data getting out onto the open internet.
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:
Subtype name:
Required parameters:
Optional parameters:
Encoding considerations:
Security considerations:
Interoperability considerations: N/A
Published specification:
Applications that use this media type:
Fragment Identifier Considerations: N/A
Additional information: N/A
Person & email address to contact for further information:
Intended usage:
Restrictions on usage:
Author:
Change controller:
Provisional registration? (standards tree only):
The mapping of the above defined payload format media type and its parameters SHALL be done according to Section 3 of RFC 4855.
Version and level SHALL be specified in decimal when present.
For example, a sample SDP mapping for VC-2 could be as follows:
m=video 30000 RTP/AVP 112
a=rtpmap:112 vc2/90000
a=fmtp:112 profile=HQ;version=3;level=0
In this example, a dynamic payload type 112 is used for vc-2 data. The 90 kHz RTP timestamp rate is specified in the "a=rtpmap" line after the subtype. In the "a=fmtp:" line, profile HQ, version 3, and level 0 (unknown or non-standard level) are specified.
All parameters are declarative.
This memo requests that IANA registers video/vc2 as specified in Section 7.1. 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 lies with 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.
To avoid buffer overruns when processing these packets the receiver MUST consider both the reported fragment length and the actual received size of a packet containing slice data.
In some cases the transmitter may need to decode variable length coded headers in order to extract some data from the VC-2 bitstream before assembling packets. This process is potentially subject to buffer overruns if not implemented carefully.
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.
| [RFC3711] | Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004. |
| [RFC4585] | Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006. |
| [RFC5109] | Li, A., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, DOI 10.17487/RFC5109, December 2007. |
| [RFC5124] | Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008. |
| [RFC7201] | Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014. |
| [RFC7202] | Perkins, C. and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014. |