Quicly

Hosted multiview for esports broadcasts, delivered over Media over QUIC and embedded with a single iframe. Send feeds by SRT, RTMP, or browser camera and get back a resizable multi-angle player that viewers can rearrange without interrupting playback.

Category

Broadcast

Plan

Freemium

Status

Beta

Ingest

SRTRTMPCamera (getUserMedia)

Media Formats

moq-lite

Quicly is a hosted live multiview product aimed at esports broadcasts. Its pitch is narrow and clear: “Every POV. No delay. One iframe.” You send it feeds, it returns an embed containing all of them side by side, and viewers can resize, rearrange, or swap angles without the video stopping.

Delivery is over Media over QUIC, using the moq-lite stack rather than the numbered draft-ietf-moq-transport revisions — so it is not directly comparable to the relays and players in our directory that advertise draft-18 or draft-19 support.

The product is in early stages at the time of writing.

Embedding

A single tag, no SDK and no player to maintain:

<iframe
src="https://quicly.live/embed?ns=your-namespace"
title="Live multiview"
allow="autoplay; fullscreen"
style="width:100%;aspect-ratio:16/9;border:0"
allowfullscreen
></iframe>

Ingest

Three ways in, each configured per stream and changeable only while the stream is stopped:

  • SRT — push from your encoder to an SRT endpoint
  • RTMP — push from your encoder to an RTMP endpoint
  • Camera — publish the browser camera directly via getUserMedia. A camera stream does not consume a concurrency slot
  • Demo — a server-side clip that feeds itself, for trying the API without an encoder

Ingested feeds are re-encoded server-side with a 300 ms GOP, with configurable bitrate, framerate, and resolution.

Latency

Quicly publishes a measured glass-to-glass figure of 683 ms — a frame leaving the source to that frame painted in a browser tab — against a 6 s segmented-HLS baseline. The company is explicit that the HLS number is the figure the segmented format is built around rather than a measurement of any particular service, which is a more honest framing than this comparison usually gets. Our own take on where those seconds come from is in MoQT vs HLS/DASH.

API and agent control

Everything the dashboard does is available over HTTP at https://api.quicly.live, authenticated with a bearer key (qk_...). The core flow is POST /v1/streams, POST /v1/streams/{id}/start, then read embed_url off GET /v1/streams/{id}. Streams move through idle → starting → live → stopping, with error as a terminal state whose cause is in GET /v1/streams/{id}/logs. Minutes are billed from the start call rather than from the first frame.

More unusually, Quicly ships a hosted MCP server so an AI agent can create, start, and stop streams and read run logs conversationally:

claude mcp add --transport http quicly https://api.quicly.live/mcp

The server signs itself in over OAuth — the client opens a browser once for approval and no credential is pasted anywhere — and connections are revoked from the Developers page. That makes it one of the first MoQ-based products with a first-class agent interface, which is worth noting alongside the agentproto work happening at the IETF.

Plans

The free tier runs the full path end to end with a watermark: 3 hours of streaming a day (surfaced in the dashboard as 180 streaming minutes), up to 720p30 at 3,000 kbps, and 4 live streams at a time. Enterprise terms cover 1080p60 and above, higher concurrency, no watermark, and a named support contact.

Observability

The dashboard surfaces per-stream warnings and errors from the MoQ layer directly — producer lifecycle warnings such as broadcast::Producer dropped without finish() and track::Producer dropped without finish() or abort() appear in the stream log rather than being swallowed. If you are debugging a publisher against it, that log is the first place to look, and a protocol-level trace is the second.