Crate ll_hls_runtime 

ll-hls-runtime — sans-IO Low-Latency HLS (RFC 8216bis) client and server/origin engines, in one crate — mirroring rtsp-runtime’s client+server split.

This crate unifies what used to be the standalone ll-hls-client crate (Stage 1: a pure rename to ll-hls-runtime, zero behaviour change) with the LL-HLS origin engine that used to live in multimux (Stage 2: moved into server — issue #663/#717, docs/superpowers/specs/2026-07-18-multimux-hub-design.md, “ll-hls-runtime — client + server in one crate”).

Module map

• client — the LL-HLS playback client engine: client::LlHlsClient, the sans-IO reload scheduler / fetch pipeline / output adapter (issue #717 slices 2-4), plus the optional tokio-feature client::TokioClient async IO adapter (slice 5). See the module docs for full behaviour. No_std-capable (the core needs only alloc).
• server (feature std) — the LL-HLS origin engine: the rolling window/store (server::MediaStore), the blocking-reload + part- availability decision logic (server::MediaStore::resolve_playlist/ server::MediaStore::resolve_resource), playlist rendering, and the TARGETDURATION/msn/abuse rules — all poll/step, no tokio, no axum. See the module docs for the caller-driven wait loop an async adapter (e.g. multimux) builds on top.

Modules

client

LL-HLS playback client engine — a sans-IO Low-Latency HLS (RFC 8216bis) client (issue #717, slices 2-4; formerly the standalone ll-hls-client crate, folded in here as ll-hls-runtime’s client module — see docs/superpowers/specs/2026-07-18-multimux-hub-design.md).

serverstd

LL-HLS origin engine (issue #663/#717 Stage 2): the sans-IO rolling window/store, the blocking-reload + part-availability decision logic, and playlist rendering, moved out of multimux so it can be shared with any async runtime — not just tokio+axum.

Constants

SPEC

The RFC this crate’s client behaviour implements against.