View Single Post
Old 26th April 2007, 02:27   #31  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
Well as an experiment, I changed three lines in motion_inlines.h
Code:
	static const int r_mvtab[64] = {
to
	static const int r_mvtab[65] = {12,

	bits += r_mvtab[x+63];
to
	bits += r_mvtab[x+64];

	bits += r_mvtab[y+63];
to
	bits += r_mvtab[y+64];
then created normal msvc and gcc optimized builds and did four encodes - vhq-b=on, vhq=1, 4mv=off, with both h263 and mpeg quant, with both dlls.

Compared the paired output .pass and .avi files, and they are identical now!

Not saying the above is a "fix", but it does seem to show that both compilers are generating equivalent functional representations of the source code (unlike the ICL builds). I'll probably run some more comparison series (range of VHQ, range of cpu-flags), but I have much greater confidence that my builds are 'right' now.

I hope someone knowledgable will chime in and indicate if "-64" is a valid value for a vector component - if it is, then the above *is* a fix. If not, it's just a workaround for some badly behaved code elsewhere (which both msvc and gcc compilers are building as directed ) Might be interesting to see if this change improves psnr/ssim/xyzzy...

The other weirdness with the opt vs noopt msvc builds and that one asm routine - I'm not sure what to think about that one. As an experiment, I added a 'femms' instruction to the asm file just before the return, and it magically caused the noopt build to produce the same output as the opt build - not the other way around. Again, I hope someone more knowledgable will look at that oddity...
plugh is offline   Reply With Quote