I'm not doing multiple threads, so not sure how this helps that.
FYI - I've been using a custom profile that has 4MV off; but have tested 4MV on as well, and so far there does not seem to be dependance on that flag elsewhere - the two builds continue to give identical results with vhq-b off.
I've decided to hold off on the qpel testing; I don't use it anyway, and it further multiplies the number of tests. (Though I did do one; vhqb=off, vhq=4, 4mv=on, qpel=on, h263, yeilding a single p-frame difference between the builds.)
There seem to be three major predicates in that vhq-b module; h263 or not, inter4v or not, qpel or not. So I'll try some test cases and see what turns up...
But I'm back to my "original" problem - which build (msvc, gcc), if either, is behaving "correctly"? Perhaps this is a gcc glitch...
Are there any xvidcore.dll builds around using yet another compiler? The ICL ones are out, since they differ no matter what encoder options I select...
BTW syskin, perhaps you can answer a question. I've noticed a several constructs in that module similar to this one
Code:
switch(mode) {
case MODE_DIRECT: return Data_d->iMinSAD[0];
case MODE_FORWARD: return Data_f->iMinSAD[0];
case MODE_BACKWARD: return Data_b->iMinSAD[0];
default:
case MODE_INTERPOLATE: return Data_i->iMinSAD[0];
My question is - is 'case interpolate' the correct path when mode is DIRECT_NONE_MV or (in particular) DIRECT_NO4V?