Initializing... drag & drop files here
Supports: XVID
Xvid is an open-source MPEG-4 Part 2 ASP video codec first released in 2001 as a free alternative to DivX, almost always wrapped in an AVI container. M2TS is the long-filename variant of the BDAV MPEG-2 Transport Stream container — the format Blu-ray Discs and AVCHD camcorders use to multiplex audio, video, and subtitle streams, with 192-byte packets (188 bytes of MPEG-TS plus a 4-byte arrival timestamp at 27 MHz). The two formats target completely different ecosystems: Xvid AVI was designed for PC playback in the 2000s, while M2TS is the on-disc format for set-top Blu-ray players, PS5/Xbox optical playback, and AVCHD-recording camcorders. Going from one to the other is essentially a re-mux from a "PC compression" container into a "broadcast/disc" transport stream — and because the Blu-ray spec does not include MPEG-4 ASP as a mandatory or optional codec, the video has to be re-encoded into H.264, H.262/MPEG-2, or VC-1 along the way.
BDMV/STREAM/ is what authoring suites like multiAVCHD, tsMuxeR, and Adobe Encore expect.| Property | Xvid (AVI) | M2TS (BDAV) |
|---|---|---|
| Container | AVI (Microsoft RIFF) | MPEG-2 Transport Stream, 192-byte packets |
| Typical video codec | MPEG-4 Part 2 ASP (Xvid) | H.264, H.262/MPEG-2, or VC-1 |
| Audio codecs supported | MP3, AC-3, PCM | AC-3, DTS, LPCM (mandatory); Dolby TrueHD, DTS-HD MA (optional) |
| MIME type | video/x-msvideo | video/MP2T |
| Filename rules | Long filenames (NTFS / exFAT) | Long names on Blu-ray; 8.3 (.MTS) on AVCHD/FAT32 |
| Max video bitrate (typical) | ~8 Mbit/s for SD content | 40 Mbit/s (BD-ROM spec) |
| Random-access resilience | Index-based; corruption breaks playback | Each packet self-syncs; resilient |
| Primary playback target | PC (VLC, MPC-HC) | Blu-ray players, AVCHD camcorders, PS5/Xbox |
| Subtitle support | External (.srt) only in practice | PGS, text subtitles muxed in stream |
| Spec finalized | Xvid project 2001 | BDA M2TS spec August 2004 |
| Target use | Resolution | Codec choice | Recommended video bitrate |
|---|---|---|---|
| Up-rezzed SD on BD-R | 720×480 (NTSC) / 720×576 (PAL) | MPEG-2 | 6–9 Mbit/s |
| 720p HD Blu-ray | 1280×720 | H.264 High | 10–15 Mbit/s |
| 1080p Blu-ray (most common) | 1920×1080 | H.264 High | 18–28 Mbit/s |
| 1080p Blu-ray archival | 1920×1080 | H.264 High | 30–35 Mbit/s |
| Hard cap (BD-ROM spec) | up to 1920×1080 | any mandatory | 40 Mbit/s video / 48 Mbit/s combined |
Only if it conforms to the BDAV/BDMV folder structure and uses a Blu-ray-mandatory codec. A bare .m2ts file dropped on a USB stick is not the same as an authored disc — most set-top players need BDMV/STREAM/00000.m2ts, BDMV/index.bdmv, and matching .clpi / .mpls files. Pick H.264 video and AC-3 audio in this converter, then run the resulting M2TS through a free authoring tool like multiAVCHD or tsMuxeR to build the BDMV folder before burning.
.avi to .m2ts instead of re-encoding?Because the two are entirely different container formats. AVI is a Microsoft RIFF interleave; M2TS is a 192-byte-packet transport stream with 4-byte arrival timestamps prepended to each 188-byte MPEG-TS packet. And the codec inside Xvid AVI is MPEG-4 Part 2 ASP, which the Blu-ray spec doesn't list as a mandatory or optional codec — only H.264, H.262/MPEG-2, and VC-1 are. A rename would produce a file no Blu-ray player or AVCHD device could decode.
H.264 in almost every case. MPEG-2 is included for backwards compatibility with very early Blu-ray titles and is roughly 2× less efficient at the same quality. The only reason to pick MPEG-2 is if your authoring software or target player explicitly demands it (a handful of broadcast pipelines still do). For consumer BD-R authoring, H.264 High Profile at Level 4.1 is the default safe choice and is supported by every Blu-ray player shipped since the format launched.
They are functionally identical. Both wrap the BDAV MPEG-2 transport stream. M2TS uses long filenames (the Blu-ray Disc convention); MTS uses 8.3 filenames so AVCHD camcorders can write to FAT32 SD cards. Renaming file.m2ts to file.mts (or vice versa) does not change the bytes inside — it's purely a filesystem-naming convention.
Yes, unless you deinterlace before encoding. Many old Xvid AVI rips were captured from interlaced sources (DV camcorders, analog captures, broadcast TV) and stored as 480i or 576i. The Blu-ray spec supports both 1080i and 1080p, so an interlaced output is legal, but most modern Blu-ray players display 1080i fine. If your authoring target is AVCHD or progressive 1080p delivery, deinterlace at the source first — re-encoding interlaced fields into a progressive H.264 stream after the fact is much messier than handling it once at encode time.
In theory, yes — Xvid AVI files often carry AC-3 (Dolby Digital) audio, which is also a Blu-ray-mandatory audio codec. In practice, this xconvert pipeline always re-multiplexes; if you need a true bit-for-bit audio passthrough into M2TS, the workflow is to demux the AC-3 from the AVI with MKVToolNix or eac3to and remux into M2TS via tsMuxeR. For most users the small quality loss from a single AC-3 → AC-3 transcode is inaudible.
There's no fixed length cap on this page — the practical limit is your upload size and connection speed and how long you're willing to wait. For Blu-ray authoring the destination has its own constraint: a single-layer BD-25 holds about 23 GiB of payload, and at 25 Mbit/s video + 640 kbit/s audio that works out to roughly 2 hours of 1080p content per disc. BD-50 dual-layer roughly doubles that.
Two main reasons. First, the original Xvid AVI was likely already lossy SD content (often 480p or below), so up-scaling to 1080p inside M2TS doesn't add real detail — it just stretches existing pixels and the H.264 encoder smooths block edges. Second, transcoding from one lossy codec (MPEG-4 ASP) to another (H.264) introduces generation loss. To minimize that, pick Constant Quality (CRF) with a low CRF value (16–18 for H.264) and keep the resolution at the original source size rather than upscaling.
Mostly, yes — H.264 is a superset of the motion-prediction features Xvid uses, so the re-encoder doesn't lose anything structurally. What can cause artifacts is when an Xvid file was encoded with non-standard GMC (Global Motion Compensation) or qpel settings that some decoders interpret loosely; if the decode is slightly off, the H.264 re-encode bakes that drift in. If you see ghosting or smearing after conversion, try decoding the AVI in VLC first to confirm the source plays cleanly before blaming the M2TS encoder.
If you want a modern web-friendly file instead of Blu-ray, look at Xvid to MP4 or Xvid to MKV. If your source is generic AVI rather than specifically Xvid, AVI to M2TS covers the broader case. To go the other direction (Blu-ray rip back to a portable file), M2TS to MP4 is the standard reverse trip.