[FFmpeg-devel] [PATCH] Enable swscale by default
Sun Sep 14 00:45:29 CEST 2008
Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
> Michael Niedermayer wrote:
>> On Sat, Sep 13, 2008 at 04:14:08PM +0100, M?ns Rullg?rd wrote:
>>> Michael Niedermayer <michaelni at gmx.at> writes:
>>>> The patch below enables swscale by default.
>>>> The intent is to get more exposure, testing and to avoid people wasting time
>>>> working on the old scaler.
>>>> Index: configure
>>>> --- configure (revision 15306)
>>>> +++ configure (working copy)
>>>> @@ -73,7 +73,7 @@
>>>> echo " --enable-nonfree allow use of nonfree code, the resulting libav*"
>>>> echo " and ffmpeg will be unredistributable [default=no]"
>>>> echo " --enable-postproc enable GPLed postprocessing support [default=no]"
>>>> - echo " --enable-swscale software scaler support [default=no]"
>>>> + echo " --disable-swscale disable software scaler support [default=no]"
>>>> echo " --enable-avfilter video filter support (replaces vhook) [default=no]"
>>>> echo " --enable-avfilter-lavf video filters dependant on avformat [default=no]"
>>>> echo " --enable-beosthreads use BeOS threads [default=no]"
>>>> @@ -972,6 +972,7 @@
>>>> enable protocols
>>>> enable static
>>>> enable stripping
>>>> +enable swscale
>>> swscale is still marked gpl-only, which means that with this patch, a
>>> plain ./configure will fail. This is IMO unacceptable. Before making
>>> swscale the default, we need to make the gpl parts optional, so it can
>>> still be built as lgpl.
>> You could have said that before i started to work on droping the old
>> scaler. I do not really disagree that a plain ./configure should not fail
>> but this leads to a deadlock because
>> 1. swscale depends currently on a yuv2rgb table generator
>> 2. ive no intent and made it clear in the past that i will not rewrite the
>> gpl yuv2rgb table generator
>> 3. noone else works on swscale, ignoring 2-3 small patches
> This might have to do with the fact that libswscale codebase is a
> _mess_, and I already gave up 2 days ago adding a new pixel format for
> 16 bit uncompressed quicktime. It is _much_ easier for me to add it to
> IMHO if you want people working on libswscale, it must be cleaned up _a
> lot_ before I see this happening.
I couldn't agree more. I have, on a few occasions, attempted to do
something or other with the libswscale code, and every time I have
found myself running away, screaming with terror.
Imagine that someone submitted libswscale as a patch today. Would you
> Im also strongly against a ffmpeg binary defaulting to gpl.
It's worse than that. It would make the lgpl FFmpeg practically
useless, since there would be no colourspace conversion or scaling
(assuming Michael makes good on his promise to remove the imgconvert).
>> 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.
I thought it was agreed since a long time that we'd drop the old
scaler when an LGPL version of swscale becomes a reality (possibly
>> And i suspect that noone will do this work when the old scaler is
>> still in svn, even less so when it is default.
> I don't think this is the main reason, see above.
This is certainly true for me.
mans at mansr.com
More information about the ffmpeg-devel