hls_runtime/lib.rs
1//! `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 `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//! "hls-runtime — client + server in one crate").
11//!
12//! # Module map
13//!
14//! - [`client`] — the LL-HLS playback client engine: [`client::HlsClient`],
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: [`server::HlsOrigin`],
20//! a `media_plane::egress::ServedEgress` rendering playlists and resolving
21//! blocking-reload/part-availability requests directly from a shared
22//! `media_plane::Trunk` (plan step 4) — no push-fed rolling-window store of
23//! its own. Playlist rendering, and the TARGETDURATION/msn/abuse rules, are
24//! all poll/step, no tokio, no axum. See the module docs for the
25//! caller-driven wait loop an async adapter (e.g. `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)";