the option 'Quarter Pixel'

[loekverhees]

Hello,

When I convert a movie into XVID, I can choose in the XVID configuration panel the option 'Quarter Pixel'. Does someone know what that option mean. And should I use this option?

[anonymez]

Q-pel (or Qpel) is the short name for Quarter Pixel motion search precision and this option activates the use of quarter pixel precision.

Motion search tries to capture all the motion between one frame and the next, so that the macroblocks (MB's) can get the right motion vectors assigned to them. If the motion is properly captured then there will be no need for extra alterations to the MB other than a motion vector, sparing quite some bits. The more precisely the motion is captured, the less bits have to be assigned to the content of the MB's, and the more MB's can just consist of a motion vector.
So, theoretically, a more precise motion capture would save in altered texture information, thereby saving bits, and increase precision of the overall compression, thereby increasing quality. (We will soon see why this is just theoretically)

Normally XviD uses half-pixel motion search precision. This means that it can 'see' movement in a sub-pixel precision; if a MB moves from a width,height-position of 200,300 to 201, 300 in the next two frames, it can detect that movement correctly and can give the MB a motion vector that says "move me half a pixel to the right this frame please" in those next two frames. Motion will be captured correctly and no texture bits get altered.
Now with Qpel you can capture motion that is only a quarter of a pixel per frame, effectively doubling precision.
Example:
A MB that moves (fluently) from position 200,300 to 201,300 in the next four frames only moves one quarter of a pixel per frame. With normal half-pixel precision this motion would appear 'jumpy' and the codec might have to compensate for this by altering the texture bits of the MB. This of course takes space, and the MB would no longer consist of only a motion vector; it would have to be assigned additional bits for the altered texture information, thereby decreasing compressibility.
With Qpel that motion still gets captured correctly and not extra texture bits would have to be assigned, reducing the number of bits used for that frame.
Easy eh? But wait, there's a catch....

So, what's the catch?

The catch is, that just using the Qpel precision alone already uses additional bits, whether it helps saving bits or not.
This is caused by the additional precision that requires more bits to be allocated to the motion vectors. Instead that a motion vector could just be something like 0.5,0 (half a pixel width movement, no height movement) it would no have to be 0.25,0 (quarter of a pixel width movement, no height movement). So instead of one decimal after the point it now requires two decimals behind the point, requiring the codec to throw more bits at it.
(Please note that this is an oversimplification of the actual process, but it is accurate enough to get the point)
Instead of another decimal Qpel actually uses another extra bit (set either to 0 or 1) for every axis, which is enough to achieve double precision. There are two axes, one for width and one for height, so each motion vector requires two extra bits for Qpel.
If we assume that there is one vector for every macroblock (there might be 4 or 0), at the resolution of 640x272 and 24fps and P-frames only, two bits for every macroblock take 40 x 17 x 2 x 24 = 32640 bits or 32.5 kbps.
So, basically, no matter the outcome, Qpel always takes a sizeable chunk of the bitrate just for itself even if it doesn't help compression one damn bit.
Now usually it does help, but the texture bits saved by the better precision have to outnumber the added bits to the motion vectors before Qpel increases compressibility at the same size. If the saved texture bits outnumber the extra motion vector bits then you will have increased compressibility (and quality) at the same size. If the saved texture bits do not outnumber the extra motion vector bits you will have wasted space and the end result might look worse.

So how can I tell if Qpel will increase or decrease compressibility?

That's the other catch: You can't. Not in advance. There's no way to tell from looking at the source if Qpel will help or not. It doesn't matter if it's a fast motion scene or a low motion scene, a panning scene or a zooming scene...there's just no way to tell beforehand. A fast motion scene could be 90% Qpel movement or 90% Half-pixel movement, or any percentage in between...making any prior assumptions about the benefits of Qpel ridiculous.

The only real way to find out is to try encoding both with and without Qpel and see which result looks better.
(Now you can see why there is a difference between theory and practice...)

If you like more information read the discussion in this Doom9 forum thread
Some additional Notes:
-Because of the increased precision, Qpel significantly increases encoding time, and requires more processing power to decode. Encoding time can be almost doubled and decoding can require as much as 30-60% more processing power.
-Current 3ivX implementation normally uses half-pixel precision. As an 'advanced' option, you can tell it to use full-pixel resolution.
-In some older (alpha) builds Qpel could introduce artifacts, but the current implementation has no known bugs. It's safe to use.

[Walmart]

My yamada divx player will not play anything using quarter pixel, though i have not updated firmware in it for a couple of years and tbh i never use it.

Newer models may be able to play these discs were users ticked quarter pixel before encoding etc.
Check the manual for your divx player, assuming you are on about a standalone if not then ignore what i just typed.

[setarip]

To anonymez

Where did you find that info?

[Walmart]

who me ?

If me, then when i try and play divx in yamada, it tells me on screen qurater pixel is not supported.


EDIt stupid me, didnt see your TO Anon in subject

[anonymez]

@ setarip: right here http://ronald.vslcatena.nl/docs/xvidfaq.html

read this a couple of years ago, as my introduction to the xvid codec. very informative...

[setarip]

To anonymez

Thanks for posting the source of the information.

It "scared" me to think that a poster to these forums might be able to slap together such a classy looking technical white paper ;>}

[anonymez]

LOL