IETF MoQ Player
IETF MoQ Player
This project was carried out during the MonteVIDEO SummerCamp 2025. Mike English proposed creating a Player for MoQ with the goal of lowering the entry barrier to this technology.
During the project, work was done on the player found in the repository englishm/moq-js, which is a fork of the project initiated by Luke Curley (kixelated), which no longer follows the IETF draft.
During the SummerCamp, efforts were focused on developing a player ready for real-time streaming use cases, with a primary focus on live sports events.
This player serves a dual purpose: on one hand, it aims to be an easy-to-use player that can be seamlessly integrated into web applications, and on the other, it acts as a tool for experimentation and to support the development of the MoQ standard.
Currently, the development team is working on implementing ABR (Adaptive Bitrate Streaming) and buffer control.
A QUIC intro to MoQ
QUIC
One of the main drawbacks of TCP is the head-of-line (HoL) blocking issue. Since TCP ensures reliable and ordered delivery, when a single packet is lost, all subsequent packets must wait for its retransmission before being processed. This is particularly problematic for modern applications that require low latency, such as video streaming and web browsing.
QUIC addresses this issue by operating over UDP and implementing multiplexed streams within a single connection. Unlike TCP, where all data is sent in a strict sequence, QUIC allows independent streams that can be processed separately. This means that if a packet is lost in one stream, the others continue to be delivered without waiting, significantly reducing delays.
MoQ
Media over QUIC (MoQ) is a new transport protocol currently being standardized by the IETF to enable low-latency, scalable, and efficient delivery of media content over QUIC. MoQ leverages QUIC's advantages, such as multiplexed streams and reduced head-of-line blocking, to improve media streaming, conferencing, and real-time communication.
MoQ is structured into three key components:
MoQT (MoQ Transport): The core transport layer that efficiently manages the delivery of media over QUIC, ensuring low latency and robustness.
Catalog: A metadata layer that describes the available streams, making it easier for clients to discover and request media segments dynamically.
Containers (LOC or CMAF): Media data is packaged using either LOC (Low Overhead Container), a lightweight format optimized for QUIC, or CMAF (Common Media Application Format), a widely used standard for audio and video streaming.
One question you may have is, why LOC if we already have CMAF? When sending real-time streaming, the audio samples that need to be transmitted are very small in terms of data. In this scenario, CMAF is an inefficient container because the size of the headers is comparable to the amount of data in the sample. This issue has led to the need for new, lighter containers such as LOC or WCP (Web Codec Package).
A key advantage of MoQ is MoQT (MoQ Transport), which serves as a single transport layer for both publishing and subscribing to media. This simplifies implementation and reduces latency by ensuring that media segments are efficiently delivered and reused across multiple consumers without requiring separate protocols for ingestion and distribution.
In MoQ, relays play a crucial role in optimizing media delivery by caching media segments. Instead of forwarding all media streams directly from the publisher to each subscriber, relays can store recently transmitted segments and serve them to new subscribers without requiring retransmission from the source.
MoQ is designed to support various media streaming and real-time communication scenarios. It enables different use cases based on how media is published and consumed, including one-to-many, many-to-many, and video-on-demand (VOD/DVR) delivery after FETCH was defined in MoQT draft-07.
MoQ Player Summer Project
Give back to the video community
Promote collaborative culture
Create VALUE while LEARNING and SHARING KNOWLEDGE
Summer Projects are tree-month learning experiences where you work on a technical project with the guidance of a sponsor. No prior experience is needed—just curiosity and willingness to learn! Each project aims to create something valuable for the community while helping you develop new skills.
During the MoQ Player Summer Project, we worked on improving a MoQ-based media player following the IETF MoQ standard. The project was technically sponsored by Mike English, and we contributed to his fork, englishm/moq-js.
Challenge 1: Player controls
At the start of the project, we identified a low-hanging fruit: implementing player controls in the existing moq-js code. During this phase, we successfully added support for play, pause, mute, unmute, volume control, fullscreen, and Picture-in-Picture (PiP).
A key distinction in MoQ is that play, pause, mute, and unmute are not just UI states—they require the player to unsubscribe and resubscribe to tracks to stop and resume data transmission efficiently. We implemented this mechanism successfully, ensuring that media delivery is properly managed while optimizing bandwidth usage.
Challenge 2: Decuple the Player and publish in NPM
The player couldn’t function independently, as it was originally just converted from TypeScript to JavaScript without proper modularization. This limitation made it difficult to use in different environments, restricting flexibility and reusability.
To solve this, we built the project using Rollup and published it on NPM, creating separate builds for both browser and ES module environments. However, we encountered an issue where Web Workers and Audio Worklets were tightly coupled to the web build process. To address this, we refined the bundling strategy, ensuring these components were handled more efficiently, resulting in a cleaner and more modular implementation
From now on, it is possible to install or use the player directly from NPM or jsdelivr.
npm install @moq-js/player
Challenge 3: Trigger events
To effectively manage and optimize media playback, we need clear insights into the player’s status and actions. In players like hls.js or dash.js, this is achieved through event subscriptions, allowing developers to react dynamically to changes. However, without a proper event system, tracking playback state and transport activity becomes difficult.
To address this, we implemented a event system, covering both playback events (e.g., play, pause, volume change, error) and MoQT events (e.g., subscribe started, subscribe done, unsubscribe started). This enables better monitoring, logging.
Challenge 4: <video-moq> Web Component
To make the player easier to use and integrate, we aimed to reduce the complexity of implementation. A Web Component is a self-contained, reusable UI element that works natively in modern browsers without requiring external frameworks. It allows developers to use custom elements as if they were standard HTML tags, making it easier to embed complex functionality with minimal setup.
To achieve this, we developed a Web Component called <video-moq> included in the bundle, designed to be fully compatible with the same APIs as the native <video> tag in HTML5. This ensures a familiar experience for developers while leveraging MoQ-based streaming. The component is already available on NPM, making it simple to install and integrate into any web project.
To support Media Chrome and player.style themes, the <video-moq> component needs to closely replicate the behavior of the native <video> tag. This ensures seamless integration with Media Chrome’s UI components, which rely on standard video element interactions.
Same API as the <video> tag – Methods like .play(), .pause(), .seek(), and properties like .currentTime, .volume, .muted, and .paused must work as expected.
Same attributes as the <video> tag – Attributes like controls, autoplay, loop, muted, poster, and preload should be supported.
Trigger the same events as the <video> tag – Events like play, pause, timeupdate, ended, error, and seeking need to be dispatched, allowing Media Chrome components to react accordingly.
Building the Foundation for a MoQ Player
Through these challenges, we have laid the groundwork for a MoQ-based player, making it easier to experiment with and adopt this new streaming technology. By leveraging bundled builds and a Web Component, we have significantly reduced the complexity of testing and integrating MoQ, allowing developers to try it out with minimal effort.
"We believe this player can serve as a valuable tool for advancing the MoQ standard, supporting research efforts, and providing early adopters with a practical way to explore and refine the technology. This is just the beginning, and we look forward to seeing how the community builds upon it."
moqjs.org
During the summer camp, we created a new home for this project! On moqjs.org, you can find all the examples created with MoQ to test moq-js.
Summer Project Demo
Check out the final demo of the MoQ Player MonteVIDEO Summer Project 2025 and learn about the challenges we faced, the lessons we learned, and the decisions we made to build this open source player.
ABR in MoQ Masterclass
During one of the summer camp sessions, we were fortunate to have Zafer Gürel and Ali Begen, who gave us a masterclass on how, at Streaming University, they prototyped a MoQ player with ABR. Thanks to their contributions, it will soon be available in this player: https://github.com/englishm/moq-js/issues/23
Watch the masterclass starting at minute 20:21.
MoQ Player Summer Camp 2025 Contributors
Mike English
Henry McIntyre
Joaquin Bartaburu
Nicolas Levy
Casey Occhialini
Sebastian Piquerez
Joao Victor
Luke Curley
Facundo Mendizabal
Nicolas Bertillod
Christopher Triantafilis
Manuel Barrabino
Emil Santurio
Ali Begen
Artur Parkhisenko
Zafer Gurel
Juan Manuel López