]> Ozyegin University

deniz.ugur@ozu.edu.tr

Ozyegin University

zafer.gurel@ozu.edu.tr

Networked Media

ali.begen@networked.media

Applications and Real-Time Media Over QUIC media over quic fast track switching adaptive bitrate This document describes subscriber-side multi-variant fast track switching (MVFTS), a technique that allows a MOQ Transport (MOQT) subscriber to switch between tracks that are encoded at the same bitrate but use different group of pictures (GoP) lengths, combining the compression efficiency of a long GoP with the low switching delay of a short GoP. A publisher using this technique packages each encoded bitrate as a ladder of tracks distinguished only by their keyframe interval, numbers those tracks' Group IDs so that they share a common alignment, and advertises the keyframe interval of each track in a MOQT Streaming Format (MSF) catalog. A subscriber uses this information to compute the nearest valid switch point on any track in scope and to perform the switch using the SWITCH_FROM request parameter in soft mode. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Adaptive bitrate (ABR) delivery of live and on-demand media involves a tension between two goals. Long GoPs improve compression efficiency, since inter-coded pictures are cheaper to send than keyframes. Short GoPs reduce the delay of joining a track or switching to a different one, since a subscriber can only begin decoding a track at a keyframe. A publisher, therefore, has to pick a single GoP length that compromises between these two goals for every track it offers, unless more than one GoP length is made available at once. This document describes a technique, subscriber-side multi-variant fast track switching (MVFTS), in which a publisher offers several tracks per encoded bitrate and resolution, each using a different GoP length, and a subscriber picks whichever of these tracks gets it to its desired bitrate the soonest. Because every track at the same bitrate carries identical content, encoded at the same resolution, a subscriber can switch between them purely to shorten its wait for a keyframe, and can equally switch between tracks of different bitrates by considering the keyframe opportunities of both the current and the target bitrate's tracks together. This technique depends on two other specifications. It reuses the Catalog and Track Object model, including the "keyframeSpacing" and "altGroup" Track Object fields, defined by the MOQT Streaming Format . It performs the actual switch using the SWITCH_FROM request parameter and its soft mode, proposed for in and , respectively. Neither pull request had been merged into at the time of writing; this document is written as though both are already part of it, and implementers should consult the referenced pull requests for their current status before relying on this document. An earlier, narrower proposal for MSF, , described how a subscriber can use the "keyframeSpacing" field to compute a single valid switch point when first joining a track. This document is intended to supersede that proposal as the primary specification of keyframe-interval- based switching for MOQT: it keeps the "keyframeSpacing" field but adds the Group ID alignment convention, the multi-track and multi-bitrate selection procedure, and the SWITCH_FROM-based switching procedure needed to use it continuously, not only when first joining a live broadcast.

Document Structure defines the terms used in this document. gives a high-level view of the technique. specifies how a publisher packages a set of switchable tracks. specifies the Catalog fields a publisher uses to advertise them. specifies how a subscriber computes candidate switch points and selects among them. specifies how a subscriber executes a switch using SWITCH_FROM. describes the buffering a subscriber needs during a switch. and conclude the document with security and IANA considerations.

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. The following terms are used with the first letter capitalized:

Quality:

A single encoded representation of media content, identified by properties such as resolution, bitrate, and codec profile, excluding its keyframe interval.

GoP:

Group of Pictures. The set of coded pictures between one keyframe (inclusive) and the next (exclusive). Within this document, each MOQT Group () carries exactly one GoP (see ).

Switch Set:

The set of Tracks that share one "altGroup" value () and among which a subscriber performs MVFTS. A Switch Set can contain Tracks of more than one bitrate/resolution.

GoP Ladder:

The subset of a Switch Set's Tracks that share one bitrate but differ in their "keyframeSpacing" () value. A Switch Set contains one GoP Ladder per bitrate it offers.

Alignment Unit (Gm):

The smallest "keyframeSpacing" value among all Tracks in a Switch Set.

Frame Number:

A non-negative integer, comparable across every Track in a Switch Set, computed from a Location () as described in .

