MTS File Documentation

---

Technical details

Feature	Value
Full name	AVCHD Video (MPEG-2 Transport Stream)
File extension	.mts
MIME type	video/mp2t
Format type	MPEG-2 Transport Stream container (binary)
Video codec	H.264/AVC (720p, 1080i, 1080p)
Audio codec	Dolby Digital (AC-3) or linear PCM
Developer	Sony & Panasonic (AVCHD consortium)
Introduced	AVCHD announced 2006
Packet size	188 bytes (fixed TS packet)
Sync byte	0x47 at offset 0 and every 188 bytes
Byte order	Big-endian
Open standard	Partial (built on ISO/IEC 13818-1 MPEG-2 TS; AVCHD licensed)
Program tables	PAT / PMT describe the streams inside
Camera folder	PRIVATE/AVCHD/BDMV/STREAM
Sidecar metadata	CLIPINF, PLAYLIST, AVF_INFO (outside the .mts)
Disc variant	.m2ts (192-byte packets, 4-byte timecode prefix)
Related extensions	.m2ts, .ts, .mp4, .mov, .m4v
Specification	en.wikipedia.org/wiki/MPEG_transport_stream

What is an MTS file?

MTS is the file extension a camcorder writes when it records AVCHD video, the high-definition consumer format Sony and Panasonic announced in 2006 and Canon, JVC and others later adopted. The letters stand for “MPEG Transport Stream”. Inside, an .mts file is an MPEG-2 Transport Stream (the same container broadcast television uses) carrying an H.264/AVC video track at 720p, 1080i or 1080p and an audio track encoded as Dolby Digital (AC-3) or linear PCM. Its MIME type is video/mp2t.

The transport-stream container was chosen because it is built for real-time recording and tolerates dropped or corrupted data: a player can resynchronise on the next packet boundary instead of losing the whole file. That resilience matters when video is being written to a memory card as you film. The container is defined by ISO/IEC 13818-1 (MPEG-2 Systems); the H.264 video it carries is ISO/IEC 14496-10. Everything below is about how those 188-byte packets are laid out and how a demuxer pulls the picture and sound back out of them.

The 188-byte packet: sync byte, PID and the four-byte header

A transport stream is not a file with one header at the front. It is a flat, endless-looking sequence of fixed 188-byte packets, each of which is completely self-locating. Every packet opens with a 4-byte header, and the remaining 184 bytes hold the payload (optionally preceded by an adaptation field).

TS packet header (4 bytes, big-endian)
 byte 0        : 0x47                      sync byte (always 'G')
 byte 1 bit 7  : transport_error_indicator
 byte 1 bit 6  : payload_unit_start_indicator
 byte 1 bit 5  : transport_priority
 byte 1-2 (13b): PID                       which stream this packet belongs to
 byte 3 bit 7-6: transport_scrambling_control
 byte 3 bit 5-4: adaptation_field_control  payload / adaptation / both
 byte 3 bit 3-0: continuity_counter        0-15, increments per PID

The first byte is always 0x47, the sync byte. Because packets are a fixed 188 bytes, a reader that finds 0x47 and sees it recur exactly 188 bytes later, again and again, has locked onto the stream: that recurring interval is the real structural fingerprint of an MTS file, since transport streams carry no single file-magic at offset 0. The 13-bit PID (packet identifier) is the key field. It labels which elementary stream the packet carries, so the video packets, the audio packets and the metadata tables are interleaved on one wire and separated purely by PID. The payload_unit_start_indicator flags the packet that begins a new PES packet, and the 4-bit continuity_counter cycles 0–15 per PID so a demuxer can detect a dropped packet.

PAT and PMT: finding the streams inside

Since one transport stream can multiplex several programs, a player needs a directory to know which PIDs hold what. That directory is the Program Specific Information, and it bootstraps from a fixed address.

PID 0x0000  PAT (Program Association Table)
             lists each program_number -> PID of its PMT
PID (from PAT)  PMT (Program Map Table)
             lists, for one program:
               stream_type 0x1B -> PID of the H.264 video
               stream_type 0x81 -> PID of the AC-3 audio
               PCR_PID          -> which PID carries the clock

A demuxer always starts at PID 0x0000, which by definition carries the Program Association Table. The PAT maps each program number to the PID of that program’s Program Map Table. The player then reads the PMT, which finally names the elementary streams: a stream_type of 0x1B marks the H.264 video PID, and an AC-3 audio track is signalled by 0x81. The PMT also names the PCR_PID, the stream that carries the Program Clock Reference. Without walking PAT then PMT there is no way to know which PID is the picture, which is why these tables are repeated throughout the file rather than written once.

PCR, PTS and DTS: keeping picture and sound in step

