Initializing... drag & drop files here
Supports: F4V
.xvid File Actually IsRead this before you convert, because it explains most of the questions people have afterwards. Xvid is a codec, not a container — an open-source encoder for MPEG-4 Part 2 Advanced Simple Profile. There is no such thing as an Xvid file format, so when a tool is asked to write .xvid, it has to put the video inside a real container and name the result .xvid anyway.
That is exactly what happens here. The file this page produces contains AVI bytes: it opens with the RIFF signature followed by AVI , the video stream is tagged with the four-character code xvid, and the audio rides alongside it as it would in any AVI. The only unusual thing about the file is the letters after the dot.
The practical consequence is simple and worth acting on: if a player refuses the file, rename it to .avi. Verified on a converted file, renaming makes it identify as a standard AVI and open normally. Nothing inside changes; you are only telling the software what it is looking at.
Encoding the same four-second 1280 x 720 source at four points on the scale:
| Quantizer | Output size | Character |
|---|---|---|
| 1 | 9.29 MB | Finest step available; enormous files for very little visible gain |
| 5 | 2.94 MB | The pre-selected value, and a sound working point for most footage |
| 15 | 1.01 MB | Visibly soft; blocking appears on motion and in flat gradients |
| 31 | 562 KB | Coarsest step; only for very constrained delivery |
The useful working range on Xvid is roughly 3 to 8. Below 3 the file grows much faster than the picture improves, and MPEG-4 Part 2 does not have the tools to make that extra data pay. Above about 10 the classic Xvid artefacts start showing: blocky flat areas, smeared motion and ringing around hard edges.
| Property | F4V source | .xvid output |
|---|---|---|
| Container | ISO/IEC 14496-12, the ISO base media file format | AVI (RIFF), named .xvid |
| Video coding | H.264/AVC | MPEG-4 Part 2, Advanced Simple Profile |
| Video four-character code | n/a | xvid |
| Audio | AAC family | MP3 by default; many alternatives offered |
| Compression efficiency | Substantially better | Roughly a generation behind H.264 |
| Pixel aspect ratio | Carried | Carried — MPEG-4 Part 2 stores it in the codec's own header, and a 720 x 480 anamorphic source came through with its 16:9 display aspect intact |
| Seeking / index | Sample tables | AVI index |
| Player support today | Anything modern | Anything that reads AVI, once renamed |
| Reason to choose it | n/a | Hardware and software that predates H.264 |
Because Xvid is meaningfully less efficient than H.264, expect the output to be larger than the source at comparable quality, or noticeably softer at comparable size. That is the trade you are making, and it is the reason to be on this page only when something actually requires MPEG-4 Part 2 — an old DVD player with DivX/Xvid support, a media box from the 2000s, or software that was written for the era. If you just want a widely compatible file, F4V to MP4 keeps the H.264 video and gives you a smaller, better-looking result.
Rename it from .xvid to .avi and try again. The file is a standard AVI internally — it begins with the RIFF/AVI signature and its video stream is tagged xvid — but most players decide how to handle a file by looking at its extension first, and .xvid is not an extension anything registers. Renaming was verified to make the file identify as a normal AVI. Nothing about the bytes changes; you are only correcting the label.
.xvid files at all if they need renaming?Because people ask for them by name. Xvid is a codec, and a good deal of software, documentation and forum advice from the 2000s refers to "an Xvid file" as though it were a format, so a route named for the codec is what many users search for. The honest thing is to produce the file, put the video in the container the codec actually ships in, and say plainly that the extension is a label rather than a format. That is what this page does. If you would rather have the conventional extension from the start, F4V to AVI writes the same kind of file with .avi on the end.
They are two implementations of the same underlying video coding — MPEG-4 Part 2, Advanced Simple Profile — that grew up as rivals, one open-source and one commercial. The bitstreams are compatible in practice: a decoder that reads one generally reads the other, and the difference visible in a file is mostly the four-character code identifying which encoder wrote it. Hardware from the era often advertised support for both. F4V to DivX is the equivalent page, and it produces the same kind of AVI-inside-a-renamed-extension file.
No, and this is worth internalising before you set it. Xvid has no constant-rate-factor mode; it takes a quantizer between 1 and 31. The control keeps the CRF label because a single control serves every codec on the site, but the scale it exposes here is 1 to 31, opening at 5. Lower is still better, but the numbers are not comparable to H.264's: 5 on this page is a reasonable working setting, while 5 on an H.264 page would be extravagant. If you copy a number across from an H.264 workflow, you will not get the result you expect.
Yes. MPEG-4 Part 2 records the pixel aspect ratio inside the video stream's own headers rather than relying on the container, so anamorphic material survives — a 720 x 480 source with a 16:9 display aspect came through the conversion with that display aspect intact. This is a real advantage over some other legacy targets, which drop the aspect signalling and leave the picture squashed. One caveat applies as elsewhere: resizing the frame flattens the pixel aspect to square, so if you resize an anamorphic source, set an explicit width and height that already have the shape you want.
MP3, which is pre-selected. It is the codec AVI files of the Xvid era almost always used, so it maximises the chance that whatever hardware or software you are targeting will play the sound as well as the picture. AC3 is the choice if you are feeding something that expects Dolby Digital, and AAC is technically better per bit but is a less traditional partner for AVI and older players may not decode it. Speex and the PCM variants are present for completeness and are poor fits for general video.
At comparable picture quality, probably yes. F4V carries H.264, which is roughly a generation ahead of MPEG-4 Part 2 in compression efficiency, so matching the source's appearance with Xvid takes more data. You can of course make the file smaller by raising the quantizer, but you will see it: the picture goes soft and blocky sooner than an H.264 file would at the equivalent size. This is inherent to the codec, not to the conversion.
No. F4V files frequently carry onMetaData structures and cue points left over from Flash authoring, and AVI has no equivalent to put them in, so they are dropped. Timing, frame rate, frame size and the display aspect all carry over correctly; anything Flash-specific does not. Make a note of it before converting if you need it.
Yes — queue several and they convert with the same settings, which is usually the point when you are preparing files for a piece of legacy hardware. Because every file receives the same quantizer, and Xvid's quantizer behaves differently on different material, run one representative file first and check it before committing to a large batch. A quantizer that looks fine on a talking-head clip can fall apart on fast motion.
Your .f4v is uploaded over an encrypted connection, decoded and re-encoded on our servers, then deleted automatically after a few hours along with the .xvid it produced. There is no sign-up, no watermark, and nothing is shared or made public. Xvid is a light codec to encode by modern standards, so the conversion itself is fast; upload time is the only part that scales with file size.