[Ffmpeg-devel] moving non-SIMD parts of libswscale to LGPL
Luca Abeni
lucabe72
Fri Dec 1 16:27:41 CET 2006
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 ! ! !
More information about the ffmpeg-devel
mailing list