Initializing... drag & drop files here
Supports: AVI
AVI is Microsoft's 1992 RIFF container from the Video for Windows era — designed for local playback, not for broadcasting or HTTP streaming. It has no built-in synchronization between elementary streams, no error-recovery mechanism, no Program Map Table, and the original AVI 1.0 spec capped files at 2 GB (OpenDML extends this to roughly 256 GB but not every player honors the extension). MPEG Transport Stream (defined in ISO/IEC 13818-1, first published July 1995) was engineered for the opposite job: lossy radio links, satellite hops, and segmented HTTP delivery.
cat a.ts b.ts > c.ts and play correctly because each 188-byte packet is self-describing. AVI concatenation breaks the index/header..ts or .m2ts). Re-wrapping AVI archives to TS standardizes a mixed library before NLE ingest.| Property | AVI | MPEG-TS |
|---|---|---|
| Origin / standard | Microsoft RIFF, November 1992 (Video for Windows) | ISO/IEC 13818-1, first published July 1995 |
| Packet structure | RIFF chunks indexed at end of file | Fixed 188-byte packets, self-synchronizing |
| Error resilience | None in container | PCR sync, continuity counters; ATSC adds 20-byte RS FEC, DVB/ISDB add 16-byte |
| Streaming over HTTP | Not designed for it; no segmentation primitive | HLS Media Segment Format (RFC 8216 §3.2) |
| Broadcast use | Not used | DVB, ATSC, ISDB-T, IPTV — the de-facto carrier |
| Concatenation | Breaks (single header/index) | Trivial (cat a.ts b.ts) when codec matches |
| File size ceiling | 2 GB (AVI 1.0); ~256 GB with OpenDML | None in spec; practical limit is filesystem |
| Typical codecs inside | DivX, Xvid, MJPEG, DV, uncompressed | H.264, H.265, MPEG-2, AC-3, AAC, MP2 |
| Mode (UI label) | What it does | Pick when |
|---|---|---|
| Quality Preset (Highest → Lowest) | One-click CRF wrapper | You want sensible defaults — start with Very High |
| Target file size (%) | Scales bitrate to N% of source | Re-targeting a master to a smaller archive copy |
| Specific file size | Solves bitrate to hit N MB | Fitting a cap (CDN budget, USB stick, courier disk) |
| Constant Bitrate | Locks bitrate every second | Broadcast contribution, fixed-bandwidth links, IPTV multicast |
| Variable Bitrate | Allocates bits where the picture needs them | HLS VOD ladders, archival masters |
| Constant Quality (CRF) | Fixed perceptual quality, variable size | One-pass HLS source, smallest size at chosen quality |
| Constraint Quality (CRF + max) | CRF with a hard ceiling | Stream peaks must stay under the playout cap |
Yes for the container — HLS (RFC 8216) explicitly accepts MPEG-2 TS — but the playlist still needs to be generated separately. XConvert produces a single TS file; to serve it as HLS you still need an .m3u8 playlist and segments cut to your target duration (around 10 seconds is typical). FFmpeg's -f hls -hls_time 10 does the slicing once you have the TS source. Codec-wise stick with H.264 + AAC or H.265 + AAC for the broadest player support.
H.264 is the default for HLS — every Apple device since iOS 3, every modern browser, every IPTV STB decodes it. H.265 / HEVC cuts the bitrate roughly 40% at equal quality but is only fully supported in HLS on iOS 11+, Safari 11+, and modern STBs; older Android devices will fail. If your player is Apple-centric, H.265 is fine. For DVB/ATSC contribution feeds, check what your playout server expects — many still mandate H.264 or MPEG-2.
All three carry MPEG-2 Transport Stream payload, just with different headers. TS is the bare 188-byte packet container used in broadcast and HLS. M2TS adds a 4-byte timecode header per packet (192 bytes total) and is the AVCHD / Blu-ray flavor. MTS is the camera-side filename for the same M2TS layout. If you need Blu-ray authoring use AVI to M2TS; for HLS, IPTV, or broadcast use plain TS.
Two common reasons. First, MPEG-TS has packetization overhead — 4-byte headers on every 188-byte packet plus PAT/PMT tables — which can add 2–5% versus the raw streams. Second, if your AVI was already low-bitrate Xvid/DivX and you encode at "Very High" quality, the new H.264 stream may use a higher bitrate than the source. Lower the quality preset, switch to Constant Quality with CRF 23–26, or use Target file size (%) to cap output at your source size.
For 1080p H.264, broadcast contribution is typically 6–10 Mbps CBR; IPTV distribution often 4–8 Mbps; ATSC over-the-air program streams sit around 12–19 Mbps multiplexed. For 720p, 3–5 Mbps is comfortable. Blu-ray-style mastering (if you're transcoding to TS as an intermediate) goes 15–25 Mbps. Check the receiving facility's spec — TR 290 / DVB conformance has tight rules and a CBR encode is usually mandatory.
Yes. Drop in as many AVI files as you want — Xvid rips, DV captures, screen recordings — and apply the same compression/resolution settings across the batch, or override per file. Files convert in parallel within your browser session and download individually or as a ZIP archive.
Yes — use Trim → Time Range and enter start time + duration in HH:MM:SS.sss (e.g. start 00:00:30.000, duration 00:00:10.000 produces a 10-second clip suitable for a single HLS segment). Trim before encoding to avoid re-encoding footage you'll throw away.
Likely yes. Files larger than 2 GB (AVI 1.0) or 4 GB usually rely on the OpenDML extension introduced around 1996. XConvert reads OpenDML AVIs that legacy editors trip over and re-wraps the streams into TS — a container with no comparable ceiling. If your source is corrupted past the OpenDML index, results vary; otherwise the conversion is straightforward.
Depends on the destination. If you're streaming to web players, sharing on social, or playing on a phone, AVI to MP4 is the right choice — MP4 is the universal sharing format. Pick TS only when you need broadcast, HLS, IPTV, or simple concatenation. For Blu-ray authoring use AVI to M2TS instead.