[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-payload-rtp-vc2hq

Internet Engineering Task Force                                J. Weaver
Internet-Draft                                                       BBC
Intended status: Standards Track                            June 9, 2016
Expires: December 11, 2016


              RTP Payload Format for VC-2 HQ Profile Video
                   draft-weaver-payload-rtp-vc2hq-02

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 December 11, 2016.

Copyright Notice

   Copyright (c) 2016 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 December 11, 2016               [Page 1]


Internet-Draft              Abbreviated Title                  June 2016


   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  . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Payload Header  . . . . . . . . . . . . . . . . . . . . .   9
     4.3.  The Choice of Parse Codes (Informative) . . . . . . . . .  10
     4.4.  Payload Data  . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.1.  Reassembling the Data . . . . . . . . . . . . . . . .  11
   5.  Congestion Control Considerations . . . . . . . . . . . . . .  12
   6.  Payload Format Parameters . . . . . . . . . . . . . . . . . .  13
     6.1.  Media Type Definition . . . . . . . . . . . . . . . . . .  13
     6.2.  Mapping to SDP  . . . . . . . . . . . . . . . . . . . . .  14
       6.2.1.  Offer/Answer Considerations . . . . . . . . . . . . .  14
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  RFC Editor Considerations . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     10.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   This memo specifies an RTP payload format for the video coding
   standard SMPTE ST 2042-1:2012 [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 December 11, 2016               [Page 2]


Internet-Draft              Abbreviated Title                  June 2016


   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  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 December 11, 2016               [Page 3]


Internet-Draft              Abbreviated Title                  June 2016


   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.

4.  Payload format

   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
   (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, and one which signals the end of a VC-2 Sequence (Figure 4).

   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 (Section 4.3).


















Weaver                  Expires December 11, 2016               [Page 4]


Internet-Draft              Abbreviated Title                  June 2016


    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 December 11, 2016               [Page 5]


Internet-Draft              Abbreviated Title                  June 2016


    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 December 11, 2016               [Page 6]


Internet-Draft              Abbreviated Title                  June 2016


    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 December 11, 2016               [Page 7]


Internet-Draft              Abbreviated Title                  June 2016


    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

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
         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



Weaver                  Expires December 11, 2016               [Page 8]


Internet-Draft              Abbreviated Title                  June 2016


         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.

   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.

   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.

   Parse Code (PC): 8 bits  Contains a Parse Code which MUST be the
         value indicated for the type of data in the packet.

   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.



Weaver                  Expires December 11, 2016               [Page 9]


Internet-Draft              Abbreviated Title                  June 2016


   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.

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.  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".





Weaver                  Expires December 11, 2016              [Page 10]


Internet-Draft              Abbreviated Title                  June 2016


   +----------+-----------+---------------------+---------------+
   | 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 |
   +----------+-----------+---------------------+---------------+

                    Figure 5: 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 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.

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 6: VC-2 Parse Info Header





Weaver                  Expires December 11, 2016              [Page 11]


Internet-Draft              Abbreviated Title                  June 2016


   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 6) 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 6) 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).

   o  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.

   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.

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 December 11, 2016              [Page 12]


Internet-Draft              Abbreviated Title                  June 2016


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 December 11, 2016              [Page 13]


Internet-Draft              Abbreviated Title                  June 2016


      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 December 11, 2016              [Page 14]


Internet-Draft              Abbreviated Title                  June 2016


   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. Varun, "Multimedia Congestion Control:
              Circuit Breakers for Unicast RTP Sessions", draft-ietf-
              avtcore-rtp-circuit-breakers-15 (work in progress), April
              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 December 11, 2016              [Page 15]


Internet-Draft              Abbreviated Title                  June 2016


   [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,
              2012, <http://standards.smpte.org/content/978-1-61482-709-
              2/st-2042-1-2012/SEC1.abstract>.

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 December 11, 2016              [Page 16]


Internet-Draft              Abbreviated Title                  June 2016


Author's Address

   James P. Weaver
   BBC

   Email: james.barrett@bbc.co.uk













































Weaver                  Expires December 11, 2016              [Page 17]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/