Live network lab

Live ISS stream. Three players. Four transports.

Watch live ISS camera views in your browser.

Compare QUIC, ROUTE/mABR, AMT, and native multicast/DIMT for a live stream from the International Space Station. Live signals show the last 60 seconds of latency, frame rate, and total received throughput, plus loss and FEC while a multicast leg reports them. Physical-path boundary latency stays blank until packet, decode, render, and transport attribution evidence is complete.

Play the live ISS camera views in this browser over QUIC. A verified local Blockcast bridge can expose explicit AMT or native multicast choices for a physical-path test.

Browser playback

Playback stays in this browser

Browser playback is active over QUIC. AMT and native multicast require a local bridge, which is still being checked.

Checking player origin availability.

Live signals

Blockcast ingress → render—

Rendered FPS—

Loss—

FEC recovered—

ABRWaiting

—

Diagnostics

Physical evidence: waiting for a selected transport.

ABR status: waiting for player telemetry.

Latency target: <100 ms.

NASA/YouTube upstream delay: unverified; excluded from the Blockcast <100 ms target.

What the <100 ms target measures

The <100 ms budget runs from the Blockcast publisher's send instant (the MMTP packet header timestamp cast stamps after NASA HLS ingest and transcode) to the decoded frame's presentation, both on the relay clock each player calibrates with BCTM; ± is that calibration plus the publisher-to-relay clock bound. NASA upstream HLS ingest/transcode and source-to-glass delay are excluded.

Transport comparison

p50, p95, and max use only producer-attested Blockcast ingress → rendered-frame samples; every sample must stay strictly below 100 ms. Publisher/media-admission diagnostics remain separate and do not satisfy this budget.

Transport	Samples	p50	p95	Max	Budget
QUIC	Waiting for evidence
ROUTE / mABR	Waiting for object-delivery evidence
AMT	Waiting for physical evidence
Native / DIMT	Waiting for physical evidence

Latency · ms

FPS · frames/s

Throughput · Mb/s

Waiting for the local multicast bridge.

Each player exposes aggregate playback counters through the same component contract. The rendition selector receives only catalog-derived video track names and display metadata. Unicast QUIC throughput adds every player's received payload; physical native/DIMT and AMT ingress are counted once before player fan-out. Missing values and unproven physical-path boundary latency remain chart gaps; they are never estimated.

Browser-owned transport

Android, iOS, desktop IWA, and extension packages provide only local discovery and thewindow.multicast bridge. This tab keeps catalog resolution, decoding, rendering, and controls.

Optional local bridge

Keep watching here

Browser playback stays on explicit QUIC/MoQ by default. With a verified bridge, choose AMT or native multicast on the Shaka player when you want a physical-path test.

Android · iOS · desktop

Bridge-only packages

SDK apps, IWAs, and extensions may supply the local transport capability. They do not host a second player or require an app handoff.

Checking for the Blockcast browser bridge…

From viewer to broadcaster

This public demo is playback-only and never receives publishing credentials. Supported encoders are FFmpeg with the moq_mmt muxer (version_filter=moqt-16) and cast, which also takes SRT contribution; HTTP live is pulled from your CMAF origin through a pull zone. Account-scoped publishing remains a roadmap item until namespace and node authorization are implemented and verified.

Planned

Publish with WHIP

Account-scoped WHIP endpoint creation is not available from this demo yet. It will ship only after signed-in namespace and node authorization are wired end to end.

Required boundary

Own your tracks

Publishing must bind track discovery, subscriptions, and revocation to the logged-in namespace. The public playback catalog does not grant that authority.

Lab and demo results

Blockcast measured MMTP over MoQ in its lab and in a recorded demo. The article has the full results.

Keyframe repair

Lab result on multicast: 97% less frozen picture from network loss

An optional FEC repair track protects keyframes and their timing packets. On multicast in Blockcast’s 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.

Multicast

52% fewer bits on multicast than on unicast, in the recorded demo

In Blockcast’s recorded demo, three players on one machine received 52% fewer bits on multicast than on unicast, repair included.

Path switch

Switch paths mid-stream

Unicast and multicast carry the same media packets. In the recorded demo, moving each of three players from unicast to multicast cost at most one pause.

The article and the drafts

Read the article See the overview Read the drafts