The case for MMTP + MoQ: one stream online and on air

At Blockcast we've written drafts for Media over QUIC (MoQ), the IETF's new protocol for low-latency live video. Our drafts also take MoQ onto multicast and broadcast networks.

We picked MMTP, the packet format of MPEG Media Transport (MMT), to carry the video. Our drafts carry the same MMTP packets from our encoder over the internet and those networks, unchanged.

Key points

• Lower latency under loss: repair without a round trip. MMT's repair packets let viewers rebuild lost packets instead of waiting for a resend. Multicast and broadcast depend on them, and our drafts let unicast viewers use them too.
• Fewer stalls, even without repair. Under our drafts, multicast video pauses only when a loss may have hit a keyframe or its timing packets. Other losses are concealed. With repair on, a second repair stream protects keyframes and their timing packets. On multicast in our lab, it cut frozen-picture time from network loss by 97%. That's at keyframes that ordinary repair couldn't rebuild, across three loss patterns.
• Lower-cost delivery. Reduce duplicated bits on multicast networks, and unicast fan-out offload via AMT on router line cards, and Linux kernel everywhere else.
• Already on air. At least three US stations transmit MMTP today, and our drafts describe a path from the air to browsers.
• Built on standards. It's all ISO, ATSC, ARIB and IETF specs, plus our drafts on the IETF datatracker.

What's inside an MMTP packet

MMT (ISO/IEC 23008-1) is built for delivery over both two-way IP networks and one-way broadcast networks. MMTP is its packet layer.

• Same media inside. Each packet carries pieces of standard fMP4-style media. Encoding profiles don't change.
• Datagram-sized. Each packet fits in one network datagram: at most about 1.3 KB in our streams.
• Self-describing. The header carries the track ID, sequence number, send time, a keyframe flag and repair information (Figure 2).
• Stands on its own. A receiver can place any packet in its stream without the packets around it. On a one-way broadcast link, it has to.

Some broadcasters already put MMTP on air: on ATSC 3.0 in South Korea and the United States, and on ARIB STD-B60 in Japan.

Unicast, today

In our lab, a viewer saw MMTP's first picture a median of 124 ms after subscribing, as fast as LOC, MoQ's lightweight container. The viewer was next to the relay and joined from its cache. Relays are MoQ's version of CDN servers. On our live ISS stream, frames reached a browser at our relay's site without waiting for their MoQ group to close.

Our encoder sends the same MMTP media packets to the MoQ relay and to the multicast group. Under our drafts, a broadcast carries the same packets, unchanged.

Unicast sends one stream per viewer. Here's how MMTP works there:

• Frame by frame. Our encoder sends each frame as its own run of packets, without waiting for a whole segment. At 30 frames a second, that's every 33 ms. Our MMT draft calls this MFU (media fragment unit) mode.
• Browsers and apps. Browsers take the stream over WebTransport, in production and in our lab. MoQ also runs directly over QUIC, for native apps.
• No MMTP code in relays. Each packet is one MoQ object. Under our MMT draft, a relay forwards it like any other object, with no MMTP or repair code.
• Joins from the cache. Our MMT draft starts a new viewer at the start of the current group, which always opens on a keyframe. A relay that caches that group serves it with no request back to the encoder.
• Next-keyframe joins keep pace with LOC and CMAF. For viewers who wait for the next keyframe, MMTP's median time from that keyframe to playback was within 10% of LOC's and CMAF's. So was its median lag behind live. We measured both in our web player, in our lab with MMT repair off.

Multicast and broadcast

In our recorded demo, three players on one machine received 52% fewer bits on multicast than on unicast, repair included. With unicast, every extra viewer is one more copy to pay for. A multicast or broadcast network sends a single copy, however many people watch.

MMTP fits these networks as it is:

