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

[Michael Niedermayer]

On Mon, Oct 07, 2013 at 10:12:14AM +0200, wm4 wrote:
> 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 add a AV_OPT_TYPE_FILTER_COEFFS
> > 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
> above.

I have no real preferrance, iam fine with this. I see mysef that the
stuff drifts off in a ugly direction ...
you can just pick what you prefer and ask me to merge/pull it


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131008/c53361ae/attachment.asc>