[XviD-devel] IA64-patch for dev-api-4

[Edouard Gomez]

Stephan Krause (s_kraste at ira.uka.de) wrote:
> Do You have a hint for me how to test? As i mentioned i didn't manage to get 
> transcode working with dev-api-4...

When i  fixed the 0.9.x tree  for various architectures, i  used to test
xvid only using  xvid_encraw, but of course i ran a  bunch of scripts on
various  sequences to  confirm the  port validity.  The problem  is that
these   scripts   are   somewhat    ugly   and   purely   for   personal
testing/checking. 

Anyway, what you can do is run tests on sequences found on:
http://www.cipr.rpi.edu/resource/sequences/sif.html

IIRC,  you'll  have  to  cat  all  frames into  one  big  file  to  feed
xvid_encraw.  Once  you  have  all  sequences  ready  to  be  used,  run
cbr/2pass/fixedquant  tests on  ia32 using  only C  version.  md5sum teh
resulting output streams.  Then do the same bunch of  tests on your IA64
machine, and check the md5sums. 

If  they  differ, there  is  a portability  issue  in  the code  (mostly
pointer<->init conversions, endianness or register sizes/overflow)

If they are equal, the  C version is portable accross the architectures.
Now you have to test the  assembly for your architecture. As the md5sums
will differ because of precision error  in dct stage, you can't use that
technic. In this  case what i used  to do, was to trust  the PSNR output
from xvid_encraw. If  the PSNR is somewhat equivalent  to ia32 runs, the
assembly code  does the right  thing. And when  i had doubts  about PSNR
output, i  used to  dump frames  and scp the  resulting frames  from the
sourceforge machines to mine to have a real look at the encoder output. 

As you see, it's  not really a test "process" but it's  a kind of recipe
that helped me find 4 or 5 bugs during 0.9.x ports.

PS: about the  patch inlining problem: you can put  patches on a website
and send the url.

-- 
Edouard Gomez