• One packet, one datagram. These networks carry media one UDP datagram at a time, and an MMTP packet already fits in one. LOC (MoQ's lightweight container) and CMAF tracks have to be repackaged first. Each of their objects holds at least a whole frame.
• Repair instead of resends. These networks never resend a lost packet. MMT's forward error correction (FEC) sends repair packets with each block of media. On our live ISS stream at 360p, that's 25% more packets: 2 repair packets for every 8 video packets. The receiver rebuilds what's lost from them. Under our drafts, that repair rides its own MoQ track. It's listed in the stream's catalog, MoQ's answer to a manifest.
• Switch paths mid-stream. Unicast and multicast carry the same media packets, so a viewer can hop between them without restarting the stream. In our recorded demo, moving each of three players from unicast to multicast cost at most one pause.
• One network at a time. Each network can turn multicast on when it's ready.

Where multicast doesn't reach, AMT (Automatic Multicast Tunneling, RFC 7450) carries the same packets. An AMT relay at the edge of a multicast network takes the stream in once. It sends a unicast copy to each AMT gateway that asks. Through an AMT tunnel, our 360p stream ran 5.5% above native multicast.

Routers can do that copying on their line cards: Juniper documents AMT relay tunnels on the line cards of its MX routers. Linux has had an AMT relay in the kernel since version 5.16.

Already on air

RabbitEars' public scans of 31 October 2026 show at least three US stations transmitting MMTP. In ATSC 3.0's standards, MMTP is for over-the-air delivery only. For broadband, they call for DASH, a second format. Our drafts carry the same MMTP online too, over MoQ.

• No transcode. For channels already on air, our drafts describe a publisher that builds the MoQ catalog and repair settings from your own signaling.
• Plays in a browser. Our web player, the Live Demo on blockcast.network, plays our live ISS stream, MMTP over MoQ, in an unmodified Chromium-based browser.
• Spare capacity. Four US station groups have formed a datacasting venture, with streaming offload among its potential applications. Our multicast draft specifies airing a streamer's MoQ stream unchanged, so its signatures stay verifiable.

Why MMTP and QUIC fit together

All of these networks lose packets. A receiver can get reliability at three layers, and each one costs something different:

• QUIC resends. Over unicast MoQ, our MMT draft puts MMTP media packets on QUIC streams by default, and QUIC resends what's lost. Each resend takes at least a round trip and needs a return path.
• MMT repair packets. They cost bandwidth but need no return path. A lost packet waits for enough of its block to arrive.
• MoQ repair tracks and fetches. Our drafts let each receiver subscribe to as much repair as its path needs. It can also fetch more repair through the relay for a block it couldn't rebuild. A fetch takes at least a round trip. It works only while the relay, or a publisher behind it, still holds that repair.

Each network uses what fits it:

• Unicast: rely on QUIC's resends and save the bandwidth.
• Unicast, when a resend would arrive too late to play: take the packets as QUIC datagrams and rebuild losses from the repair packets.
• Multicast: rebuild losses from the repair packets, then fetch extra repair, starting with blocks that may hold part of a keyframe.
• Antenna only: rebuild losses from the repair packets alone.

On the multicast path in our lab, MMT's repair alone rebuilt 91% of the video frames hit by bursts of loss. For the keyframes it missed, our drafts add a second repair stream.

Keyframes get repaired first

Lose one keyframe packet beyond repair, and our MMT draft has the player wait for the next keyframe before it shows video again. In our lab, with a keyframe every second, that froze the picture until the next keyframe.

So under our drafts, a multicast receiver treats keyframes differently:

• It pauses only for keyframes. Video pauses only when a loss may have hit a keyframe or one of the two timing packets sent just before it. Those packets tell the player when to show the keyframe.
• It conceals everything else. Other video that repair can't rebuild in time is concealed until the next keyframe. Audio and the clock keep running. Lost audio is concealed too, never waited for.

In our 720p test stream, a keyframe was about three times the size of each frame after it. With repair spread evenly, one burst can take more of a keyframe than its share of repair can rebuild.

We call the ordinary repair every packet gets base repair. On top of it, keyframes get a second repair stream on an optional track: the keyframe overlay. Our MMT draft gives the overlay a repair block of its own, without changing base repair's latency. Its next revision also has the overlay cover the two timing packets sent just before each keyframe. The player can't use a rebuilt keyframe without them.

In a simulation with 1% loss, in bursts averaging ten packets, aiming some repair at keyframes gave:

• 85% fewer simulated freezes than spreading a 25% repair budget evenly, while spending 7% less on repair.
• The price: about a fifth more frames concealed between keyframes.
• Longer bursts: at two and a half times the length, it still cut freezes by 61%.

The numbers

We tested the overlay, timing packets included, on a live 720p stream over our lab's MoQ multicast path. About 2% of the video was lost, in bursts of about a third of a second.

At keyframes that base repair couldn't rebuild, across three loss patterns, the overlay gave:

• 97% less frozen picture from network loss.
• No keyframe lost. Without the overlay, the player lost every one.
• No pause from network loss at 97% of those keyframes.

Two more results:

• With the overlay's repair also hit. On one pattern, bursts also hit the overlay's own repair. The picture still spent 29% less time frozen per keyframe that base repair missed, compared with no overlay.
• Cost. In these tests, the overlay's repair took about a sixth of the video's bitrate, on top of base repair.

If you build encoders or players

MMTP packaging runs after the encoder:

• You cut the media into MMTP packets in MFU mode, and flag the ones that carry a keyframe.
• Each packet goes out as soon as it's made. The MoQ catalog describes the tracks, as MMT signaling does on multicast and broadcast.
• The base repair track and the keyframe overlay are optional.

MMTP is one more packaging option for MoQ, next to LOC and CMAF.

What we've built:

• An FFmpeg muxer that writes MMTP in MFU mode, repair tracks included.
• Rust libraries for the MoQ transport and the RaptorQ repair code, with C bindings.
• One TypeScript receiver library, shared by three browser players, public on npm as @blockcast/mmt-* under Apache-2.0.
• Our moq-pub-mmtp publisher and a Rust MoQ relay we maintain, public in Blockcast/moq-rs.

Read the drafts

All of them are on the IETF datatracker:

• draft-ramadan-moq-mmt: MMT inside MoQ, including the keyframe overlay. Its next revision extends the overlay to keyframe timing packets and adds unicast delivery as QUIC datagrams.
• draft-ramadan-moq-multicast: multicast and broadcast delivery.
• The draft-ramadan-moq-fec set: fec-core, fec-block-codes, fec-catalog and fec-multicast, for repair and the receiver's repair policy.

If you run a media service, I'd like to hear what one output for every network would be worth to you.

If you build encoders or players, read the drafts against your own gear. Tell me where they'd break, while they're still individual drafts.

#MoQ #MediaOverQUIC #Multicast #MMT #ATSC3 #FEC #LiveStreaming #IETF