What is a TS file?

TS is a stream format, written and read from front to back. It is used for broadcast and streaming.

The extension is .ts, and the full name is MPEG Transport Stream. Both matter less than what the file can hold, which is what the rest of this page is about.

MPEG published it in 1995. The specification is ISO/IEC 13818-1.

A format that has been readable for that long is a format worth trusting with something you want back in ten years.

It is published in full, so anyone can implement it from the document rather than by inspection, which is why it turns up in so many programs and why files written twenty years ago still open. A published specification is not the same thing as a royalty-free one: where a format wraps a codec, the patent licensing is a separate question the standard does not settle.

TS can hold several audio tracks, subtitle tracks and a layout that lets it start playing before it has finished arriving.

That matters mostly when converting: whatever the target cannot hold is dropped, usually without a warning.

VLC and FFmpeg read it, and so do most programs of the same kind.

If a file will not open, the format is rarely the problem — it is more often that the program predates it. Converting to something older is the reliable way past that, and it is what the rest of this site is for.

No browser reads it.

That is the single most common reason to convert it: not that the format is bad, but that the place you want to show the file cannot read it.

TS is meant to be handed over rather than worked in. Editing one is possible and rarely pleasant; the sane approach is to change the source and export again.

A transport stream is designed around one assumption: that it will be received badly. It was specified for digital television, where a receiver might tune in halfway through, lose signal for two seconds, and have to carry on as though nothing happened.

So the data is cut into fixed 188-byte packets, and everything needed to start decoding is repeated over and over rather than written once at the beginning. Tune in at any moment and within a fraction of a second the receiver has found the packet boundaries, the stream descriptions and a keyframe. That redundancy is the whole design, and it is why the format behaves so unlike a normal video file.

Three sources cover almost everything. A television recording, from a set-top box, a tuner card or a channel captured over the air. A camcorder: AVCHD writes .mts or .m2ts files into a structured folder on the card, and Sony, Panasonic and Canon consumer camcorders have done so for years. Or a stream downloaded from the web, since HLS — the delivery method behind most online video — cuts its video into short transport-stream segments.

In every case the file is a byproduct of how the video travelled rather than a choice anybody made. That is worth knowing, because it means nothing about the format was selected for editing or archiving, and neither is a job it does well.

A transport stream is a container. What it holds is normally H.264 video with AC-3 or AAC audio, which is exactly what an MP4 holds. The picture is not in some broadcast-specific encoding that has to be translated — it is the same encoded video, wrapped differently.

This is the single most useful fact about the format, because it means MKVToolNix or ffmpeg can unwrap the streams and rewrap them into an MP4 in seconds, losing nothing. That is not what happens here: this converter hands the encoder a bitrate, and a requested bitrate is exactly what disqualifies a packet copy, so the picture is decoded and encoded again. For a broadcast recording or a camcorder card, the desktop tool is the better instrument and this page would rather say so.

Because the format has no index. An MP4 carries a table saying where every frame is, so a player can jump to eleven minutes instantly. A transport stream has nothing of the kind — seeking means scanning for the next entry point, which is why scrubbing through a recording is sluggish and why some editors refuse the format outright or import it painfully slowly.

The other complication is timestamps. Broadcast timestamps wrap around after about 26 hours and can jump when a broadcaster splices in an advertisement, so a recording can contain time going backwards. Robust players cope; less robust ones show a wrong duration, refuse to seek past the discontinuity, or lose audio sync at exactly that point.

A .ts file is the plain transport stream, usually from a tuner or a downloaded segment. A .m2ts is the same thing with a four-byte timestamp added to each packet, which is what Blu-ray uses. An .mts is what a consumer camcorder writes to its card — structurally an m2ts under a different name.

Practically they are the same format and the same tools read all three. If a program accepts one and refuses another, renaming the file is worth trying before anything else; it works more often than it should.

A broadcast stream can hold several audio tracks — the original language, a dub, an audio description — as well as subtitles and, in older European recordings, teletext. All of it survives in the file, and most of it is discarded silently by whatever you convert with, because the target format either cannot hold it or was not asked to.

If a recording has subtitles or a second audio track you care about, check for them before converting and convert with a tool that is told to keep them. Recovering them afterwards means going back to the original recording, which people generally discover after deleting it.

Copy the whole card structure, not the individual files. AVCHD stores the video in a subfolder alongside index files that record clip order, dates and, on some cameras, information the editor needs. Dragging out only the .mts files loses that, and it is unrecoverable.

Then remux to MP4 with ffmpeg or MKVToolNix for anything that has to be edited, shared or kept. Modern editors handle MP4 better than AVCHD, the picture survives a remux untouched, and the result is a file that will still open in software that has never heard of camcorders.