I just read on the DivX FAQs page that if you are doing an n pass encoding using DivX 5.1, you can encoding every pass except the last using Standard Mode, Write MV, and turn off PV. In the second last pass, then turn off MV and turn on PV. Then encode the last pass in Slow Mode.....

Sounds like a rather complicated procedure that one can only work out through experience, I guess. Anyway, does anyone have any good tips and tricks to get good DivX encodings (other than setting every slider to the fullest)?

I don't know how many passes you intend to do but I am going to give you a couple tips:
1) Don't use the mv if you intend to switch performance/quality and probably don't use PVE unless you are doing quite low bitrates. Apparently, changing the performance/quality along with the use of the mv will negate all the benefits of using a slower mode and it may actually even be worse. This is according to Gej at DXN.

2) Here is what I would do for the best compromise of speed/quality, first download 5.11 beta 2 which is a lot faster http://labs.divx.com and for a 3 pass encode do the first 2 passes in standard mode and then for the last pass switch to slow.

3) As for which ASP features you should or should not use, use b-frames all the time. Really the only time you should consider not using them is if your encode is undersized and you not happy with the quality. Don't use GMC it is absolutely useless. Quarterpixel will produce a good sharp picture but unfortunately it is not compatible with divx hardware, the authors of the codec only recommend its use if you are using a really high bitrates and don't care about playing it on divx hardware. Quarterpixel obviously takes a much more powerful chip to decode it.

EDIT: Just to emphasize, I did say slow, not slowest. IMO slow is a fairly decent compromise between quality and speed. Also if you are not using avisynth 2.5 and virtualdubmod you should be! If these programs really scare you then download gordainknot from http://gordainknot.sourceforge.net this will automate the avisynth/virtualdubmod procedure. This is faster because it will allow for no color conversions if your source is already in YV12 as in mpeg2. Say if you were encoding from a dvd source it is YV12->YV12 as opposed to YV12->YUY2->YV12.

You explained it essentially how it should be done.

1st Pass: Standard, MV-File ON, Bi-Di ON, PVE Off
2nd Pass: Standard, MV-File ON, Bi-Di ON, PVE Off
3rd Pass: Slow or Slowest, MV-File OFF, Bi-Di ON, PVE Fast ON

That's how it should be done for essentially all encodes. PVE in Fast mode is more aggerssive than PVE in Slow mode. PVE in Slow mode tries to make sure there are no noticeable artifacts in the video. PVE Fast is generally the recomended setting although you might want to test both before making a decision.

Bonzi's right, definately go and get DivX 5.1.1 Beta 2 to improve the speed of the codec.

Ok rather than just speculating on whether MV should or should not be used I decided to do some tests. I encoded the matrix reloaded trailer, 2291 frames, 704x304 res, 940kbps, w/ b-frames.

1) First Pass: Standard, MV written Second Pass: Standard, MV read Third Pass: Slow, MV not read

#RESULTS#
Average PSNR: 23.1157
Average SSIM: 0.521379
Average Scaled SSIM: 0.54604
Average VQM: 8.190705

#RESULTS IN DETAIL#

#PSNR#

Mean Absolute Deviation (Minimum/Average/Maximum): 0.1250 / 12.3104 / 49.6499
Mean Deviation (Minimum/Average/Maximum): -0.8565 / +5.3655 / +27.3888
PSNR (Minimum/Average/Maximum): 9.3292 / 23.1157 / 57.1617

#SSIM#

SSIM: (Minimum/Average/Maximum): 0.01504 / 0.521379 / 0.99318

SCALED SSIM: 0.54604

#VQM#

VQM Average: 8.190705

2) First pass: Standard No MV written Second Pass: Standard Third Pass: Slow

#RESULTS#
Average PSNR: 23.1234
Average SSIM: 0.521430
Average Scaled SSIM: 0.54647
Average VQM: 8.189937

#RESULTS IN DETAIL#

#PSNR#

