Convert MTS to MKV Online Free
Convert an MTS camera clip to an MKV file with deliberate tracks, timing, and retention decisions.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Convert MTS to MKV With an Explicit Track Plan
MTS to MKV is a container and compatibility decision, not automatically a quality repair. MTS commonly stores AVCHD camera material as an MPEG transport stream. MKV is the video-file extension used for Matroska, an open multimedia container based on EBML. A conversion may decode and re-encode the camera media, or it may be able to copy compatible coded streams into a new Matroska structure. The correct path depends on the codecs, the intended player, and whether a clean derivative rather than the original camera package is the goal.
Keep the MTS clip and its camera-card material before producing an MKV. Matroska can carry multiple tracks and useful descriptive elements, but it cannot reconstruct source transport packets, AVCHD relationships, or image information lost in an earlier encode. Treat the MKV as a well-described access, editing, or delivery copy. State which source streams were retained, re-encoded, omitted, or added, particularly when audio, captions, or chapters matter.
MTS Program Tables Are Not Matroska Track Entries
An MTS file is generally an MPEG transport stream made from fixed 188-byte packets. A packet begins with the sync byte 0x47 and includes a 13-bit packet identifier, or PID. The Program Association Table identifies a Program Map Table, and the map identifies the elementary-stream PIDs and program timing reference. Audio and video are carried in packetized elementary streams; presentation timestamps and, where needed, decoding timestamps establish the intended timeline.
Matroska does not use PAT, PMT, PIDs, or transport packets. The converter must first demultiplex the selected MTS program and understand its streams. It then writes Matroska Track Entries that describe the target audio, video, subtitle, or other tracks. If re-encoding is required, decoding precedes target coding; if stream copying is possible, the coded essence is still placed into a different container layout with new track metadata and block timing. Changing the extension alone leaves the source as a transport stream.
This distinction is important with camera footage. A program may carry video and audio, but the surrounding AVCHD card can provide additional acquisition context. Preserve that source context instead of assuming a single MKV has become an equivalent camera archive.
Matroska Uses EBML Elements Inside a Segment
Matroska is an EBML Document Type. EBML is often described as a binary counterpart to XML: data is represented as identified, sized elements rather than fixed transport packets or RIFF chunks. In a Matroska file, the Segment is the root element containing all other top-level elements. The current Matroska element specification identifies Segment with EBML ID 0x18538067. Its children can include information, track definitions, clusters, cues, chapters, tags, attachments, and seek information.
A playable Matroska file must contain at least one Tracks element and at least one Cluster element. Tracks define the available streams and their properties; clusters carry the timed media blocks. This means an MKV is not “one codec.” The Track Entry identifies what a decoder should expect for a particular stream, while the actual coded audio or video appears in blocks associated with that track. A player may understand the EBML structure yet fail on a video codec it does not implement.
The flexible element structure is useful when a workflow needs multiple audio languages, subtitles, chapters, or attachments. It does not mean every destination supports every combination. Build only the tracks the recipient needs and verify them individually.
Clusters Blocks and Cues Govern the MKV Timeline
Clusters hold timed block data. A block refers to a track and carries media data positioned on the Matroska timeline; the source MTS presentation timing must be translated into this target arrangement. A clean output requires audio and video to remain aligned through the beginning, scene changes, and end of the file. This cannot be assumed merely because the first frame displays.
Cues provide a temporal index used for seeking. RFC 9559 explains that a CuePoint stores the position of the Cluster containing the relevant BlockGroup or SimpleBlock, with its time in CueTime and location in CueTrackPositions. Cues can be written after Clusters, which is simpler for a writer that cannot know final positions beforehand. For a viewer, the practical consequence is that seeking behavior depends on the final file structure as well as its media codec.
Test an MKV at several positions, not only from time zero. Seek forward, seek backward, listen for sync after the seek, and inspect the final minutes. If a delivery workflow requires rapid access or chapters, test those functions in the actual player rather than relying on a generic container claim.
Stream Copy and Re-encoding Answer Different MKV Needs
Stream copy, often called remuxing, keeps an already-coded audio or video stream while changing the surrounding container. It can avoid an additional lossy picture generation, but it only works when the target Matroska muxer and intended player accept the source codecs and their configuration. It also does not resolve problems inherent in the source stream. Re-encoding decodes to images or samples and creates new compressed streams, allowing changes to dimensions, frame rate, bitrate, codec, or audio settings at the cost of time and possible loss.
| Decision | MKV effect | What to test |
|---|---|---|
| Copy or re-encode | Preserves or replaces coded essence | Decoder support and visual result |
| Track selection | Determines audio, video, subtitle, and data entries | Each intended track is selectable |
| Language and default flags | Influences player track choice | Correct automatic selection |
| Cluster and cue writing | Influences timeline access | Seeking and end-of-file behavior |
| Video settings | Changes coded quality and decoder needs | Motion, text, and dark detail |
| Attachments or chapters | Adds optional contextual material | Target application recognizes them |
Do not call a remux “lossless” without qualification. The coded audio/video samples may be copied, but source container information and camera-card context are not preserved as MTS transport data. Record exactly what was retained and why.
MTS Camera Program and MKV Matroska File Compared
| Property | MTS source clip | MKV result |
|---|---|---|
| Outer structure | 188-byte MPEG transport packets | EBML document and Segment elements |
| Media identification | PAT/PMT and elementary-stream PIDs | Track Entries and codec identification |
| Timed media | Packetized elementary streams with timestamps | Blocks within Clusters |
| Seeking | Transport/program timing behavior | Cues point temporally to Cluster positions |
| Extra content | Camera-card context may live beside the clip | Can include chapters, tags, or attachments |
| Retention role | Original acquisition media | Access, edit, or delivery derivative |
An MKV made from the camera clip cannot later restore omitted source packets, original PIDs, AVCHD folder metadata, or picture detail lost through re-encoding. Keep the original MTS intact and give the MKV a technical manifest that names the source, track mappings, codec settings, and validation player.
Questions Before Using an MKV Derived From MTS
Is MKV a video codec?
No. MKV is the usual extension for Matroska video files. It is a container based on EBML; playback still depends on the codec and configuration of every track inside it.
Can I rename MTS to MKV?
No. MTS transport packets, PAT/PMT tables, and PIDs are not Matroska Elements, Tracks, or Clusters. A valid conversion builds the target structure after demultiplexing the source.
What are Cues useful for?
Cues provide a temporal index that helps a player seek to the Cluster holding material for a time. Test seeking in the intended player, particularly with longer files.
Does stream copying preserve everything?
It can retain coded streams without another encode when compatible, but it does not preserve the original MTS transport structure or all camera-card context. Document the boundary clearly.
What should I check after conversion?
Confirm the selected tracks, automatic language/default behavior, start and end sync, seeking, captions or chapters if used, and playback in the actual destination—not just a different desktop player.
For important deliveries, retain a checksum of the source and output, plus a record of the muxer, codec settings, track mapping, and validation environment. Those details make later preservation or compatibility work far more reliable.
Do a second inspection when an MKV contains more than one audio or subtitle track. A player may select a default track automatically according to its language preferences, which can conceal a wrong language tag or default flag during a quick test. Verify both manual selection and automatic behavior. If an attachment, chapter list, or descriptive tag has delivery value, confirm it survives the exact player or archive ingest path. Matroska permits rich structure, but optional elements are only useful when the next system reads and exposes them as intended.
For a visually sensitive camera clip, compare a few exact frames from the MTS decode and the MKV output at the same scale. Check high-motion scenes, fine patterns, saturated color, and dark gradients. That is more informative than judging the output from a file-size reduction alone.