If all your standard codecs disappeared due to a faulty installer (I had a faulty installer online for some hours and some people didn't read the advice to use the new installer to replace it) you need to re-install your codecs using this procedure: http://www.free-codecs.com/guides/Ho...ws_XP_2000.htm

Since this FAQ is a bit outdated in most regions, please head over to Crusty's FAQ (PDF) in the meantime. Once it's completely overhauled and wiped clean, it'll get adopted here.

1. Why XviD?
2. How do I encode using XviD?
3. What do all the different options mean?
4. Is XviD better than DivX?
5. Where can I get the XviD codec/binaries?
6. Which quantizer mode should I use?
7. What to do if I get green and or pink blocks?
8. What filter should I use to play back XviD encoded videos?
9. What is Lumi masking?
10. What is the Chroma Optimiser
11. Why are there new binaries on a daily basis?
12. Can I start using XviD now and will I be able to play files created with today's build once the final version comes out?
13. What does the quality mode do?
14a. What's the difference between Payback with bias and Payback proportionally?
14b. Thx for the info But what are the advant/disadvant of each?
15. I want to playback this movie I d/l'ed but there is no sound!
16. I only get a green/no picture on playback!
17. Are B-Frames safe to use?
18. How does Q-Pel work and when should I use it?
19. How do I get the latest CVS sourcecode?
20. Is packed bitstream safe to use?
21. What is meant by mod16/mod8/mod4 in concern to resolutions?

1. Why XviD?

The developers of XviD are just ordinary people, who happen to enjoy writing code for video compression. The developers work on XviD in their spare time, for no compensation other than the fun of doing it and the occasional thankyou. If you wonder why XviD isn't perfect, or bugs sometimes appear without immediate fixes, it's because the developers are normal people and cannot commit their lives to the project.

It is best to think of the MPEG quantizer as "sharpening" the image, and the H.263 quantizer as "softening" it. For high bitrates, you will find that MPEG quantization preserves more detail - for low bitrates, the smoothing of H.263 will give you less block noise.

However with the introduction of New Modulated HQ it may be considered the other way round. Modulated means switching between the two (MPEG/H263). More can be found in iago's guide and by searching this forum. Modulated Quants actually break the MPEG-4 spec so it is perhaps not best to use them. They also cannot be used with B-Frames correctly.
Koepi's post here may help: http://forum.doom9.org/showthread.ph...peg#post258145
(beware - outdated now!)

7. What to do if I get green and or pink blocks?

Some versions released after 2/2/2003 had this problem. It should be fixed now so try out the latest binaries.
(beware - outdated now!)

Although FFDShow has more options, it is not based on the XviD project and may contain incompatibilities from time to time. It is advised to try both and see what works best for you.
(These filters do not decode audio! only video! XviD does not decode or deal with audio in anyway)

9. What is Lumi masking?

Lumi masking is a first 'psychological' innovation in XviD; it is supposed make use of the fact that the human eye tends to notice encoding errors less if they happen in very dark or very bright parts of the picture. XviD is - in contrast to DivX - capable of using different quantizers for each macroblock. Lumi-masking compresses very dark or bright areas stronger than medium ones. So it will use less bits on some frames in the second pass than in the first pass. The saved bits are of course spent again and that way we gain a bit of quality in the medium-brightness part of the picture. As it is experimental, you may sometimes notice more blocks than when it is disabled.

10. What is the Chroma Optimiser

Chroma optimizer reduces PSNR by it's nature. The _mathematical_ deviation to the original picture will get bigger - but the subjective image quality will raise (as mentioned, the "stair step artifacts" get less).
Though some people reported problems with complete colour mismatches
It's on the debug-tab for a reason: it _certainly_ needs testing.

11. Why are there new binaries on a daily basis?

XviD is still in alpha state and under heavy development.
(beware - outdated now!)

12. Can I start using XviD now and will I be able to play files created with today's build once the final version comes out?

As XviD is creating MPEG4-compliant video streams, you can play your movies encoded today with any MPEG4-compliant decoder (i.e. any future version of XviD, or other MPEG4 players). XviD will, however, incorporate new features in the future such as B-frames, which cannot be played with the current build of either XviD or DivX.

13. What does the quality mode do?

The quality mode chooses an "average quantizer" for the entire video. It is similar to setting a quantizer in the "1-pass - quantizer" mode, though the quality mode lets you have a quantizer of say 4.5. In the case of 4.5, the 1st frame would be encoded with 4, the second with 5, the third with 4, the fourth with 5, etc., so that the "average" quantizer at the end of the video will be 4.5. The equation that gives you the "average quantizer" is:

((MaxQuant-MinQuant)/100 * (100-quality)) + MinQuant

(beware - outdated now!)

14a. What's the difference between Payback with bias and Payback proportionally?

Bias won't quickly use up the reserve on a demanding scene after a still / highly compressible sequence in the video but might use too much on an easy scene following such a sequence such as stationary text on a static background.
(beware - outdated now!)

15. I want to playback this movie I d/l'ed but there is no sound!
XviD is a video codec, thus has nothing to do with sound. Anyways, go to the download-section and fetch the audio-playback-filters for ac3, you're most likely lacking them.
You may also need an Ogg Vorbis filter which can be found @ http://tobias.everwicked.com/oggds.htm

16. I only get a green/no picture on playback!
Several reasons are possible: your VGA card can't cope with the resolution of the video - install the DivX-G400-patch from the download-section.
You installed the Nimo pack? The Nimo Codec Pack is evil[tm]! Happy reformating and fresh-installing your system! After that, stick with ffdshow or the XviD decoders. Just install the codecs you need, and no bloated packs!
FFDShow can be downloaded here: http://sourceforge.net/project/showf...group_id=53761

19. How do I get the latest CVS sourcecode?
Download WinCVS and use
cvs -d:pserver:anonymous@cvs.xvid.org:/xvid co -R -r dev-api-4 xvidcore
cvs -d:pserver:anonymous@cvs.xvid.org:/xvid co -R -r dev-api-4 vfw
To get the dev-api-3 branch. Read more about it at www.xvid.org.

21. What is meant by mod16/mod8/mod4 in concern to resolutions?
This refers to the resolution being able to be divided by a number cleanly. i.e. mod16 refers to resolutions such as 640x480, 720x576, etc. where both the horizontal and vertical are divisible by 16.

If you have downloaded a movie then you will get no other help here! We do not help with piracy of movies!
(beware - will never be outdated!)

Last edited by Koepi; 7th May 2008 at 05:59.
Reason: Added my site for binary-downloads again

MPEG4 video is based heavily on H.263 - most of the MPEG4 docs assume a prior knowledge of H.263 so you may be better off looking for it instead.

B-frames are one of 3 different frame types that MPEG4 supports. I-frames (Intra frames) are completely self-contained, that is they don't reference any other frames. These are commonly called key frames. P-frames (Predicted (?) frames, can't remember for some reason) are frames which reference the frame that came before it for image data. Each 16x16 block (macroblock) of a P-frame can either be encoded independently of anything else (an "intra" block) or be "compensated" from the frame that came before it. By expoiting the similarities often found in subsequent frames, P-frames are significantly smaller than I-frames - the cost is that you must decode every preceding P-frame from the last I-frame in order to decode one.

