[FFmpeg-devel] lavfi state of affairs
Fri Feb 6 13:14:05 CET 2009
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;
> uint8_t * table_gU;
> int table_gV;
> uint8_t * table_bU;
> 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
More information about the ffmpeg-devel