What is MPEG-TS?

How a transport stream works

A transport stream is a sequence of 188-byte packets, each starting with the sync byte 0x47. A packet header carries a PID — a number saying which track the packet belongs to: this video stream, that audio stream, the tables describing them. A receiver sorts packets by PID and reassembles the tracks. Inside the packets ride the actual codecs — typically H.264 or HEVC video with AAC, AC-3, or MP2 audio.

The design goal was broadcast: a television tuning in mid-transmission has no file header to consult, so the stream repeats its bookkeeping tables and marks safe joining points as it goes. That’s the practical difference from a container like MP4, which is a file with an index — a transport stream is an endless ribbon you can cut into anywhere. It’s why the same format still carries live TV forty years of codecs later.

It’s also the same container DVB satellite, cable, and terrestrial broadcasts use — one reason IPTV channels, often re-broadcasts of those signals, arrive already wrapped in it.

Browsers can’t play raw MPEG-TS. A web player has to demux the packets and repackage the tracks into fragmented MP4 before the browser’s own decoder will touch them.

The fixed packet size is the point. On a lossy link, one corrupted packet costs 188 bytes and the stream carries on; a format built from long, variable-length records would lose far more. Timing rides inside too — the stream carries its own clock references, so a receiver can pace playback and hold audio and video in step without asking anything upstream.

In Twiga

Most channels arrive as MPEG-TS, and the format’s envelope/payload split is exactly where Twiga draws its privacy line. The relay reads only a few framing bytes at the head of each packet — enough to forward the stream — and never parses the payload, which is what makes it a blind relay.

Everything else happens in your tab: the browser demuxes the packets, remuxes the tracks into fragmented MP4, and hands them to your device’s hardware decoder.