HLS2SRT / Contribution Gateway

SOURCE REVIEWED C++ IMPLEMENTATION

Adaptive input. Contribution-grade transport.

HLS2SRT selects HLS services, remuxes their elementary streams into MPEG-TS and delivers SPTS or MPTS over SRT and UDP—without forcing a decode and re-encode cycle.

CONTRIBUTION PATH / ACTIVEREMUX / NO RE-ENCODE
ADAPTIVE INPUTHLS master / variantPrograms · renditions · audio tracks
HLS2SRT COREProbe · Select · RemuxFFmpeg · MPEG-TS · timestamp policy
01 / SPTSSRTCaller / listener
02 / SPTSUDPUnicast / multicast
03 / MPTSProgramsMulti-source multiplex
INPUT-DERIVED CODECSCONTRIBUTION-GRADE TRANSPORT
No re-encodePacket-level remultiplexing
SRT + UDPMultiple transport destinations
SPTS + MPTSSingle or multi-program output
C++23 + FFmpegPerformance-oriented media core
HLS2SRT is a transport gateway—not a transcoder.

Resolution, codec and bitrate come from the selected HLS input. Use the CDN++ transcoding fabric when a new adaptive-bitrate ladder is required.

End-to-end remux path

Preserve the media. Change the transport.

The source code establishes a clean contribution boundary: inspect the adaptive input, choose deliberately, normalize it for MPEG-TS and hand the result to the required network protocol.

  1. 01INPUT

    Open + inspect HLS

    Read media or master playlists, inspect the available streams and identify the video, audio and program context that should enter the contribution path.

    MASTER · VARIANT · MEDIA
  2. 02POLICY

    Select the service

    Choose the required program and audio language instead of carrying every rendition or track by accident.

    PROGRAM · AUDIO · LANGUAGE
  3. 03REMUX

    Normalize transport

    Map the selected elementary streams into MPEG-TS and apply H.264 or HEVC Annex-B bitstream conversion when the source requires it.

    NO RE-ENCODE
  4. 04OUTPUT

    Send over SRT or UDP

    Operate SRT in caller or listener mode, or use managed UDP destinations including unicast and multicast network paths.

    SRT · UDP
  5. 05OPERATE

    Queue + recover

    Use producer queues, a dedicated writer and explicit reconnect behavior to keep input work separated from the output transport.

    BOUNDED QUEUE · RECONNECT
SINGLE-PROGRAM PATHOne HLS service → one SPTS → many destinations

Useful for contribution handoff, protocol conversion and operational fan-out.

MULTI-PROGRAM PATHMany HLS sources → AVPrograms → one MPTS

Useful when independent inputs need a shared MPEG-TS contribution multiplex.

Four implementations in one code family

Choose the operating model—not a marketing abstraction.

The supplied project contains several executable directions. They share the same media idea but target different operational roles.

MODE / 01SOURCE REVIEWED

Desktop monitor + mirror

A Dear ImGui, OpenGL and SDL2 application plays the selected HLS feed locally while optionally remuxing the same packets to an SRT destination.

  • Local video and audio monitoring
  • Optional SRT mirror
  • Playback continues if transport is unavailable
MODE / 02SOURCE REVIEWED

Headless SPTS fan-out

A compact service converts one HLS input into MPEG-TS and writes it to one or more SRT or UDP destinations without a decoding and encoding cycle.

  • One selected service
  • Multiple destinations
  • SRT caller or listener
MODE / 03SOURCE REVIEWED

Multi-source MPTS gateway

Multiple HLS sources become separate MPEG-TS programs inside one multiplex, with program metadata, paced packet writing and reconnection logic.

  • One AVProgram per source
  • Video, audio, subtitle and data mapping
  • Dedicated multiplex writer
MODE / 04ENGINEERING TRACK

Broadcast + hybrid output

Experimental variants extend the multiplex toward simultaneous SRT clients and a local segmented-HLS output. They demonstrate direction, not finished production scale.

  • Multiple SRT clients
  • SRT plus local HLS prototype
  • Explicit production-hardening boundary

What the supplied code establishes

Implementation evidence, not feature inflation.

These capabilities come directly from the attached C++ sources. Prototype branches are identified separately from the reviewed core.

01 / SOURCE REVIEWED

FFmpeg media core

libavformat, libavcodec and libavutil handle stream inspection, packet mapping, bitstream filters, timestamp rescaling and MPEG-TS output.

C++23 · LIBAVFORMAT · LIBAVCODEC
02 / SOURCE REVIEWED

Protocol-neutral output

The same remux path can feed SRT or UDP destinations, keeping transport policy separate from codec and program selection.

SRT CALLER / LISTENER · UDP
03 / SOURCE REVIEWED

Single and multi-program TS

The code supports one selected service as SPTS and aggregates independent sources as programs inside an MPTS.

SPTS · MPTS · AVPROGRAM
04 / SOURCE REVIEWED

Concurrent media flow

Per-program producers, bounded queues and a dedicated writer provide a practical base for isolating ingest timing from multiplex output.

PRODUCERS · QUEUE · WRITER
CODEC BOUNDARY

Remuxing is fast because it does not invent a new rendition.

H.264 and HEVC streams may be converted to Annex-B framing for MPEG-TS compatibility, but their encoded picture content remains unchanged. There is no hidden quality ladder, resolution change or bitrate reduction inside HLS2SRT.

Production boundary

Good media plumbing still needs deterministic operations.

The supplied implementations prove the transport architecture. The next engineering phase turns that proof into a secure, observable and supportable 24×7 gateway.

  1. 01

    Normalize PTS, DTS and PCR across independent HLS timelines and discontinuities

  2. 02

    Isolate destination backpressure so one slow output cannot stall every client

  3. 03

    Externalize program, audio-language, URL and transport policy into validated configuration

  4. 04

    Add SRT passphrase, stream ID, access policy and secret-management boundaries

  5. 05

    Expose bitrate, queue depth, packet age, reconnect and loss/retransmission metrics

  6. 06

    Define bounded drop, restart and recovery behavior for 24×7 unattended operation

HLS2SRT + CDN++

A contribution component inside a larger media system.

HLS2SRT brings existing adaptive HTTP streams into a managed MPEG-TS contribution path. CDN++ can then separate programs, build GPU or CPU ABR ladders, package HLS and apply origin and delivery policy.

Open the CDN++ processing architecture
01 / CONTRIBUTEHLS2SRTHLS → MPEG-TS → SRT / UDP
02 / PROCESSCDN++Program route → ABR → package
03 / DELIVERSPICA EdgeOrigin → cache → HTTP / operator path

SPICA Networks engineering

Move the right program through the right transport.

Talk to Engineering