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

[Michael Niedermayer]

Hi

On Fri, Dec 01, 2006 at 04:27:41PM +0100, Luca Abeni wrote:
> 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

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


> 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


> 
> 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 :)


> 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


> 
> 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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is