Cut XviD video by setting start and end times. Trim legacy DivX-era video files. No re-encoding preserves original quality.
Process files in seconds with our optimized servers
Frame-accurate cuts with intuitive timeline controls
Maintain original quality with smart re-encoding
XviD is the open-source MPEG-4 ASP video codec that powered most of the DivX-era AVI ecosystem from 2001 onward — the workhorse behind Kazaa, eDonkey, DC++, and BitTorrent video sharing before H.264 took over around 2010. It still shows up in archived .avi rips, set-top DVD player encodings, and old camcorder exports. Cuts are frame-accurate — the clip is re-encoded at the visually-lossless default quality preset, so it stays true to the source. Cutting XviD is useful for:
For a different output container after cutting, see XviD to MP4 or XviD to MKV. To compress without trimming, see Compress XviD. For the same workflow framed as a trim, see Trim XviD.
| Property | Default settings | Custom re-encode (XviD / DivX / MPEG-4 / H.264) |
|---|---|---|
| Speed | Proportional to clip length | Proportional to clip length and codec |
| Quality | Visually-lossless default quality preset | Depends on the CRF / bitrate you pick |
| Cut precision | Frame-accurate | Frame-accurate |
| Output codec | Stays XviD (MPEG-4 ASP) | Any: XviD, DivX, MPEG-4, H.264, H.265, MJPEG, HuffYUV |
| Audio | Re-encoded at a matching bitrate | Re-encoded to chosen codec |
| File size | Proportional to duration kept | Variable by CRF / bitrate |
| Best for | Quick extraction at source quality | Smaller file, codec change |
XviD encoders from the DivX era typically placed keyframes every 250-300 frames (~10-12 seconds at 24 fps), but that doesn't limit the cut point: the kept segment is decoded and re-encoded, so cuts land on the exact frame you specify.
| Output codec | Quality vs Size | Typical Bitrate / CRF | Best for |
|---|---|---|---|
| XviD (default) | Good / Medium | ~1100-1500 kbps | Keep the original codec, broadest legacy player support |
| DivX | Good / Medium | ~1100-1500 kbps | DivX-certified DVD players and set-top boxes (2003-2010) |
| MPEG-4 (Part 2) | Good / Medium | ~1500 kbps | General legacy playback, reference MPEG-4 ASP |
| H.264 | Excellent / Small | CRF 23 | Modern playback, ~50% smaller at the same visual quality |
| H.265 | Excellent / Smallest | CRF 28 | Newest playback, smallest file, slower encode |
| MJPEG | Frame-independent / Large | ~8000 kbps | NLE scrubbing, frame-by-frame editing |
| HuffYUV | Lossless / Very large | n/a | Editing intermediate, no quality loss between cuts |
Lower CRF = higher quality and larger file. CRF 23 is "visually lossless" for H.264; CRF 28 is the typical default for H.265. If you don't need to keep XviD specifically, XviD to MP4 gives broader device support at similar size.
No — the cut always decodes and re-encodes the kept segment; there is no stream-copy path. The upside is frame accuracy: even though XviD encoders from the DivX era often placed keyframes every 10-12 seconds, the clip starts exactly at your specified time instead of snapping back to a keyframe. Left on defaults, the re-encode uses the visually-lossless default quality preset, so the cut clip looks the same as the source.
With XConvert it shouldn't — the cut is re-encoded, so it starts at the exact time you asked for. The snap-back you're describing is how stream-copy cutters behave: they can only cut at keyframes (I-frames), and XviD encoders that produced most pre-2010 AVI rips placed keyframes far apart — every 250-300 frames is typical, which is 10-12 seconds at 24 fps. In those tools a cut requested at 00:01:23 may snap back to 00:01:14; here it lands on the requested frame.
Yes. The cut keeps XviD (MPEG-4 ASP) video in an AVI container — if it played in VLC, Kodi, or MX Player before the cut, it plays after. VLC and Kodi have shipped with XviD support since the early 2000s, and MX Player handles XviD natively on Android. Windows Media Player needs a codec pack like K-Lite or LAV Filters, which is the same situation as before the cut.
There's no fixed cap on our side. Cutting runs on our servers, so the practical limit is upload size and connection speed and how long you're willing to wait for the file to load. Multi-GB compilation rips and hours-long archived recordings work fine. Processing time scales with the length of the segment you keep, not the full source duration. The classic AVI container has a 4 GB single-file limit; OpenDML / AVI 2.0 raises this and most XviD files written after roughly 2003 use OpenDML.
If a specific player, DVD authoring tool, or legacy device requires XviD, keep XviD. Otherwise, MP4 (with H.264 or H.265) is smaller for the same quality, plays natively on every phone and browser, and uploads cleanly to YouTube, Drive, and WhatsApp without re-encode on the platform side. The recommended workflow is: cut first, then run XviD to MP4 on the cut clip — much faster than transcoding the full source and then trimming, because the conversion only has to process the clip.
Yes. Cut the XviD to the segment you want, then run XviD to MP3, XviD to WAV, or XviD to AAC on the result. Cutting first is faster because the audio extraction only has to process the clip, not the full source.
Yes. Add multiple trim segments — each pair of start time + duration produces a separate output XviD file. Useful for splitting a multi-episode TV rip into individual files, pulling several music videos out of a compilation AVI, or extracting all the relevant scenes from a long DivX-era download in one batch.
No, by default the output AVI keeps both the video and the audio track. XviD AVI typically carries MP3, AC-3, or PCM audio — the audio is re-encoded along with the video at a bitrate matched to the source. If you specifically want a silent clip (for over-dubbing, looping background, or muted social posts), set the audio codec option to "no audio" before cutting.
XviD and DivX are both MPEG-4 ASP implementations and produce broadly similar output at similar bitrates. DivX is the original commercial encoder; XviD is the open-source reimplementation that became the de facto free alternative. Pick DivX if you specifically need a DivX-certified DVD player to recognize the file (some checked the FourCC tag), otherwise XviD is the more common modern choice. For anything outside the DivX-era ecosystem, H.264 in MP4 is a better target.