Internet-Draft moq-test-tracks November 2026
Marzot Expires 6 May 2027 [Page]
Workgroup:
Media Over QUIC
Internet-Draft:
draft-marzot-moq-test-tracks-00
Published:
Intended Status:
Informational
Expires:
Author:
G. Marzot
Oracle

MOQT Media Test Tracks

Abstract

This document specifies moq-test-tracks, a protocol for testing Media over QUIC (MOQ) media implementations. Like moq-test, it carries its parameters to the publisher in the Track Namespace. The parameters describe a set of media tracks, including the catalog, packaging, codecs and delivery, so that any publisher that implements the protocol can generate media of the requested shape.

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://gmarzot.github.io/draft-marzot-moq-test-tracks/draft-marzot-moq-test-tracks.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-marzot-moq-test-tracks/.

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/gmarzot/draft-marzot-moq-test-tracks.

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 6 May 2027.

▲

Table of Contents

1. Introduction

moq-test [MoQTest] provides a testing framework for MOQT [MOQT], using objects with synthetic payloads. moq-test-tracks extends the same approach to media. It lets testers request a set of tracks with encoded video and audio, a catalog, and a specific packaging. Catalog parsers, packagers, players and relays can then be tested against media of a known shape.

In the Track Namespace, testers specify the content, packaging, codecs, resolution, frame rate, catalog format, placement of initialization data, group duration, audio delivery, duration and number of video tracks. Any publisher that implements the protocol can produce the requested tracks without out-of-band coordination. Each set of parameters has one shortest Track Namespace, which publishers use to name it. Subscribers that request the same media therefore share one set of tracks, and results from different publishers can be compared.

2. Track Namespace Parameters

The moq-test-tracks protocol uses the Track Namespace to convey the parameters of a set of media tracks to the publisher. The Track Namespace tuple fields are defined as follows. Appendix A shows complete Track Namespaces.

Track Namespaces that differ only in trailing tuple fields, which one omits and the other spells out with the values they take when omitted, describe the same set of tracks. A publisher that names a set of tracks itself, for example in PUBLISH_NAMESPACE or PUBLISH, MUST omit every trailing tuple field whose value equals the value it takes when omitted.

Future versions will use a different value for tuple field 0 and may define a different set of parameters.

2.1. Tuple Field 0: "mtt_00"

This field identifies the moq-test-tracks protocol and this version of its parameters. Its value is mtt_00.

2.2. Tuple Field 1: Content

This field specifies the picture and sound. The content determines how much the media compresses, and so the size of the objects. The following values are defined:

  • clock := A moving picture with a 440 Hz tone. The picture shows the capture time of each frame and a frame counter, and SHOULD show the group and object IDs. At each whole second of capture time, a 1 kHz beep plays for 100 ms and the picture shows a marker for one frame, so that audio/video sync can be checked.

  • bars := Static color bars with a 1 kHz tone. The media compresses to near the encoder's minimum.

  • noise := Random noise in picture and sound. The encoder runs at the target bitrate (Section 3.1).

  • Any other value := A clip: content chosen by the deployment, such as a film or a recorded broadcast, encoded to the parameters of the namespace. The value is the clip's identifier. This document does not specify any clip. Each deployment chooses the clips it serves and their identifiers, and may add to them. A Track Namespace that asks for a track the clip does not have, such as a view or audio, describes tracks the publisher does not support (Section 4). When a clip's license requires attribution, the picture SHOULD show it.

clock, bars and noise name classes of content by what they let a subscriber measure, not specific media. The values black, motion, zoneplate, ramp, sweep, silence, sync, scroll, clip, none, any, all, default, test, live and random are reserved for later revisions of this document. A clip identifier MUST NOT be a defined or reserved value.

2.3. Tuple Field 2: Packaging

This field specifies the packaging of the media tracks. The following values are defined:

2.4. Tuple Field 3: Video Codec

This field specifies the video codec. The following values are defined:

  • h264 := H.264 High

  • h264cb := H.264 Constrained Baseline

  • h265 := H.265 Main

  • av1 := AV1 Main

  • none := No video track

Video is encoded without B-frames, so decode order is presentation order. The level is the lowest that fits the height, frame rate and bitrate. When the value is none, tuple fields 4, 5, 10 and 13 MUST be _.

