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

[Michael Niedermayer]

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.


> 
> I've already explained why I don't do any work on swscale: I cannot
> comprehend the code, and every time I've attempted to do anything with
> it, I've ended up breaking something.

But the patch you wrote for the x86-64 accurate scaler stuff (i assume
you mean that) was a very complex part. Factorizing code and cleanups
are not at all.
There are trivial things like droping of #if 0 code, fixing indention to
match ffmpeg style and such that really do not need any kind of 
"comprehend the code".


> 
> Michael wants swscale to be the default/only scaler.  It is thus his
> duty to get it into a shape worthy of that position.  He's made a good
> start, but the work is far from complete.

>  Luca has posted some
> patches to further clean it up, so why doesn't Michael work with him
> on getting these committed?  Then we'd have an lgpl swscale (albeit
> unaccelerated), and nobody should have any objections to dropping the
> old scaler entirely.

You are deeply confused, there is no patch that replaces the gpl yuv2rgb
table generator. What there is,
is a git repo from the soc student that
contains the begin of a failed rewrite of swscale, this rewrite does one
thing and that is remove litterally all asm code. It does not replace
the preprocessor mess, not factorize code, not fix bugs, not add features,
not replace the template mess by function pointers.

The second part that exists is the begin of a failed yuv2rgb rewrite, here
the student choose to use wiki instead of git to keep track of the code,
the code contained assumtations like a^b being pow(a,b).

The third i remember where 2 patches written and posted by luca,
the first was commited the second has been reviewed and iam waiting for some
changes


> 
> I'd even go as far as suggesting we treat libswscale as a new
> submission, and subject it to all the scrutiny that has come to be
> standard procedure in FFmpeg.

Well, why shouldnt we treat the default scaler as a new submission?
That would implicate it being unacceptable due to obviously being totally
inefficient and suboptimal, lacking slice support that we need for
avfilter, not maintaining full chroma resolution during scaling. Yes
ive fixed swscale already so it no longer subsamples chroma for rgb->rgb
rescaling.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080914/bcc8294b/attachment.pgp>