[FFmpeg-devel] [PATCH] Enable swscale by default
Sun Sep 14 03:13:46 CEST 2008
On Sat, Sep 13, 2008 at 11:45:29PM +0100, M?ns Rullg?rd wrote:
> Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:
> > Hi,
> > 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:
> >>>> Hi
> >>>> 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
> >>>> vhook="default"
> >>> 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
> > imgconvert.
yes, but imgconvert is slow, its low quality scaler, and does not support
slices. Fixing imgconvert would be orders of magnitude harder than cleaning
up swscale ...
Besides of course a more powerfull scaler inevitably is more complex.
Cleaning up swscale is largely moving code around, getting rid of the
preprocessor templating magic and use normal function pointers in the
context for the various optimizations. Factorizing code, ...
> > IMHO if you want people working on libswscale, it must be cleaned up _a
> > lot_ before I see this happening.
What stops you and mans from helping with cleaning it up?
> 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
> accept it?
No, swscale is messy, i am the last who would dispute that.
ffmpeg has accumulated some messy code and theres no real choice besides
cleaning it up. What is special about swscale is that there is another
very primitive and thus also easy to understand scaler that
pulls manpower away from it.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Thouse who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel