On Thu, Jan 15, 2015 at 3:24 PM, Martin Storsjö <[email protected]> wrote:
> On Thu, 15 Jan 2015, Vittorio Giovara wrote:
>
>> ---
>> libswscale/input.c                  | 5 ++---
>> tests/ref/fate/filter-pixfmts-scale | 2 +-
>> 2 files changed, 3 insertions(+), 4 deletions(-)
>>
>> diff --git a/libswscale/input.c b/libswscale/input.c
>> index f575b7b..e806bce 100644
>> --- a/libswscale/input.c
>> +++ b/libswscale/input.c
>> @@ -596,12 +596,11 @@ static void planar_rgb_to_y(uint8_t *dst, const
>> uint8_t *src[4], int width)
>>     }
>> }
>>
>> -static void planar_rgb_to_a(uint8_t *_dst, const uint8_t *src[4], int
>> width)
>> +static void planar_rgb_to_a(uint8_t *dst, const uint8_t *src[4], int
>> width)
>> {
>> -    uint16_t *dst = (uint16_t *)_dst;
>>     int i;
>>     for (i = 0; i < width; i++)
>> -        dst[i] = src[3][i] << 6;
>> +        dst[i] = src[3][i];
>> }
>>
>> static void planar_rgb_to_uv(uint8_t *dstU, uint8_t *dstV, const uint8_t
>> *src[4], int width)
>> diff --git a/tests/ref/fate/filter-pixfmts-scale
>> b/tests/ref/fate/filter-pixfmts-scale
>> index 712754c..408644b 100644
>> --- a/tests/ref/fate/filter-pixfmts-scale
>> +++ b/tests/ref/fate/filter-pixfmts-scale
>> @@ -12,7 +12,7 @@ bgr565be            922a2503767036ae9536f4f7823c04ee
>> bgr565le            3a514a298c6161a071ddf9963c06509d
>> bgr8                7f007fa6c153a16e808a9c51605a4016
>> bgra                a5e7040f9a80cccd65e5acf2ca09ace5
>> -gbrap               08ea11431bc436d788494d678b3edc6f
>> +gbrap               7df4fd8da27245788cb422794e03acd4
>> gbrp                205c50f8359cb4ba2827a7711dea2cc6
>> gbrp10be            30b7f9d5ef5da474fb794743146236aa
>> gbrp10le            2e9949a01fe4c38774728e34795165cc
>> --
>> 1.9.3 (Apple Git-50)
>
>
> Ok - I'm not familiar enough to comment much on the swscale internals, but
> this makes the output consistent on bigendian, and actually makes at least a
> fully opaque alpha plane stay that way after scaling, so ok as far as I can
> see.
>
> Karma points for scaling a picture with actual alpha (not just 255 for all
> pixels) and checking that it turns out right after scaling.

Yes I did test with a real alpha image :)

Updating the changelog to explain more what has been changed

    swscale: fix gbrap to gbrap alpha scaling

    Casting and shifting to uint16_t was incorrect, instead use the value
    from the alpha plane directly.

Thanks
-- 
Vittorio
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to