[Ffmpeg-devel] libswscale questions

[Steven Johnson]

Michael Niedermayer wrote:
>> 1.2 If yes to 1, If I was to activate pal8to* conversion in libswscale,
>> Should I put the code into rgb2rgbWrapper, OR should I create a
>> pal8torgbWrapper. (The 2nd option seems cleaner).
>>     
>
> are you asking about the name? pal8torgbWrapper sound better yes
>   
Yes, but also if I should put the new code in the existing function.  I 
would prefer a new function.
>   
>> 2.1 If yes to 2, would it be acceptable to just have rgb24topal8
>> conversion, and to implement the other rgb??topal8 conversions by going
>> from rgb?? to rgb24 and then rgb24topal8?
>>     
>
> the swscaler internally uses yuv so your conversation will have to be
> from that or you will have to add internal rgb support (very welcome too), 
> also note that X->pal support where X -> scaling -> pal fails is not 
> acceptable (note to thouse who complain now about crap design and lost 
> precission in rgb->rgb, the internal yuv is 15bit per sample)
>   
Ok.  I need scaling for my application anyway, so I had every intention 
of supporting X -> scaling -> pal. :)
> [...]
>   
>> 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.  

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 
library, it wont break binary compatibility to add the new fields (which 
I would group in their own substructure within SwsContext), and the 
addition of the single call to set the options.

Steven J