[Ffmpeg-devel] [PATCH] ported SGI decoder to the new API

Michael Niedermayer michaelni
Wed Mar 28 12:50:31 CEST 2007


Hi

On Wed, Mar 28, 2007 at 04:24:30PM +0800, Xiaohui Sun wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Michael Niedermayer ????:
> > Hi
> > 
> > On Wed, Mar 28, 2007 at 09:52:36AM +0800, Xiaohui Sun wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Michael Niedermayer wrote:
> >>>> +
> >>>> +        count = (row - start) / stride;
> >>>> +        while (count > 0) {
> >>>> +            i = count > 126 ? 126 : count;
> >>>> +            count -= i;
> >>>> +
> >>>> +            bytestream_put_byte(buf, i);
> >>>> +            length++;
> >>>> +
> >>>> +            bytestream_put_byte(buf, repeat);
> >>>> +            length++;
> >>>> +        };
> >>>> +    };
> >>> with an input of 1 1
> >>> this loop would produce 0x82 0x01 0x01
> >>> instead of the shorter 0x02 0x01
> >>>
> >>> also its code duplication, the rle encoding code from targaenc.c should be
> >>> used or if your code is faster and works correctly then you should place it
> >>> in rle.c/h and make targaenc.c use it
> >>>
> >> I have read the code in targaenc.c, the rle code is below
> >> [...]
> >>     for(pos = start + bpp; count < FFMIN(128, len); pos += bpp, count ++) {
> >>         if(same != !memcmp(pos-bpp, pos, bpp)) {
> >> [...]
> >>
> >> This may not proper for sgi and here we compare each color in a pixel
> >> instead of the pixel,
> > 
> > yes, the code in targaenc.c would have to be extended to be able to compare
> > both colors and pixels
> 
> Another question. I found the RLE format is slightly different in SGI
> and TGA. for SGI, [...]if bit[7] of the first short is 0, then the count
> is used to specify how many times to repeat the value[...] in
> TGA,[...]This 7 bit value is actually encoded as 1 LESS THAN the number
> of pixels in the packet (a value of 0 implies 1 pixel while a value of
> 0x7F implies 128 pixels).
> If we want to let them use the same code, we have to provide it with
> additonal parameters, which will make it rather complex.

no, a simple common ff_encode_rle() function as suggested by kostya would
not increase in complexity due to different encodings

int ff_encode_rle(uint8_t *src, int size, int step, int bpp)

that is the function returns the number of run or raw values the
caller can then subtract 1 or flip the sign as needed

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070328/840636f1/attachment.pgp>



More information about the ffmpeg-devel mailing list