AOM Metadata Registry

Pre-Draft,

This version:
https://aomediacodec.github.io/metadata/
Issue Tracking:
GitHub
Editor:
(Netflix)
Warning

This specification is a proposed draft not endorsed by the working group.

Copyright 2022, AOM

Licensing information is available at http://aomedia.org/license/

The MATERIALS ARE PROVIDED “AS IS.” The Alliance for Open Media, its members, and its contributors expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE ALLIANCE FOR OPEN MEDIA, ITS MEMBERS, OR CONTRIBUTORS BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Abstract

This document centralizes the definitions of AOM-defined metadata payloads, in particular of ITU-T T.35 ones.

1. Introduction

This document centralizes the definitions of AOM-defined metadata payloads that can be used in more than one context (e.g. in video elementary streams, in audio elementary streams, or in container formats). Metadata means data not needed by media decoder to produce its output but possibly needed by further downstream processes to produce their output. A metadata payload is a byte stream representing metadata.

The metadata payloads defined in this document may be used by AOM specifications and non-AOM specifications. However, some metadata payloads based on ITU-T T.35 also defined in this specification are intended to have few or no dependencies to other AOM specifications and to be more easily reusable by non-AOM specifications.

TODO add example ...

Support for the metadata payloads defined in this specification is optional. However, if a processor claims to support one of the metadata payloads defined in this specification, it shall support identifying them, parsing the associated syntax, and respect the associated normative statements.

2. General Metadata Payloads

The metadata payloads defined in this section are intended to be used in AOM specifications. The exact carriage of this metadata is left to the specification using it. For example, a specification may have a generic metadata payload container, with a header carrying an identifier indicating the actual payload type. In this case, that specification would define the identifier associated with a payload defined in this section.

EXAMPLE: The AV1 video specification defines a metadata_type field to indicate the possible metadata payloads in AV1 bitstreams.

2.1. Timecode

NOTE: The following payload was initially defined in the AV1 video specification but is now documented in this specification for use by other specifcations that don’t need dependency on the AV1 video specification itself.

TODO add syntax

3. ITU-T T.35 Metadata

The mechanisms and metadata payloads defined in this section are intended to be used by AOM or non-AOM specifications capable of carrying ITU-T T.35 payloads.

This section defines how to identify AOM metadata payloads within ITU-T T.35 messages. It also defines a generic header for all AOM T.35 messages, including elements to identify the specific type of AOM payload. This section also lists the current set of such AOM-defined payloads.

3.1. General header and AOM code points

ITU-T T.35 AOM Metadata is ITU-T T.35 data using the following values:

What is the specification that defines the common header for all T.35 messages. Does it include a terminal_provider_oriented_code (2 bytes)? If so, AOM should define how to use it? Similarly, what about application identifier and application mode (used for e.g. in HDR10+ T.35 messages)?

3.2. AOM T.35 messages

3.2.1. Film Grain

This section defines the code point and syntax of AOM’s Film Grain metadata.

TODO add text

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Index

Terms defined by this specification

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119