At this year’s NAB Show in Las Vegas, we are demonstrating FAMIUM MoQ, our brand-new implementation of the IETF’s Media over QUIC Transport (draft-ietf-moq-transport-16), which we have been working on over the past months. The demo shows a live camera feed streamed from Berlin to Las Vegas with sub-second glass-to-glass latency, using nothing but a standard browser for playback. No plugins, no proprietary protocols, no dedicated hardware decoders. Just QUIC, WebTransport, and the open web platform.
The Demo: 9,300 km, Under 1 Second
The setup is straightforward:
- Source: A Blackmagic camera at Fraunhofer FOKUS in Berlin captures a live street view via HDMI. Of course, other (professional) cameras can be used as well.
- Ingest: An HDMI capture card feeds the raw video into ffmpeg, which encodes H.264 in real time and packages it as CMAF (fragmented MP4) segments.
- Publishing: Our Go-based moq-pub reads the fMP4 pipe and publishes it over QUIC to the relay.
- Relay: The moq-relay server, running on Fraunhofer FOKUS infrastructure in Berlin, routes the stream to all subscribers.
- Playback: A standard browser at the NAB Show booth in Las Vegas receives the stream over WebTransport and plays it back using the Media Source Extensions (MSE) API.
The result: consistent latency under one second across 9,300 km. Our player measures the glass-to-glass latency by comparing a wall-clock timestamp burned into the video at capture time with the browser’s local clock at display time.
Why MoQ?
Live streaming on the web today is dominated by HTTP-based protocols HLS and DASH that deliver excellent quality at scale but at the cost of latency. Even “low-latency” variants (LL-HLS, LL-DASH) typically achieve 2-5 seconds. WebRTC gets latency down to sub-second but was designed for small-scale communication, not media distribution.
Media over QUIC Transport (MoQ) is an IETF effort to bridge this gap. It combines the low-latency properties of QUIC with a publish/subscribe model designed for media distribution:
- QUIC streams per group: Each video GOP travels on its own QUIC stream, enabling independent delivery and avoiding head-of-line blocking.
- Sub-GOP delivery: Individual frames are delivered as separate MoQ objects within a group, so partial GOPs can be forwarded immediately.
- Relay-based architecture: A relay server routes subscriptions and forwards data, publishers and subscribers never connect directly, enabling fan-out.
- WebTransport for browsers: The browser connects to the relay over WebTransport, which provides native QUIC stream access from JavaScript.
- Codec-agnostic: The protocol carries opaque payloads H.264, HEVC, AV1, Opus, AAC all work without protocol changes.
Browser-to-Browser: Sub-100 ms
FAMIUM MoQ is not limited to the ffmpeg-to-browser pipeline. We also support browser-to-browser streaming using the WebCodecs API. The browser captures camera and microphone via MediaCapture, encodes with WebCodecs (H.264 + Opus), and publishes directly over WebTransport to the relay. A subscriber in another browser (or the same one, for loopback testing) receives, decodes, and renders in real time.
In our loopback tests, publisher and subscriber in separate browser windows, both connecting through the relay, we measure transport latency consistently under 100 ms.
Architecture
FAMIUM MoQ is written in Go (Publisher, Subscriber, Relay) and TypeScript (browser libraries for Publisher and Subscriber), targeting draft-ietf-moq-transport-16. The key components:
| Component | Language | Role |
|---|---|---|
| famium-moq-relay | Go | Routes subscriptions, forwards data streams, caches recent groups for late joiners |
| famium-moq-pub | Go | Reads fMP4 from stdin, auto-detects tracks, publishes over QUIC |
| famium-moq-sub | Go | Subscribes via catalog discovery, writes fMP4 to stdout |
| famium-moq-pub.js | TypeScript | Browser publisher: WebCodecs encode + WebTransport publish |
| famium-moq-sub.js | TypeScript | Browser subscriber: WebTransport receive + MSE or WebCodecs decode |
The relay is format-agnostic, it forwards opaque MoQ objects between publishers and subscribers. This means the same relay handles both CMAF/MSE playback and WebCodecs real-time communication simultaneously.
What Makes It Fast
Several design choices contribute to the low latency:
- Sub-GOP framing: Each video frame is a separate MoQ object. The relay forwards frames as they arrive, without waiting for a complete GOP.
- Per-stream flow control: QUIC’s per-stream flow control prevents a slow audio stream from blocking video delivery.
- Non-blocking subscriber forwarding: The relay uses independent goroutines per subscriber with buffered channels. A slow subscriber gets dropped objects rather than blocking the publisher.
- Late-joiner caching: The relay caches the most recent group per track, so new subscribers can start playback immediately without waiting for the next keyframe (player can then catchup with ).
What’s Next
MoQ Transport is still an evolving IETF draft, and FAMIUM MoQ evolves with it. Areas we are actively working on:
- Adaptive bitrate: Using MoQ’s priority and track mechanisms for quality switching.
- Ad insertion: Leveraging MoQ’s relay architecture and track switching for seamless server-side ad insertion.
- End-to-end encryption: Leveraging QUIC’s built-in TLS with application-level media encryption.
- Interoperability: Testing against other MoQ implementations as the ecosystem grows.
See It Live
If you are at NAB Show 2026, visit our Fraunhofer booth to see the Berlin-to-Vegas and Real-Time Communication demo in action. You can find us in West Hall Booth W2343. For more details, please visit our NAB Demo page.
FAMIUM MoQ is developed by the Future Applications and Media (FAME) group at Fraunhofer FOKUS in Berlin.