[FFmpeg-devel] need help fixing sws on PPC

[Michael Niedermayer]

On Tue, Oct 07, 2008 at 09:24:26PM +0200, Vitor Sessak wrote:
> Michael Niedermayer escreveu:
>> On Mon, Oct 06, 2008 at 09:42:56PM +0200, Vitor Sessak wrote:
>>   
>>> Michael Niedermayer escreveu:
>>>     
>>>> On Wed, Sep 10, 2008 at 01:42:44PM +0200, Vitor Sessak wrote:
>>>>         
>>>>> Michael Niedermayer escreveu:
[...]
>>> @@ -2659,12 +2702,18 @@
>>>      int i;
>>>      uint8_t* src2[4]= {src[0], src[1], src[2]};
>>>      uint32_t pal[256];
>>> -    int use_pal=   c->srcFormat == PIX_FMT_PAL8
>>> -                || c->srcFormat == PIX_FMT_BGR4_BYTE
>>> +    int use_pal=   c->srcFormat == PIX_FMT_BGR4_BYTE
>>>                  || c->srcFormat == PIX_FMT_RGB4_BYTE
>>>                  || c->srcFormat == PIX_FMT_BGR8
>>>                  || c->srcFormat == PIX_FMT_RGB8;
>>>  +    use_pal = use_pal
>>> +                && c->srcFormat == PIX_FMT_PAL8
>>> +                && c->dstFormat != PIX_FMT_RGB32
>>> +                && c->dstFormat != PIX_FMT_RGB24
>>> +                && c->dstFormat != PIX_FMT_BGR32
>>> +                && c->dstFormat != PIX_FMT_BGR24;
>>> +
>>>      if (c->sliceDir == 0 && srcSliceY != 0 && srcSliceY + srcSliceH != 
>>> c->srcH) {
>>>          av_log(c, AV_LOG_ERROR, "Slices start in the middle!\n");
>>>          return 0;
>>>     
>>
>> This code makes no sense at all
>> it assumes that no scaling happens which surely is not correct but it
>>   
>
> indeed, changed the logic in my patch and fixed it.
>
>> likely is wrong in more ways than just that.
>>   
>
> Is swscale such a big mess that is that easy to break stuff?

dont insult my poor swscaler


>
>> also may i suggest that you use swscale-example to test that your changes
>> dont break things!
>>   
>
> I will as soon as I get a ssh from Hudo...

fine, but it has to be checked before commit


[...]
> @@ -2658,12 +2705,7 @@
>                int srcSliceH, uint8_t* dst[], int dstStride[]){
>      int i;
>      uint8_t* src2[4]= {src[0], src[1], src[2]};
> -    uint32_t pal[256];
> -    int use_pal=   c->srcFormat == PIX_FMT_PAL8
> -                || c->srcFormat == PIX_FMT_BGR4_BYTE
> -                || c->srcFormat == PIX_FMT_RGB4_BYTE
> -                || c->srcFormat == PIX_FMT_BGR8
> -                || c->srcFormat == PIX_FMT_RGB8;
> +    uint32_t pal[512];

what about putting a rgbpal and yuvpal in the context?
i think this would be cleaner than the "didnt you know the rgb pal was
at pal+256?!"

complaining about messyness of code and then adding more mess,
thats what people try to do to my little sws ;(

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20081007/a2b4672c/attachment.pgp>