An Evaluation of ABR Switching for Time-Shifted Clients in MoQ Abanisenioluwa Orojo , Tanvir Redoy , Samira Afzal , Andrew C. Freeman
arXiv:2606.26368v1 [eess.IV] 24 Jun 2026
Department of Computer Science Baylor University, USA
Abstract—Media over QUIC enables ultra low latency video streaming over QUIC, but its default quality-switching semantics risk introducing playback gaps during periods of network congestion. The in-progress SWITCH specification for MOQ Transport aims to streamline rate adaptation for MoQ. In this work, we characterize the performance of SWITCH-style Adaptive Bitrate (ABR) for both live and time-shifted clients in a Mininet simulated topology. We validate that standard ABR algorithms can be directly applied to time-shifted playback without modification, yielding substantially higher throughput. We demonstrate that a subscriber can experience increased overall throughput after a rebuffering scenario, and we identify focal points for further optimizations of MoQ ABR switching. Index Terms—MoQ, adaptive bitrate streaming, content filtering, live video analysis, HEVC encoding, MoQ streaming format
I. I NTRODUCTION Live-streaming events are quickly increasing network burdens, accounting for all of the top ten Internet traffic days in 2024 [1]. Although HTTP Adaptive Streaming (HAS) protocols such as Dynamic Adaptive Streaming over HTTP (DASH) [2] and HTTP Live Streaming (HLS) have become ubiquitous for over-the-top video delivery, they have suffered from high latency. Low-latency variants (e.g., LL-DASH, LLHLS) [3]–[5] have recently gained prominence for live streaming applications. However, these protocols are encumbered by the pull-based semantics of HTTP, limiting delivery speed and scalability [6]–[8]. To address these limitations, the Internet Engineering Task Force (IETF) is developing the Media Over QUIC Transport (MOQT) protocol [9] as a flexible and latency configurable framework for diverse applications. MOQT uses a publisher/subscriber model with a relay fan-out system, delivering arbitrary temporally-ordered data payloads across WebTransport or raw QUIC. Unlike LL-DASH, MOQT’s QUIC-based prioritization schemes ensure that under tight latency budgets higher throughput is achievable [10]. Hence, MOQT is positioned as a better protocol for real-time video streaming applications that demand both low-latency delivery and fine-grained control over stream prioritization. A user does not always require minimal latency, however. For example, a live broadcast client may experience rebuffering due to network congestion. Rather than jump ahead to the live edge after switching quality, the user may wish to continue playback at the same point, and maintain a delay (time shift) from the live edge. Our own recent work explored
a similar scenario with Media over QUIC (MoQ), where a user may choose to have higher playback latency in order to unlock more granular video analysis for content moderation [11], [12]. While single-stream playback is naturally supported in MOQT reference software, Adaptive Bitrate (ABR) switching semantics are an area of active discussion, research, and development within the MoQ Working Group. Although many contributors are focused on live-edge playback, we see that time-shifted playback with ABR is understudied and unaddressed in current implementations. To better understand the implications of rate adaptation in heterogeneous latency regimes, we introduce an extension to the MOQtail [13] reference software that enables near-seamless playback with ABR for both live and time-shifted clients. The system separates quality selection from timeline synchronization. The main contributions of this work are the following: • We implement time shift-aware ABR switching and multiple ABR algorithms in open-source reference MoQ software. • We produce a Mininet testing environment for reproducible network simulations. • We characterize the performance of time shift-aware ABR under various network conditions and ABR configurations, demonstrating that by adding less than four seconds of stream delay can increase the throughput by four times. Our open-source MOQtail fork and Mininet testing framework are available at https://github.com/BaylorMultimediaLab/moqtail/. II. BACKGROUND AND R ELATED W ORK A. Media over QUIC Transport HAS operates on a pull-based mechanism where clients independently request specific content chunks based on network conditions [14]. Video clients fetch segments, which couple media delivery directly to HTTP request–response cycles, incurring inherent delivery latency. WebRTC delivers real-time media streams over UDP to achieve low latency [15]. However, it is fundamentally engineered for low-latency teleconferencing applications, making it inflexible for broadcast streaming or diverse latency regimes. MOQT [9] aims to achieve the best of both worlds: it uses fast, push-based UDP delivery (via QUIC), and it expresses media as named units that relays can cache and fan out in a Content Delivery Network
(CDN). MOQT is an IETF protocol draft specification [9] that operates on push-based publish/subscribe semantics. Data units are delivered as Objects grouped into Groups within named Tracks, carried over QUIC streams or datagrams via relays [9]. MOQT is associated with two video streaming format specifications: the MOQT Streaming Format (MSF), which defines the catalog (a manifest track defining the publisher’s available media representation Tracks) and mandates that Tracks in a common render group be synchronized and switchable at Group boundaries [16]; and CMAF compliant MOQT Streaming Format (CMSF), which synchronizes Common Media Application Format (CMAF) fragment boundaries with MOQT Group boundaries and carries CMAF chunks as MOQT Objects [17]. Under these formats, a video frame maps to an Object, a Group of Pictures (GOP) maps to a Group, and a given video representation or quality level maps to a Track.
B. Switching Mechanics and Timeline Continuity MSF/CMSF [16], [17] establishes that a Group boundary is the join point at which a subscriber may enter a Track. MOQT offers three ways to act on it. The naive approach is to issue a SUBSCRIBE message for the new Track and an UNSUBSCRIBE message for the old one; However, because UNSUBSCRIBE stops future delivery but does not cancel Groups already queued or in flight, the old Track can continue delivering while the new Track begins. The two subscriptions overlap, duplicating Group IDs and producing a bandwidth spike during the switch that competes with the new Track and can stall playback. A downside of this approach is that the new subscription only receives Groups published after the subscription starts, so any media already elapsed on the target Track is not delivered. A Joining FETCH [9] lets a client recover older objects from a Track while a SUBSCRIBE keeps receiving new objects from that same Track. In other words, FETCH can fill in missing past data, and SUBSCRIBE can continue forward delivery. However, in the context of ABR, FETCH is entirely client-driven, requiring each client to mitigate potential overlap or gaps between the UNSUBSCRIBE and FETCH messages. In contrast, the pending MOQ SWITCH [18] design introduces an atomic relay-side transition from a current Track to a target Track. With SWITCH, the subscriber asks the relay to move an existing subscription from one Track to another. The request identifies the current subscription, the target Track, and the earliest Group where the switch is allowed to occur. The relay then chooses a valid transition Group at or after that point, usually at a Group boundary shared by both Tracks. If that Group is behind the live edge, the relay first sends the missing target-Track data needed to catch up. Once the target Track subscription has begun, the relay ends the prior Track subscription, so the client changes representations through a single relay-managed transition rather than two independent control messages.
C. Problem Statement A gap remains open in the literature surveyed above: ABR for the time-shifted regime in MoQ is understudied. Existing MoQ ABR work is focused on optimizing for a fixed liveedge target. In practice, however, many applications will not demand the lowest possible latency at all times. Therefore, we seek to evaluate the efficacy of relay-side ABR switching under heterogeneous latency requirements. III. S YSTEM OVERVIEW Fig. 1a illustrates our system architecture. Our modifications from a typical MoQ implementation are primarily to the relay and subscriber, to support controlled playback offsets and ABR algorithms. Publisher. The publisher ingests a source video and constructs a High Efficiency Video Coding (HEVC) bitrate ladder with a fixed GOP duration. Frames and GOPs are sent to the relay as MOQT Objects and Groups, respectively, according to the MSF protocol. Relay. The relay accepts SUBSCRIBE messages from clients and forwards data from the subscribed Tracks. For each Track, the relay maintains a bounded cache of the N most recent Groups. This cache allows the relay to serve both live clients, which receive Groups immediately, and time-shifted clients, which receive Groups from the cache. Time-shifted subscriber. The subscriber client maintains a single active video Track subscription and runs an ABR controller that issues representation-change requests in response to throughput, buffer occupancy, and per-frame latency signals. In the time-shifted configuration considered in this work, the client can begin playback from D Groups behind the publisher’s live edge. We represent the live edge by L, the latest Group currently available at the relay. For example, in Fig. 1b, the live edge is at Group L = k + 11, while the client’s playhead is at Group k + 5. The client is therefore D = 6 Groups behind the live edge. With a 1-second GOP duration, this corresponds to a 6-second playback offset. IV. TSA-SWITCH This section describes our switch implementation, known as Time Shift-Aware SWITCH (TSA-SWITCH). We note that the SWITCH mechanism for MOQT is still under active discussion in a pull request at the time of writing [19], and the current MOQtail implementation of SWITCH only supports ABR for live edge clients, so we refer to it as LiveSWITCH. As such, we extend the MOQtail implementation to add simplified support for time-shifted ABR. Whereas the current SWITCH [19] specification draft cedes some authority to the relay to determine the best Group to deliver, our implementation allows only the client to specify the intended Group to receive during a quality switch. A. Delayed subscription First, we introduce a DELAY_GROUPS subscription parameter, included in the client’s SUBSCRIBE request to specify a playback delay of D Groups behind the live edge. After
(a) System architecture: publisher, relay cache, and behind-live client.
(b) Group timeline example showing playback delay offset, and track switching at the playhead.
Fig. 1: Overview of the MOQ-based adaptive streaming design.
receiving the request, the relay computes the target Group as gtarget = L − D. This target Group determines where delivery should begin. The relay then handles the request in one of three ways. If gtarget is available within the relay cache, the relay starts forwarding media from that Group. If gtarget is older than the oldest cached Group, the relay starts from the oldest Group still available in the cache. If the stream has not yet produced enough Groups to satisfy the requested delay, the relay holds the subscription pending, activating it only when the live edge advances enough for gtarget to become available. B. Timeline-to-Group mapping Second, we introduce a TimeMap data structure that the client maintains to record Group boundaries as objects arrive. The TimeMap maintains a sparse mapping from media Presentation Timestamp (PTS) to Group ID. When the ABR controller requests a representation switch, the client captures the current playhead PTS, obtained from the video element’s currentTime. The client then queries the TimeMap for the Group containing that PTS, and attaches the result as the START_LOCATION_GROUP parameter in the SWITCH message. In TSA-SWITCH, the client sends the playhead-derived Group ID as a START_LOCATION_GROUP parameter that approximates the Minimum Switching Group ID from the draft SWITCH design [19]. The relay uses this value to create an absolute-start subscription for the target Track, and begins sending from that requested Group. In the pending SWITCH draft [19], the equivalent signal is carried as a SWITCH field, and the relay may choose a later valid G_switch if required by common-boundary or cache-availability constraints. C. Motivation We emphasize that our goal at this stage is not to propose a competing SWITCH design. Instead, we aim to provide early experimental results for the ABR performance of clients under heterogeneous latency regimes, which may inform future refinements to SWITCH and ABR specifications within the MoQ Working Group.
Configuration
Rules Enabled
None All
None All dash.js ABR rules in the player [22], [23] ThroughputRule [24] BolaRule [25], [26] ThroughputRule, BolaRule [23], [26] ThroughputRule, BolaRule, SwitchHistoryRule [23], [27] ThroughputRule, BolaRule [23] LoL+ [28], [29] L2A-LL [30]
Throughput Only BOLA Only Default Dampened Aggressive LoLp L2A
Override Settings
Tightened switch-history threshold bandwidth Safety Factor= 1.0
TABLE I: ABR configurations evaluated. “All” enables all dash.js ABR rules available in the player stack as a stress configuration.
V. E XPERIMENTAL S ETUP A. Implementation To evaluate ABR for time-shifted playback, we build upon the MOQtail [13] reference software, which, at the time of our evaluation, tracked Draft 14 of the MOQT protocol specification [20]. B. Video Sequence and Ladder To avoid transcoder bottlenecks and ensure reproducibility, we pre-encode the video segments. We take the first 60 seconds of Tears of Steel [21] encoded as a five-rung HEVC ladder, with target bitrates of {150, 200, 500, 1200, 4000} kilobits per second (kbps). The top rung is deliberately set above our tested bandwidth ceiling so that down-switching is induced under the constrained profiles. We set our GOP duration to 1 s. C. ABR Configurations As detailed in Tab. I, our evaluation uses eight ABR configurations derived from the rule set exposed by the dash.js reference player [22], plus a baseline “None” configuration with
None
150
150
150
4000
None
0.00
0.00
0.00
None
n/a
n/a
n/a
All
365
403
942
3500
All
0.03
0.05
0.04
0.35
All
1.6
0.9
1.0
Default
797
1187
1267
3000
Default
0.09
0.07
0.08
0.30
Default
2.0
1.6
1.8
Throughput only
2454
1106
852
2500
Throughput only
0.21
0.08
0.01
0.25
Throughput only
1.9
1.5
1.4
BOLA only
150
150
150
2000
BOLA only
0.00
0.00
0.00
0.20
BOLA only
n/a
n/a
n/a
4
Dampened
1491
959
943
1500
Dampened
0.13
0.18
0.08
0.15
Dampened
1.6
1.4
1.4
3
Aggressive
1890
581
1508
1000
Aggressive
0.20
0.02
0.17
0.10
Aggressive
1.3
1.1
2.8
LoLp
794
1391
695
500
LoLp
0.09
0.03
0.03
0.05
LoLp
1.2
1.3
1.5
L2A
2989
1970
1802
L2A
0.24
0.14
0.13
0.00
L2A
1.5
2.3
2.2
Stable
Step
Sinusoidal
Stable
Step
Sinusoidal
Stable
Step
Sinusoidal
(a) Received bitrate (kbps)
(b) Rebuffering ratio
6 5
2 1
(c) Time to switch (s)
Fig. 2: Average results for Live-SWITCH on the live edge. None
150
150
150
4000
None
0.00
0.00
0.00
None
n/a
n/a
n/a
All
1487
896
1024
3500
All
0.06
0.12
0.06
0.35
All
1.5
1.0
0.9
Default
2995
1365
1605
3000
Default
0.26
0.11
0.09
0.30
Default
1.6
2.0
2.2
6 5
Throughput only
1792
1714
639
2500
Throughput only
0.12
0.15
0.07
0.25
Throughput only
2.2
1.7
1.6
BOLA only
150
150
150
2000
BOLA only
0.00
0.00
0.00
0.20
BOLA only
n/a
n/a
n/a
4
Dampened
3374
1991
1247
1500
Dampened
0.22
0.05
0.10
0.15
Dampened
1.5
2.3
2.9
3
Aggressive
814
1909
1087
1000
Aggressive
0.05
0.18
0.06
0.10
Aggressive
2.1
2.2
1.9
LoLp
1239
1212
686
500
LoLp
0.05
0.09
0.08
0.05
LoLp
1.9
2.3
2.1
0.00
L2A
L2A
2861
2625
848
Stable
Step
Sinusoidal
L2A
(a) Bitrate requested (kbps)
0.39
0.14
0.08
Stable
Step
Sinusoidal
(b) Rebuffering ratio
1.9
2.4
2.8
Stable
Step
Sinusoidal
2 1
(c) Time to switch (s)
Fig. 3: Average results for TSA-SWITCH beginning at the live edge. None
150
150
150
4000
None
0.00
0.00
0.00
None
n/a
n/a
n/a
All
3965
3471
2643
3500
All
0.02
0.10
0.03
0.35
All
3.0
2.3
5.2
Default
2996
4000
3767
3000
Default
0.06
0.00
0.03
0.30
Default
2.4
1.8
2.2
Throughput only
2029
1194
3003
2500
Throughput only
0.04
0.24
0.01
0.25
Throughput only
2.4
2.6
5.2
6 5
BOLA only
1753
1462
2103
2000
BOLA only
0.00
0.00
0.00
0.20
BOLA only
4.0
2.4
3.0
4
Dampened
2996
3894
3515
1500
Dampened
0.00
0.08
0.05
0.15
Dampened
2.7
1.9
5.1
3
Aggressive
2864
3914
3840
1000
Aggressive
0.01
0.11
0.03
0.10
Aggressive
2.5
1.9
2.2
LoLp
3835
3315
3768
500
LoLp
0.07
0.11
0.03
0.05
LoLp
2.6
2.6
2.0
L2A
3943
3901
3463
L2A
0.00
0.07
0.00
0.00
L2A
2.7
6.8
2.3
Stable
Step
Sinusoidal
Stable
Step
Sinusoidal
Stable
Step
Sinusoidal
(a) Bitrate requested (kbps)
(b) Rebuffering ratio
2 1
(c) Time to switch (s)
Fig. 4: Average results for TSA-SWITCH with a delayed starting offset of 10 s.
ABR disabled. We use the term driver for a rule that directly selects the candidate representation, such as the throughputbased rule, BOLA, L2A, or LoL+. We use the term support rule for a rule that modifies or constrains that decision, such as switch-history, insufficient-buffer, dropped-frame, or requestabandonment logic. The Override Settings column reports only parameters changed relative to the corresponding baseline configuration. The All configuration is a configuration in which all dash.js ABR rules available in our player stack are enabled, whereas default corresponds to the dash.js dynamic pairing of throughput-based and BOLA-based decision logic. Where applicable, we preserved the default dash.js playback buffer target of 18 s. D. Testbed All experiments were run under Mininet [31] network simulation. The relay is placed between two emulated switches,
and the client runs in a separate network namespace using headless Chromium 148.0.7778.179. Both links are TCLinkshaped with a 10 ms one-way delay; bandwidth on the relayto-client link (s2 ) is varied at runtime by the experiment harness. Link 1 (publisher-to-relay) is held at 10 Mbps and is not the bottleneck for the experiment. To emulate a live source with our pre-encoded bitrate ladder, the publisher paces the sending of these segments to the relay. E. Bandwidth Profiles Three bandwidth profiles were used in the evaluation. Stable: a flat 1.5 Mbps holding for 60 s. This is sufficient for the four lowest-quality representations. • Step: begin at 3 Mbps, step down to 500 kbps at t = 30 s, and recover to 3 Mbps at t = 50 s. This is designed to force a fast down-switch followed by an up-switch. •
None 4000 All Default 3000 Throughput only BOLA 2000 only Dampened Aggressive 1000 LoLP L2A 0
None 4000 All Default 3000 Throughput only BOLA only 2000 Dampened Aggressive 1000 LoLP L2A 0
3000 2000 1000 0 0.0
2.5
5.0
7.5
10.0 12.5 15.0 17.5 20.0
0.0
Time (s)
2.5
5.0
7.5
10.0 12.5 15.0 17.5 20.0
Time (s)
(a) Live-SWITCH on the Live Edge
None All Default Throughput only BOLA only Dampened Aggressive LoLP L2A
Bitrate (kbps)
Bitrate (kbps)
Bitrate (kbps)
4000
0.0
2.5
5.0
7.5
10.0 12.5 15.0 17.5 20.0
Time (s)
(b) TSA-SWITCH beginning on the Live Edge
(c) TSA-SWITCH with an offset of 10 s
Fig. 5: Time series plots of representative experimental runs on the Sinusoidal bandwidth profile.
•
Sinusoidal: a sine wave on [0.6, 3.0] Mbps with a 60 s period. This is used to probe ABR behavior under continuously varying capacity without sharp transitions.
F. Subscribers Our baseline subscriber configuration targets the live edge, performing the Live-SWITCH as implemented in the MOQtail reference software [13]. We compare to a subscriber with TSA-SWITCH beginning at the live edge, and to a subscriber with TSA-SWITCH beginning with a delay offset of 10 s. G. Metrics For each experimental run, we measure the following: • Average received video bitrate (kbps). • Ratio of playback time spent rebuffering. This is measured in the client player in 500 ms intervals. • Average time to switch (s). This measures the time elapsed between the client sending a SWITCH message and receiving the first data from the new Track subscription. VI. R ESULTS A. Live-SWITCH on the Live Edge We first examine the scenario of live stream client that wishes to remain as close to the live edge as possible. We configure this by using the Live-SWITCH mechanism as implemented in the MOQtail [13] reference software. Fig. 2a shows the average bitrates for our live edge client using the existing MOQtail Live-SWITCH implementation across our experimental test suite. We see quite low throughput overall, and inconsistent ABR configuration performance. From Fig. 2b, we see that this Live-SWITCH can have substantial rebuffering up to 24% of the playback duration for L2A, due to the small playback buffer. In this configuration, rebuffering causes jumps in the playback to remain at the live edge. The LoLp and All configurations provide the best all-around performance, yielding high throughput, little rebuffering, and low switch latencies (Fig. 2). B. TSA-SWITCH Beginning on the Live Edge We next examine the scenario of a live stream client that is tolerant to increases in latency, through the use of the TSA-SWITCH mechanism. In this case, the client begins by
targeting the live edge. If rebuffering occurs, the client does not experience substantial gaps in the received video content, and will instead pause and enter a time-shifted state, where the delay is equivalent to the cumulative duration of rebuffers. We see in Fig. 3a that this yields much higher throughput overall, but the amount of time spent rebuffering (Fig. 3b) generally increases. Although the Dampened throughput is more than double that of the Live-SWITCH, the rebuffering time is also nearly double. The average rebuffer period for the All configuration is less than 4 seconds for the Stable profile, but we see a 4-times improvement in throughput over the LiveSWITCH. C. TSA-SWITCH Beginning with 10-Second Time Shift Finally, we explore TSA-SWITCH with a 10-second time shift at the outset. As the playhead moves further from the live edge, the client benefits more from the relay’s cache and bursty network conditions, yielding consistently higher throughput as in Fig. 4a. However, this comes with even greater switch latency (Fig. 4c) and in some cases higher rebuffering rates. We see dramatic decreases in rebuffering rates for the Stable and Sinusoidal profiles, but the Step rebuffering remains high, as its dramatic bandwidth change is harder for the ABR controller to predict. Fig. 5 illustrates the change in received bitrate over time, showing that the flexibility of a higher latency tolerance allows for quicker rate stabilization and fewer quality switches. D. Discussion Our experimental observations are in line with expectations for ABR switching across different latency regimes. We see that the reduced rebuffering at higher delay offsets corresponds to the greater headroom afforded by the relay’s cache availability. Unsurprisingly, the All configuration maintains strong performance across our bandwidth profiles as the offset increases. We find that the overall switch latency is higher than expected, especially for the live-oriented clients. Under TSA-SWITCH, if switch executes later than the next GOP begins, the client receives redundant (past) data which the player discards. Ideally, the time to switch will be less than or equal to the GOP duration, to support faster reactions to changes in network conditions. Since the control streams used for the SWITCH messages are already assigned the highest
QUIC stream priority, this latency is likely due to the relayside overhead of initiating the new Track subscription. This is a target for further software optimization. VII. C ONCLUSION We evaluated early ABR semantics within MoQ, exploring heterogeneous latency regimes with a single SWITCH implementation (TSA-SWITCH). We demonstrated that a timeshifted client seamlessly provided more adaptation headroom, enabling higher and more consistent delivered quality across the tested network profiles, frequently approaching the maximum bitrate target of 4000 kbps. We identify opportunities to optimize the relay-side SWITCH execution time, and we anticipate the development of advanced hybrid ABR systems, where the relay coordinates with the client to improve ABR decision-making (e.g., suggesting algorithm parameter adjustments based on its own connection to the upstream publisher). Towards this end, we provide an open-source Mininet integration to streamline further evaluation of MoQ ABR with repeatable experiments. With this foundation, an extended evaluation can compare SWITCH-based ABR to Joining FETCH and relay-side switching. Ongoing research will inform the development of the SWITCH design and its implementation in reference software, helping to enable the adoption of MOQT for live streams, video on demand, and everything in between. R EFERENCES [1] AppLogic Networks, “The Global Internet Phenomena Report 2025,” technical report, AppLogic Networks, Feb. 2025. Accessed: 2026-0504. [2] “Information technology – dynamic adaptive streaming over http (dash) – part 1: Media presentation description and segment formats,” 2022. [3] DASH-IF and DVB, “Low-latency Modes for DASH.” [Online] Available: https://dashif.org/news/low-latency-dash/, 2020. Accessed: 202605-27. [4] Apple, “Protocol Extension for Low-Latency HLS.” [Online] Available: https://developer.apple.com/documentation/http-live-streaming/ enabling-low-latency-http-live-streaming-hls, 2019. Accessed: 2026-05-27. [5] A. Bentaleb, Z. Zhan, F. Tashtarian, M. Lim, S. Harous, C. Timmerer, H. Hellwagner, and R. Zimmermann, “Low latency live streaming implementation in dash and hls,” in Proceedings of the 30th ACM International Conference on Multimedia, MM ’22, (New York, NY, USA), p. 7343–7346, Association for Computing Machinery, 2022. [6] M. Nguyen, H. Amirpour, C. Timmerer, and H. Hellwagner, “Scalable high efficiency video coding based http adaptive streaming over quic,” in Proceedings of the Workshop on the Evolution, Performance, and Interoperability of QUIC, EPIQ ’20, (New York, NY, USA), p. 28–34, Association for Computing Machinery, 2020. [7] M. Nguyen, C. Timmerer, S. Pham, D. Silhavy, and A. C. Begen, “Take the red pill for h3 and see how deep the rabbit hole goes,” in Proceedings of the 1st Mile-High Video Conference, MHV ’22, (New York, NY, USA), p. 7–12, Association for Computing Machinery, 2022. [8] M. Nguyen, P. Nys, S. Pham, D. Silhavy, S. Arbanowski, and S. Steglich, “Streaming face-off: A testbed analysis of media-over-quic and lowlatency dash,” in Proceedings of the 16th ACM Multimedia Systems Conference, MMSys ’25, (New York, NY, USA), p. 317–321, Association for Computing Machinery, 2025. [9] S. Nandakumar, V. Vasiliev, I. Swett, and M. Thomson, “Media over QUIC Transport.” IETF Internet-Draft draft-ietf-moq-transport, 2026. Work in Progress, rev. 17. [10] Z. Gurel, T. Erkilic Civelek, D. Ugur, Y. K. Erinc, and A. C. Begen, “Media-over-QUIC Transport vs. Low-Latency DASH: A Deathmatch Testbed,” in Proc. 15th ACM Multimedia Systems Conf. (MMSys), pp. 412–418, 2024.
[11] A. C. Freeman, “Toward accessible and safe live streaming using distributed content filtering with moq,” in 2025 IEEE International Conference on Multimedia and Expo Workshops (ICMEW), pp. 1–6, 2025. [12] A. Freeman, J. Bellert, A. Orojo, and G. Speegle, “Client-side video analysis for content moderation with moq,” in Proceedings of the 5th Mile-High Video Conference, MHV ’26, (New York, NY, USA), p. 93–99, Association for Computing Machinery, 2026. [13] Z. Gurel, D. Ugur, and A. C. Begen, “Moqtail: Open-source, ietfcompliant moqt protocol libraries,” in Proceedings of the ACM Multimedia Systems Conference 2026, MMSys ’26, (New York, NY, USA), p. 477–483, Association for Computing Machinery, 2026. [14] C. Timmerer, H. Amirpour, F. Tashtarian, S. Afzal, A. Rizk, M. Zink, and H. Hellwagner, “Http adaptive streaming: A review on current advances and future challenges,” ACM Trans. Multimedia Comput. Commun. Appl., vol. 21, July 2025. [15] G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo, “Analysis and design of the google congestion control for web real-time communication (webrtc),” in Proceedings of the 7th International Conference on Multimedia Systems, MMSys ’16, (New York, NY, USA), Association for Computing Machinery, 2016. [16] W. Law, “MOQT Streaming Format.” IETF Internet-Draft draft-ietfmoq-msf, 2025. Work in Progress. [17] W. Law, “CMSF—a CMAF Compliant Implementation of MOQT Streaming Format.” IETF Internet-Draft draft-ietf-moq-cmsf, 2025. Work in Progress. [18] Z. Gürel and A. C. Begen, “Track Switching in Media over QUIC Transport,” Internet-Draft draft-gurel-moq-track-switching-01, Internet Engineering Task Force, Feb. 2025. Work in Progress. [19] G. Simon, “SWITCH for Client-side ABR by gwendalsimon · Pull Request #1378 · moq-wg/moq-transport,” 2026. [20] S. Nandakumar, V. Vasiliev, I. Swett, and A. Frindell, “Media over QUIC Transport,” Internet-Draft draft-ietf-moq-transport-14, Internet Engineering Task Force, Sept. 2025. Work in Progress. [21] Blender Foundation, “Tears of steel.” Mango Open Movie Project, 2012. Directed by Ian Hubert; released under Creative Commons Attribution 3.0. [22] DASH Industry Forum, “dash.js: Reference MPEG-DASH player.” https://github.com/Dash-Industry-Forum/dash.js/releases/tag/v5.0.3, 2025. Commit: abc1234, accessed 2026-05-10. [23] DASH Industry Forum, “dash.js ABR Settings Documentation.” https:// dashif.org/dash.js/pages/usage/abr/settings.html. Accessed: 2026-05-27. [24] DASH Industry Forum, “dash.js ThroughputRule Documentation.” https: //dashif.org/dash.js/pages/usage/abr/throughput-rule.html. Accessed: 2026-05-27. [25] K. Spiteri, R. Urgaonkar, and R. K. Sitaraman, “BOLA: Near-Optimal Bitrate Adaptation for Online Videos,” IEEE/ACM Transactions on Networking, vol. 28, no. 4, pp. 1698–1711, 2020. [26] K. Spiteri, R. Sitaraman, and D. Sparacio, “From Theory to Practice: Improving Bitrate Adaptation in the DASH Reference Player,” ACM Transactions on Multimedia Computing, Communications, and Applications, vol. 15, no. 2s, 2019. [27] DASH Industry Forum, “dash.js SwitchHistoryRule Documentation.” https://dashif.org/dash.js/pages/usage/abr/switch-history-rule.html. Accessed: 2026-05-27. [28] M.-F. Lim, M. N. Akcay, A. Bentaleb, A. C. Begen, and R. Zimmermann, “When They Go High, We Go Low: Low-Latency Live Streaming in dash.js with LoL,” in Proceedings of the 11th ACM Multimedia Systems Conference, MMSys ’20, pp. 321–326, Association for Computing Machinery, 2020. [29] A. Bentaleb, M. N. Akcay, M. Lim, A. C. Begen, and R. Zimmermann, “Catching the Moment With LoL+ in Twitch-Like Low-Latency Live Streaming Platforms,” IEEE Transactions on Multimedia, vol. 24, pp. 2300–2314, 2022. [30] T. Karagkioules, R. Mekuria, D. Griffioen, and A. Wagenaar, “Online Learning for Low-Latency Adaptive Streaming,” in Proceedings of the 11th ACM Multimedia Systems Conference, MMSys ’20, pp. 315–320, Association for Computing Machinery, 2020. [31] B. Lantz, B. Heller, and N. McKeown, “A network in a laptop: rapid prototyping for software-defined networks,” in Proceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks, Hotnets-IX, (New York, NY, USA), Association for Computing Machinery, 2010.