Payload Working Group J. Weaver
Internet-Draft BBC
Intended status: Standards Track August 9, 2017
Expires: February 10, 2018
RTP Payload Format for VC-2 HQ Profile Video
draft-ietf-payload-rtp-vc2hq-03
Abstract
This memo describes an RTP Payload format for the High Quality (HQ)
profile of SMPTE 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).
Status of This Memo
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 http://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 February 10, 2018.
Copyright Notice
Copyright (c) 2017 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
(http://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
Weaver Expires February 10, 2018 [Page 1]
Internet-Draft Abbreviated Title August 2017
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3
3. Media Format Description . . . . . . . . . . . . . . . . . . 3
4. Payload format . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . 9
4.2. Payload Header . . . . . . . . . . . . . . . . . . . . . 10
4.3. The Choice of Parse Codes (Informative) . . . . . . . . . 12
4.4. Payload Data . . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Reassembling the Data . . . . . . . . . . . . . . . . 13
5. Congestion Control Considerations . . . . . . . . . . . . . . 14
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 15
6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 15
6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . 16
6.2.1. Offer/Answer Considerations . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
This memo specifies an RTP payload format for the video coding
standard SMPTE ST 2042-1:2017 [VC2] 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.
Weaver Expires February 10, 2018 [Page 2]
Internet-Draft Abbreviated Title August 2017
The primary use for VC-2 is likely to be in professional video
production environments.
2. Conventions, Definitions and Acronyms
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 [RFC2119].
3. Media Format Description
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:
o Sequence Headers,
o High Quality Pictures,
o High Quality Fragments,
o Auxiliary Data,
o Padding Data, and
o 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.
Weaver Expires February 10, 2018 [Page 3]
Internet-Draft Abbreviated Title August 2017
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 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.
4. Payload format
This specification only covers the transport of Sequence Headers,
High Quality Fragments, Auxiliary Data, and (optionally) End of
Sequence headers and Padding Data.
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: one which carries the VC-2 Sequence Header
(Figure 1), one which carries the Picture Fragment containing the
VC-2 Transform Parameters for a Picture (Figure 2), one which carries
a Picture Fragment containing VC-2 Coded Slices (Figure 3) for a
picture, one which signals the end of a VC-2 Sequence (Figure 4), one
which carries the contents of an auxiliary data unit (Figure 5), and
one which indicates the presence of a padding data unit (Figure 6).
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 (Section 4.3).
Weaver Expires February 10, 2018 [Page 4]
Internet-Draft Abbreviated Title August 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Weaver Expires February 10, 2018 [Page 5]
Internet-Draft Abbreviated Title August 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Weaver Expires February 10, 2018 [Page 6]
Internet-Draft Abbreviated Title August 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Slices
Weaver Expires February 10, 2018 [Page 7]
Internet-Draft Abbreviated Title August 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
Weaver Expires February 10, 2018 [Page 8]
Internet-Draft Abbreviated Title August 2017
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Optional Extension Header |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Extended Sequence Number |B|E| Reserved | PC = 0x30 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Optional Payload Data .
. .
+---------------------------------------------------------------+
Figure 6: RTP Payload Format For Padding Data
4.1. RTP Header Usage
The fields of the RTP header have the following additional notes on
their useage:
Marker Bit (M): 1 bit The marker bit MUST be set on any packet which
contains the final slice in a coded picture and MUST NOT be set
otherwise.
Payload Type (PT): 7 bits A dynamically allocated payload type field
that designates the payload as VC-2 coded video.
Sequence Number: 16 bits 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.
Timestamp: 32 bits 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
Weaver Expires February 10, 2018 [Page 9]
Internet-Draft Abbreviated Title August 2017
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
[RFC3550].
4.2. Payload Header
The fields of the extended headers are defined as follows:
Extended Sequence Number: 16 bits 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.
B: 1 bit MUST be set to 1 if the packet contains the first byte of
an Auxiliary Data or Padded Data Unit.
E: 1 bit MUST be set to 1 if the packet contains the final byte of
an Auxiliary Data or Padded Data Unit.
I: 1 bit 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 if the packet contains data from any part of a
progressive frame.
F: 1 bit 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 if the packet contains data from the first
field of an interlaced frame or any part of a progressive
frame.
Parse Code (PC): 8 bits Contains a Parse Code which MUST be the
value indicated for the type of data in the packet.
Data Length: 32 bits For an auxiliary data unit this contains the
number of bytes of data contained in the uncoded payload
section of this packet. For a Padding Data Unit this field may
have any value and simply indicates the size of the recommended
padding.
Weaver Expires February 10, 2018 [Page 10]
Internet-Draft Abbreviated Title August 2017
Picture Number: 32 bits 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 [VC2].
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.
Slice Prefix Bytes: 16 bits 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 [VC2].
In the VC-2 specification this value is not restricted to 16
bits, but in practice this is unlikely to ever be too large.
Slice Size Scaler: 16 bits 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 [VC2].
In the VC-2 specification this value is not restricted to 16
bits, but in practice this is unlikely to ever be too large.
Fragment Length: 16 bits Contains the number of bytes of data
contained in the coded payload section of this packet.
No. of Slices: 16 bits 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.
Slice Offset X: 16 bits Indicates the X coordinate of the first
slice in this packet, in slices, starting from the top left
corner of the picture.
Slice Offset Y: 16 bits Indicates the Y coordinate of the first
slice in this packet, in slices, starting from the top left
corner of the picture.
Weaver Expires February 10, 2018 [Page 11]
Internet-Draft Abbreviated Title August 2017
4.3. The Choice of Parse Codes (Informative)
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.
If an incoming stream to be transmitted contains High Quality Picture
Data Units (Parse Code 0xE8) then these MUST be converted into High
Quality Picture Fragments (Parse Code 0xEC) before the data is placed
in the RTP packets.
+----------+-----------+---------------------+---------------+
| PC (hex) | Binary | Description | Origin |
+----------+-----------+---------------------+---------------+
| 0x00 | 0000 0000 | Sequence Header | VC-2 Spec |
| 0x10 | 0001 0000 | End of Sequence | VC-2 Spec |
+----------+-----------+---------------------+---------------+
| 0xEC | 1110 1100 | HQ Picture Fragment | VC-2 Spec |
+----------+-----------+---------------------+---------------+
Figure 7: Parse Codes and Meanings
4.4. Payload Data
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 Padding Data packet type (PC = 0x30) the payload data is
OPTIONAL, and if present MUST be a series of 0x00 values.
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
Weaver Expires February 10, 2018 [Page 12]
Internet-Draft Abbreviated Title August 2017
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.
4.4.1. Reassembling the 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:
o Take the data from each packet with a Parse Code of 0x00 and
prepend a valid VC-2 Parse Info header (Figure 8) 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.
o 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 (Figure 8) followed by the picture
number, fragment data length, and slice count (0) to it with the
same parse code.
o Take the data from each packet with a Parse Code of 0xEC and No.
of Slices not set to 0 (which together indicates that this packet
contains coded slices) and prepend a valid VC-2 Parse Info header
(Figure 8) followed by the picture number, fragment data length,
slice count, x offset and y offset taken from the packet header to
it with the same parse code.
Weaver Expires February 10, 2018 [Page 13]
Internet-Draft Abbreviated Title August 2017
o A receiver MAY combine all fragment data units (with parse code
0xEC) and the same picture number into a single picture data unit
with parse code 0xE8. If the stream is required to comply with
major version 2 of the VC-2 Spec then this MUST be done.
o Take the data from each packet with a Parse Code of 0x20 and the B
bit set and prepend a valid VC-2 Parse Info header (Figure 8) with
the parse code 0x20 and then take each subsequent packet with
parse code 0x20 without the B bit set and append their payload to
the growing data unit. When all packets for a particular data
unit have been received it SHOULD be included in the output
stream. The final packet for a data unit will have the E bit set.
o Once a data unit has been assembled, whether a Sequence Header,
Coded Picture Fragment, Coded Picture, or Auxiliary Data Unit, 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.
o 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.
o A Padding Data parse info header MAY be inserted when a packet
with parse code set to 0x30 and the B bit set is encountered, or
at any other time that is allowed in a valid VC-2 stream. The
length of this padding data MAY have any value, and its contents
MUST be set to a series of zero bytes.
5. Congestion Control Considerations
Congestion control for RTP SHALL be used in accordance with RFC 3550
[RFC3550], and with any applicable RTP profile; e.g., RFC 3551
[RFC3551]. 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 [I-D.ietf-avtcore-rtp-circuit-breakers] is an update
to RTP [RFC3550] that defines criteria for when one is required to
stop sending RTP Packet Streams. The circuit breakers is to be
implemented and followed.
Weaver Expires February 10, 2018 [Page 14]
Internet-Draft Abbreviated Title August 2017
6. Payload Format Parameters
This RTP payload format is identified using the video/vc2 media type
which is registered in accordance with RFC 4855 [RFC4855] and using
the template of RFC 6838 [RFC6838].
6.1. Media Type Definition
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
[RFC6838].
Security considerations:
Please see security consideration in RFCXXXX
Interoperability considerations: N/A
Published specification:
"VC-2 Video Compression", SMPTE Standard ST 2042-1 [VC2]
Applications that use this media type:
Video Communication.
Additional information: N/A
Person & email address to contact for further information:
Weaver Expires February 10, 2018 [Page 15]
Internet-Draft Abbreviated Title August 2017
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.)
6.2. Mapping to SDP
The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of RFC 4855
[RFC4855].
6.2.1. Offer/Answer Considerations
All parameters are declarative.
7. IANA Considerations
This memo requests that IANA registers video/vc2 as specified in
Section 6.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).
8. Security Considerations
RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP
specification [RFC3550] , and in any applicable RTP profile such as
RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
Weaver Expires February 10, 2018 [Page 16]
Internet-Draft Abbreviated Title August 2017
SAVPF [RFC5124]. However, as "Securing the RTP Protocol Framework:
Why RTP Does Not Mandate a Single Media Security Solution" [RFC7202]
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
[RFC7201]. 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.
9. RFC Editor Considerations
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.
10. References
10.1. Normative References
[I-D.ietf-avtcore-rtp-circuit-breakers]
Perkins, C. and V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-18 (work in progress), August
2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>.
Weaver Expires February 10, 2018 [Page 17]
Internet-Draft Abbreviated Title August 2017
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
DOI 10.17487/RFC3551, July 2003,
<http://www.rfc-editor.org/info/rfc3551>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007,
<http://www.rfc-editor.org/info/rfc4855>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<http://www.rfc-editor.org/info/rfc6838>.
[VC2] SMPTE, "VC-2 Video Compression", SMPTE Standard ST 2042-1,
2017, <http://ieeexplore.ieee.org/document/7967896/>.
10.2. Informative References
[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,
<http://www.rfc-editor.org/info/rfc3711>.
[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,
<http://www.rfc-editor.org/info/rfc4585>.
[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, <http://www.rfc-editor.org/info/rfc5124>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<http://www.rfc-editor.org/info/rfc7201>.
[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, <http://www.rfc-editor.org/info/rfc7202>.
Weaver Expires February 10, 2018 [Page 18]
Internet-Draft Abbreviated Title August 2017
Author's Address
James P. Weaver
BBC
Email: james.barrett@bbc.co.uk
Weaver Expires February 10, 2018 [Page 19]