[Ffmpeg-devel] moving non-SIMD parts of libswscale to LGPL

[Luca Abeni]

Hi all,

On Mon, 2006-11-13 at 14:19 +0100, Luca Abeni wrote:
[...]
> > ive copy and pasted the tables from the mpeg4 spec below ...
> > 
> > 
> > if video_range=0:
> >                      n-8          n-4
> >        Y  = ( 219 * 2   * EY ) + 2 .
> >                      n-8           n-1
> >        Cb = ( 224 * 2   * EPB ) + 2
> >                      n-8           n-1
> >        Cr = ( 224 * 2   * EPR ) + 2
> [...]
> Thanks for the explaination... I am going to study it, and see if I can
> come out with a proper replacement of the yuv --> rgb tables from
> yuv2rgb.c... But I'll need some time to study this stuff.
Ok; some time has passed, but I still have to fully understand what
yuv2rgb.c is doing.
The theory is simple, but I am not able to see how it matches the
current code :(
For example, the rgb ---> yuv conversion matrix for SMPTE 170M (the one
used by default) is
 Y = 0.2990 R + 0.5870 G + 0.1140 B      |0.2990  0.5870  0.1140|
 U = -0.169 R - 0.3310 G + 0.5000 B ---> |-0.169 -0.3310  0.5000|
 V = 0.5000 R - 0.4190 G - 0.0810 B      |0.5000 -0.4190 -0.0810|

Inverting it, I get
|1  0       1.4017  |
|1 -0.3437 -0.71417 |
|1  1.7722  0       |
so I'd expect Rv = 1.4017, Gu = -0.3437, Gv = -0.71417, and Bu = 1.7722
and I'd expect the values in Inverse_Table_6_9 to be a somehow rescaled
version of above (and I'd expect the scale factor to be 76309)... But
104597 / 1.4017 = 74622
132201 / 1.7722 = 74597
25675 / 0.3437 =  74702
53279 / 0.71417 = 74603
so the scale factor seems to be around 74600... Where is this value
coming from? And why is 76309 used in 
c->table_rV[i] = table_r + entry_size * div_round (crv * (i-128), 76309);
and similar?

Moreover, there are a lot of "magic numbers" that I cannot understand,
starting from the sizes of the table allocated in
yuv2rgb_c_init_tables(), and the offsets used to initialize table_r,
table_b, and table_g in the various cases...

Finally, I do not understand how the values in the dither_* tables are
computed.

Due to this lack of understanding, when I finally arrived to rewrite a
new version of yuv2rgb_c_init_tables() which works, I noticed that it is
very very similar to the original one (I basically copied all the "magic
numbers" cited above). So, I think it is derived work.

Since I do not know how to replace the GPLed data and code from
yuv2rgb.c without being "relevantly inspired" by them, I think In the
weekend I'll try to follow a different path porting the LGPLed code from
ingconvert.c (to be only compiled when "--enable-gpl" is not used). Is
this ok?

Of course, if someone with a better understanding of the current code
wants to rewrite an LGPLed version of the needed yuv2rgb.c portions,
that would be great... :)

			Thanks,
				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !