[XviD-devel] divx5, bframes and non-coded vops

Christoph Lampert xvid-devel@xvid.org
Wed, 2 Oct 2002 15:37:05 +0200 (CEST)


On Wed, 2 Oct 2002, peter ross wrote:

> >g'day all,
> >
> >in packed-avi files (divx5.02+brfames), the divx5 decoder REQUIRES
> >n_vops otherwise it "forgets" to display the refernce pframe.
> >this is rather hilarious!
> 
> ive patched xvidcore to give improve compatbility with the divx5
> decoder. the bug where-by p-vops with [pb]-frames bug are decoder
> immediality still exissts.
> 
> its either caused by
> * invalid timestamps. however, i think xvid timestamps are 100%
>    correct now (thx gruel).
> * divx5 does not to detect the b-vop start code. maybe theres some
>    magic bits between the p-vop and b-vop; maybe it has to be 8-bit
>    padded, OR not padded?

I don't think you meant that, but vop start has to be 8-bit aligned.

# NOTE All the start codes start at the byte boundary. Appropriate number
# of bits is stuffed before any start code to byte-align the bitstream.

Is XviD stuffing corrected now? If I remember correctly, there 
was some issue with wrong values (too many zeroes) for stuffing
bits. 

There are many ugly things hidden in the standard, which I'm not sure
we care about (or we do, but DivX5 doesn't?), like this one: 

#7.13.1 Start codes and bit stuffing A start code is a two-byte code of
#the form  0000 0000 00xx xxxx . Several such codes are inserted into the
#bitstream for synchronisation purposes. To prevent any wrongful
#synchronisation, such codes shall not be emulated by the data. This is
#guaranteed by the insertion of a stuffing bit  1  after each byte-aligned
#sequence of eight 0 s. The decoder shall skip these stuffing bits when
#parsing the bit stream. Note that the arithmetic coder is designed such
#as to never generate a synchronisation code. Therefore the bit skipping
#rule does not need be applied to the portions of the bit stream that
#contain arithmetic coded data.

8 zeroes at byte boundary is e.g. possible if we have a high value
for VOP timebase (like windows 65535 -> 16 bit), which causes a high
number of bits to be saved for vop_time_increment. But since e.g. for the
first I-VOP and following N-VOPs vop_time_increment==0 
16 consecutive zeroes are written as timestamp at this position, 
surely leading to 8 of them begin byte aligned... then what?

Or did I overlook anything? 

gruel

> * divx5 fails to decode the b-vop, and returns an error leaving the
>    the p-vop in memory. highly unlikely.
> * or, something else???
> 
> damn this. i though i had divx5 compatibility figured out when i
> first uploaded the packed/dx50 code.