[XviD-devel] Invalid stuffing bits and divx 5.0.3 qpel

[b0b0l0l0 at free.fr]

En réponse à Christoph Lampert <chl at math.uni-bonn.de>:

[stuffing bits fix]
 
> The 0xFFFF were plain wrong. Most likely they were inserted for some
> Windows VfW compatability or something. Anyway, they are against the
> standard, so they have to be removed. 
> The BitstreamPad() routine pads the Bitstream to full byte boundary if
> needed by inserting one 0 bit and then 1 bits until the byte boundary
> is reached. 
> The BitstreamPadAlways() routine does the same, but it _always_ writes
> the first 0 bit, so BitstreamPadAlways() writes 1 to 8 bits to stream,
> whereas BitstreamPad writes 0 to 7 padding bits.

Ok I've been trapped since I was looking at the code in the
release-0_9_1-fixes branch in which BistreamPad() isn't up-to-date
compared to the version in the HEAD branch.
 
> At the end of VOP, BitstreamPadAlways() is required, if I remember
> correctly. 

You're right.

By the way, I've also noticed some problems with divx pro 5.0.3 qpel. The 
bitstream generated by divx with qpel enabled produces some chroma glitches 
once decoded with xvid or other mpeg4 codec (3ivx, momusys, etc). According to 
their changelog, they are supposed to comply with 14496-2 DCOR1 (N4740) but I 
can't manage to decode their stream with any decoders. Have you any idea of 
what could be wrong (except that divx is bugged ;)

Bobololo.