B-frames are a different matter, and complicate the encoding/decoding procedure by quite a bit. They are "Bidirectional" frames, meaning that they can reference frames that come both before and after itself. How can a frame reference a frame that comes after itself, you ask? The encoder reorders the frames so that they are no longer stored one after the other in order, that's how.

Say you had 4 frames. You wanted the first to be an I-frame (naturally), the next to to be B-frames (as they are usually a quarter of the size of P-frames, to give you some idea of the compression benefits), and the last frame to be a P-frame (as B-frames need something ahead of themselves to be predicted from). The frames would sequentially look like this:

1 2 3 4
I B B P

However, they would be stored in the file as:

1 4 2 3
I P B B

After encoding the I-frame, the encoder skips ahead and grabs the frame that is destined to be the P-frame, and encodes it as if it immediately followed the I-frame. Now, that will increase the size of the P-frame, as more will have changed between the I-frame and itself over the 2 intermediate frames, but we are hoping that the B-frames will make up for this loss of compressability. Now we have an I-frame and a P-frame compressed. Once this is done, the encoder goes back to the second frame (which was destined to be our first B-frame), and references both the I-frame and the P-frame to find similarities. Once the first B-frame is completed, the encoder again uses the original I-frame and the P-frame to compress the second B-frame. Note that B-frames can't reference other B-frames for finding matches.

As you can see, B-frames make things messy

Anyway, here's another diagram:

