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

Bobololo b0b0l0l0 at free.fr
Thu Mar 20 05:02:32 CET 2003


On Wed, 19 Mar 2003, Michael Niedermayer wrote:

> > > > ffdshow/ffmpeg/mplayer should decode it correctly, if not then upload a
> > > > sample file to ftp://mplayerhq.hu & tell me that u did
> > >
> > > btw, IIRC its some chroma MV rounding bug in divx 503 which causes this
> >
> > Do you have a sample? As far as I heard, DivXnetworks believes QPel chroma
> perhaps, but i cant find it, i guess any video with slow moving stuff should
> do

I've done a few more tests and you may be interested by the results. I've
uploaded coastguard_cif-q3-qpel.m4v to ftp://mplayerhq.hu/MPlayer/incoming

This file is an elementary stream generated (m4v) using DivX 503 Pro. The
encoding settings are :

- rc = constant quantiser set to 3
- slowest motion estimation
- max keyframe interval = 300
- use quarter pel

I decoded this stream with XviD using xvid_decraw. Except the fact
that only 285 frames are decoded due to the very basic input buffer
management, the result is near from DivX decoding. I think there is a
problem with the chroma that we can see from frame 28 (red color shift
on the upper boat).

ffmpeg completely failed to decode this stream. I guess it's probably an
issue with the raw elementary reading since it doesn't seem to find the
VOPs position correctly in the stream. I've tried to look at the sources
and WoW! This piece of code is for real programmers :))

Both XviD and ffmpeg I used were directly checked out from their
respective CVS repositories (HEAD branch).


Bobololo.

ps: The m4v file was generated using vfwbench I uploaded a while ago.
    If needed, I can send/upload it to you, just ask.


More information about the XviD-devel mailing list