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

MoQT Media Test Tracks

Abstract

This document specifies the moq-test-tracks protocol, a testing protocol for Media over QUIC (MOQ) media implementations. Like moq-test, moq-test-tracks utilizes the Track Namespace as parameters to the publisher. The parameters describe a set of media tracks (catalog, packaging, codecs and delivery), so that a publisher can generate media of a 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 3 May 2027.

▲

Table of Contents

1. Introduction

moq-test [MoQTest] provides a testing framework for the MOQ transport, 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.

By leveraging the Track Namespace, moq-test-tracks lets testers specify the content, catalog format, packaging, codecs, resolution, frame rate, group duration, audio delivery and number of video tracks. Any publisher that implements the protocol can produce them, without out-of-band coordination. Each set of parameters has one shortest Track Namespace, which publishers use, so subscribers requesting the same media share one set of tracks, and results from different publishers can be compared.

2. Track Namespace Parameters

The moq-test-tracks protocol utilizes 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.

Track Namespaces that differ only in tuple fields omitted from one and spelled out with the same values in the other 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 potentially define a different set of parameters.

2.1. Tuple Field 0: "moq_test_tracks_00"

This field indicates that the Track Namespace parameters are for the moq-test-tracks protocol.

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. Each value names a class of content by what it lets a subscriber measure, not specific media. 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. Once per second, 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).

  • clip := Content chosen by the publisher, such as a film or a recorded broadcast, encoded to the parameters of the namespace. This document does not specify any clip. Each deployment chooses the clips it serves and may add to them. The last field of the Track Namespace prefix identifies the clip. When a clip's license requires attribution, the picture SHOULD show it.

2.3. Tuple Field 2: 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, the subscriber learns the media configuration from the Track Namespace and from the media itself (Section 3).

2.4. Tuple Field 3: Packaging

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

Catalog none requires loc.

2.5. Tuple Field 4: 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, fields 5, 6, 10 and 13 are _.

2.6. Tuple Field 5: 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.7. Tuple Field 6: 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.8. Tuple Field 7: 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, fields 8 and 11 are _.

2.9. Tuple Field 8: Audio Channels

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

  • 1 := Mono

  • 2 := Stereo

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 track-property and object-property types are in the MSF editor's copy [MSF-EDITORS]. 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 is catalog, as CMSF requires for CMAF headers [CMSF]. When tuple field 2 is none, the value is _, and the initialization data is carried in the media itself (Section 3).

When omitted, the value is catalog, or _ when tuple field 2 is none.

2.11. Tuple Field 10: Group Duration

This field specifies the interval between video key frames in milliseconds, from 100 to 10000. Each video group begins with a key frame. The interval MUST be a whole number of frames, for example 2000 at 30 frames per second or 2002 at 29_97.

When omitted, the value is 2000, or 2002 when tuple field 6 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]

dgram requires loc or cmaf packaging.

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 5 and 6

When omitted, the value is 1.

In a ladder, the first rendition has the height of tuple field 5. Each following rendition has the largest height defined for tuple field 5 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 5. For example, alt4 at a height of 1080 yields 1080, 720, 540 and 360. Every rendition has the frame rate of tuple field 6 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 clip content, the clip identifies a set of synchronized views, and the publisher returns DOES_NOT_EXIST when the clip has fewer than N views.

Values other than 1 require catalog 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-EDITORS], except audio sent in datagrams (tuple field 11).

When tuple field 2 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, so the capture time of each object follows from its Group ID and Object ID. 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 is the first Group ID published, and the Base Timestamp is the capture time of its first object.

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

Latency is the time at which an object is received minus its capture time. It includes encoding only when the publisher encodes live, so latency results state how the publisher encoded the media. Measuring it 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, a REQUEST_ERROR with DOES_NOT_EXIST is returned. The reason phrase SHOULD identify the tuple field. If producing the tracks would exceed the publisher's limits, a REQUEST_ERROR with EXCESSIVE_LOAD is returned.

A publisher delivers a set of tracks in one of two ways. It sends PUBLISH_NAMESPACE for the Track Namespace and then PUBLISH for each track, so that relays receive the tracks before any subscriber asks for them. Or it sends PUBLISH_NAMESPACE for the Track Namespace only, and relays forward each SUBSCRIBE for a track in the namespace to it.

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 stops sending objects for that track immediately.

A publisher MAY serve moq-test-tracks on demand. To do so, it sends PUBLISH_NAMESPACE for a prefix whose last tuple field is "moq_test_tracks_00". Relays route any SUBSCRIBE whose Track Namespace matches this prefix to the publisher (Section 2.4.2 of [MoQT]).

A publisher that serves clips on demand sends one PUBLISH_NAMESPACE for each clip, with the clip's prefix. A subscriber can discover the clips a deployment offers by sending SUBSCRIBE_NAMESPACE for the deployment's prefix [MoQT].

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. A deployment that runs publishers of fixed sets of tracks alongside an on-demand publisher SHOULD give them distinct prefixes. Otherwise a relay can route a request that the on-demand publisher would serve to a fixed publisher that cannot.

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 ends 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 does not use GOAWAY to end tracks; GOAWAY asks peers to move to a new session.

When audio is sent in datagrams, certain combinations of codec and channels result in objects that cannot be transmitted below the maximum datagram size. If the publisher detects this when handling the request, it responds with REQUEST_ERROR. If it detects this when publishing an object, it sends PUBLISH_DONE with an error code. 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

The subscriber can generate an asymmetric amount of work on the server, and encoding media makes it larger than for moq-test. Servers 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. Servers 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>.
[MSF-EDITORS]
"MOQT Streaming Format, editor's copy", , <https://moq-wg.github.io/msf/draft-ietf-moq-msf.html>.
[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 "openmoq/mtt", followed in the clip example by a clip identifier.

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

openmoq/mtt/moq_test_tracks_00/
  clock/msf/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:

openmoq/mtt/moq_test_tracks_00/
  clock/msf/loc/h264/720/30/aac/2/catalog/2000/1/0/1

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

openmoq-mtt-moq_test_tracks_00-clock-msf-loc-h264-720-30-aac-2--video

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

openmoq/mtt/moq_test_tracks_00/
  clock/msf/loc/av1/1080/60/opus/2/track/2000/dgram

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

openmoq/mtt/moq_test_tracks_00/
  clock/msf/loc/h264cb/360/30/aac/2/object

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

openmoq/mtt/moq_test_tracks_00/
  clock/msf/cmaf/h264/720/29_97/none/_/catalog/2002/_/600

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

openmoq/mtt/moq_test_tracks_00/
  clock/none/loc/none/_/_/opus/1/_/_/10

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

openmoq/mtt/clip_a/moq_test_tracks_00/
  clip/msf/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:

openmoq/mtt/moq_test_tracks_00/
  clock/msf/loc/h264/1080/30/aac/2/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:

openmoq/mtt/moq_test_tracks_00/
  clock/msf/loc/h264/720/30/aac/2/catalog/2000/1/0/view4

Acknowledgments

This document builds on moq-test [MoQTest] by Alan Frindell. 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