[Ffmpeg-devel] (L)GPLed yuv2rgb code

Michael Niedermayer michaelni
Sat Dec 23 15:10:24 CET 2006


Hi

On Fri, Dec 22, 2006 at 09:57:09PM -0800, Michel Lespinasse wrote:
> On Fri, Dec 22, 2006 at 06:27:00PM -0800, Trent Piepho wrote:
> > The code you linked to looks to be nearly identical to this code here:
> > http://www.google.com/codesearch?hl=en&q=show:spitw_BsS18:XktR4Rb56GI:ZMtqWWQie4Y&sa=N&ct=rd&cs_p=http://libmpeg2.sourceforge.net/files/mpeg2dec-0.1.7.tar.gz&cs_f=mpeg2dec-0.1.7/libvo/yuv2rgb.c
> 
> Yes. I wrote this in 1998 or 1999, then sent it to aaron in april 2000
> (just fished the email - I thought it had been earlier:) for integration
> in his mpeg2dec. From then the code went to livid, then back into 'my'
> mpeg2dec after aaron stopped maintaining it, and then into apparently
> most everything else.
> 
> > It's from mpeg2dec-0.1.7 and claims copyright 1999-2000 Aaron Holtzman.  Of
> > course that doesn't necessarily mean Aaron Holtzman wrote it.  I've found
> > my code with someone else's copyright on it when they didn't write a single
> > line.  But this does appear to be the oldest version of the code I could
> > find, which is used all over the place.  I haven't found a version of
> > mpeg2dec older than 0.1.7 to see just how "new" the "new yuv2rgb code"
> > mentioned in the changelog for 0.1.7 really is.  Sometimes people think
> > changing a variable name makes something new.
> 
> I dont know how to get every version out of SVN - plus, at the time
> most things were just in aaron's private tree anyway, so we'd only see
> 0.1.5 then 0.1.6 then 0.1.7. But, at least 0.1.5 is accessible in SVN.
> At the time the code was in display_x11.c and as you can see it was
> quite different:
> https://trac.videolan.org/libmpeg2/browser/tags/MPEG2DEC_0_1_5/mpeg2dec-livid/display_x11.c?rev=9
> 
> It would of course be possible for someone to write a LGPLed routine that
> combines the Y,U,V values to generate an RGB pixel, but for this to be
> LGPLed it should be implemented based on a mathematical description of
> the operation to be performed rather than reuse the same particular
> combination of tables and logical operations that were used in the GPL code.

what you ask for is like saying dont use quicksort but rather start with
the problem of "sorting a list of elements" IANAL but i dont think copyright
does cover that, and note iam not saying that lucas code doesnt fall under
your copyright iam just saying that you cannot copyright the use of lookup
tables to solve a problem, and IMO not even a specific trick with LUTs

yuv->rgb has very commonly be done with LUTs, for example in my 2010 program
(which has copyright 1998 on top) i wrote

printf("Building YUV to RGB LookUp Tables!\n");
 yuv2rgb_lut=new char[256*4*2];
 for(i=0; i<256; i++){
   if(i>=128) j=i-256;
   else j=i;
   double d= double(j);

   yuv2rgb_lut[(i<<2)       ]= short( d * ( 1.734375) * 0.5 );
   yuv2rgb_lut[(i<<2) + 1   ]= short( d * (-0.34375 ) * 0.5 )
                             + is_pos(yuv2rgb_lut[(i<<2)       ]);
   yuv2rgb_lut[(i<<2) + 2   ]= is_pos(yuv2rgb_lut[(i<<2) + 1   ]);
   yuv2rgb_lut[(i<<2) + 3   ]= 0;

   yuv2rgb_lut[(i<<2) + 1024]= 0;
   yuv2rgb_lut[(i<<2) + 1025]= short( d * (-0.703125) * 0.5  );
   yuv2rgb_lut[(i<<2) + 1026]= short( d * ( 1.375   ) * 0.5  )
                             + is_pos(yuv2rgb_lut[(i<<2) + 1025]);
   yuv2rgb_lut[(i<<2) + 1027]= 0;
 }

and

printf("Building YUV to RGB LookUp Tables!\n");
 yuv2RgbLut=new unsigned short[256*128];
 for(int u=-16; u<=15; u++)
    {
    for(int v=-16; v<=15; v++)
        {
        for(int y=0; y<=31; y++)
            {
            int r= minmax(0, int( y + double(v) * 1.375                       +.5), 31); 
            int g= minmax(0, int((y - double(v) * 0.703 - double(u) * 0.343)*2+.5), 63); 
            int b= minmax(0, int( y                     + double(u) * 1.734   +.5), 31); 

            const int xLut= y + ((u&0x1F)<<5) + ((v&0x1F)<<10);
            yuv2RgbLut[ xLut ]= b + (g<<5) + (r<<11);

            }
        }
    }

both can be used under LGPL if anyone wants (note the first looks buggy ...)

also note, i wouldnt mind if the LGPL version of the swscaler would use
a slow naive implementation of yuv->rgb, just dont expect me to rewrite my
code in swscale.c which uses tables

[...]
-- 
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: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061223/8267352c/attachment.pgp>



More information about the ffmpeg-devel mailing list