[XviD-devel] how to make struct smaller

[syskin at ihug.com.au]

Hi,

gruel wrote:
> Yes, that was the reason why I didn't make vectors into unions from the
> beginning (it would be nice to check them for zero as 32bit, but still be
> able to address them as 2 16bit as well).

You can still cast a vector to uint64_t and check for zero ;) Actually this would be the
best 
reason to keep vector as { int32_t, int32_t } rather than { int, int }.

> In any way: This is not a change relevant for
> functionality of XviD 1.0. Please don't just commit to the 
> hopefully-soon-to-be-released branch. 

OK deal ;) I'll just remove mv16 and mb_type because they are never used (mv16 like for 
ages, mb_type since I updated decoder.c two days ago).

BTW I recently gained 2-3% encoding speed. The thing is, we treat interpolated pictures 
(refH, V, HV) like temporary buffers which are filled at the beginning of FrameCodeX and 
fogotten at the end of FrameCodeX. However:

1) when the first B-frame is coded, FrameCodeB creates intepolated pictures for 
references. Next B-frame does not need to create them again, ever. Same for 
SetEdges().
2) the past reference is almost always interpolated. It's not interpolated only if future 
reference is an I-frame. If not, it's got correct rounding in 50% of cases (and is
correctly 
edged always).
3) when we code new P-frame, and the reference of this frame was also a (future) 
reference for a B-frame, we don't have to SetEdges() and again we don't have to create 
interpolated pictures in 50% of cases.

I was able to code 1) and 3) and the SetEdges() part of 2) very easly. The rest of 2) 
requires some FRAMEINFO and ENCODER struct sanitization - interpolated pictures 
need to be bounded with the real picture rather than being just buffers accessible from 
pEnc.

Again, comments?

Radek