Transport streams solve timing differently from a file-based container like MP4, which stores a sample table up front. A transport stream is meant to be decoded as it arrives, so timing is embedded in the stream itself. The Program Clock Reference is sampled from a 27 MHz system clock and inserted periodically in the adaptation field of the PCR_PID; the decoder locks its own clock to these values. Individual frames then carry a Presentation Time Stamp (PTS) and, when frames are reordered, a separate Decode Time Stamp (DTS) in their PES headers, measured against a 90 kHz clock derived from the PCR. B-frames in H.264 are decoded before they are shown, so PTS and DTS diverge exactly as they do in MP4’s ctts table, but here the offsets ride inside the stream instead of a lookup table.

PES packets and the H.264 payload

The coded video and audio do not sit raw in the transport packets. Each elementary stream is first cut into Packetized Elementary Stream (PES) packets, and those PES packets are then sliced across the 184-byte payloads of many transport packets. A PES header carries the stream ID and the PTS/DTS for the access unit that follows. Reassembling one video frame therefore means collecting every TS packet with the video PID from the payload_unit_start_indicator of one PES packet up to the start of the next, stripping the 4-byte TS headers, and concatenating the payloads. The result is an H.264 Annex B byte stream: NAL units separated by 00 00 00 01 start codes, with the SPS and PPS parameter sets that a decoder needs to initialise. This is a real structural difference from MP4, where H.264 is stored length-prefixed with parameter sets held separately in an avcC box. Remuxing MTS to MP4 has to rewrite that framing, which is why the operation is not a plain byte copy even though the coded picture is identical.

The AVCHD folder and spanned clips

On the camera’s card an MTS clip does not live alone. AVCHD defines a fixed directory tree, PRIVATE/AVCHD/BDMV/STREAM, where the numbered .mts files sit, alongside management folders CLIPINF, PLAYLIST and AVF_INFO that index the clips, record their order and dates, and tie together recordings that were split across several files. Cameras split a long take at a size limit (historically the 4 GB FAT32 ceiling), so one continuous recording can span several numbered MTS files that only the index knows belong together. Copying just the raw .mts files, without the whole AVCHD folder, discards that spanning and metadata, which is why editors often ask you to import the entire folder rather than a single clip. Sony writes its per-clip index as small binary sidecars such as .modd/.moff and the .bnp catalogue in AVF_INFO.

MTS versus M2TS versus TS

The same AVCHD stream appears under three extensions that differ only in packet framing. A plain TS broadcast file uses the bare 188-byte packet described above. An M2TS file, the form burned to Blu-ray and AVCHD discs, prefixes every packet with a 4-byte arrival-timecode header, giving 192-byte packets: its sync byte therefore sits at offset 4, not 0, and repeats every 192 bytes. The camera’s on-card .mts is essentially the M2TS content the camcorder writes for you to copy off. Because the coded H.264 and AC-3 are identical across all three, tools such as tsMuxeR or FFmpeg can rewrap between them without re-encoding; only the per-packet timecode wrapper is added or removed.

Why 1080i footage looks combed on a monitor

Many AVCHD camcorders record 1080i: interlaced fields at roughly 50 or 60 fields per second, where each frame is two half-height fields sampled a fraction of a second apart. A television built for interlace weaves them smoothly, but a progressive computer or phone screen showing both fields at once produces the “combing” or feathering seen on horizontal motion. This is a property of the source signal, not a decoding fault. Converting the clip with a deinterlace (or decomb) filter reconstructs progressive frames, which is why a conversion to MP4 for on-screen viewing should enable deinterlacing when the source is 1080i. The video codec is unchanged by that step; only the field structure of the pictures is resolved to full frames.

Frequently asked questions

Why does an MTS file have no header at byte 0?

Because a transport stream is designed for broadcast, where a receiver may tune in mid-stream. There is no single start-of-file structure to miss. Instead every 188-byte packet begins with the 0x47 sync byte, and the decoder locks on by confirming that byte recurs at the packet interval. The program tables (PAT, PMT) are repeated throughout the file so a late-joining decoder can rebuild the stream map without seeking to the beginning.

How does a player know which packets are video and which are audio?

By PID. Each 188-byte packet header holds a 13-bit PID that labels its elementary stream. The player reads the PAT at PID 0x0000 to find the PMT, then reads the PMT to learn which PID carries the H.264 video (stream_type 0x1B) and which carries the AC-3 audio (0x81). After that it simply filters packets by PID.

References

• Wikipedia — MPEG transport stream (packet structure, .mts/.m2ts)
• Wikipedia — AVCHD format and folder structure
• Microsoft — Overview of MPEG-2 Systems (PAT/PMT/PID)

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.