2.5. Tuple Field 4: Video Height

This field specifies the video height in pixels. The following values are defined: 180, 360, 480, 540, 720, 1080, 1440 and 2160.

The width is the height multiplied by 16/9, rounded to the nearest even number (854 for a height of 480).

2.6. Tuple Field 5: Frame Rate

This field specifies the video frame rate in frames per second, as an integer from 1 to 120. The values 23_976, 29_97 and 59_94 specify 24000/1001, 30000/1001 and 60000/1001.

2.7. Tuple Field 6: Audio Codec

This field specifies the audio codec. The following values are defined:

  • aac := AAC-LC

  • opus := Opus with 20 ms frames

  • none := No audio track

Audio is sampled at 48000 Hz. When the value is none, tuple fields 7 and 11 MUST be _.

2.8. Tuple Field 7: Audio Channels

This field specifies the number of audio channels. The following values are defined:

  • 1 := Mono

  • 2 := Stereo

2.9. Tuple Field 8: Catalog

This field specifies the catalog format published on the "catalog" track. The following values are defined:

  • msf := MSF catalog [MSF], using the CMSF extensions [CMSF] for tracks with cmaf or locmaf packaging

  • none := No catalog track

When the value is none, tuple field 2 MUST be loc, and the subscriber learns the media configuration from the Track Namespace and from the media itself (Section 3).

When omitted, the value is msf.

2.10. Tuple Field 9: Init Data

This field specifies where the decoder initialization data of the media tracks is carried. Each value corresponds to an entry type in the catalog's Initialization Data List [MSF]. The following values are defined:

  • catalog := In the catalog (type inline)

  • track := In the VIDEO_CONFIG or AUDIO_CONFIG Track Property (type track-property)

  • object := In the VIDEO_CONFIG or AUDIO_CONFIG Object Property on the first object of each group (type object-property)

With cmaf and locmaf packaging, the value MUST be catalog, as CMSF requires for CMAF headers [CMSF]. When tuple field 8 is none, the value MUST be _, and the initialization data is carried in the media itself (Section 3).

When omitted, the value is catalog.

2.11. Tuple Field 10: Group Duration

This field specifies the interval between video key frames in milliseconds, from 100 to 10000, and so the duration of each video group (Section 3). The interval MUST be a whole number of frames, for example 2000 at 30 frames per second. At 23_976, 29_97 and 59_94, this makes it a multiple of 1001, for example 2002.

When omitted, the value is 2000, or 2002 when tuple field 5 is 23_976, 29_97 or 59_94.

2.12. Tuple Field 11: Audio Delivery

This field specifies how audio frames are grouped and delivered. The following values are defined:

  • An integer from 1 to 100 := That many audio frames in each audio group, with each group on one stream (Section 3)

  • dgram := Each audio frame is its own group and is sent in a datagram [MOQT]

With dgram, tuple field 2 MUST be loc or cmaf.

When omitted, the value is 1.

2.13. Tuple Field 12: Duration

This field specifies the duration of the tracks in seconds, from 0 to 86400. The value 0 means the tracks continue until unsubscribed.

When omitted, the value is 0.

2.14. Tuple Field 13: Video Tracks

This field specifies how many video tracks the set contains, and how they relate. The following values are defined:

  • 1 := One video track

  • altN, where N is from 2 to 7 := A ladder of N renditions of the same picture, for adaptive bitrate switching

  • viewN, where N is from 2 to 16 := N views, each a different picture with the height and frame rate of tuple fields 4 and 5

When omitted, the value is 1.

In a ladder, the first rendition has the height of tuple field 4. Each following rendition has the largest height defined for tuple field 4 that is at most three quarters of the height of the rendition before it. N MUST NOT exceed the number of renditions this yields from the height of tuple field 4. For example, alt4 at a height of 1080 yields 1080, 720, 540 and 360. The longest ladder, from a height of 2160, has seven renditions: 2160, 1440, 1080, 720, 540, 360 and 180. Every rendition has the frame rate of tuple field 5 and the bitrate of its own height (Section 3.1).

With clock, bars or noise content, the views are distinct pictures of that content. With a clip, the views are the clip's synchronized views, if it has them (Section 2.2).

With values other than 1, tuple field 8 MUST be msf.

3. Tracks

