[FFmpeg-devel] [PATCH] Enable swscale by default
Sun Sep 14 16:14:08 CEST 2008
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.
>> 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".
Any editing of code requires some level of understanding of what the
code actually does.
>> 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,
Of course I am. I looked at swscale code.
> there is no patch that replaces the gpl yuv2rgb table generator.
I never meant to suggest one existed.
> 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
Good. Separating generic and asm code should make it much easier to
understand what's going on.
>> 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?
We can't, simply because it's already in use. Libswscale is the
replacement, and as such should be required to be better in all
respects, including code quality, not just speed or features.
mans at mansr.com
More information about the ffmpeg-devel