One document matched: draft-ietf-payload-rtp-vc2hq-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc4585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc6838 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6838.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-payload-rtp-vc2hq-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">RTP Payload Format for VC-2 HQ Profile Video</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="James P. Weaver" initials="J.W."
surname="Weaver">
<organization>BBC</organization>
<address>
<email>james.barrett@bbc.co.uk</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Payload Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>rtp</keyword>
<keyword>vc-2</keyword>
<keyword>VC2</keyword>
<keyword>dirac</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.
</t>
<t>
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).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This memo specifies an RTP payload format for the video
coding standard <xref target="VC2">SMPTE ST 2042-1:2012</xref>
also known as VC-2</t>
<t>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.</t>
<t>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.</t>
<t>The primary use for VC-2 is likely to be in professional video
production environments.</t>
</section>
<section title="Conventions, Definitions and Acronyms">
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Media Format Description">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>The High Quality (HQ) profile for VC-2 restricts the types of
parse info headers which may appear in the Sequence to only:
<list style="symbols">
<t>Sequence Headers,</t>
<t>High Quality Pictures,</t>
<t>Auxiliary Data,</t>
<t>Padding Data, and</t>
<t>End of Sequence.</t>
</list>
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.</t>
<t>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.</t>
</section>
<section title="Payload format">
<t>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.</t>
<t>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.</t>
<t>For this reason this document defines four types of RTP packets in a VC-2
media stream: one which carries the <xref target="rtp_hdr_seq">VC-2 Sequence
Header</xref>, one which carries the <xref
target="rtp_hdr_preamble">picture fragment containing the VC-2 Transform Parameters for a
Picture</xref>, one which carries <xref
target="rtp_hdr_slices">a picture fragment containing VC-2 Coded Slices</xref> for a picture, and
one which signals the <xref target="rtp_hdr_eos">end of a VC-2
Sequence</xref>.</t>
<t>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.</t>
<t>The choices of PC codes is explained in more detail in <xref
target="pc_choice">a following informative section</xref>.</t>
<figure align="center" anchor="rtp_hdr_seq" title="RTP Payload
Format For
Sequence Header">
<artwork align="left"><![CDATA[
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 .
. .
+---------------------------------------------------------------+
]]></artwork>
</figure>
<figure align="center" anchor="rtp_hdr_preamble" title="RTP
Payload
Format
For
Transform
Parameters">
<artwork align="left"><![CDATA[
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 .
. .
+---------------------------------------------------------------+
]]></artwork>
</figure>
<figure align="center" anchor="rtp_hdr_slices" title="RTP
Payload
Format
For
Slices">
<artwork align="left"><![CDATA[
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 .
. .
+---------------------------------------------------------------+
]]></artwork>
</figure>
<figure align="center" anchor="rtp_hdr_eos" title="RTP Payload
Format For
End of Sequence">
<artwork align="left"><![CDATA[
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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
]]></artwork>
</figure>
<section title="RTP Header Usage">
<t>The fields of the RTP header have the following additional
notes on their useage:
<list style="hanging" hangIndent="6">
<t hangText="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.
</t>
<t hangText="Payload Type (PT): 7 bits">
A dynamically allocated payload type field that designates
the payload as VC-2 coded video.
</t>
<t hangText="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.
</t>
<t hangText="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 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.</t>
<t>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.
</t>
</list>
</t>
<t>The remaining RTP header fields are used as specified in
<xref target="RFC3550">RTP</xref>.</t>
</section>
<section title="Payload Header">
<t>The fields of the extended headers are defined as follows:
<list style="hanging" hangIndent="6">
<t hangText="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.
</t>
<t hangText="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 otherwise.
</t>
<t hangText="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 otherwise.
</t>
<t hangText="Parse Code (PC): 8 bits">
Contains a Parse Code which MUST be the value indicated
for the type of data in the packet.
</t>
<t hangText="Picture Number: 32 bits">
MUST contain the Picture Number for the coded picture this
packet contains data for, as described in <xref
target="VC2">Section 12.1 of the VC-2
specification</xref>.</t>
<t>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.</t>
<t>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.
</t>
<t hangText="Slice Prefix Bytes: 16 bits">
MUST contain the Slice Prefix Bytes value for the coded picture this
packet contains data for, as described in <xref
target="VC2">Section 12.3.4 of the VC-2
specification</xref>.</t>
<t> In the VC-2 specification this value is not restricted
to 16 bits, but in practice this is unlikely to ever be
too large.</t>
<t hangText="Slice Size Scaler: 16 bits">
MUST contain the Slice Size Scaler value for the coded picture this
packet contains data for, as described in <xref
target="VC2">Section 12.3.4 of the VC-2
specification</xref>.</t>
<t> In the VC-2 specification this value is not restricted
to 16 bits, but in practice this is unlikely to ever be
too large.</t>
<t hangText="Fragment Length: 16 bits">
Contains the number of bytes of data contained in the coded
payload section of this packet.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
<t hangText="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.
</t>
</list>
</t>
</section>
<section title="The Choice of Parse Codes (Informative)"
anchor="pc_choice">
<t>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.</t>
<t>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.</t>
<t>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".</t>
<figure align="center" anchor="parse_codes" title="Parse Codes
and Meanings">
<artwork align="left"><![CDATA[
+----------+-----------+---------------------+---------------+
| 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 | This document |
+----------+-----------+---------------------+---------------+
]]></artwork>
</figure>
</section>
<section title="Payload Data">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>For the End of Sequence packet type (PC = 0x10) there is no
payload data.</t>
<section title="Reassembling the Data">
<figure align="center" anchor="parse_info" title="VC-2 Parse
Info
Header">
<artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>To reassemble the data in the RTP packets into a valid VC-2
sequence the receiver SHOULD:
<list style="symbols">
<t>
Take the data from each packet with a Parse Code of 0x00
and prepend a valid <xref
target="parse_info">VC-2 Parse Info header</xref> 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.
</t>
<t>
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 <xref
target="parse_info">VC-2 Parse Info header</xref> 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).
</t>
<t>
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.
</t>
<t>
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.
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Congestion Control Considerations">
<t>Congestion control for RTP SHALL be used in accordance with <xref
target="RFC3550">RFC 3550</xref>, and with any applicable RTP profile;
e.g., <xref target="RFC3551">RFC 3551</xref>. 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. <xref
target="I-D.ietf-avtcore-rtp-circuit-breakers">Circuit Breakers</xref>
is an update to <xref target="RFC3550">RTP</xref> that defines
criteria for when one is required to stop sending RTP Packet Streams.
The circuit breakers is to be implemented and followed.</t>
</section>
<section title="Payload Format Parameters">
<t>This RTP payload format is identified using the video/vc2 media type
which is registered in accordance with <xref target="RFC4855">RFC
4855</xref> and using the template of <xref target="RFC6838">RFC
6838</xref>.</t>
<section anchor="media-type" title="Media Type Definition">
<t>Type name:</t>
<t><list style="empty">
<t>video</t>
</list>Subtype name:</t>
<t><list style="empty">
<t>vc2</t>
</list>Required parameters:</t>
<t><list style="empty">
<t>rate: The RTP timestamp clock rate. Applications using this payload format SHOULD use a value of 90000.</t>
<t>profile: The VC-2 profile in use, the only currently allowed value is "HQ".</t>
</list>Optional parameters: N/A</t>
<t>Encoding considerations:</t>
<t><list style="empty">
<t>This media type is framed and binary, see section 4.8 in
<xref target="RFC6838">RFC6838</xref>.</t>
</list>Security considerations:</t>
<t><list style="empty">
<t>Please see security consideration in RFCXXXX</t>
</list></t>
<t>Interoperability considerations: N/A</t>
<t>Published specification:</t>
<t><list style="empty">
<t><xref target="VC2">"VC-2 Video Compression", SMPTE Standard ST 2042-1</xref></t>
</list>Applications that use this media type:</t>
<t><list style="empty">
<t>Video Communication.</t>
</list>Additional information: N/A</t>
<t>Person & email address to contact for further
information:</t>
<t><list style="empty">
<t>james.barrett@bbc.co.uk</t>
</list>Intended usage:</t>
<t><list style="empty">
<t>COMMON</t>
</list>Restrictions on usage:</t>
<t><list style="empty">
<t>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.</t>
</list>Author:</t>
<t>Change controller:</t>
<t><list style="empty">
<t>IETF Payload working group delegated from the IESG.</t>
</list>Provisional registration? (standards tree only):</t>
<t><list style="empty">
<t>No</t>
</list>(Any other information that the author deems interesting
may be added below this line.)</t>
</section>
<section title="Mapping to SDP">
<t>The mapping of the above defined payload format media type and
its parameters SHALL be done according to Section 3 of <xref
target="RFC4855">RFC 4855</xref>.</t>
<section title="Offer/Answer Considerations">
<t>All parameters are declarative.</t>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>This memo requests that IANA registers video/vc2 as specified in
<xref target="media-type"></xref>. 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).</t>
</section>
<section title="Security Considerations">
<t>RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the <xref
target="RFC3550">RTP specification</xref> , and in any applicable RTP
profile such as <xref target="RFC3551">RTP/AVP</xref>, RTP/<xref
target="RFC4585">AVPF</xref>, <xref target="RFC3711">RTP/SAVP</xref>
or <xref target="RFC5124">RTP/SAVPF</xref>. However, as <xref
target="RFC7202">"Securing the RTP Protocol Framework: Why RTP Does
Not Mandate a Single Media Security Solution"</xref> 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 <xref target="RFC7201">Options for Securing RTP
Sessions</xref>. 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.</t>
<t>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.</t>
</section>
<section title="RFC Editor Considerations">
<t>Note to RFC Editor: This section may be removed after carrying out
all the instructions of this section.</t>
<t>RFCXXXX is to be replaced by the RFC number this specification
receives when published.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3550;
&rfc3551;
&rfc6838;
<?rfc include='reference.I-D.ietf-avtcore-rtp-circuit-breakers'?>
<?rfc include='reference.RFC.4855'?>
<reference anchor="VC2" target="http://standards.smpte.org/content/978-1-61482-709-2/st-2042-1-2012/SEC1.abstract">
<front>
<title>VC-2 Video Compression</title>
<author>
<organization>SMPTE</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="SMPTE Standard" value="ST 2042-1" />
</reference>
</references>
<references title="Informative References">
&rfc3711;
&rfc4585;
<?rfc include='reference.RFC.7202'?>
<?rfc include='reference.RFC.7201'?>
<?rfc include='reference.RFC.5124'?>
</references>
<!-- <section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section> -->
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:35 |