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

[Michael Niedermayer]

On Sun, Sep 14, 2008 at 04:01:57PM +0100, M?ns Rullg?rd wrote:
> 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?

not hard, but first to awnser justins similar question. Posting the
output is useless because it depends on contrast, saturation, ... parameters.

What the tables contain is so that
8bit u, v, y0, y1 of 2 pixels YUV 4:2:2 can be converted to RGB by

    pr = tab_rV[v];
    pg = tab_gU[u] + tab_gV[v];
    pb = tab_bU[u];

    pixel0= pr[y0] + pg[y0] + pb[y0];
    pixel1= pr[y1] + pg[y1] + pb[y1];

pixel0 and pixel1 here are 32 bit rgb/bgr32 or 16 bit rgb/bgr 15/16


rgb/bgr24 is a special case for which the code looks like
    pr = tab_rV[v];
    pg = tab_gU[u] + tab_gV[v];
    pb = tab_bU[u];

    pixel0r= pr[y0];
    pixel0g= pg[y0];
    pixel0b= pb[y0];
    pixel1r= pr[y1];
    pixel1g= pg[y1];
    pixel1b= pb[y1];

tab_* thus contain pointers and the type of the pointers pr/pg/pb depends
on the output.

The tables depend on the yuv type and 255 vs 219/224 range as well as a few
parameters like user specified contrast and brightness.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- 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/a4d01d79/attachment.pgp>