[FFmpeg-devel] lavfi state of affairs

[Kostya]

On Fri, Feb 06, 2009 at 11:16:42AM +0100, Michael Niedermayer wrote:
> 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
 
ok, I'll try to work on that at this weekend. 
 
> > 
> > [...]
> > > > 
> > > > 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.

I think one can always construct an image that will be bad for any given algorithm.
And with harsh quantizing a lot of information may be lost.

It should be good enough for spheric viewer in vacuum though ;)
 
> > 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

It's far superior than current solution though.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB