CMAF Packaging for moq-transport

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 https://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 22 January 2025.¶

Copyright Notice

Copyright (c) 2024 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 (https://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 to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This specification defines an interoperable method of transmitting CMAF [CMAF] compliant media content over Media Over QUIC Transport (MOQT) [MoQTransport]. Multiple mappings are supported, including mapping complete Groups of Pictures (GOPS) [ISOBMFF] or individual frames to MoQTransport Objects. This specification is intended to be referenced by MOQT-compliant Streaming Formats.¶

2. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶

3. Media Object Payload

This specification defines a direct mapping between CMAF Tracks ( [CMAF] Sect 3.2.1) and MOQT tracks ([MoQTransport] Sect 2.3). As a consequence, the MOQT Object payload:¶

• MUST consist of a Segment Type Box (styp) followed by any number of media fragments. Each media fragment consists of a Movie Fragment Box (moof) followed by a Media Data Box (mdat). The Media Fragment Box (moof) MUST contain a Movie Fragment Header Box (mfhd) and Track Box (trak) with a Track ID (track_ID) matching a Track Box in the initialization fragment.¶

• MUST contain a single [ISOBMFF] track.¶

• MUST contain media content encoded in decode order. This implies an increasing decoding time stamp (DTS).¶

• MAY contain any number of frames/samples.¶

• MAY have gaps between frames/samples.¶

• MAY overlap with other objects. This means timestamps may be interleaved between objects.¶

4. Mapping CMAF objects to MOQT Streams

This specification defines two methods for mapping CMAF objects to MOQT objects:¶

5. Switching sets

CMAF switching sets are a set of one or more CMAF tracks (3.2.1), where each track is an alternative encoding of the same source content and are constrained to enable seamless track switching (3.3.9). If such switching sets are to be transported over MOQT, irrespective of the mapping of CMAF Objects to MOQT Streams, then MOQT Group numbers MUST be media time-aligned between the MOQT tracks. Media time-aligned requires that the presentation time of the first media sample contained within the first MOQT Object of each MOQT Group is identical.¶

6. Initialization headers

A CMAF header is sequence of CMAF constrained ISO BMFF boxes that do not reference any media samples (3.3.15), but are associated with a CMAF track (3.2.1) and necessary for the decoding of its CMAF fragments (3.1.1). The header for a given MOQT Track may be packaged in one of two ways:¶

7. Content protection and encryption

The media object payloads MAY be encrypted. If the content is encrypted then Common Encryption [CENC] MUST be used. CMAF Track encruption MUST be applied following [CENC] Section 8.2. using either CENC with 'cbcs' mode (AES 128-bit keys in Cipher-block chaining mode and pattern encruption) or 'cenc' mode (AES 128-bit keys in Counter Mode).¶

Any license acquisition information used to acquire CMAF decryption key(s) MUST be signalled by the Streaming Format, and not in the CMAF header.¶

8. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

9. Security Considerations

TODO Security¶

10. IANA Considerations

This document has no IANA actions.¶

11. Normative References

[CENC]

"International Organization for Standardization - Information technology - MPEG systems technologies - Part 7: Common encryption in ISO base media file format files", December 2020.

[CMAF]

"Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media", March 2020.

[ISOBMFF]

"Information technology -- Coding of audio-visual objects -- Part 12: ISO Base Media File Format", December 2015.

[MoQTransport]

Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-05, 8 July 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-05>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

TODO acknowledge.¶

Authors' Addresses