Streaming Protocols: HLS, LL-HLS, MPEG-TS and RTMP

XUI.live delivers every channel from a single source in whatever protocol the viewer’s player speaks. This page explains what each one is, why it exists, and — for the low-latency path — how much closer to live it gets you.

The four protocols

HLS — the universal default

HLS (HTTP Live Streaming) chops a channel into short files and lists them in an .m3u8 playlist the player fetches over ordinary HTTP. Because it is just files over HTTP, it plays everywhere — smart TVs, phones, browsers, every modern app — and passes through any CDN or cache without special handling.

The trade is latency. A player buffers several segments before it starts, so with the default six-second segment length a viewer sits comfortably behind live. That is invisible for a film and fine for most channels; it only matters when behind live is a problem — sport, news, anything a viewer might also be watching on air.

MPEG-TS — the set-top-box classic

MPEG-TS delivers one continuous transport stream over HTTP rather than a playlist of files. It is the long-standing format for set-top boxes and desktop players, starts fast, and holds a steady low latency because there is no multi-segment buffer to fill. Where HLS optimises for reach, MPEG-TS optimises for immediacy on the devices built around it.

RTMP — the legacy and the ingest path

RTMP is the older streaming protocol, still spoken by a long tail of players and — more usefully today — by encoders and pipelines that publish into a panel. XUI.live serves RTMP for the players that need it and accepts RTMP push and pull for ingest, guarded by an authorised-IP list.

LL-HLS — low latency, kept universal

LL-HLS (Low-Latency HLS) is the newest output, and the reason this page exists. It keeps everything that makes HLS worth using — plain HTTP, plays everywhere, caches cleanly — while cutting the delay to live down to a few seconds.

How LL-HLS works here

Classic HLS is slow because its segments are long: the player will not start until it has buffered a few of them, and at six seconds each that is a wall of delay built in before a frame plays.

XUI.live’s LL-HLS attacks exactly that. It produces a second, parallel output in fMP4 — an .m4s segment stream with an init segment — at a target segment length of half a second to one second instead of six. Shorter segments mean a shorter buffer, and a shorter buffer means the viewer sits seconds behind live instead of tens of seconds. The classic HLS and MPEG-TS outputs keep running alongside it untouched, so enabling LL-HLS adds a fast path without taking anything away from compatibility.

It is low latency achieved the robust way — through short fMP4 segments over standard HTTP — so it inherits HLS’s universal reach and CDN-friendliness rather than trading them for a fragile edge. A player that speaks it gets close to live; a player that does not still has classic HLS and MPEG-TS to fall back on.

Where to enable it

LL-HLS is a panel-wide switch: Settings → Streaming → Enable LL-HLS Output. Turning it on generates the fMP4 output for your live channels in addition to the classic ones. Three dials tune it, right below the switch:

• LL-HLS segment time — the target segment duration, recommended between 0.5 and 1.0 seconds. Lower is closer to live; too low and weak connections start to struggle.
• LL-HLS list size — how many segments the playlist holds.
• LL-HLS delete threshold — how many old segments to keep before cleanup.

The other three outputs are governed where delivery is decided — outputs and playlists covers the per-line and per-package switches, and the global enable/disable for HLS, MPEG-TS and RTMP.

Choosing per channel

There is no single right protocol — there is the right one per audience:

Because all four come from one source, you are not choosing once for the whole panel — a sports package can lead with LL-HLS while a movie library stays on classic HLS, and every subscriber’s player simply asks for the format it wants.