Delivering Live TV Over HTTP: Supporting Advanced Modern Delivery Formats

Live streaming is a pipeline problem. Most platforms treat each format — HLS, DASH, low-latency, bare MPEG-TS — as a separate deployment with its own ingress, encoding, and delivery stack. Muvie runs all of them from a single channel configuration, with upstream fail over baked in at every layer and no external CDN required. ABR is Adaptive Bit Rate, When Viewers Device does not have strong internet connectivity, it switches to a lower quality/bitrate stream. We transcode and create multiple qualities of same stream which becomes selectable qualities at viewers end considering their internet speed.

One Ingest, Every Output

We can Ingest RTMP, RTSP, MPEG-TS

Single Stream can have multiple upstream, We fail over automatically if there is problem with one specific upstream automatically.

Output Formats

MPEG-TS:

Still Widely used at production cable television. super resilient but single quality for video. it is possible to have multiple video tracks but no real benefits due to player has to download full stream, so no proper ABR.

• ABR: NO
• Latency: 1-2 seconds.
• Codecs Video: H264, H265
• Codecs Audio: AAC-HE, AAC-LE, AC3, AC4, EAC3
• Transcoding: Partial (only audio normalization)
• Scalablity: multi viewers from Muvie, Edge cache not supported from nginx or else.

Transcoding: Partial support added because most of streams play natively in most browsers, only interlaced streams do not play on Apple Devices. encoder should not output Interlaced streams.

it is Possible to add transcoding support, but at muvie, we did not add transcoding support for MPEG-TS, transcoding support is partial, only audio is normalized at muvie. it could be used for Streams Which need extremely Low latency.

HLS:

Developed by Apple Still the most wide support on electronic distribution format.

• ABR: YES
• Latency: 15-30 seconds, segment duration configurable.
• Codecs Video: H264, H265
• Codecs Audio: AAC-HE, AAC-LE, AC3/AC4/EAC3(only on supported devices, could be transcoded to AAC)
• Transcoding: Full support
• Passthrough: Full Support
• Scalablity: multi viewers from Muvie and also, Full Support for Edge cache from Nginx alike fanout.

DASH:

Developed by MPEG consortium. Dash is now widely used and natively supported in most of platforms, Apple does not support DASH natively, but it can be played with DASH.js in frontend web players(Tested).

• ABR: YES
• Latency: 15-30 seconds, segment duration Configurable.
• Codecs Video: H264, H265
• Codecs Audio: AAC-HE, AAC-LE, AC3/AC4/EAC3(only on supported devices, could be transcoded to AAC)
• Transcoding: Full Support
• Passthrough: When format has proper NAL and GOP.
• Scalablity: multi viewers from Muvie and also, Full Support for Edge cache from Nginx alike fanout.

LL-HLS:

Apple added support for low latency HLS recently in 2020. We support byte-range based growing segments also multiple micro fragments too.

• ABR: YES
• Latency: 3-10 seconds, segment duration and fragment duration configurable.
• Codecs Video: H264, H265
• Codecs Audio: AAC-HE, AAC-LE, AC3/AC4/EAC3(only on supported devices, could be transcoded to AAC)
• Transcoding: Full Support
• Passthrough: When format has proper NAL and GOP.
• Scalablity: multi viewers from Muvie and also, Full Support for Edge cache from Nginx alike fanout.

LL-DASH:

• ABR: YES
• Latency: 3-10 seconds, segment duration and fragment duration configurable.
• Codecs Video: H264, H265
• Codecs Audio: AAC-HE, AAC-LE, AC3/AC4/EAC3(only on supported devices, could be transcoded to AAC)
• Transcoding: Full Support
• Passthrough: When format has proper NAL and GOP.
• Scalablity: multi viewers from Muvie and also, Edge nginx cache not supported due to chunked encoding which is per viewer socket write in small chunks.

No additional Complexity is needed to have ABR streams. They are directly configurable and outputted in streams. Latency at player shows a bit high sometimes in LL-HLS/LL-DASH just because all players add a small cache. LL-DASH is a bit forgiving for a bit slower CDN/Networks. LL-HLS needs very capable CDN and network to work with. You can watch Akamai Talk on this here.

Super-Resilient Upstream Failover:

Every channel defines a primary upstream URL and an ordered list of alternative upstream URLs. These are not just DNS fallbacks — they are fully independent stream sources, potentially served by different providers, in different regions, with different codec configurations.

The fetcher maintains a failure counter per candidate. On connection errors, HTTP 5xx responses, or stream corruption, it rotates to the next candidate. Candidates that fail repeatedly are penalised with an exponential backoff, preventing the fetcher from oscillating between two broken sources. A candidate that recovers and serves clean data for a sustained period has its penalty cleared.

This rotation happens hot— without tearing down the downstream pipeline. The upstream HTTP connection is swapped under the buffered input layer, so the transcoder and packager never see a disconnection. They receive a continuous byte stream regardless of which upstream source is currently active.

Inactive alternative URLs are tracked separately. They can be re-enabled without editing the active list, making it safe to designate backup sources that should only be used when the primary chain is exhausted.

Fanout Chunk Distribution:

Inside every relay node, the fetcher reads the upstream TS stream in configurable chunk sizes and pushes them into a buffered fanout channel. Multiple consumers — the transcoder, the packager, the bare TS passthrough — all read from the same byte source without creating separate upstream connections.

The input buffer is configurable per channel: chunk size (how many bytes to read per fetch),

buffer depth (how many chunks to hold in memory), and flush interval (how often to push accumulated bytes downstream). This lets operators tune for latency (smaller buffers, faster flushes) or stability (deeper buffers absorb upstream jitter).

When upstream sources swap, the buffer drains the old connection's remaining bytes before seamlessly switching to the new source. Downstream consumers see an uninterrupted byte stream with no gaps or duplication.

We can add support to additional formats but at current landscape only certain devices support Hardware Encode and Decode of AV1/VP8/VP9. our encoder pipeline does support software transcoding, but We believe Without Hardware transcoding support the CPU transcoding cost without GPU is not a sufficient factor to add support. We can have multiple 4K High bitrate HDR Streams in ABR transcoding simultaneously with current GPU transcoding pipeline with nearly 1-2s added latency or even less.