]> Oracle

gmarzot@marzresearch.net

Web and Internet Transport Media Over QUIC moq moqt test media 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Media Over QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction moq-test provides a testing framework for 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.

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. shows complete Track Namespaces.

• A Track Namespace can begin with a prefix: zero or more fields chosen by the deployment, which this document does not interpret. The tuple fields defined here follow the prefix and are numbered from 0.
• Tuple fields 0 through 7 are required. Tuple fields 8 through 13 are optional: the Track Namespace can end after any tuple field from 7 onward, and each omitted tuple field takes the value given in its section.
• MOQT does not permit empty Track Namespace fields , so every tuple field that is present carries an explicit value.
• A field that does not apply to the set of tracks MUST be _. For example, the audio fields are _ when there is no audio. A field that does not apply takes the value _ when omitted.
• Tuple field values use only the characters a-z, 0-9 and _, which the MOQT name representation renders verbatim (). Numeric fields are decimal integers without leading zeros.

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.

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

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 ().
• 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 (). 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.

Tuple Field 2: Packaging This field specifies the packaging of the media tracks. The following values are defined:

• loc := LOC
• cmaf := CMAF, as specified by
• locmaf := LOCMAF

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

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

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.

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

Tuple Field 7: Audio Channels This field specifies the number of audio channels. The following values are defined:

• 1 := Mono
• 2 := Stereo

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

• msf := MSF catalog , using the CMSF extensions 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 (). When omitted, the value is msf.

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 . 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 . When tuple field 8 is none, the value MUST be _, and the initialization data is carried in the media itself (). When omitted, the value is catalog.

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 (). 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.

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 ()
• dgram := Each audio frame is its own group and is sent in a datagram

With dgram, tuple field 2 MUST be loc or cmaf. When omitted, the value is 1.

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.

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 (). 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 (). With values other than 1, tuple field 8 MUST be msf.

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

• "catalog", unless tuple field 8 is none. This is the Track Name MSF reserves for the catalog .
• "video", unless tuple field 3 is none. With more than one video track (), the others are "video_1", "video_2" and so on, in ladder or view order.
• "audio", unless tuple field 6 is none.

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 for the exact profile and level, and the bitrate (). Each track in the catalog is live (isLive true) and has a targetLatency of 250 milliseconds . 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 (). Each group is sent on one stream, as subgroup 0 , except audio sent in datagrams (tuple field 11). When tuple field 8 is none:

• Video carries its decoder configuration in the payload (): the parameter sets with H.264 and H.265, the sequence header with AV1.
• With aac, the first object of each audio group carries the Audio Config property ().
• With opus, no decoder configuration is sent. The subscriber configures its decoder for 48000 Hz and the channel count of tuple field 7.

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

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:

Codec	Mono kbps	Stereo kbps
aac	64	128
opus	32	64

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.

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

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:

• 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.
• 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 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 ().

• The prefix is the only Track Namespace the publisher announces for the sets of tracks it can produce. The parameters allow far too many sets to enumerate, and no set exists until a request names its Track Namespace.
• The publisher begins producing a set of tracks upon the first request for its Track Namespace. While it produces the set, it MAY send PUBLISH_NAMESPACE for the set's Track Namespace. If it does, it sends PUBLISH_NAMESPACE_DONE when it stops producing the set.
• It serves later requests for the same Track Namespace from the same media. It MAY also serve a Track Namespace that describes the same set of tracks from the same media.
• It MAY stop producing the tracks when no subscriptions remain.

A subscriber discovers what a deployment serves by sending SUBSCRIBE_NAMESPACE for the deployment's prefix followed by mtt_00 . 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 :

• It marks the end of the track with the End of Track object status.
• It sends PUBLISH_DONE with status code TRACK_ENDED for each subscription to the track.
• If it sent PUBLISH_NAMESPACE for the Track Namespace of the set, it then sends PUBLISH_NAMESPACE_DONE.

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.

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 when, and only when, they appear in all capitals, as shown here.

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 .

IANA Considerations This document has no IANA actions.

References Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. Akamai Cisco This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport. Akamai This document updates MOQT Streaming Format by defining optional syntax and semantics for carrying CMAF-packaged media. Cisco Cisco Microsoft 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. Meta Google This document defines a set of MOQT Properties for carrying per- Object timestamps efficiently. The encoded timestamp is intended for use in MOQT, but can be referenced for application specific purposes. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Meta This document specifies the moq-test protocol, a testing protocol for Media over QUIC (MOQ) implementations. moq-test utilizes the Track Namespace as parameters to the publisher, enabling flexible and customizable testing scenarios. Eyevinn Technology This document specifies LOCMAF (Low Overhead CMAF for Media over QUIC), a compact packaging for low-latency CMAF media carried end-to- end as MoQ Transport (MOQT) Object payloads, with per-object overhead comparable to the Low Overhead Container (LOC). LOCMAF carries the CMAF chunk head metadata from a single moof (movie fragment) as a small set of tagged fields, while leaving the sample data (mdat) untouched. Boxes that may surround the moof in a CMAF chunk — styp (segment type), prft (producer reference time), and any number of emsg (event message) boxes — are carried verbatim, each through a generic box element (a genBox). The first Object of each MOQT group carries a full reference; subsequent Objects in the same group carry only the differences. The receiver reconstructs CMAF chunks that are decode-equivalent to the sender input, including the encryption metadata required by CMAF DRM (Common Encryption) pipelines, and a canonical byte-identical reconstruction — independent of the encoder's representation choices — is defined for conformance testing. Akamai Comcast Synamedia Cisco A token-based authorization scheme for use with Media Over QUIC Transport. Several MIME type/subtype combinations exist that can contain different media formats. A receiving agent thus needs to examine the details of such media content to determine if the specific elements can be rendered given an available set of codecs. Especially when the end system has limited resources, or the connection to the end system has limited bandwidth, it is helpful to know from the Content- Type alone if the content can be rendered. This document specifies two parameters, 'codecs' and 'profiles', that are used with various MIME types or type/subtype combinations to allow for unambiguous specification of the codecs employed by the media formats contained within, or the profile(s) of the overall container format. This document obsoletes RFC 4281; RFC 4281 defines the 'codecs' parameter, which this document retains in a backwards compatible manner with minor clarifications; the 'profiles' parameter is added by this document. By labeling content with the specific codecs indicated to render the contained media, receiving systems can determine if the codecs are supported by the end system, and if not, can take appropriate action (such as rejecting the content, sending notification of the situation, transcoding the content to a supported type, fetching and installing the required codecs, further inspection to determine if it will be sufficient to support a subset of the indicated codecs, etc.). Similarly, the profiles can provide an overall indication, to the receiver, of the specifications with which the content complies. This is an indication of the compatibility of the container format and its contents to some specification. The receiver may be able to work out the extent to which it can handle and render the content by examining to see which of the declared profiles it supports, and what they mean. [STANDARDS-TRACK]

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: The same set of tracks with every optional tuple field spelled out. A publisher names it with the shorter form above: The "video" track of the first example, in the MOQT name representation (): 1080p60 AV1 with Opus audio on datagrams, initialization data in Track Properties: 360p30 H.264 Constrained Baseline, initialization data on the first object of each group: 720p at 29.97 frames per second, CMAF packaging, no audio, for 10 minutes: Opus mono audio only, 10 frames per group, no catalog: A clip that the deployment identifies as "clip_a", as 1080p30 H.264 with CMAF packaging: 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: Four views of 720p30 H.264, as the tracks "video" ("view 1") through "video_3" ("view 4"), each in its own altGroup:

Acknowledgments This document builds on moq-test 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.