TS file video: what it is and what plays it

What a TS file actually is

TS is an acronym for transport stream. The full name is MPEG transport stream, and it is a container format: a wrapper that holds compressed video and audio together with the timing information needed to play them in step. A TS file video is therefore ordinary video in an unusual wrapper. It is not a codec. Nothing inside is encoded differently because the wrapper is this one rather than another.

What makes it unusual is what it was designed for. Most containers assume a complete file sitting on a disk, with an index at one end describing everything in it. Transport stream assumes the opposite: that you are joining something already in progress, over a link that may drop bytes, with no chance to ask for them again. So it repeats its timing and format information every few frames, which is why you can point a player at the middle of a broadcast and get a picture within a second rather than an error.

That design decision explains everything below.

Why you ended up with one

Three common routes, and they feel quite different from the outside.

Broadcast is the original one. Digital television carries transport streams, so a recording made by a set-top box or a tuner card usually lands as .ts. These tend to be large, and they often contain more than you expected: several audio tracks, subtitle streams, and sometimes a few seconds of whatever was on before the recording started.

Streaming is the route most people arrive by now. HTTP Live Streaming cuts video into short pieces, and those pieces are transport streams. A folder of files named segment0.ts, segment1.ts and onward is not a collection of videos. It is one video, in slices, and the playlist that lists them in order is the part that makes them a film rather than a heap.

The third route is a download tool that saved the pieces and never joined them up. Same folder, same puzzle, and the section at the end deals with it.

What plays a TS file

A desktop media player is the short answer. VLC opens them without complaint, as do most players built on the same underlying libraries, and no conversion step is needed first.

Video editors are fussier. Many will import a transport stream and then behave oddly on the timeline, because the format carries timing in a way that assumes a live signal rather than a clip with a definite start. If an editor stutters or reports a strange duration, that is usually why, and remuxing to another container first is the normal fix.

Browsers are the awkward case, and worth understanding rather than working around.

Why a browser will not open one directly

Hand a browser a .ts file and it will usually offer to download it. That is not a fault. Browsers natively play a short list of containers, and transport stream is not on it, for the good reason that it was designed for broadcast rather than for the web.

What a browser can do is play the segments as part of a stream. A JavaScript player fetches each piece, unpacks the video and audio out of the transport stream wrapper, and hands the result to the video element in a container the browser does accept. That repackaging is invisible and happens continuously while you watch, which is why HLS works in a browser that would refuse the very same segment if you opened it on its own.

So a single segment is not much use by itself. The playlist is what turns the pieces into something playable, and without it you have a fragment of a few seconds with no idea where it belongs.

A folder full of segments

This is the situation that sends most people looking. Hundreds of small files, numbered, none of them playing more than a few seconds.

They join. Transport stream is one of the few containers you can concatenate directly, because each segment repeats the information a decoder needs rather than relying on a header at the front of the file. Order matters, and numeric order is not always what a file manager shows you: segment10.ts sorts before segment2.ts alphabetically, which produces a video that jumps about for no obvious reason.

The tool for this is ffmpeg, and the operation you want is a remux rather than a re-encode. Remuxing moves the existing video and audio into a different container untouched, so it is fast and loses nothing. Re-encoding decodes and compresses again, which takes far longer and makes the result slightly worse every time. If a piece of software offers to convert your file and takes an hour over it, it is doing the second thing, and for this job it did not need to.

We do not convert video here, and this page is not going to pretend otherwise. The playlist tools on this site work on the lists, not on the media they point at.