| Internet-Draft | moq-fast-switching | October 2026 |
| Ugur, et al. | Expires 16 April 2027 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://moqtail.github.io/draft-ugur-moq-fast-switching/draft-ugur-moq-fast-switching.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ugur-moq-fast-switching/.¶
Source for this draft and an issue tracker can be found at https://github.com/moqtail/draft-ugur-moq-fast-switching.¶
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 16 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [MSF]. It performs the actual switch using the SWITCH_FROM request parameter and its soft mode, proposed for [MoQTransport] in [SWITCH-FROM-PR] and [SWITCH-FROM-SOFT-PR], respectively. Neither pull request had been merged into [MoQTransport] 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, [MSF-ZAPPING-PR], 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.¶
Section 2 defines the terms used in this document. Section 3 gives a high-level view of the technique. Section 4 specifies how a publisher packages a set of switchable tracks. Section 5 specifies the Catalog fields a publisher uses to advertise them. Section 6 specifies how a subscriber computes candidate switch points and selects among them. Section 7 specifies how a subscriber executes a switch using SWITCH_FROM. Section 8 describes the buffering a subscriber needs during a switch. Section 9 and Section 10 conclude the document with security and IANA considerations.¶
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.¶
The following terms are used with the first letter capitalized:¶
A single encoded representation of media content, identified by properties such as resolution, bitrate, and codec profile, excluding its keyframe interval.¶
Group of Pictures. The set of coded pictures between one keyframe (inclusive) and the next (exclusive). Within this document, each MOQT Group ([MoQTransport]) carries exactly one GoP (see Section 4).¶
The set of Tracks that share one "altGroup" value ([MSF]) and among which a subscriber performs MVFTS. A Switch Set can contain Tracks of more than one bitrate/resolution.¶
The subset of a Switch Set's Tracks that share one bitrate but differ in their "keyframeSpacing" ([MSF]) value. A Switch Set contains one GoP Ladder per bitrate it offers.¶
The smallest "keyframeSpacing" value among all Tracks in a Switch Set.¶
A non-negative integer, comparable across every Track in a Switch Set, computed from a Location ([MoQTransport]) as described in Section 6.¶
The Track a subscriber is receiving at the time it evaluates a switch.¶
A Track a subscriber is considering switching to.¶
A Group ID on a Target Track at which a subscriber can begin receiving that track without missing or duplicating any presented media.¶
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:¶
Switch Set (altGroup = 1)
+-- 720p GoP Ladder
| +-- 720p-short (keyframeSpacing = 2)
| +-- 720p-medium (keyframeSpacing = 4)
| +-- 720p-long (keyframeSpacing = 8)
+-- 1080p GoP Ladder
+-- 1080p-short (keyframeSpacing = 2)
+-- 1080p-medium (keyframeSpacing = 4)
+-- 1080p-long (keyframeSpacing = 8)
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 (Section 4), and advertises each Track's "keyframeSpacing" and "altGroup" in the Catalog (Section 5).¶
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 (Section 6). When it finds one, it issues a SUBSCRIBE or REQUEST_UPDATE carrying SWITCH_FROM in soft mode, targeting that Switch Point (Section 7), and buffers objects from both Tracks until the handoff completes (Section 8).¶
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 [MSF]:¶
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 Section 6 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 ([MoQTransport]) 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.¶
A publisher advertises the properties needed for MVFTS using two Track Object fields already defined by [MSF]:¶
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.¶
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 Section 4, 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 Section 6.¶
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").¶
Within one Switch Set, let Gm be the Alignment Unit. For a Track with keyframeSpacing S, let k = S / Gm as in Section 4. The Frame Number of Object O (0-based, per [MoQTransport]) of Group G on that Track is:¶
frameNumber = (G - 1) * Gm + O + 1¶
Because every Track's Group IDs have been numbered as described in Section 4, 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.¶
Given a candidate Target Track with keyframeSpacing T (also a multiple of Gm, per Section 4), 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:¶
targetGroup(T) = 1 + (T / Gm) * ceil((F - 1) / T)¶
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,¶
Distance(T) = (targetGroup(T) - 1) * Gm + 1 - F¶
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.¶
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.¶
Consider the Switch Set from Section 3, 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:¶
frameNumber = (13 - 1) * 2 + 3 + 1 = 28¶
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.¶
A subscriber performs a switch found as described in Section 6 by sending a SUBSCRIBE, or a REQUEST_UPDATE on an existing subscription, carrying the SWITCH_FROM parameter ([SWITCH-FROM-PR]) in soft mode ([SWITCH-FROM-SOFT-PR]), 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 [SWITCH-FROM-SOFT-PR], 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:¶
End Group = 1 + k_old * (floor((switchFrame - 1) / S) - 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 Section 6, 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 ([MoQTransport]) 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 Section 6 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 Section 9.¶
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.¶
A subscriber that follows the recommendation in Section 7 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 [MoQTransport] 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 [MSF] and [MoQTransport] already describe.¶
This document has no IANA actions. It reuses the "keyframeSpacing" and "altGroup" Track Object fields defined by [MSF] and the Prior Group ID Gap Object Property, the FORWARD parameter, and the SWITCH_FROM parameter defined or proposed for [MoQTransport], without modifying or extending any of them.¶
The authors thank the participants of the Media Over QUIC Working Group, and in particular the authors of and commenters on [SWITCH-FROM-PR], [SWITCH-FROM-SOFT-PR], and [MSF-ZAPPING-PR], whose discussion of track switching and keyframe-interval-based switch points informed this document.¶
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.¶
This section is to be removed before publishing as an RFC.¶
RFC Editor's Note: Please remove this section prior to publication of a final version of this document.¶
Initial version.¶