Building a Browser Multiview with Media over QUIC

On the first version of our browser multiview, dragging a tile across the wall made its picture disappear. Nothing had crashed. The page had restarted the live player while it was being moved. I had treated the players like ordinary cards in a web layout, and live video does not forgive that assumption.

When Gabriel Natter and I started Quicly, we set one practical boundary: contribution encoders should not have to change. Feeds can keep arriving over SRT. Quicly handles the work behind that handoff - preparing each feed for browser playback, publishing each angle over Media over QUIC, checking that it is ready, and presenting the whole multiview in one iframe. Viewers can resize, swap, maximize, close, or reopen an angle without interrupting the rest.

The public no-account demo uses four synchronized recordings so anyone can try the interaction without an encoder or account. The live SRT-to-MoQ path was measured separately on July 31, 2026; the 683 ms figure below comes from that controlled live-input test, not from the recordings.

Keeping contribution familiar

At a high level, the deployment path is deliberately short:

Quicly owns the product layer across that path: media preparation, per-angle publication, readiness checks, viewer session control, and the embeddable multiview. Cloudflare provides the relay path that carries those broadcasts to viewers. Because angles stay independent, the browser receives only those in use; a layout change never asks a server to render a new composite.

The disappearing tile was the first proof that the live session and the layout had to be separate. We redesigned the player lifetime so every session stays in place while the visual layout moves around it. It sounds small, but it is what makes the wall feel solid: drag a seam, swap two angles, or maximize one, and playback stays put.

A latency number we can reproduce

For the latency runs, we placed the sender's wall clock inside every frame and displayed a current clock beside the browser player. One screenshot captured both values. The sender and viewer ran on the same laptop, so the comparison did not depend on synchronizing clocks across two machines.

Across six runs through Cloudflare's relay, the median glass-to-glass delay was 683ms, and the readings stayed within a roughly 20ms band. Traffic left the laptop through Cloudflare and returned to the browser; the SRT contribution leg ran locally. That gave us a controlled baseline for the complete viewing path.

A remote encoder adds its own network conditions, so we present 683 ms as a measured engineering baseline, not a universal promise. Quicly keeps startup and steady-state timing separate, which means every deployment can be checked honestly with the encoder and network that will actually be used.

The startup delay was somewhere else

The first user-visible pause in our early tests happened before steady-state delivery. Preparing a live input took 5.10 seconds before the first media was ready. File-based tests had made that delay easy to overlook, because a file can be inspected much faster than a live source. The relay was not the cause.

After tightening the live-input analysis, the interval from encoder connection to first media fell to 0.60 seconds. We stopped there after confirming that both video and audio were present across the inputs we test. The useful result was not one magic setting; it was a repeatable startup check built into our release process.

We now report time to first frame separately from glass-to-glass delay after playback has settled, and both tests use a live contribution source. Quicly also records progress through the viewing path, so an operator can tell whether a delay began before publication or later in the browser.

Two compatible feeds that did not play

Two publishers could both claim MoQ support and still describe their media differently. The first symptom was a blank tile, not a helpful negotiation error. We fixed that by making compatibility explicit instead of asking the player to guess.

Quicly now identifies the supported media format, chooses the matching playback path, and records the transport, publisher, relay, and player as a tested release set. That turns a broad 'supports MoQ' statement into something reproducible and gives teams a combination they can deploy with confidence.

Browser checks that age better

Our early browser support relied too much on browser labels. Quicly now checks the capabilities it actually needs before playback begins. If something is missing, the viewer gets a specific compatibility message instead of an unexplained blank tile.

On browsers that pass those checks, Quicly watches the incoming media rather than treating an open connection as proof that playback is healthy. Each visible angle has its own health state, so a problem in one tile does not take down the rest of the wall.

If a session stalls, Quicly rebuilds that player automatically and keeps the other angles intact. It also records the last completed stage - discovery, subscription, decoding, or rendering - so browser testing and support start with evidence rather than guesswork.

What Cloudflare's relay enabled

Cloudflare's relay gave Quicly a dependable internet distribution path early in development. It let someone outside our network open the same multiview and test the complete chain without relay infrastructure for us to operate. That kept our engineering focused on the product experience: feed control, multiview behavior, readiness, and diagnostics.

Testing over a real external path also raised the bar for Quicly. A feed is not ready merely because contribution has connected; it is ready when a browser can subscribe, decode, and render it. Quicly now verifies those steps before opening a tile and reports where any issue occurred. Cloudflare's relay made that end-to-end validation practical.

Cloudflare has also introduced APIs for isolated MoQ relays with expiring, revocable publish and subscribe credentials. That gives Quicly a clear route from open evaluation to controlled deployments while Cloudflare handles relay operations. For customers, the result is a simpler rollout and separate access for publishers and viewers.

Where Quicly fits

Quicly turns live contribution feeds into a viewer-controlled multiview that teams can embed as one iframe. It manages media preparation, per-angle publishing, readiness, recovery, diagnostics, and the browser experience as one product. Existing encoders stay useful, Cloudflare provides distribution, and viewers get immediate control without a server-rendered composite.

For a live event, we pin and test the transport, media format, relay, player, and browser as one release set, then repeat the startup and steady-state measurements with the actual encoder and network. Quicly turns that into a routine release check instead of a new integration project each time.

The no-account demo remains the easiest way to decide whether the interaction fits. Swap two recorded angles, drag a seam, and maximize one. The recordings remove setup from the first visit; the live path uses the same interaction with contribution feeds behind it. A team can then validate that live path with its own encoder and network.

[Editor's note: This is a contributed article from Bitmovin. Streaming Media accepts vendor bylines based solely on their value to our readers.]

QUIC vs. Web Transport vs. Media Over QUIC

With emerging and still-developing streaming technologies and protocols like Media over QUIC (MoQ) and web transport, some basic definitions are in order to differentiate them from one another and to ensure that they aren't used interchangeably. Akamai's Will Law, an expert on all things QUIC, provides a cogent and crucial breakdown of QUIC and associated terminology in this discussion with Help Me Stream Research Foundation's Timothy Fore-Siglin from the latest Streaming Media Connect.

18 Jul 2025