Current Track:

The Track a subscriber is receiving at the time it evaluates a switch.

Target Track:

A Track a subscriber is considering switching to.

Switch Point:

A Group ID on a Target Track at which a subscriber can begin receiving that track without missing or duplicating any presented media.

Overview A publisher using MVFTS offers one or more bitrates, each as a GoP Ladder of two or more Tracks that are otherwise identical but use different keyframe intervals, all combined into a single Switch Set. For example, a publisher might offer a 720p bitrate and a 1080p bitrate, each with short-, medium-, and long-GoP Tracks, for a Switch Set of six Tracks in total:

Example Switch Set with two bitrates

The publisher numbers the Group IDs of every Track in the Switch Set according to a single, shared Alignment Unit, so that any Group ID on any Track corresponds to a specific, predictable position in every other Track (), and advertises each Track's "keyframeSpacing" and "altGroup" in the Catalog (). A subscriber that is receiving one Track from the Switch Set continuously re-evaluates whether a different Track in the same GoP Ladder, or a different GoP Ladder entirely, has a closer upcoming Switch Point (). When it finds one, it issues a SUBSCRIBE or REQUEST_UPDATE carrying SWITCH_FROM in soft mode, targeting that Switch Point (), and buffers objects from both Tracks until the handoff completes ().

Publisher Requirements A publisher that offers a Switch Set for use with MVFTS MUST meet the following requirements for every Track in that Switch Set, in addition to any other applicable requirements of :

• Each MOQT Group MUST begin with exactly one keyframe, and MUST NOT contain any other keyframe. This ensures that every Group boundary is a usable join or switch point, and that no join or switch point is hidden inside a Group.
• Every Track in the Switch Set MUST be time-aligned with every other Track at Object boundaries: the media presentation time of the first Object of a Group on one Track MUST coincide with the media presentation time of the same Object on every other Track in the Switch Set.
• Every Track's "keyframeSpacing" value MUST be an integer multiple of the Switch Set's Alignment Unit (Gm), i.e., the smallest "keyframeSpacing" value among all Tracks in the Switch Set. This is what makes the Frame Number defined in comparable across every Track in the Switch Set, including Tracks of different bitrates.
• For a Track whose "keyframeSpacing" is S, let k = S / Gm. The publisher MUST number that Track's Groups 1, 1 + k, 1 + 2k, 1 + 3k, and so on (instead of 1, 2, 3, ...), and MUST include a Prior Group ID Gap Object Property () with value k - 1 on the first Object of every Group after the first. This signals that the k - 1 intervening Group ID values are intentionally never used, rather than missing.

For example, a Track with keyframeSpacing 8 in a Switch Set whose Alignment Unit is 2 has k = 4, and is numbered Group 1, Group 5, Group 9, and so on; the first Object of Group 5 carries a Prior Group ID Gap of 3, indicating that Groups 2, 3, and 4 will never be published on this Track.

Catalog A publisher advertises the properties needed for MVFTS using two Track Object fields already defined by :

altGroup:

Tracks that are part of the same Switch Set MUST share one "altGroup" value, and MUST NOT share that value with any Track outside the Switch Set.

keyframeSpacing:

Every Track in a Switch Set MUST include "keyframeSpacing", populated with the number of Objects in each of that Track's Groups (equivalently, its keyframe interval expressed in Objects). A subscriber uses this field, and the constraints in , to identify each Track's GoP Ladder (the other Tracks in the Switch Set that share the same bitrate) and to compute Frame Numbers and Switch Points as described in .

This document does not define any further Catalog fields; a subscriber distinguishes Tracks of the same bitrate from Tracks of different bitrates within a Switch Set using the same bitrate-identifying Track Object fields it would otherwise use to select among non-MVFTS Tracks (for example, "width", "height", and "bitrate").

Client-Side Track and Group Selection

