You pick the projects
we’ll build together

The problem, and who feels it

Live streaming over MoQ has to work on networks that are messy: Wi-Fi, cellular, satellite, long intercontinental paths. On a short, clean path, retransmission is enough. On a long or lossy one, waiting for retransmissions causes stalls, so operators either over-protect every viewer or accept rebuffering. Forward error correction helps, but traditionally the sender applies it to everyone, so every viewer pays the bandwidth tax. With MoQ, the publisher can send repair data as extra tracks, and each player subscribes only to the protection its own path needs. Relays stay unchanged. Viewers on bad networks feel this problem most, and so do the operators and streamers who pay for their rebuffering.

Where agents come in

Deciding how much protection to take is an operations problem. A player sees its own losses but can’t tell whether they come from congestion, where extra repair data makes things worse, or from interference near the player, where it helps. An agent watching CMCD and player telemetry across many players can tell the two apart and steer protection and bitrate choices for groups of players. Agents also help build the project itself: much of the existing prototype was written with AI coding tools.

Why it matters to the community

MoQ players today ship with very simple ABR, and MoQ needs better bitrate estimation whether or not FEC is involved. Protection by subscription is new territory. The results would carry over to multicast delivery and non-video, low-latency uses. Results should come from realistic loss, including bursts and congestion with cross traffic, not only random loss.

What a team would need, and what ends up on GitHub

A working prototype exists: a publisher, an unmodified relay, and FEC-enabled versions of Shaka and Red5’s Playa, running in stock Chrome and Firefox. Pick your path:

1. Player: bandwidth estimation and an ABR for MoQ that chooses bitrate and protection together. A better ABR alone is a contribution.
2. Packager: content-aware protection, for example protecting I-frames more than P or B frames. Source content is video files for now.
3. Measurement: realistic loss and congestion scenarios, comparing FEC against plain MoQ with retransmissions. On GitHub: the player, packager and estimator code, a loss-scenario test harness, and published results. Skills: TypeScript or JavaScript players, packaging, networking. FEC expertise isn’t required.

The problem, and who feels it

Live and global streaming operations teams collect player telemetry, CDN metrics, and content availability rules, but this data usually lives in silos. Diagnosing QoE degradation (rebuffering, startup time, bitrate switches), unexpected CDN cost increases, or incorrect blackouts requires manual investigation and ad-hoc queries. This affects live ops and data teams that need to react quickly during events or daily operations.

Where agents come in

An agent can sit on top of clean dbt models and let operators or analysts ask questions in natural language instead of writing SQL. Examples: “Why did rebuffering spike in Brazil last night?” or “Show CDN cost per stream by region this week and highlight anomalies.” The agent turns raw telemetry and operational data into faster diagnosis and suggested actions.

Why it matters to the community

It provides an open-source foundation for modern streaming observability and a data copilot. Many teams lack the bandwidth or budget to build this internally or buy commercial solutions. A reusable dbt + agent stack would make QoE monitoring, cost analysis, and operational diagnostics more accessible.

What a team would need, and what ends up on GitHub

• dbt models (with DuckDB examples) that transform player telemetry, CDN metrics, and blackout/availability rules into clear QoE, cost, and status tables by region.
• A simple Python script that loads sample data and runs dbt.
• A lightweight agent (FastAPI) that queries the models and answers operational questions.
• A Docker Compose file so anyone can run the full stack locally with one command.
• Optional GitHub Actions workflow to refresh the sample data automatically.
• Documentation and sample data.
• Useful skills: data modeling, dbt, SQL, and building a simple agent over a warehouse. Deep video pipeline expertise is not required.

The problem, and who feels it

Many web-based MSF/CMSF players exist, but they all focus on the mechanics of playback and neglect the UI which is usually minimal and basic. MOQ lacks a web video player with a great UI, one that can accommodate skinning, customizable components and a framework for composing only the elements that are needed. Video.js v10 is a framework for media players that supports a skinnable and customizable UI. Playa is a fully functioning Typescript library for MOQT streaming including MSF and CMSF. The goal of this challenge is to combine Video.js and Playa to produce an open-source MOQT player which has an excellent UI and supports skinning, customizable components (including new MSF ones such as Show-Catalog, renderGroup selection etc), composable elements and integration with agentic services providing real-time translation and captions. The resulting player will be open-sourced under Apache 2 and hosted and maintained on the OpenMOQ github.

Where agents come in

The player SHOULD interface with agents providing real-time translation and captions.

Why it matters to the community

MOQ is still associated with hastily built players. To upgrade MOQ media to a professional status, we need a reliable, robust and beautiful player with full support for modern features including AI integration and skinning.

What a team would need, and what ends up on GitHub

The dev team will need good Typescript/Javascript coding skills, as well as a working knowledge of MSF/CMSF and a familiarity with library integrations. The output of the project will be a new player repo on the OpenMOQ github, free for everyone to use, that pulls in code from the video.js and playa projects. The repo should provide easy-to-use binaries and documentation/examples so that functional players can be stood up in less than a minute.

The problem, and who feels it

