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

[Michael Niedermayer]

Hi

On Wednesday 02 October 2002 15:37, Christoph Lampert wrote:
> On Wed, 2 Oct 2002, peter ross wrote:
[...]
> 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?
yes, this is for the arithmetic coder IIRC, which is used for wavelet coded 
images in mpeg4 IIRC

[...]

Michael