[XviD-devel] Extra padding after FrameCodeI/P

[suxen_drol]

On Mon, 13 Jan 2003 15:16:40 +0100 (CET) Christoph Lampert <chl@math.uni-bonn.de> wrote:

> 
> Hi,

HI
> 
> at the end of encoder_encode() there are 32 extra bits
> 0xFFFF, 0xFFFF written to bitstream. That's that for? 

it's a encore2 relic.

> Just to remove the risk of a bitstream-reader reading 
> undefined/out-of-bounds memory? There has to be a better 
> way, e.g. the encoding application simply allocing more mem.
> 4 extra bytes per frame is wasteful at very low bitrates, and
> also it's against MPEG-4 standard. 

yep. encoder_encode_bframes() never wrote 0xffff, only the older
encoder_encode() function.

padding before startcodes: while the iso suggests this, i dont think it
was the authors intention.

vfw 0x7f: i agree christoph:
using the new api, xvid_encore(XVID_ENC_ENCODE,xxx) will return:
	<0	an error (XVID_ERR_xxx values..)
	0	ther was no encoder output 
		(vfw can then perform its 0x7f hack)
	>0	the number of output bytes (previously "frame.length")

-- pete; life is like a box of ammo