Re: [libdv-dev] Attempting to port libdev to win32

[Charles 'B. K. <kr...@ac...>]

John Carter <jn...@ec...> writes:

> I cured this when I realized that the on X86 implementation (the C
> code) was probably for a Sun or other such machine with a different
> byte order.

No.  Libdv's native home is x86 linux.  I use Redhat 7.0 myself.  I've
had some users report experiences porting to SGI/IRIX.

> So the parse.c was changed as follows

> #if !ARCH_X86
> #if WIN32
>      dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] / 8) * 8) +
>      (dv_88_reorder_prime[i] % 8);
> 
> #else
>      dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] % 8) * 8) +
>      (dv_88_reorder_prime[i] / 8);
> 
> #endif
> #else
>      dv_reorder[DV_DCT_88][i] = ((dv_88_reorder_prime[i] % 8) * 8) +
>      (dv_88_reorder_prime[i] / 8);
> 
> #endif

> going back to the byte order of an Intel machine.

Your change is definitely wrong.  The conditional in the code above
isn't about byte order.  It is about transposing the DCT coefficients
as part of re-ordering, because the mmx iDCT expects them that way.

> As I said, this cured the segmentation fault, and even produced
> pictures, but they were almost unrecognizable, similar to a
> television picture with a dubious horizontal sync, and lots of block
> errors.

> I've also attempted to recompile the assembly language version with
> the cygwin implementation of gcc, but have had to make many changes,
> and it currently blows up as it starts.


> Before I go any further I would appreciate some advice and
> information.

> Should the C code compiled on an Intel machine give the same results
> as the assembler version?

Umm, not exactly.  Some of the assembly routines are less precise than
their C counterparts, for example the idct.  Also, the C parsing code
is a little more robust.  In particular, the assembly version will
segfault on some faulty streams where the C version does not.


> If not, is it a byte order problem and could I have some pointers
> where to look.


> Is it possible to build a C version under linux so I can see exactly
> what is going on and what the differences are?

Yes.  

  ./configure --disable-asm


> Any other advice would be wonderful, unfortunately not doing this is
> not an option. I have the SMPTE standard and will probably start
> there next


> Thanks in advance,

> John Carter

I'm suprised how hard this is.  I may take a stab at it myself over
the weekend.

-- Buck