[XviD-devel] [CVS commit] 1.0.0 -- RGB16 fix.

Edouard Gomez ed.gomez at free.fr
Thu Apr 8 00:16:36 CEST 2004


suxen_drol (suxen_drol at hotmail.com) wrote:
> i agree with the plain c bug, however in his patch, "ROW" should be
> enclosed within round brackets.

Commited:

2004-04-07 22:01:54 GMT	patch-8

    Summary:
      RGB 16bit output fix.
    Revision:
      xvidcore--stable--1.0--patch-8

    From ScarletteTout (XviD Forum):
     * Fix RGB 16bit output in C functions.
    
    From ed.gomez:
     * Replaced PGM output by TGA output so it's easy to implement
       RGB 16/24/32 and greyscale bitmaps support in a single format.
       (pgm could have supported RGB 24 and Greyscale only)
     * Added colorspace choice to xvid_decraw
       Use option -c csp, where csp is either rgb16, rgb24, rgb32, yv12 or i420
       Defaults to i420.
    
    PS: original bug report
    http://www.xvid.org/modules.php?op=modload&name=phpBB2&file=viewtopic&t=1960&highlight=

    modified files:
     examples/xvid_decraw.c src/image/colorspace.c

> > I'll have a look, but at first sight, i believe his conclusions are a
> > bit too impacting, most of the MMX code would be buggy...
> 
> from his 19-Mar post:
> > And another thing. I often  see some wrong colored blocks (and shape
> > is even wrong) in decoded  sequnce, but if I compress and decompress
> > the same seq.  again, some blocks disappeared, some  moved, and some
> > added...  seems these wrong blocks were generated during ME decoding
> > randomly, not during encoding.
> 
> it should be consistanct, so maybe something else is causing it? 
> buffer overflow, emms issue? threads?

Yes i don't think MMX code is  the bug, but i think something is playing
bad with the MMX stuff.

> has any one tried running xvid_enc w/ valgrind recently?

Yes it's been part of beta stage fixes iirc (around devapi4
patch-100). No unitialized reads were left, and at that time, not a
single out of bound read was present, so i doubt RC releases did
introduce regressions.

I'll do some valgrind checking tomorrow on both the encoder and the
decoder.

PS: i'll do 1.0->head merging later (tla is very good at this kind of
things)

-- 
Edouard Gomez


More information about the XviD-devel mailing list