Under the Track Namespace, the publisher publishes tracks with the following Track Names:

The "video", "video_N" and "audio" Track Names are defined by this document.

The catalog describes the video and audio tracks with the parameters of the namespace. This includes the codec string [RFC6381] for the exact profile and level, and the bitrate (Section 3.1). Each track in the catalog is live (isLive true) and has a targetLatency of 250 milliseconds [MSF]. No tuple field changes the target latency.

Each video group begins with a key frame and contains the frames up to the next key frame. Each video frame is one object, and so is each audio frame. With cmaf packaging, each object is one CMAF chunk ([CMSF]). Each group is sent on one stream, as subgroup 0 [MSF], except audio sent in datagrams (tuple field 11).

When tuple field 8 is none:

3.1. Bitrates

The target bitrate of each video track follows from its height:

Table 1
Height Video kbps
180 200
360 600
480 1000
540 1500
720 2500
1080 4500
1440 9000
2160 16000

At frame rates above 30, the video bitrate is 1.5 times the value in the table.

The target bitrate of the audio track follows from its codec and channels:

Table 2
Codec Mono kbps Stereo kbps
aac 64 128
opus 32 64

3.2. Several Video Tracks

When tuple field 13 specifies more than one video track:

  • All video tracks share the frame rate and group duration. Frames captured at the same time have the same Group ID and Object ID in every video track, so a subscriber can switch between the tracks at any group boundary.

  • The catalog gives every video track a label. In a ladder, the label is the height followed by "p", for example "720p". The views are numbered from 1 in Track Name order, and the label of a view is "view" followed by a space and its number, for example "view 2".

  • With clock, bars or noise content, the picture of every video track shows its label, so that a switch between tracks is visible.

  • In a ladder, the catalog gives all video tracks the same altGroup. Each view has an altGroup of its own.

  • The set has one audio track, which has no altGroup.

3.3. Timing

The capture time of a media object is the wall-clock time at which its frame is captured, before it is encoded. The publisher captures frames on a fixed schedule anchored at the Unix epoch, so the capture time of each object follows from its Group ID and Object ID alone. A publisher that encodes ahead of time and sends recorded media uses each frame's scheduled time as its capture time.

Each media track carries the TIMESCALE and TIMESTAMP_MAPPING Track Properties [MoQTimestamp], without CLOCK_ID, so that timestamps are wall-clock time:

  • For video, the timescale is 1000 times the frame rate, or 24000, 30000 and 60000 for 23_976, 29_97 and 59_94. The Object Multiplier is 1000, or 1001 for those three frame rates.

  • For audio, the timescale is 48000. The Object Multiplier is the number of samples per frame.

  • The Group Multiplier is the number of objects per group multiplied by the Object Multiplier.

  • The Base Group and the Base Timestamp are 0. The Group ID of a group is the capture time of its first object, in ticks of the timescale since the Unix epoch, divided by the Group Multiplier.

The Track Properties therefore follow from the Track Namespace alone, so every publisher of a track sends the same values, including after a restart (Section 7 of [MoQTimestamp]). A publisher starts each track at its next group boundary.

With cmaf and locmaf packaging, the media timescale of each track in its CMAF header [CMSF] is the timescale above, so the media timestamps count the same ticks as the mapping.

Capture times are in whole ticks. An object whose capture time differs from its mapped timestamp carries OBJECT_TIMESTAMP with the correction. A publisher that keeps to the schedule sends no per-object timing.

In addition:

  • With loc packaging, the Timestamp property ([LOC]) carries the capture time in microseconds since the Unix epoch, rounded to the nearest microsecond, and the LOC Timescale property is not sent.

  • With cmaf and locmaf packaging, the first object of each group contains a ProducerReferenceTimeBox (prft) with the capture time.

These times agree with the mapped timestamp to within one tick, as microseconds and ticks do not divide evenly.

Latency is the time at which an object is received minus its capture time. It includes encoding only when the publisher encodes live, so a latency result needs to state whether the publisher encoded the media live or ahead of time. Measuring latency requires the subscriber's clock to agree with the publisher's, for example by running the subscriber on the publisher's host, or by synchronizing both to a common time source.

4. Publisher Behavior

