[FFmpeg-devel] [PATCH] Enable swscale by default

Måns Rullgård mans
Sun Sep 14 17:01:57 CEST 2008


Michael Niedermayer <michaelni at gmx.at> writes:

> On Sun, Sep 14, 2008 at 03:14:08PM +0100, M?ns Rullg?rd wrote:
>> Michael Niedermayer <michaelni at gmx.at> writes:
>> 
>> > On Sun, Sep 14, 2008 at 02:12:00PM +0100, M?ns Rullg?rd wrote:
>> >> Diego Biurrun <diego at biurrun.de> writes:
>> >> 
>> >> > On Sat, Sep 13, 2008 at 03:27:44PM -0700, Baptiste Coudurier wrote:
>> >> >> 
>> >> >> Michael Niedermayer wrote:
>> >> >> > I thought it was agreed in the droping of the old scaler thread
>> >> >> > that whoever wants a lgpl scaler will have to do the work.
>> >> >> 
>> >> >> I didn't agree _at all_ with that, and I will vote against.
>> >> >
>> >> > While I surely do not want to fan the flames, this has been a long time
>> >> > coming - I think it's time for the LGPL faction to stand up and work...
>> >> 
>> >> Until last night, I was under the impression that the switch to
>> >> swscale would only be done when the mmx parts were separated from the
>> >> main code, and an lgpl version could be built.  It would appear that I
>> >> was mistaken, if not misled.  Making the scaler and colourspace
>> >> converter gpl is effectively making all of ffmpeg gpl.
>> >
>> > I must admit i was myself not fully aware of a few consequences of droping
>> > the old scaler, like ./configure failing. Though i thought it was obvious
>> > that droping the old scaler would implicate one way or another no lgpl
>> > scaler until walkens yuv2rgb code was rewritten.
>> 
>> Why has it been repeatedly stated in the past, that the GPL-only parts
>> were only needed for mmx, and that a plain-C LGPL swscale is easily
>> possible, if this is not true?  If I were prone to conspiracy theories
>> (and I sometimes am), I might suspect this was an underhanded attempt
>> to make FFmpeg GPL without anyone noticing before it was too late.
>> I'm in a good mood today, so I won't make such accusations just yet.
>
> The only plain C GPL code that iam aware of that we need in there are
> 220 lines of yuv2rgb table generation code.
> Rewriting this is easy, luca did it already IIRC but walken
> claimed copyright on the rewritten table generator. Noone else dared to
> try again and i simply have no personal interrest in rewriting FOSS code
> due to its license being disliked by some other people.
>
> Also the scaler might almost function entirely without this table generator
> We by now have a almost complete plain C rgb->yuv path that doesnt need it.
> Though it from a technical POV would be better to keep this or a equivalent
> table generator because it means more flexibility in terms of speed vs.
> quality.

Can someone explain what the table should contain?  How hard can it be
to generate a table?

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list