7.4. Encoding with the Xvid codec

Xvid is a free library for encoding MPEG-4 ASP video streams. Before starting to encode, you need to set up MEncoder to support it.

This guide mainly aims at featuring the same kind of information as x264's encoding guide. Therefore, please begin by reading the first part of that guide.

7.4.1. What options should I use to get the best results?

Please begin by reviewing the Xvid section of MPlayer's man page. This section is intended to be a supplement to the man page.

The Xvid default settings are already a good tradeoff between speed and quality, therefore you can safely stick to them if the following section puzzles you.

7.4.2. Encoding options of Xvid

  • vhq This setting affects the macroblock decision algorithm, where the higher the setting, the wiser the decision. The default setting may be safely used for every encode, while higher settings always help PSNR but are significantly slower. Please note that a better PSNR does not necessarily mean that the picture will look better, but tells you that it is closer to the original. Turning it off will noticeably speed up encoding; if speed is critical for you, the tradeoff may be worth it.

  • bvhq This does the same job as vhq, but does it on B-frames. It has a negligible impact on speed, and slightly improves quality (around +0.1dB PSNR).

  • max_bframes A higher number of consecutive allowed B-frames usually improves compressibility, although it may also lead to more blocking artifacts. The default setting is a good tradeoff between compressibility and quality, but you may increase it up to 3 if you are bitrate-starved. You may also decrease it to 1 or 0 if you are aiming at perfect quality, though in that case you should make sure your target bitrate is high enough to ensure that the encoder does not have to increase quantizers to reach it.

  • bf_threshold This controls the B-frame sensitivity of the encoder, where a higher value leads to more B-frames being used (and vice versa). This setting is to be used together with max_bframes; if you are bitrate-starved, you should increase both max_bframes and bf_threshold, while you may increase max_bframes and reduce bf_threshold so that the encoder may use more B-frames in places that only really need them. A low number of max_bframes and a high value of bf_threshold is probably not a wise choice as it will force the encoder to put B-frames in places that would not benefit from them, therefore reducing visual quality. However, if you need to be compatible with standalone players that only support old DivX profiles (which only supports up to 1 consecutive B-frame), this would be your only way to increase compressibility through using B-frames.

  • trellis Optimizes the quantization process to get an optimal tradeoff between PSNR and bitrate, which allows significant bit saving. These bits will in return be spent elsewhere on the video, raising overall visual quality. You should always leave it on as its impact on quality is huge. Even if you are looking for speed, do not disable it until you have turned down vhq and all other more CPU-hungry options to the minimum.

  • hq_ac Activates a better coefficient cost estimation method, which slightly reduces file size by around 0.15 to 0.19% (which corresponds to less than 0.01dB PSNR increase), while having a negligible impact on speed. It is therefore recommended to always leave it on.

  • cartoon Designed to better encode cartoon content, and has no impact on speed as it just tunes the mode decision heuristics for this type of content.

  • me_quality This setting is to control the precision of the motion estimation. The higher me_quality, the more precise the estimation of the original motion will be, and the better the resulting clip will capture the original motion.

    The default setting is best in all cases; thus it is not recommended to turn it down unless you are really looking for speed, as all the bits saved by a good motion estimation would be spent elsewhere, raising overall quality. Therefore, do not go any lower than 5, and even that only as a last resort.

  • chroma_me Improves motion estimation by also taking the chroma (color) information into account, whereas me_quality alone only uses luma (grayscale). This slows down encoding by 5-10% but improves visual quality quite a bit by reducing blocking effects and reduces file size by around 1.3%. If you are looking for speed, you should disable this option before starting to consider reducing me_quality.

  • chroma_opt Is intended to increase chroma image quality around pure white/black edges, rather than improving compression. This can help to reduce the "red stairs" effect.

  • lumi_mask Tries to give less bitrate to part of the picture that the human eye cannot see very well, which should allow the encoder to spend the saved bits on more important parts of the picture. The quality of the encode yielded by this option highly depends on personal preferences and on the type and monitor settings used to watch it (typically, it will not look as good if it is bright or if it is a TFT monitor).

  • qpel Raise the number of candidate motion vectors by increasing the precision of the motion estimation from halfpel to quarterpel. The idea is to find better motion vectors which will in return reduce bitrate (hence increasing quality). However, motion vectors with quarterpel precision require a few extra bits to code, but the candidate vectors do not always give (much) better results. Quite often, the codec still spends bits on the extra precision, but little or no extra quality is gained in return. Unfortunately, there is no way to foresee the possible gains of qpel, so you need to actually encode with and without it to know for sure.

    qpel can be almost double encoding time, and requires as much as 25% more processing power to decode. It is not supported by all standalone players.

  • gmc Tries to save bits on panning scenes by using a single motion vector for the whole frame. This almost always raises PSNR, but significantly slows down encoding (as well as decoding). Therefore, you should only use it when you have turned vhq to the maximum. Xvid's GMC is more sophisticated than DivX's, but is only supported by few standalone players.

7.4.3. Encoding profiles

Xvid supports encoding profiles through the profile option, which are used to impose restrictions on the properties of the Xvid video stream such that it will be playable on anything which supports the chosen profile. The restrictions relate to resolutions, bitrates and certain MPEG-4 features. The following table shows what each profile supports.

 SimpleAdvanced SimpleDivX
Profile name0123012345HandheldPortable NTSCPortable PALHome Theater NTSCHome Theater PALHDTV
Width [pixels]1761763523521761763523523527201763523527207201280
Height [pixels]144144288288144144288288576576144240288480576720
Frame rate [fps]15151515303015303030153025302530
Max average bitrate [kbps]646412838412812838476830008000537.648544854485448549708.4
Peak average bitrate over 3 secs [kbps]          800800080008000800016000
Max. B-frames0000      011112
MPEG quantization    XXXXXX      
Adaptive quantization    XXXXXXXXXXXX
Interlaced encoding    XXXXXX   XXX
Quarterpixel    XXXXXX      
Global motion compensation    XXXXXX      

7.4.4. Encoding setting examples

The following settings are examples of different encoding option combinations that affect the speed vs quality tradeoff at the same target bitrate.

All the encoding settings were tested on a 720x448 @30000/1001 fps video sample, the target bitrate was 900kbps, and the machine was an AMD-64 3400+ at 2400 MHz in 64 bits mode. Each encoding setting features the measured encoding speed (in frames per second) and the PSNR loss (in dB) compared to the "very high quality" setting. Please understand that depending on your source, your machine type and development advancements, you may get very different results.

DescriptionEncoding optionsspeed (in fps)Relative PSNR loss (in dB)
Very high qualitychroma_opt:vhq=4:bvhq=1:quant_type=mpeg16fps0dB
High qualityvhq=2:bvhq=1:chroma_opt:quant_type=mpeg18fps-0.1dB