Skip to content
PhramePhrame

egress — Deliver Anywhere

egress — Deliver Anywhere

Section titled “egress — Deliver Anywhere”

Whatever you produced needs to reach its audience — a file, a stream, a browser, another facility. Phrame’s egress services take live frames off the bus and deliver them in whatever formats you need, at once.

egress — deliver anywhere frame busVDI / MXL output-processorre-encode · tee file — MP4 / MOV / MKV RTP · RTMP · SRT WebRTC (WHIP) NDI hls-encoder HLS.m3u8 + .ts / .m4s outputs fan out via tee · rtp-streamer provides dedicated RTP egress

Why it matters

Section titled “Why it matters”

Distribution is where broadcast meets the real world, and the real world wants many formats at once — a recording, a contribution feed, a browser preview, a hand-off to another system.

  • One production, many destinations. File, RTP/RTMP/SRT, WebRTC, NDI, and HLS — simultaneously, from the same live output.
  • Re-encode only when you must. Passthrough where possible; a configurable codec chain where you need it.
  • Fan out freely. A single output can tee to several destinations at once — record while you stream while you monitor.
  • Standards and the web. SRT for contribution, WebRTC (WHIP) for low-latency browser delivery, HLS for scale, NDI for the local LAN.

In one line: produce once, deliver everywhere — recording, streaming, and web, in parallel.

How it works

Section titled “How it works”

Three services share the egress role:

ServiceDelivers
output-processorThe general egress: file (MP4/MOV/MKV), RTP/RTMP/SRT, WebRTC (WHIP), NDI, raw YUV, and tee fan-out.
hls-encoderReads a VDI video stream, encodes H.264, and writes an HLS .m3u8 playlist plus .ts/.m4s segments for HTTP delivery.
rtp-streamerDedicated RTP egress.

output-processor is configured by a JSON file with four sections — inputs, compressors, outputs, pipelines. A pipeline binds one input through an ordered list of compressors to one output; an empty compressor list means passthrough. Outputs are typed:

  • file → path; rtp/rtmp/srt → url (e.g. srt://0.0.0.0:9998?mode=listener); webrtc → ice_servers (WHIP); ndi → url; yuv → path; tee → a list of child outputs.

It can run static (all pipelines from the file) or in controller mode, subscribing to a live MQTT config topic and publishing state.

Full field reference: output-processor config — every field, type, default, and description (including all nine output types), generated from the JSON Schema.

hls-encoder is configured purely by environment (VDI_INPUT_UUID, HLS_OUTPUT_DIR, …); the encoding parameters themselves live in the HLS plugin. It typically shares /dev/shm and the IPC namespace with the VDI producer container.

Under the hood

Section titled “Under the hood”
  • output-processor — Rust. pipeline.rs wires a FrameSource → compressor chain → N OutputSinks with a graceful drain→flush→join shutdown. Inputs (vdi.rs/mxl.rs) and outputs (file, network, webrtc via str0m WHIP, wep, ndi, yuv, tee, null) implement common traits; controller.rs reconciles pipelines keyed on (input_id, compressor_ids, output_id). Video compression uses FFmpeg with rayon YUV conversion.
  • hls-encoder — Rust (hls-server). main.rs retries opening the VDI stream (up to 100× at 500 ms), reads with a 5 s timeout, and drives libplugin-hls.so via hls_writer.rs.
  • Plugins. All egress uses the same C ABI plugin loading as the rest of the pipeline — see Frame bus & plugins.

MQTT topics (output-processor): {prefix}/config (subscribed, retain recommended), {prefix}/state (per-pipeline counts/drops/bitrates), {prefix}/registered (once at startup).

Part of the Phrame documentation system — one Markdown source, four audiences, a code-generated house-style diagram.