1 2 3 4
I B B P

1. Codec compresses I-frame
2. Codec jumps ahead and compresses P-frame as if it immediately followed the I-frame. Our bitstream now contains:

1 4
I P

3. Codec grabs the 2nd frame, and references both the I-frame and the P-frame to compress it. Adds compressed B-frame to bitstream:

1 4 2
I P B

4. Codec grabs the 3rd frame, and references both the I-frame and P-frame to compress it. We have finally completed our encoding:

1 4 2 3
I P B B

Since B-frame encoding requires frames to be fed to the encoder "out of order", there is talk of creating a custom encoding program to generate XviD AVI's containing B-frames. These AVI's will be playable with all the normal tools (Media Player, PowerDivX, etc.), it's just the encoding that's tricky.

Hope that's made things less (more?) confusing.

-h

And this, again by -h:

The I-frame quantization settings restrict the quantizers that may be used for I-frames (key frames). If you set the min and max to 2 and 2, then the keyframes in your movies will be high quality and large in size.

Now, because of the way the 2-pass "bit bucket" works, setting the I-frames to artificially low quantizers will result in the P-frames following it to have extremely high quantizers - such a quick jump will produce ugly output. So, the "Smooth quantizers" checkbox will prevent the quantizer from jumping too far between subsequent frames.

If you're going to mess with the I-frame quantizers, you should check that box.

Constant Quantizer for Credits:
Make sure you enable the credits start/end frame and quantizer options for the
1st pass as well as the 2nd pass

Nandub:
You CAN'T use the .stats files from a first pass with Nandub to do the second pass with XviD.
Nandub CANNOT encode XVID!

Compiling XviD:
For Win32, you will need either Visual C++ 6 / 7(.net)
For VC6 you will also need Service pack 6 + Processor Pack 5
For all the assembly code you will need the latest version of NASM (The Netwide Assembler)
For the DirectShow filter you will need a copy of the Direct X SDK

Lumafilter is a function of Mpeg2Dec3. So that, no further plugin is needed. Values for Lumafilter may differ here, so -1 or -3 might also work well. For more Information see the readme of Mpeg2Dec3.

Regarding the values for Unfilter, the same applies. These are just the values I prefer. You will have to experiment to find out what suits your needs

Answer 2:
There is also a filter called Blockbuster by Sansgrip(?). It seems, however, that it is designed to get rid of blocks which were already in the source.
I 've never tried it but it is supposed to work well.

Q:Can I paste a clip encoded with and a clip encoded without Qpel together to a single file?

A: Yes you can. In Vdub or Vdubmod you simply open the first file and then choose 'append avi segment(/file/whatever)', then save it as a new file with direct stream (no recompression).
EDIT: The resulting is not MPEG4 compliant and therefore this operation isn't supported by XviD developers.

Q: Why would I want to do that?

A: Encoding the end credits separately with Qpel can save you quite some bits. Especially on the classic vertical scrolling end credits you can easily save 1/3 of the size. Your end credits will look just as good (or bad) as the original with 1/3 less filesize.

Q: Does decoding Qpel require more processing power?

A: Yes it does. Some people have reported somewhere between 30 to 60% more processor usage with Qpel, but details are few and far between.
Try it out for yourself and see. People with 1 GHz or faster processors generally don't have to worry, unless your decoding a 1280x1024 clip or something like that.

