Internet DRAFT - draft-wilaw-moq-cmafpackaging

draft-wilaw-moq-cmafpackaging







Media Over QUIC                                                   W. Law
Internet-Draft                                                    Akamai
Intended status: Informational                                 L. Curley
Expires: 4 April 2024                                     2 October 2023


                    CMAF Packaging for moq-transport
                    draft-wilaw-moq-cmafpackaging-00

Abstract

   Packaging CMAF content for use with moq-transport.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://wilaw.github.io/moq-cmaf-packaging/draft-wilaw-moq-
   cmafpackaging.html.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-wilaw-moq-
   cmafpackaging/.

   Discussion of this document takes place on the Media Over QUIC
   Working Group mailing list (mailto:moq@ietf.org), which is archived
   at https://mailarchive.ietf.org/arch/browse/moq/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/moq/.

   Source for this draft and an issue tracker can be found at
   https://github.com/wilaw/moq-cmaf-packaging.

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 4 April 2024.




Law & Curley              Expires 4 April 2024                  [Page 1]

Internet-Draft      CMAF Packaging for moq-transport        October 2023


Copyright Notice

   Copyright (c) 2023 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Media Object Payload  . . . . . . . . . . . . . . . . . . . .   3
   4.  Mapping CMAF objects to MOQT Streams  . . . . . . . . . . . .   3
     4.1.  CMAF Fragment to MOQT Group . . . . . . . . . . . . . . .   3
     4.2.  CMAF Chunk to MOQT Object . . . . . . . . . . . . . . . .   3
   5.  Switching sets  . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Initialization headers  . . . . . . . . . . . . . . . . . . .   4
     6.1.  Binary objects  . . . . . . . . . . . . . . . . . . . . .   4
     6.2.  MOQT Tracks . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Content protection and encryption . . . . . . . . . . . . . .   4
   8.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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.









Law & Curley              Expires 4 April 2024                  [Page 2]

Internet-Draft      CMAF Packaging for moq-transport        October 2023


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:

4.1.  CMAF Fragment to MOQT Group

   A complete CMAF Fragment (see [CMAF] sect 6.6.1) into a single object
   within each group.  This results in there being a single GOP (Group
   of Pictures) in the media object and a single media object per group.

4.2.  CMAF Chunk to MOQT Object







Law & Curley              Expires 4 April 2024                  [Page 3]

Internet-Draft      CMAF Packaging for moq-transport        October 2023


   *  Each CMAF chunk (see [CMAF] sect 6.6.5) in a separate MOQT Object.
      All MOQT Objects holding chunks from the same parent fragment MUST
      belong to the same MOQT Group.  A new MOQT Group MUST be generated
      for each new CMAF Fragment.

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:

6.1.  Binary objects

   As a binary blob which is communicated to the client via a mechanism
   defined by the streaming format.

6.2.  MOQT Tracks

   As a MOQT Track.  In this case the track MUST have only a single
   GROUP and a single OBJECT.  The payload of the object MUST be the
   complete initialization header.  The mapping of this initialization
   MOQT TRACK to the MOQT track which it initializes is defined by the
   streaming format.

7.  Content protection and encryption

   The media object payloads MAY be encrypted.  If the content is
   encryptedm then Common Encryption [CENC] MUST be used.  CMAF Track
   encruption MUST be applied following [CENC] Sectino 8.2.  CENC with
   'cbcs' mode (AES CBC with pattern encryption) is the RECOMMENDED
   encryption method.






Law & Curley              Expires 4 April 2024                  [Page 4]

Internet-Draft      CMAF Packaging for moq-transport        October 2023


   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., and V. Vasiliev,
              "Media over QUIC Transport", Work in Progress, Internet-
              Draft, draft-lcurley-moq-transport-00, 26 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-lcurley-moq-
              transport-00>.

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






Law & Curley              Expires 4 April 2024                  [Page 5]

Internet-Draft      CMAF Packaging for moq-transport        October 2023


   [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

   Will Law
   Akamai
   Email: wilaw@akamai.com


   Luke Curley
   Email: kixelated@gmail.com


































Law & Curley              Expires 4 April 2024                  [Page 6]