[FFmpeg-devel] lavfi state of affairs

[Michael Niedermayer]

On Fri, Feb 06, 2009 at 09:43:44AM +0200, Kostya wrote:
> On Thu, Feb 05, 2009 at 11:02:24PM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 05, 2009 at 12:36:55PM -0800, Baptiste Coudurier wrote:
> > > Hi Michael,
> > > 
> > > On 2/5/2009 12:21 PM, Michael Niedermayer wrote:
> > > 
> > > Sorry but if _you_ want imgconvert dropped, _you_ have to make some 
> > > efforts too.
> >
> > Dont you think its a little offensive to ask the one who probably spend more
> > efforts on sws than anyone else to make some effort "too" ?
> > Also i dont mind fixing technical issues and cleanliness ones, but i will
> > not rewrite the GPL code. There are people who want the yuv table generator
> > to be under LGPL, they can rewrite it but IMHO they should not block the
> > removial of cruft if they decide not to.
> > And i know you are an excelent developer, you could likely rewrite the darn
> > table generator in less than 2 hours.
> 
> Well, I think I can do that (if I find the requirements to it). 

there are
 void * yuvTable;            // pointer to the yuv->rgb table start so it can be freed()
    uint8_t * table_rV[256];
    uint8_t * table_gU[256];
    int    table_gV[256];
    uint8_t * table_bU[256];
in the sws context

their use in swscale should make it obvious what they contain.

simply dumping the contents and the pointers (overlap) for the tables
should also make it clear what they contain for the various pix_fmts



> 
> [...]
> > > 
> > > Also libswscale does not support palette output, this makes GIF encoder 
> > > _useless_.
> > 
> > swscale supports 4bit and 8bit palette output with a fixed palette
> > imgconvert supportes 8bit with a fixed palette
> > swscale supports ordered dither providing MUCH higher quality over imgconvert
> > imgconvert uses only 216 of 256 colors, swscale uses all.
> > imgconvert does 6 divisions and modulo operations per pixel for pal8
> > output swscales does 0
> > and gif.c has the imgconvert palette hardcoded. Which id say is not such
> > a bright idea ...
> > besides imgconvert calls functions from gif.c (much cleaner design than
> > sws, which is selfcontained ;)
>  
> Now we have libavcodec/elbg.[ch] which cries "Wanna have good palette for each frame?
> Ooh, pick me!"

i dont want to ruin your dream but elbg is not that good for palettes, it
might very well be good enough (and surely is better than nothing) 
but thats a different thing.

To see the problem, consider a grayscale image from 0..255 with each color
occuring approximately equally often. and a 2 color palette
elbg will give you something like one color at 64 and one at 192 which will
effectively clip 50% of the image off as its not representable anymore.

The problem is elbg assumes that only the colors themselfs can be represented,
that way it will try to place the colors where colors occur most often and
thus loose the ability to represent the more extreem corners.
But due to dither intermediate points like 50% color A 50% color B are very
well representable while the same distance outside the A-B line is not.


> That's another trivial patch (for imgconvert though, for swscale some
> dependencies should be resolved) noone has produced yet :(

> And personally I'd like to have decent PAL8 encoding support.

me too but elbg as such might not be the best solution

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090206/15663ee9/attachment.pgp>