QuicFeed

QUIC-based feed ingest & backhaul — replacing SRT and WHIP

HTTP Push Listener (ATEME or VIDEON)

1. Create a namespace and set tx/rx passwords at /admin

2. Start the receiver:

./quicfeed-receiver \
  --namespace youtube-nfl-001 \
  --listen-addr 0.0.0.0:443 \
  --cert /etc/letsencrypt/live/use.l3dcmaf.com/fullchain.pem \
  --key /etc/letsencrypt/live/use.l3dcmaf.com/privkey.pem \
  --dash-dir /var/www/html/stream/dash/

3. Start the transmitter in HTTP mode:

./quicfeed-sender \
  --namespace youtube-nfl-001 \
  --rx-addr use.l3dcmaf.com:443 \
  http --port 9078

4. Point your encoder's HTTP PUT output at the tx listener:

gpac -i /root/adena_groomed_1s.mp4 reframer:rt=on \
  -o http://localhost:9078/manifest.mpd:gpac:hmode=push:cdur=0.0333:cmaf=cmfc

Each namespace has separate tx and rx passwords. Set them in the admin panel before connecting.

How It Works

Both tx and rx authenticate with this worker, then establish a direct QUIC connection. Each file is sent on its own unidirectional QUIC stream, eliminating head-of-line blocking — a retransmit on one segment never stalls delivery of later segments. The tx acquires a namespace lock (one active tx per namespace) refreshed via heartbeat every 15 seconds.

The rx enforces an absolute delay floor matching SRT's TLPKTDROP: --max-transfer-time kills QUIC streams that exceed a transfer deadline via STOP_SENDING (saving bandwidth on doomed retransmissions), and --latency drops files that arrive past their playout deadline. Together they guarantee no segment stalls the pipeline beyond the configured deadline.

Options

quicfeed-sender

quicfeed-sender --namespace <NS> --password <PW> --rx-addr <HOST:PORT> http [--port <PORT>]

  --namespace <NS>         Feed namespace (e.g. "youtube-nfl-001")
  --password <PW>          TX password for this namespace
  --rx-addr <HOST:PORT>    Receiver address to connect to
  --worker-url <URL>       Auth endpoint [default: https://quicfeed.net]
  --max-bitrate <BYTES/S>  LiveCC target rate [default: 5000000 = 40 Mbps]
  http --port <PORT>       Listen for HTTP Push (DASH/HLS) from encoder and send over QUIC [default: 9078]

quicfeed-receiver

quicfeed-receiver --namespace <NS> --password <PW> --cert <FILE> --key <FILE> [OPTIONS]

  --namespace <NS>         Feed namespace (e.g. "youtube-nfl-001")
  --password <PW>          RX password for this namespace
  --listen-addr <ADDR>     Listen address [default: 0.0.0.0:4443]
  --cert <FILE>            TLS certificate (PEM) — required unless --multicast-in
  --key <FILE>             TLS private key (PEM) — required unless --multicast-in
  --hls-dir <DIR>          LL-HLS output directory (enables LL-HLS mode)
  --dash-dir <DIR>         L3D-DASH output directory (enables L3D-DASH mode)
  --multicast-out <ADDR>   Multicast group:port to forward fragments to (e.g. 239.0.0.8:5000)
  --multicast-in <ADDR>    Multicast group:port to receive from — bypasses QUIC server
  --latency <MS>           TSBPD jitter buffer latency [default: 0 = immediate]
  --max-transfer-time <MS> Absolute delay floor — kill streams exceeding deadline [default: 0 = disabled]
  --max-bitrate <BYTES/S>  LiveCC target rate [default: 5000000 = 40 Mbps]
  --abr                    ABR mode — multi-representation manifests (requires --hls-dir/--dash-dir)
  --chunked-transfer       DASH incremental segment writes for chunk-aware origins (requires --dash-dir)
  --window <SECS>          DVR window size in seconds [default: 30]
  --worker-url <URL>       Auth endpoint [default: https://quicfeed.net]

Claims to Be Validated

By replacing SRT's reliance on fixed host/port 4-tuples with QUIC Connection IDs, we decouple the session from the physical network interface. This makes seamless multipath and hitless failover much more feasible than the "bonding" hacks we currently use in the SRT ecosystem.

One of the biggest wins for our approach is solving Head-of-Line (HoL) blocking, which is a baked-in limitation of SRT's single-stream architecture. In SRT, a single lost packet stalls delivery within that SRT stream while the receiver waits for a retransmission — this block is bounded by SRT's TLPKTDROP timeout (user-configurable: 20–8000ms), after which the packet is dropped and delivery resumes. A lost packet on one SRT stream doesn't stall other SRT streams, but everything within the affected stream is delayed for up to that duration. By using QUIC's multi-streaming capabilities, we map different media components to independent streams. If a metadata or audio packet drops, it won't stall the video frames. We get the reliability of SRT without the cascading delays caused by serial packet dependency.

The setup speed is another area where we see a huge benefit over SRT. While SRT requires a multi-step handshake before data flows, we can leverage QUIC's 0-RTT session resumption. If an encoder in the field loses signal and reconnects, it doesn't have to wait for a full handshake cycle. It can literally send the encrypted setup request and the first flight of media data in the very first packet. For live contribution, this means the difference between a 3-second recovery and a near-instant one.

---

Detailed Comparison with SRT Detailed Comparison with WHIP
Open Admin Panel Test Reports Request Binaries