TS / M2TS
Built for broadcast, where the receiver may join halfway through and nothing has an end.
MPEG Transport Stream is what television is transmitted as. It is designed so a receiver can start decoding at any moment and recover from lost data, which makes it excellent over the air and awkward as a file: there is no index, so seeking is a guess, and durations are often wrong or missing entirely.
30 July 2026
Opened without help by
Neither system opens a .ts or .m2ts file, though both decode the H.264 or HEVC inside it perfectly well once something else has unwrapped it. The wrapper is again the obstacle.
The facts
| Full name | MPEG-2 Transport Stream |
|---|---|
| Kind | Container, designed for transmission rather than storage |
| Extensions | .ts, .m2ts, .mts, .m2t |
| Published | 1995, as part of MPEG-2 |
| Packet size | 188 bytes, fixed — small enough that a corrupted one loses almost nothing |
| Video inside | MPEG-2 on older broadcasts, H.264 and HEVC on newer ones |
| Audio inside | AC-3, E-AC-3, AAC, MP2 |
| Index | None. Nothing in the file says where any given moment lives |
| Where it comes from | IPTV streams, DVB and ATSC recordings, AVCHD camcorders, Blu-ray discs |
A format with no beginning
Every other container here assumes you have the whole file and can read its header first. Transport Stream assumes the opposite: that you have tuned in partway through a broadcast that started before you arrived and will continue after you leave. So it repeats everything a decoder needs — the stream layout, the timing references, the parameters — every fraction of a second, forever.
The 188-byte packets are the same idea. Interference destroys a packet; the decoder loses a few milliseconds and carries on. A format built around one large index would lose the entire rest of the file.
This is genuinely good engineering for its purpose, and it is the wrong shape for a file sitting on a disk. Everything that makes a broadcast resilient makes a recording clumsy.
Why a recording behaves oddly
Without an index, a player that wants the 47-minute mark has to estimate: multiply the bitrate by the time, jump roughly there, hunt for the next decodable frame. On a constant-bitrate broadcast this lands close. On a variable-bitrate recording it can be seconds out, and on a recording spliced from an interrupted stream it can be minutes out.
The duration has the same origin. A player has to either read the whole file to find out how long it is or guess from the bitrate. That is why a recording sometimes shows a wrong length, or none, and why the scrub bar can be a work of fiction.
The repair is remuxing: read the stream once, and write the same video and audio into an MP4 or MKV with a real index. Nothing is re-encoded, quality is untouched, and it runs at disk speed. Afterwards seeking is instant and exact, because the file finally knows where its own frames are.
What to do with one
- Play it directly if you only want to watch it
A player with its own demuxer opens a .ts without any preparation. Seeking will be approximate — that is the format, not the player — but for watching something through, it is fine.
- Remux to MP4 or MKV if you are keeping it
Fast, lossless and it fixes seeking and duration permanently. For anything going into a library rather than being watched once, do this.
- Leave IPTV streams alone
When TS arrives as a live stream rather than a file, none of this applies: there is nothing to index because nothing has ended. Buffering there is a network question.
Questions about this format
Nearby formats
Your library, finally in one place.
Free to download. No account, no sign-up, nothing to hand over.