Subject: [media-types] Registration of video/smpte291 media type

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 9 Aug 2016 18:21:04 +0300

Hi there,

https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-ancillary/
completed WGLC in the Payload WG.
The document registers video/smpte291.

The new registration is in Section 3.1 of the document and is also given
below.

Comments on the registration are welcome.

Thanks.

Ali Begen
Payload WG co-chair

   Type name: video

   Subtype name: smpte291

   Required parameters:

      Rate: RTP timestamp clock rate.  When an ANC RTP stream is to be
      associated with an RTP video stream, the RTP timestamp rates
      SHOULD be the same to ensure that ANC data packets can be
      associated with the appropriate frame or field.  Otherwise, a 90
      kHz rate SHOULD be used.

   Optional parameters:

      DID_SDID: Data identification and Secondary data identification
      words.

      The presence of the DID_SDID parameters signals that all ancillary
      data packets of this stream are of a particular type or types,
      i.e., labeled with a particular DIDs and SDIDs.  DID and SDID
      values of SMPTE Registered ANC packet types can be found on the
      SMPTE Registry for Data Identification Word Assignments at:

      http://www.smpte-ra.org/smpte-ancillary-data-smpte-st-291

      "Type 1" ANC packets (which do not have SDIDs defined) SHALL be
      labeled with SDID=0x00.

      DID and SDID values can be registered with SMPTE as per SMPTE ST
      291-1 [ST291].

   Encoding considerations: This media type is framed and binary; see
   Section 4.8 of RFC 6838 [RFC6838].

   Security considerations: See Section 5 of [this RFC]

   Interoperability considerations: Data items in smpte291 can be very
   diverse.  Receivers might only be capable of interpreting a subset of
   the possible data items.  Some implementations may care about the
   location of the ANC data packets in the SDI raster, but other
   implementations may not care.

   Published specification: [this RFC]

   Applications that use this media type: Devices that stream real-time
   professional video, especially those that must interoperate with
   legacy serial digital interfaces (SDI).

   Additional Information: none

   Person & email address to contact for further information: T.
   Edwards <[email-masked]>, IETF Payload Working Group
   <[email-masked]>

   Intended usage: COMMON

   Restrictions on usage: This media type depends on RTP framing, and
   hence is only defined for transfer via RTP RFC 3550 [RFC3550].
   Transport within other framing protocols is not defined at this time.

   Author: T.  Edwards <[email-masked]>

   Change controller: IETF Audio/Video Transport Payloads working group
   delegated from the IESG.