If any namespace tuple field is not valid as defined in this document, or describes tracks that the publisher does not support, the publisher MUST respond with REQUEST_ERROR with error code DOES_NOT_EXIST. The reason phrase SHOULD identify the tuple field. If producing the tracks would exceed the publisher's limits, the publisher MUST respond with REQUEST_ERROR with error code EXCESSIVE_LOAD.

A publisher delivers a set of tracks in one of two ways:

Upon receiving a valid SUBSCRIBE or FETCH for a moq-test-tracks track, the publisher MUST publish objects according to the parameters of the namespace.

Upon receiving a SUBSCRIBE_TRACKS whose Track Namespace Prefix is a moq-test-tracks Track Namespace, the publisher MUST use PUBLISH to send each track in the namespace. If a PUBLISH is rejected, the publisher MUST stop sending objects for that track immediately. A Track Namespace Prefix that ends before tuple field 7 names no set of tracks. For such a prefix, the publisher sends PUBLISH only for the tracks of sets it is already producing under the prefix, and starts no new set.

A publisher MAY serve moq-test-tracks on demand. To do so, it sends PUBLISH_NAMESPACE for a prefix that ends with mtt_00, or with mtt_00 and a value of tuple field 1 to serve only that content, such as one clip. Relays route any SUBSCRIBE whose Track Namespace matches this prefix to the publisher (Section 2.4.2 of [MOQT]).

A subscriber discovers what a deployment serves by sending SUBSCRIBE_NAMESPACE for the deployment's prefix followed by mtt_00 [MOQT]. It receives the prefixes that on-demand publishers announce, and the Track Namespaces of the sets that publishers announce while producing them. An on-demand publisher that announces one prefix for each value of tuple field 1 it serves thereby lists its content, including its clips. The subscriber does not learn which other parameters a publisher supports. It writes out the Track Namespace it wants, and a publisher that does not support that set of tracks responds with DOES_NOT_EXIST.

A Track Namespace that omits trailing tuple fields is a tuple prefix of the Track Namespaces that spell them out. A relay that routes by Track Namespace prefix can therefore forward a request for a longer Track Namespace to the publisher of a shorter one, which returns DOES_NOT_EXIST unless it serves the requested set of tracks. Likewise, a SUBSCRIBE_NAMESPACE for a moq-test-tracks Track Namespace also matches the longer Track Namespaces that extend it. Publishers that share a relay SHOULD have distinct prefixes, for example by including a field that identifies the publisher. Otherwise a relay can route a request to a publisher that does not serve it, such as a request that an on-demand publisher would serve to a publisher of fixed sets of tracks.

Ending a set of tracks is not an error. When the duration in tuple field 12 elapses, or when the publisher ends the tracks earlier, for example at a limit of its own, the publisher MUST end each track gracefully [MOQT]:

The End of Track status takes the Location one past the last object of the last group. It is sent on that group's stream before the stream ends. When that stream has already ended, as is usual for the catalog track, the status instead takes the first Location of the next group, on a new stream. With dgram audio, the status is sent in a datagram and can be lost, so subscribers rely on PUBLISH_DONE.

The publisher MUST NOT use GOAWAY to end tracks; GOAWAY asks peers to move to a new session.

When audio is sent in datagrams, some combinations of codec and channels produce objects larger than the maximum datagram size. If the publisher detects this when handling the request, it MUST respond with REQUEST_ERROR with error code DOES_NOT_EXIST. If it detects this when publishing an object, it MUST send PUBLISH_DONE with status code INTERNAL_ERROR. The publisher MUST NOT send such objects on a stream instead.

Media encoders are not deterministic, so object payloads differ between publishers for the same Track Namespace. A subscriber that validates moq-test-tracks media checks the parameters of the namespace rather than payload bytes. These parameters are the codec configuration, frame rate, group duration, objects per group, audio delivery and the video tracks of the set.

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

6. Security Considerations

A subscriber can make a publisher do far more work than the request costs, and encoding media makes the imbalance larger than for moq-test. Publishers SHOULD set limits on values such as height, frame rate, duration, the number of video tracks and the number of concurrent sets of tracks, to prevent resource exhaustion attacks. Publishers SHOULD serve all subscriptions to one Track Namespace from a single set of tracks.

A publisher serving on demand SHOULD do so only through relays that authorize subscribers for its prefix, for example with Common Access Tokens [C4M].

7. IANA Considerations

