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

Michel Bardiaux mbardiaux
Wed Mar 28 11:14:22 CEST 2007


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.
> 
Not to mention that some form of RLE encoding still has to be added to
the bmp encoder, and there are the msrle and qtrle codecs too. WHich
means that a common set of RLE functions will be *very* complex (not
just 'rather'), maybe so complex that accepting the duplication of code
might actually be better.

Greetings,
-- 
Michel Bardiaux
R&D Director
T +32 [0] 2 790 29 41
F +32 [0] 2 790 29 02
E mailto:mbardiaux at mediaxim.be

Mediaxim NV/SA
Vorstlaan 191 Boulevard du Souverain
Brussel 1160 Bruxelles
http://www.mediaxim.com/




More information about the ffmpeg-devel mailing list