CMCD defines a means by which a media player can communicate structured data and have it processed consistently by delivery networks and third-party data collection services. CMCD v1 and V2 has become the cornerstone of client-side QOE data generation and transmission for HAS players. In the MOQT/MSF world, we are lacking a standard means of transmitting such QoE data. The draft https://github.com/wilaw/CMCD-over-MSF-event-timeline specifies how an MSF catalog can instruct a publisher to publish configurable CMCD data at a target destination using MSF Event Timeline tracks as well as how to transmit CMCD data over the MSF event-timeline track format. The goal of this challenge is to demonstrate a CMCD-4-MOQ workflow by:

1. Integrating https://github.com/wilaw/CMCD-over-MSF-event-timeline support into a web-based MSF/CMSF player, preferably the Playa open-source library.
2. Updating the ffmpeg plugin publishing component to allow catalog-based configuration and initiation of that CMCD data.
3. Building a real-time collection system which can collect, process and display the incoming client QOE data.

Where agents come in

Agents can be used to analyze the incoming CMCD data to detect and warn on anomalies.

Why it matters to the community

Collecting real-user QoE data is critical to allowing MOQT and MSF/CMSF workflows to reach a production-ready level of performance.

What a team would need, and what ends up on GitHub

The dev team will need TypeScript/Javascript skills for the player development, C++ for the ffmpeg plugin update and general back-end and data-viz skills for the data collection. Open-source libraries for player and ffmpeg can be provided by the OpenMOQ project, along with relay and hosting assets. All output is expected to be open-sourced under an Apache-2 license.

The problem, and who feels it

In order to deliver the highest user-quality, MSF/CMSF players need to implement an Adaptive bitrate algorithm to allow them to smoothly switch between tracks at differing quality levels. Typically this is done on the client side. However, a server-side implementation of ABR has some theoretical advantages - it knows about congestion RTT/2 before the client and it also knows the subscribe state of the incoming tracks. Sender-Side Track Selection (SSTS) - https://wilaw.github.io/moqt-ssts/draft-wilaw-moq-moqt-ssts.html - is a draft defining an extension to MOQT enabling a server-side ABR solution to be implemented on a MOQT relay. It defines a subscriber-initiated and controlled behavior in which a MOQT publisher dynamically selects which track to forward from a switching set based on various algorithms. The specification defines a default algorithm - type 0. Other algorithms are referenced in the "SSTS Algorithms" registry. The goal of this challenge is to:

1. Implement the SSTS draft, along with algorithm 0, in the moqx relay.
2. Design an improved algorithm, algorithm 1, and also implement that to illustrate multi-algorithmic support. This may be an AI (neural) model rather than a heuristic algorithm.
3. Test both algorithms under a variety of real-world scenarios encompassing variable RTT, loss and jitter characteristics.
4. Validate the usefulness of SSTS as an approach.
5. For bonus points, compare the performance of SSTS against an equivalent client-side ABR scheme.

Where agents come in

Agents may be used to train and implement an AI model for sender-side switching. The training environment would be simple - create a model of the system, in which a switcher is given 4 choices of bitrate and some simple inputs on estimated throughput, RTT etc. Then score it on maximizing client side average quality and minimizing the number of switches.

Why it matters to the community

SSTS represents a novel approach to OTT delivery in MOQT, and it has not yet been rigorously explored in the lab. Having these results would greatly improve the adoption of the extension point in commercial relays.

What a team would need, and what ends up on GitHub

C++ skills to implement SSTS in moqx, TypeScript skills to build and instrument a player. AI and agentic skills to optionally train a lightweight switching model. Resultant code should be open-sourced under an Apache-2 license for moqx and the algorithm 1, if successful and better than algorithm 0, defined in a new IETF draft.

The problem, and who feels it

Client-side ABR remains a challenge for MSF/CMSF players with MOQT-delivered content. The ABR must function at very low buffer levels and with limited signals. Traditional ABR approaches are implemented using a combination of rules and heuristics. The switching problem is however well suited to an AI-based solution. The output decision is very simple - switch up, switch down, or don't switch. The inputs are limited - a history of throughput estimates, current buffer length and knowledge of the bitrate stack. Training data is cheap as simulations can be built to predict client QOE and then run faster-than real-time. The score is unambiguous - maximize average delivered bitrate and minimize switch count. The goal of this challenge is to develop an AI-based client-ABR switching solution for web-based MSF/CMSF players. The approach may use Deep Reinforcement Learning, 1-D Convolutional Neural Networks or other approaches as determined useful by the developers. The resulting model and player implementation should use Playa as a base and must be open sourced under Apache-2 so that the community can benefit.

Where agents come in

The solution could be developed as a series of micro-agents operating on the client. For example, a network profiler agent would estimate the bandwidth, a Device agent monitors buffers and dropped frames, a user context agent monitors received QoE and an ABR Switching agent coordinates with the other agents and implements the switch.

Why it matters to the community

Functional client-side ABR for sub-second latency ABR remains a challenge for MOQT adoption.

What a team would need, and what ends up on GitHub

Strong agentic and AI skills to develop, train and implement the models, TypeScript skills to implement the ABR in the player. Results should be open-sourced under an Apache-2 license. Resources (hosted relays, compute etc) will be provided by OpenMOQ.