Frame Numbers Within one Switch Set, let Gm be the Alignment Unit. For a Track with keyframeSpacing S, let k = S / Gm as in . The Frame Number of Object O (0-based, per ) of Group G on that Track is: Because every Track's Group IDs have been numbered as described in , frameNumber increases by exactly one for each successive Object across Group boundaries on a single Track, and, by construction, identifies the same position in the underlying media timeline on every Track in the Switch Set.

Switch Points Given a candidate Target Track with keyframeSpacing T (also a multiple of Gm, per ), and the subscriber's current Frame Number F (computed from the Current Track's most recently received Location), the nearest Switch Point on the Target Track that is not earlier than F is Group ID: This is the Group ID of the first Group on the Target Track whose first Object's Frame Number is greater than or equal to F. The number of Frame Numbers between F and that Switch Point, is zero if F already falls exactly on a Group boundary of the Target Track, and otherwise gives subscribers a way to compare how soon different candidate Target Tracks reach a Switch Point.

Selection Policy A subscriber evaluates candidate Target Tracks and picks one as follows:

• If the subscriber is not changing bitrate, the candidates are the other Tracks in the Current Track's GoP Ladder with a strictly larger "keyframeSpacing" than the Current Track. The subscriber picks the candidate with the smallest Distance, i.e., the one that lets it move to a more efficient Track as soon as possible. A subscriber that finds no Switch Point closer than remaining on the Current Track SHOULD NOT switch.
• If the subscriber is changing to a different bitrate, the candidates are every Track in the Target bitrate's GoP Ladder, together with the other Tracks in the Current Track's GoP Ladder with a strictly larger "keyframeSpacing" than the Current Track. The subscriber picks the candidate with the smallest Distance. If more than one candidate ties for the smallest Distance, the subscriber prefers a candidate in the Target Quality's GoP Ladder, since it makes direct progress toward the desired bitrate. A switch to a Track in the Current Track's own GoP Ladder in this case is an intermediate step and does not end the bitrate change; the subscriber repeats this procedure after each switch until it reaches the Target bitrate.

A subscriber MAY instead implement a simpler policy that only ever considers one GoP Ladder at a time (the Current Track's GoP Ladder, or, when changing bitrate, only the Target Quality's GoP Ladder) and that breaks ties by preferring the candidate with the largest "keyframeSpacing" rather than by preferring progress toward the Target bitrate. This simpler policy is easier to implement and is already in use in at least one implementation of this document, at the cost of occasionally taking a less direct path to the Target bitrate.

Worked Example Consider the Switch Set from , with Gm = 2. A subscriber is receiving 720p-long (keyframeSpacing 8, k = 4) and has just received Object 3 of Group 13 (the fourth Group of this Track, since Group 1 is the first and Groups are numbered 1, 5, 9, 13, ...). Its Frame Number is: Suppose the application now requests a switch to the 1080p bitrate. The subscriber computes targetGroup(T) and Distance(T) for every Track in the 1080p GoP Ladder:

Track	T	targetGroup(T)	Distance(T)
1080p-short	2	15	1
1080p-medium	4	15	1
1080p-long	8	17	5

1080p-short and 1080p-medium tie for the smallest Distance; both are in the Target bitrate's GoP Ladder, so the subscriber picks one of them, for example 1080p-medium, and switches to Group 15 of that Track.

Performing the Switch A subscriber performs a switch found as described in by sending a SUBSCRIBE, or a REQUEST_UPDATE on an existing subscription, carrying the SWITCH_FROM parameter () in soft mode (), with the Switch From Request ID identifying the Current Track's subscription and the Start Group set to the computed targetGroup(T). A subscriber MUST NOT use hard mode for this purpose. Because the Current and Target Tracks use different keyframe intervals, a relay has no way to know, from hard mode alone, where the two Tracks' Objects correspond to the same point in the media timeline, and could stop forwarding the Current Track before the Target Track has anything to show in its place. Soft mode avoids this by having the publisher continue the Current Track's subscription up to a computed End Group before stopping it, giving a clean handoff instead of a gap or an overlap of arbitrary duration. Per , soft mode stops the suspending subscription at "Start Group - 1". Because Group IDs are not comparable 1:1 across Tracks with different "keyframeSpacing" values, a subscriber instead computes the End Group it expects the publisher to use directly from the Current Track's own numbering. Let S and k_old = S / Gm be the Current Track's own keyframeSpacing and group increment, and let switchFrame be the Frame Number of the chosen Switch Point, (targetGroup(T) - 1) * Gm + 1:

