Skip to main content

Crate multimux

Crate multimux 

Source
Expand description

multimux — a multi-input, multi-output just-in-time repackaging HTTP origin.

Pull or receive live media over any of ten ingest sources — config::InputSpec: RTSP pull, raw RTP/UDP, MPEG-TS/UDP, MPEG-TS/HTTP, SRT, HLS pull, DASH pull, Smooth pull, RTMP push, and a local media file (config::InputSpec::File, issue #748) — and serve each ingested stream as any combination of output::OutputKind: Low-Latency HLS, DASH, LL-DASH, Smooth Streaming, classic TS-HLS, catch-up/VOD, and SRT/RTMP/RTSP push re-egress — from one in-process tokio + axum HTTP origin. One ingest, many outputs, no per-output re-mux. Muxing only — samples are never transcoded.

Every input runs on one ingest architecture: media-plane’s ingress contracts (Dialer for the eight that dial out, Listener for RTMP’s push accept) driven by its IngestDriver/ListenDriver, publishing samples into a per-program Trunk that egress serves from. Issue #805 converged the last holdout onto this, so there is no second path a sample can take from socket to segment.

Also built on rtsp-runtime (RTSP), rtmp-runtime (RTMP), srt-runtime (SRT), hls-runtime (LL-HLS client/server engine + HLS pull), broadcast-auth (client and server auth), and transmux (RTP/TS depayload + CMAF segmentation + DASH packaging).

Third-party crates can add a new input/output/output-auth scheme without editing this crate at all — see registry (issue #663 external scheme plugin registry) and origin::serve_with_registry.

Re-exports§

pub use error::MultimuxError;
pub use error::Result;
pub use origin::serve;
pub use origin::serve_config_file;
pub use origin::serve_config_file_with_registry;
pub use origin::serve_with_registry;
pub use origin::supervisor::Backoff;
pub use origin::supervisor::supervise_driver;
pub use output::Output;
pub use registry::AuthCtx;
pub use registry::AuthFactory;
pub use registry::InputCtx;
pub use registry::InputFactory;
pub use registry::OutputCtx;
pub use registry::OutputFactory;
pub use registry::SchemeRegistry;
pub use route::HealthState;
pub use route::RouteHandle;
pub use source::Source;
pub use broadcast_auth;

Modules§

config
multimux configuration: routes + segmentation/window/bind parameters.
dvr
DVR durable segment archive — a media_plane::egress::SegmentEgress implementation that persists finished segments to disk as contiguous period files (one container file per period epoch), with a byte-range index and configurable retention. The operator chooses the media_plane::trunk::ArchiveOverrun policy for the loss/stall/drop trade when the live ring wants to evict a pinned entry.
error
Error type for multimux.
origin
HTTP origin server for stream delivery.
output
The Output abstraction: one implementation per delivery protocol (LL-HLS, DASH, LL-DASH, classic TS-HLS) layered over the protocol-neutral crate::route::RouteHandle (step 5b’s replacement for the deleted hls_runtime::server::MediaStore — see that module’s own docs).
prometheus
Process-wide Prometheus metrics plumbing (issue #663, P1c).
push
Push output driver (issue #744) — relay/restream ingested media to a downstream server (an SRT Listener, RTMP publish, or RTSP ANNOUNCE/RECORD) rather than serving it over HTTP.
registry
External scheme plugin registry (issue #663): lets a third-party crate add a new input/output/output-auth scheme to the multimux origin without editing multimux, wired purely via config JSON.
route
One route’s shared state: a ProgramId-keyed registry of ProgramServing bundles — each one the media_plane::Trunk a program’s samples land in, the sans-IO LL-HLS origin over it (hls_runtime::server::HlsOrigin, plan step 4), and the small Trunk-drained window DASH/LL-DASH need beyond what any Trunk ring holds (DashState, below) — plus this route’s HealthState, which is route-wide, not per-program.
source
Ingest sources feeding the segmentation pipeline. RtspSource (RTSP pull), RtpUdpSource (raw RTP over UDP, uni/multicast), TsUdpSource (MPEG-2 TS over UDP, uni/multicast), ts_http::TsHttpSource (MPEG-2 TS over HTTP), hls_pull::HlsPullRoute (pull a remote (LL-)HLS origin), dash_pull::DashPullRoute (pull a remote MPEG-DASH origin, issue #758), smooth_pull::SmoothPullRoute (pull a remote Microsoft Smooth Streaming origin, issue #759), rtmp::RtmpRoute (RTMP push ingest, issue #738 — a push source implementing media_plane::ingress::Listener since issue #805 task 4; every other source above dials out), and srt::SrtRoute (SRT-carried MPEG-2 TS ingest, issue #739 — listener or caller mode) all implement the Source marker trait; every one — including InputSpec::Custom, via a crate::registry::SchemeRegistry-provided factory, since issue #805 task 5 deleted the old SourceConnector/supervise/pipeline path — is driven over media_plane::ingress (Dialer/Listener + IngestSession) by crate::origin::supervisor::supervise_driver. advance_route is the one per-iteration call every driver-backed run_* in this module makes (and that a SchemeRegistry-registered Custom factory’s own driver loop must make too — see examples/custom_scheme.rs); it is pub for exactly that reason, not just for this crate’s own in-tree sources. report_driver_progress/segment::drive_program_segmenters are the two steps it bundles — both pub(crate) (issue #805 task 6 narrowed them back from pub; see advance_route’s own doc for why one call replaced two). http_auth is shared auth glue for the HTTP-based sources (issue #663 P3c).