[Ffmpeg-devel] libswscale questions

[Michael Niedermayer]

Hi

On Tue, Oct 31, 2006 at 12:54:05PM +1100, Steven Johnson wrote:
[...]
> >>4. Decent RGB to PAL8 conversion requires parameters to the converter
> >>such as (method of conversion, quality vs speed, max colours to use,
> >>etc).  Would it be acceptable for these options to be passed in as part
> >>of SwsContext? AND as SwsContext is opaque outside libswswcale, would it
> >>be acceptable to have a function to set these parameters inside
> >>SwsContext?  Something like:
> >>   int sws_setPaletteGenerationControl(struct SwsContext *c, int mode,
> >>int quality, etc) ??
> >>    
> >
> >hmm how hard/messy would it be to use AVOption for that?
> >
> >[...]
> >
> >  
> I am happy to put it anywhere.  The problem I have is how do I get those 
> options down to the (proposed) palette generation code deep in 
> libswscale, without breaking the API.  The only structure I see holding 
> values I can use that comes from the ffmpeg outer loop (and so can be 
> set as options), down into libswscale is SwsContext.  Unless there is a 
> way to interrogate AVOption from the palette generation code directly 
> from within libswscale, I will need to  pass AVOption into sws_scale 
> which seems messy, but not hard.  It would also break compatibility.  

RTFS AVOption


> 
> I would make the options default to something sane (like use a 666 fixed 
> palette colour cube).  So if the options weren't set explicitly, it 
> would still operate correctly.  The options would then only need to be 
> used by someone who needed better palette control, say for example 
> specifying the use a dynamic palette generator that gives the best 
> palette it can per frame.  Given SwsContext is opaque outside the 

changing the palette per frame will likely lead to flickering, and
might cause weird problems like somewhat wrong colors on slow display 
devices (TFT monitors for example)
2pass global palette selection or some smart code which is aware of the
last palette and frame contents seems to be a better choice if you want
something more optimal, also changng the palette at random between frames
will make inter frame compression impossible with current codecs

also if you choose a fixed palette for a simple mode, that palete should
be irregular or to be more precisse it should contain few colors for which
A+B=C+D, A+B+C=D+E+F, ... is true, if its not obvious why think about
a simple 0,6,12,18 grayscale palette
with constant color you can represent 0,6,12,18 (obvious)
by alternating 2 colors you can additionally represent (3,9,15)

with 0,4,12,18 you could represent 0,2,4,6,8,9,11,12,15,18 with 2 colors
that makes

    0123456789012345678
    X  X  X  X  X  X  X
vs. X X X X XX XX  X  X


[...]

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