[FFmpeg-devel] [PATCH] swscale: fix To{Y, UV} extern prototypes.

[Ronald S. Bultje]

On Sun, Sep 30, 2012 at 1:18 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Sun, Sep 30, 2012 at 08:48:23PM +0200, Clément Bœsch wrote:
>> On Sun, Sep 30, 2012 at 05:04:20PM +0200, Michael Niedermayer wrote:
>> > On Sun, Sep 30, 2012 at 10:54:02AM +0200, Clément Bœsch wrote:
>> > > This fix a bunch of "assignment from incompatible pointer type" warnings
>> > > with GCC.
>> > > ---
>> > > What I'm afraid of is that the prototypes don't seem to match what's in
>> > > sws/x86/input.asm (based on the comments) in comparison to the C versions in
>> > > sws/swscale.c.
>> >
>> > i think the comments are wrong
>>
>> OK, see attached patch then.
>>
>> > following is the difference of the input.asm "prototypes" to libav
>> >
>> > -cglobal %2 %+ 24ToY, 3, 3, %1, dst, src, w
>> > +cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, u3
>> > -cglobal %2 %+ 24ToUV, 3, 4, %1, dstU, dstV, src, w
>> > +cglobal %2 %+ 24ToUV, 7, 7, %1, dstU, dstV, u1, src, u2, w, u3
>> > -cglobal %2%3%4%5 %+ ToY, 3, 3, %1, dst, src, w
>> > +cglobal %2%3%4%5 %+ ToY, 6, 6, %1, dst, src, u1, u2, w, u3
>> > -cglobal %2%3%4%5 %+ ToUV, 3, 4, %1, dstU, dstV, src, w
>> > +cglobal %2%3%4%5 %+ ToUV, 7, 7, %1, dstU, dstV, u1, src, u2, w, u3
>> > -cglobal %2ToY, 3, 3, %1, dst, src, w
>> > +cglobal %2ToY, 5, 5, %1, dst, unused0, unused1, src, w
>> > -cglobal %2ToUV, 3, 4, %1, dstU, dstV, src, w
>> > +cglobal %2ToUV, 4, 5, %1, dstU, dstV, unused, src, w
>> > -cglobal %2ToUV, 3, 4, %1, dstU, dstV, src, w
>> > +cglobal %2ToUV, 4, 5, %1, dstU, dstV, unused, src, w
>> >
>>
>> Right, OK
>>
>> >
>> > >
>> > > AFAIU, those prototypes were simplified by libav but it seems they were kept
>> > > unchanged in FFmpeg (because of a bug? because the prototypes could be shared
>> > > with the others functions?). Though, it might be important to check the if the
>> >
>> > the prototypes where the same originally, the additional fields
>> > where added by me to support planar RGB (packed was fine with 1 pointer
>> > but planar needed 3)
>> > libav later reimplemented planar rgb support by adding a seperate
>> > function pointer that takes 3, leaving the existing with 1 and adding
>> > a if() to all calls
>>
>> Wouldn't it make sense to keep them in sync?
>
> in sync with libav? to simplify merge work?
> that makes only sense when libav will continue to work on sws and
> there is something to merge ...
> and recent rumors dont point in that direction.
> that said we certainly can switch to the 2 fptr API. And we certainly
> should integrate all improvments anyone does on a swscale fork or
> another scaler.

See, it's these kind of statements, so full of utter arrogance, that
make me actually want to do the libswscale fork/rework. I could
probably be convinced at some level that it should be done in swscale,
but why on earth would I care if this is the best I get in response
for all my efforts?

*merge*
*hahahahaha look ffmpeg is better suckers*

You have a lot to learn about social skills, Michael.

Ronald