[XviD-devel] [CVS commits] head -- Stable merge + decoder optims

[Christoph Lampert]

> Here is what i remember and what i analysed:
> - DECODER struct holds 32 bit values for bp and pp
> - in decoder.c, i dunno why, but a - operation is supposed to
>   give 64bit
> - 64bit values were introduced in *encoder* because there was
>   no safe way to do bp/pp using 32bits, and 64bit were just so
>   easy to use in order to solve the problem.
> 
> As i see it, 64bit introduced by christoph were in encoder.c,
> not in decoder.c. And afaict, 64bit aren't needed to
> interpolate vectors.
> 
> Of course, christoph is the one who can confirm this. Waiting
> for his answer.

Boy, long ago.

Yes, I did the 64bit timecodes in encoder, because, err... because...
I guess it must have been an overflow thing (everyone surprised).

Possibly like this: time_increment itself is at most 16 bit in the
bitstream, but to simply calculation of TRD for B-VOPs, I wanted to have
an absolute and unique time value for every frame encoded (at least until
hell freezes => 281 zillion frames), and not just the relative values
"since last I-VOP" or "since last second". Since a clip can have much more
than 65536 frames, 32 bits wasn't enough when using time_increment as
stepwidth. So, I switched to 64bit for the encoder's internal timestamp.  
In the decoding, that doesn't matter, because timestamp is just used for
B-VOP distances and there the 32 bit values cannot overflow.

I can't see a problem for 64bit architectures, but if 64bit is a problem,
there surely would be a workaround using really only MPEG-4 internal
method of counting (16 bit per value, 32 for arithmetics). However, at
that time I was too lazy to find that and to then debug till it works. 
I guess I still am. 

chl