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

[Luca Abeni]

Hi Michael,

On Fri, 2006-12-01 at 18:01 +0100, Michael Niedermayer wrote:
[...]
> > 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
> 
> 255/224*2^16 ~ 74605.71429
> so this looks correct, the remaining error is likely caused by inaccuracies
> in the in approximation of the inverse matrix you choosed
Ok, thanks... Now I know how to ``generate'' Inverse_Table_6_9 without
copying it :)

> > 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?
> 
> 255/219*2^16= 76309.0411
> = (max rgb - min rgb) / (max y - min y) * fixed point scale
I see... Thanks

> > 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(),
> 
> the sizes will likely be what is needed to have no out of array accesses :)
Yes, I expected something similar... I was just trying to understand
where the array sizes were coming from

> > and the offsets used to initialize table_r,
> > table_b, and table_g in the various cases...
> 
> are choosen so the tables dont overlap, yes this is not beatifully
> implemented but its simple, it also gurantees that the table are
> consecuive in memory which might help the cache a little
Ah, ok... In my original rewriting of yuv2rgb_c_init_tables() I did not
think about cache effects, so I used three separate calls to
av_malloc(). I rewrote it using one single call, as in the original
version.

Anyway, I had to copy all the "197 + 2*682 + 256 + 132", "256 + 2 *
232", and similar values from the original version. So I do not know if
my rewriting is derived work or not...

> > Finally, I do not understand how the values in the dither_* tables are
> > computed.
> 
> i _think_ i wrote them (i definitly wrote some, dunno if i wrote all)
> if so they are under LGPL and you can use them
> 
> they are bayer ordered dither matrixes with some manual changes by me to
> improve the subjective quality
Ok. So, if I get it right such tables are either written by you or taken
from a paper by Bayer... Can they be reused in LGPLed code? (I would say
yes, because they are by you or from a previous - non GPLed - work. But
IANAL, so I am asking :)


Anyway, I attach a patch for libswscale (enabling to compile the LGPLed
code if CONFIG_GPL is not set) and my "rewriting" of the yuv2rgb tables
and initialization. Some notes:
1) It is only lightly tested (I just tried some simple yuv420p --->
rgb32 and rgb24 / bgr24 conversion). Hints about how to test this stuff
are welcome (in other words: can people provide some ffmpeg or mplayer
command line to output files with pixel format
rgb/bgr{32,24,15,15,8,4,1}?). Until extensive testing is performed, bugs
are to be expected

2) As you can see, yuv2rgb_init.c has no header. This is because even if
I started rewriting it from scratch, I had to copy some "magic numbers"
from the original yuv2rgb.c (see for example how table_r, table_b, and
table_g are assinged in allocate_tables()). So, I do not know if this
can be LGPLed (I see on the list there are people with good legal
skills, so I hope they can provide a good answer to this question). If
it cannot, I doubt I can write any LGPLed replacement for the tables and
the initialization code in yuv2rgb.c.

(I do not want to play strange games with the licenses, nor to "steal"
GPLed code, nor to create problems for users of the LGPLed libav*
libraries... I am just trying to do my best to make everyone happy
without breaking licenses)

3) The values in Inverse_Table_6_9 have been quickly computed based on
the tables sent by Michael - I inverted the rgb ---> yuv matrix with
octave. I do not know if octave somehow truncated / approximated some
results. If needed, I can redo the computation with a higher accuracy

4) This is not a submission, it is more an RFC to see if this is the way
to go, and if this code can actually be LGPLed. Review and comments are
more than welcome. If people agree that this patch is legal and that it
can be applied, I can split/rework it as required.



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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: yuv2rgb_init.c
Type: text/x-csrc
Size: 12404 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061204/8cc37c06/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lgpled-nonsimd.diff
Type: text/x-patch
Size: 5902 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061204/8cc37c06/attachment.bin>