[FFmpeg-devel] [PATCH] swscale: Support setting filters through AVOptions

wm4 nfxjfg at googlemail.com
Mon Oct 7 10:12:14 CEST 2013

On Mon, 7 Oct 2013 02:44:21 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> On Mon, Oct 07, 2013 at 12:10:16AM +0200, wm4 wrote:
> > On Sat,  5 Oct 2013 22:49:55 +0200
> > Michael Niedermayer <michaelni at gmx.at> wrote:
> > 
> > > anything else could be used or the routine even be made to accept
> > > any character as separator.
> > > 
> > > Docs are omitted as i expect long bikesheds on the syntax and which
> > > separator char to use
> > > 
> > > Examples:
> > > -vf scale=640:480:src_filter=1#h-0.5#0#0#0#1
> > > -vf scale=640:480:src_filter=1#c1#1#1#1#1#1#1#1#1#1#1#1#1#1#1#1#1#1
> > > -vf scale=640:480:src_filter=1#lh-0.2#1#-0.2#lv1#0#0#0#0#0#0#0#0#0#0#0#0#1
> > > 
> > > Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
> > > ---
> > 
> > Can't say much about it. I assume this easily allows
> > porting code that uses sws_getDefaultFilter()?
> that should not be hard we could just add support in the parser to use
> sws_getDefaultFilter() from user specified parameters
> like s=2 instead of 0#0#1
> or the parameters could be seperated out into individual int/float
> AVOptions

Sounds ok, but of course this wouldn't necessarily cover the complete
old API.

> > What about code that
> > constructs SwsFilters directly?
> we could move the parser code into libavutil/opt.c
> and then use SwsFilters more or less directly
> or add a function that turns a SwsFilter into a char*

This is getting awkward quickly. To me it seems like the typical thing
is happening: a core API gets strange additions like option parsing or
mapping things which are not strings to strings, just because it's
convenient for the frontend utilities. Such user-facing concerns should
really be handled by the utilities themselves, and not a few layers
deeper in core API. I'd rather prefer some nice setters and getters than
shoehorning everything into AVOption. In fact, I think the AVOption API
is morally wrong and technically backwards, because it hides important
parts of the API away. If you look at the public libswscale headers,
you wouldn't guess that you must call the AVOption API to set required
parameters. To make matters worse, the old APIs which didn't require
this are still around. Utterly confusing.

(Unfortunately, libavfilter has the same problem of shoehorning
everything into AVOptions and strings, because it shoehornes everything
into the filter graph language. Even a layer below the filter graph
parser, it's just AVOption everywhere.)

> or add some set/get functions to set non string SwsFilter
> which would API wise basically be what was in the new API proposal

Sounds fine too and I think I'd prefer this. But do what you must. I
don't actually want to make a big issue out of this. Ignore my rant from

> or maybe theres another idea ?
> what do people (mainly sws API users) prefer ?
> [...]

More information about the ffmpeg-devel mailing list