This document has no IANA actions.

8. References

8.1. Normative References

[CMSF]
Law, W., "CMSF- a CMAF compliant implementation of MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-cmsf-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-cmsf-01>.
[LOC]
Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead Media Container", Work in Progress, Internet-Draft, draft-ietf-moq-loc-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-loc-04>.
[MOQT]
Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-22, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-22>.
[MoQTimestamp]
Frindell, A. and I. Swett, "Timestamp Properties for MOQT", Work in Progress, Internet-Draft, draft-frindell-moq-timestamp-00, , <https://datatracker.ietf.org/doc/html/draft-frindell-moq-timestamp-00>.
[MSF]
Law, W. and S. Nandakumar, "MOQT Streaming Format", Work in Progress, Internet-Draft, draft-ietf-moq-msf-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-msf-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <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, , <https://www.rfc-editor.org/rfc/rfc8174>.

8.2. Informative References

[C4M]
Law, W., Lemmons, C., Simon, G., and S. Nandakumar, "Authorization scheme for MOQT using Common Access Tokens", Work in Progress, Internet-Draft, draft-ietf-moq-c4m-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-c4m-01>.
[LOCMAF]
Einarsson, T., "Low Overhead CMAF for Media over QUIC (LOCMAF)", Work in Progress, Internet-Draft, draft-einarsson-moq-locmaf-01, , <https://datatracker.ietf.org/doc/html/draft-einarsson-moq-locmaf-01>.
[MoQTest]
Frindell, A., "MoQT Test", Work in Progress, Internet-Draft, draft-afrind-moq-test-01, , <https://datatracker.ietf.org/doc/html/draft-afrind-moq-test-01>.
[RFC6381]
Gellens, R., Singer, D., and P. Frojdh, "The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types", RFC 6381, DOI 10.17487/RFC6381, , <https://www.rfc-editor.org/rfc/rfc6381>.

Appendix A. Examples

The examples write the Track Namespace with its tuple fields separated by "/", and wrap it after tuple field 0. The prefix is "example".

720p30 H.264 with stereo AAC, LOC packaging, MSF catalog with the initialization data in it:

example/mtt_00/
  clock/loc/h264/720/30/aac/2

The same set of tracks with every optional tuple field spelled out. A publisher names it with the shorter form above:

example/mtt_00/
  clock/loc/h264/720/30/aac/2/msf/catalog/2000/1/0/1

The "video" track of the first example, in the MOQT name representation (Section 8.8 of [MOQT]):

example-mtt_00-clock-loc-h264-720-30-aac-2--video

1080p60 AV1 with Opus audio on datagrams, initialization data in Track Properties:

example/mtt_00/
  clock/loc/av1/1080/60/opus/2/msf/track/2000/dgram

360p30 H.264 Constrained Baseline, initialization data on the first object of each group:

example/mtt_00/
  clock/loc/h264cb/360/30/aac/2/msf/object

720p at 29.97 frames per second, CMAF packaging, no audio, for 10 minutes:

example/mtt_00/
  clock/cmaf/h264/720/29_97/none/_/msf/catalog/2002/_/600

Opus mono audio only, 10 frames per group, no catalog:

example/mtt_00/
  clock/loc/none/_/_/opus/1/none/_/_/10

A clip that the deployment identifies as "clip_a", as 1080p30 H.264 with CMAF packaging:

example/mtt_00/
  clip_a/cmaf/h264/1080/30/aac/2

A three-rendition ladder from 1080p30 H.264. The video tracks are "video" (1080p, 4500 kbps), "video_1" (720p, 2500 kbps) and "video_2" (540p, 1500 kbps), all in one altGroup:

example/mtt_00/
  clock/loc/h264/1080/30/aac/2/msf/catalog/2000/1/0/alt3

Four views of 720p30 H.264, as the tracks "video" ("view 1") through "video_3" ("view 4"), each in its own altGroup:

example/mtt_00/
  clock/loc/h264/720/30/aac/2/msf/catalog/2000/1/0/view4

Acknowledgments

This document builds on moq-test [MoQTest] by Alan Frindell, who also reviewed it. Thanks to the OpenMOQ team for implementations and test deployments, and to members of the Media over QUIC working group for discussion and review.

Author's Address

Giovanni Marzot
Oracle