DivX 5.1.1 PRO so slow?

[BloodyRipper]

Yesterday, I've been encoding 'Amelia' on my computer. It was DivX 5.1.1 PRO @ 1411 kbps with Quarter Pixel, GMC, Bidirectional Encoding, Fast Psychovisual Enhancements and Normal Pre-Processing Source. I noticed that when I checked 'Quarter Pixel', the 'Rate Control Mode' changed to 'Normal Qpel' - is it similar to any of these 'normal' (I mean standard, slow, slowest) settings ?? The worst thing is that the whole encoding took 16 hours !! First pass - 6:53 , second pass - 7:13 - is it something wrong with my computer? Usually, I'm not using Quarter Pixel, but I heard that when bitrate is higher that 1400 kbps, then I can enable the Quarter Pixel. Also, I usually use 'standard' rate mode setting and then - one pass codes in approx. two hours.

[jggimi]

DivX 5.1+ had significant changes to the encoding algorithms, and offered different techniques that are significantly slower than previous releases. From a performance comparison perspective, "Standard" in 5.1+ is similar to "Slowest" in 5.0. If you'd like to see a large number of threads on this subject, merely search with those two keywords.

For details on codec settings, including whether/when to use QPel, Slow or Slowest, you can review the excellent guide at http://www.divx.com/support/guides/DivXGuide51.pdf.

[Wolfman]

but I heard that when bitrate is higher that 1400 kbps, then I can enable the Quarter Pixel.
Actually I heard its the opposite.. qpel has some advantage on a low bitrate encoding but very little on high bitrates such as yours, whilst however increasing encoding time significantly.

[Nazgul]

Originally posted by Wolfman
Actually I heard its the opposite.. qpel has some advantage on a low bitrate encoding but very little on high bitrates such as yours, whilst however increasing encoding time significantly.

Check out page 80 of the Official Guide, it says that using Qpel increases the number of bits spent on motion vectors(which would make sense, when you increase the precision of a number you need more digits to represent it), leaving fewer bits for the rest of the info to be encoded. So the question becomes, do the bits you save by using Qpel motion vectors to describe the picture rather than just encoding that block again get balanced out by the number of bits you now have to use to describe those Qpel motion vectors.