Convert M2TS to MKV Online Free
Repackage or convert M2TS Blu-ray and camera media into a Matroska MKV file with the tracks you need.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Convert M2TS to MKV Without Confusing a Container Change With Re-Encoding
M2TS-to-MKV can mean two very different jobs. M2TS is the Blu-ray Disc Audio/Video (BDAV) form of MPEG transport stream; it multiplexes picture, audio, subtitles, and timing into packets. MKV is the usual file extension for Matroska, an EBML-based media container that can also hold separate video, audio, subtitle, chapter, attachment, and tag tracks. If the selected source codecs can legally and practically be written into Matroska, a remux copies their encoded packets into a new container. In that case, picture and sound quality do not change because no codec is decoded and encoded again.
A conversion can instead include transcoding when you ask for a different video or audio codec, resize a picture, change frame rate, downmix sound, or encounter a source stream the output workflow cannot carry. That produces a new encoded stream and can take longer, reduce quality, or change file size. The useful first decision is therefore not merely “M2TS or MKV?” but which original tracks you need, whether the target player supports their codecs inside MKV, and whether a stream-copy remux is enough.
Why an M2TS Demuxer Must Account for 192-Byte Records
An ordinary MPEG-2 transport stream uses fixed 188-byte packets. M2TS adds a four-byte TP_extra_header before each of them, creating 192-byte records. The UK National Archives' PRONOM registry calls out that four-byte prefix as the defining difference from the related MPEG-2 transport-stream format. A reader must account for it before interpreting the TS packet, whose header begins with the familiar 0x47 synchronization byte. An application that expects 0x47 every 188 bytes without this adjustment can lose packet alignment on an M2TS input.
Those four bytes are transport-related information, not a codec header that should travel to MKV. The remuxer removes the BDAV wrapper, reads the 188-byte transport packets, and reconstructs each elementary stream from payload fragments. This is why changing the extension to .mkv does not convert anything: the original still contains transport-stream packets and no EBML document header, Segment, TrackEntry elements, or Matroska clusters.
Use PAT, PMT, and PIDs to Choose What Comes Across
A transport stream is designed to carry many components at once. The program association table (PAT) identifies program map tables (PMTs); a PMT describes the elementary streams in one program and the packet identifiers, or PIDs, that carry them. A single title can consequently include video, multiple language tracks, commentary, audio description, subtitles, and private data. The demuxing stage follows those tables and PIDs rather than treating the M2TS as one indivisible video file.
MKV gives you a practical chance to keep only the material needed. Select the main video plus the wanted audio and subtitle tracks, or retain every supported track if the destination needs them. Check language, channel count, codec, and track role before conversion: a two-channel commentary PID and a six-channel main mix may be valid but serve very different uses. Removing a track from the MKV does not damage the M2TS, provided the original is retained; it simply makes the new file a more focused delivery copy.
How M2TS Clocking Becomes Matroska Timing
Transport-stream audio and video are packetized elementary streams with presentation time stamps (PTS), which tell a player when decoded media is due for presentation. A remuxer uses those timestamps to place frames in the new timeline and preserve audio/video sync. The source also has program-clock context and can contain discontinuities or separate segments. Writing payloads in byte order without interpreting access-unit boundaries and time stamps would not make a reliable playable MKV.
Matroska stores timed frames in Clusters. Within a cluster, media data is represented by Block or SimpleBlock structures and their time relationship comes from the cluster timecode plus block timing. A timestamp-aware remux maps the source timeline into this structure. When a source disc title is composed of several M2TS clips controlled by a playlist, converting only one clip can make a technically correct MKV that is missing later scenes. For the full feature, use the intended sequence rather than assuming one file always equals one complete title.
Inside MKV: EBML, Segment Tracks, and CodecPrivate Data
Matroska is specified as an EBML document. RFC 9559 describes an EBML header followed by a Segment and defines top-level elements such as Info, Tracks, Clusters, Cues, Chapters, Attachments, and Tags. The TrackEntry for each selected stream identifies its role and codec mapping. This differs from M2TS PIDs: a PID is an address in a transport multiplex; a Matroska track is a declared entry in a structured container with its own track number, type, language information, and codec identifier.
Some codecs need initialization data before a decoder can start. Matroska's CodecPrivate element is binary private data known to the codec and sits under Segment/Tracks/TrackEntry. RFC 9559 permits it once per TrackEntry. A proper remux carries or constructs the appropriate codec configuration as required by the Matroska codec mapping; blindly copying bytes is not enough if the source describes initialization differently. That is one reason stream copy is a technical operation, not simply a filename change.
Matroska Clusters hold the timed media blocks. Cues provide a time-oriented index: RFC 9559 says a CuePoint records the position of the Cluster containing a BlockGroup or SimpleBlock, with a CueTime and CueTrackPositions. A player can seek without Cues by scanning, but the RFC notes that it is much harder because the reader must hunt through the file for the right timestamp. An MKV that plays from beginning to end can therefore still be inconvenient when its cues are absent, incomplete, or only finalized at the end of an interrupted write.
For a long film, test seeks after the conversion finishes: jump near the middle and near the end, then check that audio returns in sync. Cues are not a guarantee that every player supports every included codec, but they are valuable structural evidence that the file was written as an indexed Matroska document rather than an arbitrary packet dump. If seeking fails while straight playback works, compare the output in another player before assuming the video stream itself is corrupt.
A clean remux does not decrypt protected content or repair a damaged source. Commercial Blu-ray material may be protected, and a converter can only process media it can lawfully read and decode. Packet loss, broken timestamp continuity, or an incomplete file can also surface as audio gaps, a shortened duration, or a muxer refusing a track. In those cases, return to a known-good source rather than trying repeated MKV conversions; a different container cannot reconstruct packets that are absent.
M2TS and MKV Compared for Preservation and Playback
| Question | M2TS source | MKV result |
|---|---|---|
| Container design | BDAV transport-stream variant | EBML-based Matroska Segment |
| Basic units | 192-byte M2TS records containing TS packets | Elements, Tracks, Clusters, and blocks |
| Track identification | Program tables and PIDs | TrackEntry fields and CodecID mappings |
| Timing and seeking | Transport timing and PTS | Cluster timing with optional Cues index |
| Optional content | Can multiplex video, audio, subtitles, data | Can carry tracks, tags, chapters, and attachments |
| Quality in a remux | Original encoded streams | Same streams when copied without re-encoding |
After exporting, inspect the new file rather than trusting only its file size. Confirm the expected duration, video resolution, frame rate, audio languages, channel layouts, subtitle availability, and several seek points. A much smaller MKV can be a useful result if unwanted streams were excluded; it can also indicate that a track was omitted or transcoded. Keep the M2TS until the review confirms that the intended program and tracks made the trip.
M2TS to MKV Questions About Remuxing, Playback, and Files
Does converting M2TS to MKV always reduce quality?
No. A stream-copy remux leaves the encoded audio and video payloads unchanged. Quality changes only if a stream is decoded and encoded again or intentionally altered.
Why is my MKV much smaller?
It may exclude extra languages, subtitles, or video streams, but it may also have been transcoded. Compare tracks and codecs, not only the number of bytes.
Can MKV preserve every M2TS feature?
It can preserve many media tracks, but disc navigation, encryption, and BDAV-specific behavior are not automatically reproduced. Keep the original for a disc-faithful archive.
Why does the result play but seek poorly?
The file may have incomplete or missing Cues, or the player may have limited support. Check the finished file in another player and make sure writing completed normally.
Will every television play an MKV?
No. Container acceptance and codec support are separate. A device can recognize MKV yet reject the particular video, audio, subtitle, or profile carried inside it.