• If the Target Track's keyframeSpacing T is greater than S, the Switch Point can fall after the Group the Current Track is presently sending, so the expected End Group is the Current Track's own Group whose last Frame Number is the greatest multiple of S not exceeding switchFrame - 1: For example, in a Switch Set with Gm = 2, a Current Track with S = 4 (k_old = 2) sending Frame Number 9 (its Group 5), switching to a Target Track with T = 6 and switchFrame = 13, has End Group 1 + 2 * (floor(12 / 4) - 1) = 1 + 2 * 2 = 5: the Current Track's Group 5 is also its last Group before the switch.
• Otherwise (T is less than or equal to S), the Current Track has no Group boundary of its own between the Group it is presently sending and the Switch Point, so the expected End Group is simply the Current Track's own Group ID at the time of the switch; the subscriber cannot cut over any earlier than the end of the Group it is already receiving. Continuing the worked example in , switching from 720p-long (S = 8) to 1080p-medium (T = 4) has T less than S, so the expected End Group is Group 13, the Group the subscriber was already receiving.

A subscriber does not need to separately unsubscribe from the Current Track's subscription: once the publisher has delivered the End Group, it concludes the suspending subscription with PUBLISH_DONE. A subscriber SHOULD subscribe in advance to Tracks it may switch to, using the FORWARD parameter () set to 0, before it expects to need them. This gives the publisher, or a relay on the path, the opportunity to establish or warm any upstream state for those Tracks ahead of time, so that the switch computed in is not delayed by the time it takes to establish a new subscription. A subscriber SHOULD bound the number of Tracks it keeps subscribed in this way at once; see .

Client Buffering and Playout Continuity Because soft mode keeps delivering the Current Track up to its End Group while the Target Track begins delivering from its Switch Point, a subscriber receives Objects from both Tracks for a short overlap. A subscriber MUST hold received Objects from both Tracks in a small buffer, keyed by Frame Number, and release them for presentation in Frame Number order, so that the presented media neither skips nor repeats any frame across the transition. A buffer sized to hold slightly more than one Alignment Unit's worth of Objects from each of the two Tracks involved in a switch is sufficient for this purpose; a subscriber does not need to retain more than this once a switch has completed.

Security Considerations A subscriber that follows the recommendation in to pre-establish subscriptions to candidate Target Tracks ahead of time increases the number of subscriptions, and therefore the amount of upstream state and bandwidth, a publisher or relay must maintain on its behalf. A subscriber MUST bound the number of Tracks it keeps subscribed with FORWARD set to 0 for this purpose, and a publisher or relay MAY apply the limits described in to protect itself from excessive resource consumption by a subscriber that does not. The set of Tracks and their "keyframeSpacing" values in a Switch Set reveal the shape of a publisher's ABR ladder to anyone who can observe the Catalog, in the same way that the set of bitrates and resolutions already does; this document does not introduce any new information disclosure beyond what and already describe.

IANA Considerations This document has no IANA actions. It reuses the "keyframeSpacing" and "altGroup" Track Object fields defined by and the Prior Group ID Gap Object Property, the FORWARD parameter, and the SWITCH_FROM parameter defined or proposed for , without modifying or extending any of them.

Acknowledgments The authors thank the participants of the Media Over QUIC Working Group, and in particular the authors of and commenters on , , and , whose discussion of track switching and keyframe-interval-based switch points informed this document.

Use of Generative AI Generative AI tools were used to assist with drafting and editing text for this document. All AI-generated content was reviewed and approved by the editors.

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

Change Log RFC Editor's Note: Please remove this section prior to publication of a final version of this document.

Since initial version

• Initial version.