[vlc-devel] [GCI] libvlc: An API for listing audio & video?filters

Olivier Aubert olivier.aubert at liris.cnrs.fr
Mon Dec 6 18:20:43 CET 2010

On Sun, 2010-12-05 at 00:01 +0100, Jean-Baptiste Kempf wrote:
> On Sun, Dec 05, 2010 at 12:38:36AM +0200, Rémi Denis-Courmont wrote :
> > And most filters depend on parameters that cannot be expressed in a generic way 
I must be missing something, but I fail to see why parameters cannot be
expressed in a generic way. All modules expose their parameters and
their types, it is used to generate the --longhelp output.
What prevents us to devise an API like the following (using basic python
syntax -- the C version would be slightly more verbose to accomodate the
multiple types - string, bool, int, etc) ?

# Return a list of available plugins
-> [ "marq", "contrast", "equalizer", ...]
# possibly filtered
-> [ "equalizer", "scaletempo"... ]

# Return a list of activated plugins
-> [ "noise0", "sepia0", "equalize0", "marquee0", "marquee1" ]
# possibly filtered too
-> [ "noise0", "sepia0", "marquee0", "marquee1" ]

# Return the list of (parameters, type) for a plugin
 ->  [ ('equalizer-preset', 'string'), ('equalizer-2pass', 'bool')...]

# Get/Set a plugin parameter
player.plugins_get_param("equalize0", 'equalizer-2pass')
-> True
player.plugins_set_param("equalize0", 'equalizer-2pass', False)
player.plugins_set_param("marquee1", "marquee", "FOOBAR")

As for use cases, this would for instance immediately alleviate the
current libvlc_marquee limitation which allows only 1 marquee filter to
be manipulated, and more generally offer a wide access to the powerful
VLC plugins architecture.

Please enlighten me if such an approach is out-of-scope or


> This is true for some of them, but not all of them:
> gradfun, grain, zoom, puzzle, gradient, invert, noise, motion,
> psychedelic, wave, posterize, sepia, to name a few are pretty usefull,
> even with the default parameters.
> Most (all) Audio filters, are useless without params adjustement now.
> SD, visualisation would gain to be listed too.
> access, access_demux, demux, art finder, decoder, inhibit, extension,
> main, memcpy, meta *, osd parser, packetizer, sql, stream filter, sub
> filter, text renderers, video blending, vod server, xml, xml reader
> I fail to see the use cases.
> Olivier, ivoire, Jakub, *: any idea of such use cases?

> sout* needs a special API
> playlist export would be pretty cool, but I don't know if the generic
> API would work.
> Best Regards,

More information about the vlc-devel mailing list