[XviD-devel] "Autoselecting" IDCT for SimpleIDCT encodes

Michael Militzer michael at xvid.org
Mon Dec 29 22:37:32 CET 2003

Hi all,

Quoting Edouard Gomez <ed.gomez at free.fr>:

> Dirk Knop (dknop at stud.uni-goettingen.de) wrote:
> > Since there are  a few bitstreams out there  with the bitstream number
> > 009 (I think) we were thinking about adding an automatic pre-selection
> > in bitstream.c (switch to simple if bitstream number is 009) - if that
> > selection is wrong, the user still can select the idct from dshow.
> Your input data is somewhat wrong, bitstream 0009 has been used for many
> time in CVS, you  built a binary from it using this,  but i'm sure there
> are 95% encodes with this BS version that is using Walken iDCT.

Hm, Koepi and Nic also included simple idct for a rather long time in
their builds, so I'm not sure that 95 percent is a good guess. However I
agree that there were many more XviD builds out there than just Koepi's
and Nic's. We have uManiac and some others too who distribute plain vanilla
CVS builds which used Walken idct with bitstream 0009. Also, there's also
the Linux world where simply everybody was using Walken all the time. So
I think simply using simple idct for bitstream no. 0009 might not be the
best idea.

> But extending the automatic detection scheme, you can do it:
>  - check if your build used to have wrong VOL headers (signal type
>    missing) Look at the changelog of xvid 1.0 to have an idea when i
>    did ccommit a fix for that.
>  - try to see if other bitstream signatures can help detecting the
>    faulting version *only*
> Btw  we  should also  add  automatic detection  of  edging  bug (old  BS
> versions <--  this one is  easy to spot,  the bug is there  since... the
> very early days :-)... which can cause more trouble than an iDCT drift.

Well, it would be great if the builds in question could be detected by bit-
stream version + characteristic bitstream 'signature'. However I doubt so,
especially it seems impossible to decide between Koepi's windows build
and a stream created with Linux at around the same time. However, most
likely most people don't encode on Linux and later on play back their
streams on Windows, so this problem might be neglectable.

BTW: no objections against some better autodetection of older XviD bugs. It
would be good to somewhat improve the compatibility between older and newer
XviD versions.


More information about the XviD-devel mailing list