Digital Video Forums  

Go Back   Digital Video Forums > Video File Formats > AVI, DivX/Xvid

Reply
 
LinkBack Thread Tools Search this Thread Rate Thread Display Modes
Old 10 Jun 2005, 10:26 PM   #1
Junior Member
Junior Member
 
Join Date: Jun 2005
Posts: 4
Question the option 'Quarter Pixel'

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?
loekverhees is offline   Reply With Quote
Old 10 Jun 2005, 10:56 PM   #2
Super Moderator
 
anonymez's Avatar
 
Join Date: Mar 2004
Posts: 5,525
Default

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.
__________________
"What were the things in Gremlins called?" - Karl Pilkington

anonymez is offline   Reply With Quote
Old 10 Jun 2005, 11:07 PM   #3
Member
Member
 
Walmart's Avatar
 
Join Date: May 2004
Location: all over the planet
Posts: 53
Default

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.
Walmart is offline   Reply With Quote
Old 10 Jun 2005, 11:19 PM   #4
Retired
 
setarip's Avatar
 
Join Date: Dec 2001
Posts: 24,955
Default To anonymez

Where did you find that info?
setarip is offline   Reply With Quote
Old 10 Jun 2005, 11:24 PM   #5
Member
Member
 
Walmart's Avatar
 
Join Date: May 2004
Location: all over the planet
Posts: 53
Default

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
Walmart is offline   Reply With Quote
Old 10 Jun 2005, 11:25 PM   #6
Super Moderator
 
anonymez's Avatar
 
Join Date: Mar 2004
Posts: 5,525
Default

@ 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...
anonymez is offline   Reply With Quote
Old 12 Jun 2005, 04:26 PM   #7
Retired
 
setarip's Avatar
 
Join Date: Dec 2001
Posts: 24,955
Default 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 ;>}
setarip is offline   Reply With Quote
Old 12 Jun 2005, 07:05 PM   #8
Super Moderator
 
anonymez's Avatar
 
Join Date: Mar 2004
Posts: 5,525
Default

LOL
anonymez is offline   Reply With Quote
Reply

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




All times are GMT +10. The time now is 11:49 PM.

Kirsch designed by Andrew & Austin


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright © 1999 - 2018 Digital Digest

Visit DivXLand   Visit dvdloc8.com