Mean Absolute Deviation (Minimum/Average/Maximum): 0.1250 / 12.3100 / 49.6499
Mean Deviation (Minimum/Average/Maximum): -0.8565 / +5.3646 / +27.3888
PSNR (Minimum/Average/Maximum): 9.3292 / 23.1234 / 57.1617

#SSIM#

SSIM: (Minimum/Average/Maximum): 0.14170 / 0.521430 / 0.99318

SCALED SSIM: 0.54647

#VQM#

VQM Average: 8.189937

Ok, so I think it is safe to say that you can write the MV in the first pass, read it in the second pass and then NOT use it in the third pass.

@Bonzi: Your numbers look very strange - far worse than should be expected. An average deviation of +5 is WAY above what's acceptable. Have you compensated for b-frames before doing the compare?

Perhaps you should do a stackvertical and check if your frames match.

Yes they are quite low, the reason why I thought it was like this is because in order for this trailer to look good you must use very very high bitrate. Maybe even double what I used. The reason why I did this at lower bitrates is because I thought possibly at lower bitrates the difference between the two encodes might be larger while a higher bitrates almost zero difference might be observed. Probably I should have explained this though. But looks like I did make a mistake, I should have done these tests the way I always do them manually with psnr4avi and not PSNRCreator. Anyway I did another one manually this time. But for some reason the first about 160 frames were not correct it just returns garbage. And even after that it is not correct. It still doesn't work and believe me the frames are 100% the same the b-frames have been properly compensated for. I can't figure out what is wrong . Maybe I will turn off b-frames and try it again.

MV stands for Motion Vectors. The DivX codec uses an algorithm to calculate motion within a frame. The Performance slider increases (or decreases) the complexity of the algorithm. Therefore, every pass you do under a particular Performance setting should theoretically have the exact same motion vectors. This is why you can take advantage of the MV file in pass 2, but have to turn it off for pass 3.

But its a beta which means it will expire in the not-to-distant future, yes?

If you have DivX Pro then I don't think it expires. In any event Beta 2 is the last beta before the fully fledged 5.1.1 release.

Of course 5.1.1 has been released now with lots more supposed speed increases, though personally I prefer quality increases for a given filesize.

How much do you want dude. DivX 5.1 introduced some pretty big quality increases and with 5.1.1 they just refined the process. I'm sure the DivX guys will continue to boost quality in the coming months.

As much as I can get! I still prefer XviD. But they're all good these days - RV9, WMV9, DivX, XviD, Ffvfw - they just have different attributes and standards compliance etc. It just depends on what you prefer. I like details and a few blocks don't really bother me too much as long as they're not excessive, so I use XviD. Plus I talk to the devs a lot and do lots of testing. Just my own interest. XviD dev-api-4 is currently being optimised and debugged to iron everything out for a 1.0 release. They've already got plenty of ideas for post 1.0 XviD.

The following is also said in the new Divx 5.1.1 Guide

Like I said the motion vectors are calculated based on an algorithm which changes in accordance with the performance slider (or did in 5.0.5, now it's only availble on standard), so I don't see why it would reduce quality if you re-calculate the motion vectors when you up the performance slider (i.e. standard to slowest). The motion vectors should be identical at a particular performance setting (i.e. all passes done in standard mode should have the same motion vectors - this is the reasoning behind having the MV file so motion vectors don't have to be recalculated). However this is just theoretical and I haven't done any testing.

Ok, great I suppose it is safe now. The reason I made a big deal about it was I was told by Gej or one of the other divx developers to not use it in the beta releases because it had caused some nasty artifacts sometimes. I didn't see how it could cause a problem or even any samples where it did create artifacts but I thought it would be wise to do a little testing first. Anyway, I would use MV now in 5.11 since they have stated that it isn't a big decrease in quality. But anyhow I'm with superdump, I prefer XviD. Certainly, it is much faster IMO, at least dev-api-4 which will be XviD 1.0 soon.