[XviD-devel] Question about xvid_decraw and XVID_DEC_FRAME.length property

[suxen_drol]

g'day

On Thu, 3 Apr 2003 16:20:30 +0100  Ricardo Ferreira <ricardo-c-ferreira at ptinovacao.pt> wrote:

> 1. What is XVID_DEC_FRAME.length property for?
> It seems that XVID_DEC_FRAME.length, as input for xvid_decore, represents
> the number of bytes presented in the bitstream ready to be processed (to
> prevent access violations). When returning from xvid_decore it gives the
> bytes consumed in this call.
> Am I right?

correct. 
however, in the upcoming dev-api-4 tree, the bytes consumed is specified
by the xvid_decore() return value.

> 2. To do some experiments I changed xvid_decraw.c code to try to only read
> 1000 bytes at each time instead of BUFFER_SIZE.
> What I get is an access violation error at the following line:
> block[scan[coeff]] = level; // in get_intra_block from mbcoding.c (line
> 1216)
> Is this a bug?

xvid lacks buffer proper underflow protection; we only use the
'frame.length' value whilst scanning for mpeg-4 start_codes.
so, xvid expects the buffer you provide to cover the entire vol or vop.

there is some overhead checking buffer underrun each time a bit is read
from the buffer.

> I carefuly analysed the code to catch any error regarding bitstream pointer
> and bitstream length but everything seemed ok.
> BTW, it seems that mp4_size it's useless and has to be changed by
> still_left_in_buffer in the following instruction: 
> status = dec_main(mp4_ptr, out_buffer, mp4_size, &used_bytes,
> &notification);
> My tests were made in both conditions (mp4_size and still_left_in_buffer)...

mp4_size sounds like a bug. i've cleaned up xvid_decraw in the dev-api-4
tree.

> Any comments will be appreciated.

any comments on how to improve (ie. strengthen) xvid's bit buffer will
be appreciated ;-)

-- pete