| Internet-Draft | media-container | March 2026 |
| Zanaty, et al. | Expires 4 September 2026 | [Page] |
This specification describes a Low Overhead Media Container (LOC) format for encoded and encrypted audio and video media data to be used primarily for interactive Media over QUIC Transport (MOQT). It may be used in the MOQT Streaming Format (MSF) specification, which defines a catalog format for publishers to declare and describe their LOC tracks and for subscribers to consume them. Examples are also provided for building media applications using LOC and MOQT.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://moq-wg.github.io/loc/draft-ietf-moq-loc.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-moq-loc/.¶
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/moq-wg/loc.¶
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 September 2026.¶
Copyright (c) 2026 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.¶
This specification describes a low-overhead media container (LOC) format for encoded and encrypted audio and video media data.¶
"Low-overhead" refers to minimal extra encapsulation as well as minimal application overhead when interfacing with WebCodecs [WebCodecs].¶
The container format description is specified for all audio and video codecs defined in the WebCodecs Codec Registry [WEBCODECS-CODEC-REGISTRY]. The audio and video payload bitstream is identical to the "internal data" inside an EncodedAudioChunk and EncodedVideoChunk, respectively, specified in the registry.¶
(Note: Do we need to support timed text tracks such as Web Video Text Tracks (WebVTT) ?)¶
In addition to the media payloads, critical metadata called properties are also specified for audio and video payloads.¶
A primary motivation is to align with media formats used in WebCodecs to minimize extra encapsulation and application overhead when interfacing with WebCodecs. Other container formats like CMAF or RTP would require more extensive application overhead in format conversions, as well as larger encapsultion overhead which may burden some use cases like low bitrate audio scenarios.¶
This specification can also be used by applications outside the context of WebCodecs or a web browser. While the media payloads are defined by referring to the "internal data" of an EncodedAudioChunk or EncodedVideoChunk in the WebCodecs Codec Registry, this "internal data" is the elementary bitstream format of codecs without any encapsulation. Referring to the WebCodecs Codec Registry avoids duplicating it in an identical IANA registry.¶
Section 2.3 defines the metadata, called properties, associated with audio and video payloads.¶
Section 3 defines the usage of end-to-end encrypted LOC payloads.¶
Section 4 provides examples with details for building audio and video applications using LOC over MOQ.¶
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.¶
Track, Group, Subgroup, Object, and their corresponding identifiers (ID or alias) are defined in [MoQTransport] and used here to refer to those aspects of the MOQT Object Model.¶
The WebCodecs Codec Registry defines the contents of an EncodedAudioChunk and EncodedVideoChunk for the audio and video codec formats in the registry. The "internal data" in these chunks is used directly in this specification as the "LOC Payload" bitstream. This "internal data" is the elementary bitstream format of each codec without any encapsulation.¶
For video formats with multiple bitstream formats in the WebCodecs Registry, such as H.264/AVC or H.265/HEVC, the LOC Payload can use either the "canonical" format ("avc" or "hevc") often used in storage containers like MP4 / ISO BMFF, or the "annexB" format used in some non-MP4 applications. These formats differ in how they carry initialization and configuration information called parameter sets as well as how parts of a video frame are delimited with length prefixes or start codes.¶
Parameter sets can be sent in the bitstream payload before key frames, similar to "annexB" formats. Newer "canonical" formats such as "avc3" and "hev1" codec strings also support parameter sets in the bitstream payload or outside it in "extradata" metadata headers.¶
Parameter sets can be sent in headers before key frames, as described in the Video Config LOC Property Section 2.3.2.1, similar to the original "canonical" formats such as "avc1" and "hvc1" codec strings. The Video Config contents are the "extradata" bytes defined by the corresponding codec specification, which map to the WebCodecs VideoDecoderConfig description property in the EncodedVideoChunkMetadata.¶
A 4-byte length prefix can be sent before each NAL Unit, similar to "canonical" ("avc" or "hevc") formats. A length value of 1 SHOULD be interpreted as a start code rather than a length. The length is in network byte order, i.e. big endian, and SHOULD be 4 bytes long to disambiguate from start code prefixes. A length prefix less than 4 bytes long, which is uncommon, MAY be specified in the Video Config Section 2.3.2.1.¶
A 4-byte start code can be sent before each NAL Unit, similar to "annexB" formats. The start code value is 1 in network byte order, i.e. big endian, and SHOULD be 4 bytes long to disambiguate from length prefixes. A 3-byte start code, which is uncommon, MAY be used if the track never uses length prefixes or any Config Section 2.3.2.1.¶
An application object when transported as a [MoQTransport] object is composed of a MOQ Object Header, with optional Properties, and a Payload. Media objects encoded using the container format defined in this specification populate the MOQ Object Properties with the LOC Public Properties, and populate the MOQ Object Payload with LOC Private Properties followed by the LOC Payload, as shown below.¶
The LOC Payload is the "internal data" of an EncodedAudioChunk or EncodedVideoChunk.¶
The LOC Public and Private Properties carry optional metadata related to the Payload, where Public Properties are visible to relays while Private Properties can be encypted end to end wi¶
<----------- MOQ Object ------------>
+----------+--------------+-----------+
| MOQ | MOQ Header | MOQ |
| Header | Properties | Payload |
+----------+--------------+-----------+
| |
| |
+--------------+---------------------------+
| LOC Public | LOC Private | LOC |
| Properties | Properties | Payload |
+--------------+---------------+-----------+
LOC Public Properties = some MOQ Object Properties
LOC Private Properties + LOC Payload = all MOQ Object Payload
LOC Payload = "internal data" of EncodedAudio/VideoChunk
¶
The LOC Public and Private Properties carry optional metadata for the corresponding LOC Payload. The LOC Public Properties are contained within the MOQ Object Properties. This metadata provides necessary information for end subscribers, relays and other intermediaries to perform their operations without accessing the media payload. For example, media switches can use this metadata to perform their media switching decisions without accessing the payload which may be encrypted end-to-end (from original publisher to end subscribers). The LOC Private Properties are contained within the MOQ Object Payload, and are not intended to be processed by relays.¶
The following sections define specific metadata as LOC Public and Private Properties and register them in the IANA registry for MOQ Object Properties.¶
Other specifications can define other metadata as LOC Public and Private Properties and register them in the same registry. Each property must specify the following information in the IANA registry.¶
Name: Short name for the metadata (not sent on the wire)¶
Description: Detailed description (not sent on the wire)¶
ID: Identifier assigned by the registry (vi64)¶
Length: Length of metadata Value in bytes (vi64 if ID is odd, omitted if ID is even)¶
Value: Value of metadata (vi64 if ID is even, Length bytes if ID is odd)¶
Name: Timestamp¶
Description: Timestamp of the encoded media frame encoded as vi64. The unit of the timestamp is determined by the Timescale property Section 2.3.1.2. If no timescale property is present, the timestamp is interpreted as wall-clock time in microseconds since the Unix epoch.¶
ID: 0x06¶
Length: Omitted (ID is even)¶
Value: vi64 (1-8 bytes)¶
Name: Timescale¶
Description: The number of Timestamp units per second, encoded as vi64. This property defines the unit for interpreting timestamp values in the Timestamp property. Common values include 1000000 for microseconds, 48000 for audio at 48kHz sample rate, 90000 for video at 90kHz clock rate. When this property is present, the Timestamp represents media time rather than wall-clock time. The epoch or anchor point for the timestamp is application-defined. If this property is not present, timestamps default to microseconds since Unix epoch.¶
ID: 0x08¶
Length: Omitted (ID is even)¶
Value: vi64 (1-9 bytes)¶
Name: Video Config¶
Description: Video codec configuration "extradata", as defined by the corresponding codec specification, which maps to the WebCodecs VideoDecoderConfig description property in the EncodedVideoChunkMetadata.¶
ID: 13 (IANA, please assign from the MOQ Properties Registry)¶
Length: Varies¶
Value: Varies¶
Name: Video Frame Marking¶
Description: Flags for video frames which are independent, discardable, or base layer sync points, as well as temporal and spatial layer identification, as defined in [RFC9626], encoded in the least significant bits of a vi64.¶
ID: 4 (IANA, please assign from the MOQ Properties Registry)¶
Length: Varies (1-4 bytes)¶
Value: Varies¶
Name: Audio Level¶
Description: The magnitude of the audio level of the corresponding audio frame as well as a voice activity indicator as defined in section 3 of [RFC6464], encoded in the least significant 8 bits of a vi64.¶
ID: 6 (IANA, please assign from the MOQ Properties Registry)¶
Length: Varies (1-2 bytes)¶
Value: Varies¶
When end to end encryption is supported, the encoded payload is encrypted with symmetric keys derived from key establishment mechanisms, such as [MOQ-MLS], and the payload itself is protected using mechanisms defined in [SecureObjects].¶
[SecureObjects] defines a comprehensive framework for end-to-end encryption of MOQT objects. When using Secure Objects with LOC, the following considerations apply:¶
The Secure Object Key ID property (type 0x2 in [SecureObjects]) MUST be included as an immutable property to identify the keying material used for encryption. This property is authenticated but not encrypted, allowing relays to forward objects without decryption while ensuring subscribers can identify the correct decryption key.¶
LOC Properties that should be immutable but visible to relays SHOULD be encoded as Immutable Properties as defined in [MoQTransport] to ensure they cannot be modified by relays and are included in the authenticated associated data (AAD) during encryption. This specification does not define any Immutable Properties, but other specifications may define some for use with LOC.¶
Some LOC metadata may be sensitive and should not be visible to relays. [SecureObjects] defines a Private properties mechanism (type 0xA) that allows metadata to be encrypted alongside the payload.¶
The following LOC properties MAY be carried as Private properties when end-to-end confidentiality is required:¶
Timestamp and Timescale - reveals timing information about the source¶
Audio Level - reveals voice activity and audio characteristics¶
Video Frame Marking - reveals encoding structure details¶
Video Config - reveals encoding configuration details¶
When using Private properties:¶
The LOC property is encoded as a key-value pair within the Private properties payload¶
The Private properties are concatenated with the media payload before encryption¶
Upon decryption, the receiver extracts the Private properties and reconstructs the LOC metadata¶
This approach allows sensitive metadata to remain confidential from relays while still being available to authorized end subscribers.¶
Implementations using LOC with Secure Objects MUST support the AES_128_GCM_SHA256_128 cipher suite (0x0004). Other cipher suites defined in [SecureObjects] MAY be used based on application requirements for authentication tag size versus bandwidth overhead.¶
This section provides examples with details for building audio and video applications using MOQ and LOC; more specifically, it provides information on:¶
Using a MSF catalog [MoQCatalog] to describe track information,¶
Packaging media into LOC streaming format, and¶
Mapping application media objects to the MOQT object model and transport.¶
The figure below shows the conceptual model for mapping media application data to the MOQT object model and underlying QUIC transport.¶
+------------------------------+
| Media Application |
| Audio, Video Frames |
+---------------+--------------+
|
|
+---------------v--------------------+
| MOQT Object Model |
| Tracks, Groups, Subgroups, Objects |
+---------------+--------------------+
|
|
+---------------v--------------+
| QUIC |
| Streams, Datagrams |
+------------------------------+
¶
An example is shown below for an Opus mono channel audio track at 48Khz.¶
codec: "opus" bitrate: 24000 samplerate: 480000 channelConfig: "mono" lang: "en"¶
When ready for publishing, each encoded audio chunk, say 10ms, represents a
MOQT Object. In this setup, there is one MOQT Object
per MOQT Group, where the GroupID in the object header is
increment by one for each encoded audio chunk and the ObjectID
is defaulted to value 0.¶
These objects can be sent as QUIC streams or datagrams. When mapped to
QUIC datagrams, each object must fit entirely within a QUIC datagram, and
when mapped to QUIC Streams, each such unitary group is sent over
an individual unidirectional QUIC stream since there is just one SubGroup per
each MOQT Group.¶
An example is shown below for an H.264 video track with 1280x720p resolution and 30 fps frame rate at 1 Mbps bitrate.¶
codec: "avc3.42E01E" bitrate: 1000000 framerate: 30 width: 1280 height: 720¶
When ready for publishing, each encoded video chunk is considered as input
to MOQT Object payload. If encrypted, the output of encryption will serve as
the object's payload. The GroupID is incremented by 1 at IDR Frame boundaries.
The ObjectID is increment by 1 for each encoded video frame, starting at 0
and resetting to 0 at the start of a new group. The first encoded video frame,
MOQT Object with ObjectID 0, shall be the Independent (IDR) frame and
the rest of the encoded video frames corresponds to dependent (delta) frames,
organized in the decode order.¶
When mapping to QUIC for sending, one unidirectional QUIC stream is setup to deliver all the encoded video chunks within a MOQT group.¶
When decoding at the 'End Consumer', the objects from each of the QUIC streams are fed in the GroupID then ObjectID order to the decoder for the track.¶
An example is shown below for an H.264 video track with 1280x720p resolution and 2 temporal layers at 30 fps and 60 fps frame rate.¶
codec: "avc3.42E01F" bitrate: 1500000 framerate: 60 width: 1280 height: 720¶
When ready for publishing, each encoded video chunk is considered as input
to MOQT Object payload. If encrypted, the output of encryption will serve as
the object's payload. The GroupID is incremented by 1 at Independent (IDR)
frame boundaries. Each MOQT group shall contain 2 SubGroups corresponding
to the 2 temporal layers as shown below:¶
Layer:0/30fps Subgroup: 0 ObjectID: even Layer:1/60fps Subgroup: 1 ObjectID: odd¶
Within the MOQT group, ObjectID is increment by 1 for each encoded video
frame, starting at 0 and resetting to 0 at the start of a new group. The
first encoded video frame, MOQT Object with ObjectID 0, shall be the
Indepedent (IDR) frame and the rest of the encoded video frames corresponds to
dependent (delta) frames, organized in the decode order. When mapping to
QUIC for sending, one unidirectional QUIC stream is used per SubGroup,
thus resulting in 2 QUIC streams per MOQT group.¶
When decoding at the 'End Consumer' for a given MOQT group, the objects must be fed in the GroupID then ObjectID order. This implies that the consumer media application needs to order objects across the SubGroup QUIC streams.¶
An example is shown below for an H.264 video track with 2 spatial qualities at 360p and 720p each at 30 fps¶
Video Track 1 codec: "avc3.42E01E" bitrate: 500000 framerate: 30 width: 640 height: 360 Video Track 2 codec: "svc1.56401F" bitrate: 1000000 framerate: 30 width: 1280 height: 720¶
When ready for publishing, the mapping to the MOQT object model and to underlying QUIC, follows the same procedures as described in Section 4.2 for each video track.¶
When decoding at the 'End Consumer' for a given MOQT group, the objects must be fed in the GroupID then ObjectID order in the ascending quality track order.¶
For the example in the section, this would imply following pattern when decoding group 5.¶
Track 1 Group 5 Object 0 Track 2 Group 5 Object 0 Track 1 Group 5 Object 1 Track 2 Group 5 Object 1 ....¶
An example is shown below for an H.264 video track with 2 spatial qualities at 360p and 720p, however, the framerate between tracks vary dyadically.¶
Video Track 1 codec: "avc3.42E01E" bitrate: 500000 framerate: 30 width: 640 height: 360 Video Track 2 codec: "svc1.56E01F" bitrate: 1000000 framerate: 60 width: 1280 height: 720¶
When ready for publishing, the mapping to the MOQT object model and to underlying QUIC, follows the same procedures as described in Section 4.2 for each video track.¶
When decoding at the 'End Consumer' for a given MOQT group, the objects from across the tracks must be fed in the timestamp order to the decoder, if no frame reordering is present in the encoding.¶
If the encoding uses frame reordering, or if timestamp cannot be obtained, the object to choose next shall follow the below formula.¶
Object Decode Order = ObjectID * multiplier + offset multiplier = 2^(maxlayer-max(0,layer-1)) offset = 2^(maxlayer-layer) MOD multiplier¶
An example is shown below for an H.264 video track with 2 simulcast spatial qualities at 360p and 720p each at 30 fps.¶
Video Track 1 codec: "avc3.42E01E" bitrate: 500000 framerate: 30 width: 640 height: 360 Video Track 2 codec: "avc3.42E01F" bitrate: 1000000 framerate: 30 width: 1280 height: 720¶
When ready for publishing, the mapping to the MOQT object model and to underlying QUIC, follows the same procedures as described in Section 4.2 for each video track.¶
When decoding at the 'End Consumer', the objects from the QUIC stream are fed in the GroupID then ObjectID order to the decoders setup for the corresponding video tracks.¶
The metadata in LOC Properties is visible to relays, since the MOQ Object Properties are often not encrypted end-to-end (from original publisher to end subscribers) in common schemes. In some cases, this may be an intentional design intent for proper relay operation. In other cases, this may be unintentional or undesirable leaking of the metadata to relays. Each metadata that is defined should consider the security and privacy aspects of granting relays visibility to the metadata.¶
The metadata defined and registered in this specification (Timestamp, Timescale, Config, Video Frame Marking, and Audio Level) may be sensitive metadata that should be encrypted end-to-end. Applications requiring confidentiality of this metadata SHOULD use the Private properties mechanism described in Section 3.1.3 to encrypt sensitive metadata alongside the payload.¶
When using [SecureObjects] for end-to-end encryption:¶
Properties marked as immutable via the IMMUTABLE_PROPERTIES mechanism in [MoQTransport] provide integrity protection - relays cannot modify these values without detection. However, immutable properties are NOT encrypted and remain visible to relays. Applications must carefully consider which properties require:¶
Different deployment scenarios have different trust models for relays:¶
Untrusted relays: Use Private properties for all sensitive metadata¶
Semi-trusted relays (media switches): May have access to metadata keys but not payload keys, enabling switching decisions without content access¶
Trusted relays: May have full key access for transcoding or processing¶
Applications should select the appropriate protection mechanisms based on their relay trust model and privacy requirements.¶
When using end-to-end encryption, relays cannot modify encrypted payloads but could selectively delete or withhold objects. [MoQTransport] defines PRIOR_GROUP_ID_GAP and PRIOR_OBJECT_ID_GAP properties that publishers can include to indicate intentional gaps in sequences. Subscribers can use these to distinguish between publisher-intended gaps and potential relay deletion. [SecureObjects] provides additional mechanisms for detecting such attacks.¶
This document registers the following entries in the "MOQ property Headers" registry established by [MoQTransport]:¶
| Type | Name | Scope | Specification |
|---|---|---|---|
| 0x06 | TIMESTAMP | Object | Section 2.3.1.1 |
| 0x08 | TIMESCALE | Track or Object | Section 2.3.1.2 |
This document creates a new entry in the "MoQ Streaming Format" Registry (see [MoQTransport] Sect 8). The type value is 0x002, the name is "LOC Streaming Format" and the RFC is XXX.¶
Thanks to Cullen Jennings for suggestions and review.¶