ll_hls_runtime/
lib.rs

1//! `ll-hls-runtime` — sans-IO Low-Latency HLS (RFC 8216bis) client **and**
2//! server/origin engines, in one crate — mirroring `rtsp-runtime`'s
3//! client+server split.
4//!
5//! This crate unifies what used to be the standalone `ll-hls-client` crate
6//! (Stage 1: a pure rename to `ll-hls-runtime`, zero behaviour change) with
7//! the LL-HLS origin engine that used to live in `multimux` (Stage 2: moved
8//! into [`server`] — issue #663/#717,
9//! `docs/superpowers/specs/2026-07-18-multimux-hub-design.md`,
10//! "ll-hls-runtime — client + server in one crate").
11//!
12//! # Module map
13//!
14//! - [`client`] — the LL-HLS playback client engine: [`client::LlHlsClient`],
15//!   the sans-IO reload scheduler / fetch pipeline / output adapter (issue
16//!   #717 slices 2-4), plus the optional `tokio`-feature
17//!   [`client::TokioClient`] async IO adapter (slice 5). See the module docs
18//!   for full behaviour. No_std-capable (the core needs only `alloc`).
19//! - [`server`] (feature `std`) — the LL-HLS origin engine: the rolling
20//!   window/store ([`server::MediaStore`]), the blocking-reload + part-
21//!   availability decision logic ([`server::MediaStore::resolve_playlist`]/
22//!   [`server::MediaStore::resolve_resource`]), playlist rendering, and the
23//!   TARGETDURATION/msn/abuse rules — all poll/step, no tokio, no axum. See
24//!   the module docs for the caller-driven wait loop an async adapter (e.g.
25//!   `multimux`) builds on top.
26
27#![cfg_attr(not(feature = "std"), no_std)]
28#![forbid(unsafe_code)]
29#![warn(missing_docs)]
30#![cfg_attr(docsrs, feature(doc_cfg))]
31
32extern crate alloc;
33
34pub mod client;
35#[cfg(feature = "std")]
36#[cfg_attr(docsrs, doc(cfg(feature = "std")))]
37pub mod server;
38
39/// The RFC this crate's client behaviour implements against.
40pub const SPEC: &str = "RFC 8216bis (HTTP Live Streaming 2nd Edition, draft-pantos-hls-rfc8216bis)";
ll_hls_runtime/lib.rs

ll_hls_runtime/
lib.rs