__________________Core 2 Duo intel, overclocked at something (can't remember what i set it at), about 2 TB in hard storage, nvidia 9800 GT and a pretty old 19tftscreen.
Crusty007 at en.Wikipedia.org

Consider a two frame videosequence, with one frame's size 1000 bytes while the other is 2000 bytes. Let's say that you wanted the whole video to be 3300 bytes big. Since the two frames used up 3000 Bytes, you have 300 bytes left in the bitreservoir to use on all the frames.

Payback with bias takes the bitreservoir and hands out bytes one-at-a-time to each frame, until it runs out of bytes. This means that both frames will get an equal share of extra bytes. The result will be that both frames get 150 extra bytes.

Payback proportionally looks at the size of the frame and says, 'Hey, you're twice as big, you're share is bigger'. Since the second frame is twice as big as the first, it gets 2 bytes for every byte the first frame gets. So the end result is that frame 1 will get 100 bytes extra and frame 2 will get 200 frames extra.

Note @ Darknight512:

It's sounds very much like you downloaded the source code
If you got files that ended with extensions like .h, .c and .cpp you've got the source code, and not a binary build.
Go to the sites mentioned in the faq and be sure to download a 'binary'. After unzipping and executing it should require zero brainpower to install.

__________________Core 2 Duo intel, overclocked at something (can't remember what i set it at), about 2 TB in hard storage, nvidia 9800 GT and a pretty old 19tftscreen.
Crusty007 at en.Wikipedia.org

...Is it possible that to much bitrate in video data causes video not to run clearly (especially on older-slower PC).
In my case: I encoded videoclip (Laibach - Tanz mit Laibach -> source DVD) with 4800 video bitrate (I used 2-pass encoding etc....). The result is that playback dosn't run as it should. Picture is somehow jumping from one frame to another every (about) 10 seconds.

(I have PII 300, 384MB RAM...., it is a "little" slow but it works fine. I have encoded many DVDs with it with almost no problem.)

On a pII 300 things sometimes got jerky here, I can verify that. This is absolutely normal for resolutions > 640x272 (or using advanced features as qpel/bframes... which all demand their processing power).

-Reviewed pictures for correctness.
-Updated XviD version info and downloads.
-Major revision of downloads section with more and updated files.
-Made website counter working again (was broken since june).
-Link-rot update on all sections, most of them now correct again.
-Some minor content alterations on sections B and D to reflect improvements and updates on the codec.

PM me if you have problems with reaching it or suggestions.
Cheers,
Crusty

__________________Core 2 Duo intel, overclocked at something (can't remember what i set it at), about 2 TB in hard storage, nvidia 9800 GT and a pretty old 19tftscreen.
Crusty007 at en.Wikipedia.org

Q: I compiled XviD myself with the latest tarball, it installed fine, but it runs way slower than all my other codecs, DivX included. What's going on? Is there something I missed?

Chances are the options you specified are causing the codec to work overtime. VHQ mode is a massive culprit of this. Setting it to "0" speeds it up dramatically (I encoded a short video, was getting between 10 and 15 FPS, with this off, I got 20+ FPS) - but you'll loose quality.

One other thing that could be slowing it down is that the ASM modules in the source weren't compiled. Make sure you have NASM installed, this will speed it up considerably. Get it here. Rename "nasmw.exe" to "nasm.exe" and it will be detected.

EDIT by Koepi: clearified the issue about VHQ - it boosts quality by a good amount - in the opposite to what was written here originally.

__________________
On Discworld it is clearly recognized that million-to-one chances happen 9 times out of 10. If the hero did not overcome huge odds, what would be the point? Terry Pratchett - The Science Of Discworld

XviD was designed to be MPEG-4 spec compliant from the start, I believe. So you should have no problems decoding from the latest build.

Q: I'm running an i686, I have the latest tarball, MinGW, MSYS and YASM. "configure" detects YASM, "make" compiles everything including the ASM modules, but it won't finish the installation. What's going on?

This is a bug with YASM on this system type. It will NOT compile the ASM modules properly. Either wait for a newer version of YASM or get NASM, which does work on this system type. Get NASM here.

__________________
On Discworld it is clearly recognized that million-to-one chances happen 9 times out of 10. If the hero did not overcome huge odds, what would be the point? Terry Pratchett - The Science Of Discworld

Originally posted by Inventive Software XviD was designed to be MPEG-4 spec compliant from the start, I believe. So you should have no problems decoding from the latest build.

IIRC the XviD ds decoder(haven't test with libavcodec, but it was too late, most of them were SHIFT-DELETEed...)
failed to decode some of my old XviD file, if the video contain GMC frames, or color were shifted...

Originally posted by Yong failed to decode some of my old XviD file, if the video contain GMC frames, or color were shifted...

Using what build of XviD? If its a file encoded with say the 16.07.2003 build, then this is a known problem (usually I get weird smearing of green over the picture) and for that stuff its best to use ffdshow and use libvacodec. This should clear up any problems.

Originally posted by KaiserS Using what build of XviD? If its a file encoded with say the 16.07.2003 build, then this is a known problem (usually I get weird smearing of green over the picture) and for that stuff its best to use ffdshow and use libvacodec. This should clear up any problems.

I thinks i use old Nic's build, build 12, 19..., then Koepi's build,
(the version number will display at OSD if decoding with ffdshow),
I couldn't find any old build for testing,
let's forget about this problem's