[FFmpeg-devel] [PATCH] libavfilter-soc: extend vf_scale.c to make it support colorspace details setting

Stefano Sabatini stefano.sabatini-lala
Tue May 19 23:15:05 CEST 2009


On date Tuesday 2009-05-19 00:52:25 +0200, Michael Niedermayer encoded:
> On Mon, May 18, 2009 at 10:00:08PM +0200, Stefano Sabatini wrote:
> > On date Monday 2009-05-18 03:03:00 +0200, Michael Niedermayer encoded:
> > > On Sun, May 17, 2009 at 01:33:48PM +0200, Stefano Sabatini wrote:
> > [...]
> > > > The only alternative I see would be to redefine in the ScaleContext
> > > > every single option of SWScaleContext, then map them to the
> > > > corresponding SWScaleContext options when setting them, I avoided it
> > > > since that looks more complicate.
> > > > 
> > > > Would that be acceptable?
> > > 
> > > no you seem to be missing the point
> > > i want, none, ZERO not even a trace of any of these options in the filter
> > > the filter should pass the stuff generically to swscale one way or another
> > > This may not be achiveable and compromises might be needed but what your
> > > patches do goes too far ...
> > >
> > > The various ways by which you dupllicate the AVOption list from swscale
> > > is why iam so unhappy with this patch
> > >
> > > I dont know if it can be done without changes to swscale ...
> > 
> > I have to confess that at this point I have no idea of what you
> > mean... you want the scale filter to be configurable but
> > "generically", which I don't know at all how to interpret.
> 
> heres a example:
> 
> generic code:
> for(all input parameters given to us)
>     give input parameter to sws
> 
> 
> non generic code OTOH checks for "sws_flags" or contains tables of
> names (if its a little less messy) and does all kinds of obscure
> things with them
> 
> is it clear now?

My proposal:
* cpu_caps
* scaler algo
* flags (bitexact, accurate_rnd, print_info)
...

each one of these parameters would be used to set some specific aspect
in the scaler.

And IMHO the way options are set in the scaler is messy, for example
the algo is not semantically a collection of flags, and cpu flags
should maybe deserve some separate flags, having a unique big flags
int doesn't help setting separately the various aspects of the scaler.

Regards.
-- 
FFmpeg = Fundamental Funny Majestic Plastic Ecumenical Glue



More information about the ffmpeg-devel mailing list