[XviD-devel] [BUG/PATCH] VOL header/forced stuffing

[Edouard Gomez]

Hello, as i pointed in an earlier mail, our bitstream was buggy in the
VOL/VOP headers.

I did some work on dev-api-4 and found what was wrong.

Here is what i answered to the forum thread:

<forum>
Ok i get something compliant now, there were two or three errors in our
VOL writer function:

1/ we did not write video_signal_type, but we were padding to the next
byte, that's why we had video_signal_type=0 and then only 1s until the
next byte boundary. This explains the 11 next_start_code();

2/ video_object_type_indication = Reserved is right on my machine,
please check again, but i doubt there is a bug there, we use 3 hard
wired values and none of them is zero.

3/ 01 : next_start_code() *** Was wrong in 24.02.2003; is correct in
dev-api-4!!! *** was a bug in fact... when we write user data, we pad to
the next byte boundary (if needed) like the standard says... by
chancepadding was almost always done, thus the next_start_code() was
respected.

(see the patch, for the 3 above bugs, concerned chunks are in the
bitstream/bitstream.c diff part)

4/ The extra stuffing bits were caused by a forced padding between our
VOL function writer and VOP header function writer (see the patch,
concerned chunks are in encoder.c diff part).

The patch is available there:
http://ed.gomez.free.fr/vrac/bitstream-errors.patch

By chance most of these bugs were (mostly) compensated. And thanks for
your detailed bug report, it has been very good at pointing exactly the
bugs.

Thanks

PS: when the patch will show to be conform to the standard (ie. doesnot
introduces other bugs) then it will be commited. I'll also debug older
versions (cvshead and 0.9.x branches)
</forum>
 
Could other devs test that patch with the MSFDAM and MoMuSys to see if
that fix the problem.

PS: is there a MPEG4 syntax checker available somewhere ? Syskin, are
you writing such a thing for the matroska MPEG4 parser ?

-- 
Edouard Gomez