[MPlayer-dev-eng] Dynamically load audio/video filter at runtime through commands

Jehan Pagès jehan.marmottard at gmail.com
Mon Mar 29 14:17:51 CEST 2010


Hi again,

so I have improved my feature-patch:

- I have fixed a bug when the playback speed is reset to 1.0 when I
was changing a filter. So now I rebuild the filter chain
(build_afilter_chain), not to forget the current playback speed.

- Now af_add and af_del can take a list of audio filters as argument
(same syntax as in the command line). For instance:

« af_add scaletempo=speed=tempo,karaoke » will add both scaletempo
filter (with parameter "speed=tempo") and karaoke filter.
« af_del scaletempo,karaoke » will remove the first occurence of
filters named scaletempo and karaoke if loaded.

- I have added "af_switch" which takes a list of filters and
parameters, similarly to af_add but replace the current loaded list
(af_add will add the list of filters, while af_switch replaces the old
one after unloading it).

So now, all I see could be interesting for this feature is have a
separate command to add filter by explicitely prepending or appending,
and making this for video filters as well.

Hope you enjoy this feature. Updated patch attached.
Bye.

Jehan

2010/3/29 Jehan Pagès <jehan.marmottard at gmail.com>:
> Hi,
>
> I would love to be able to load and unload an audio filter at runtime
> (hence listen to a song by adding/removing filters on the fly without
> having to stop the song and rewrite the command line by changing -af
> options, but either by a slave command or simply by binding specific
> commands to a key). So I went on the irc channel a few hours ago, and
> I have been confirmed this is not possible currently (someone said it
> is possible with something called ffdshow used with mplayer but
> searching this on the web, it appears to be Windows only, which I
> don't have).
>
> So I made a first patch to add such fonctionnality. As far as my tests
> went, it works pretty well. So before going further, here is what I
> added:
> -------
> ./mplayer -input cmdlist |grep af
> af_add               String
> af_del               String
> af_clr
> -------
>
> 1/ So "af_add filter_name" adds an audio filter. For instance the
> command "af_add karaoke" will add the karaoke filter. You can also
> give filter options the same way as the command line, for instance:
> "af_add scaletempo=speed=tempo".
> 2/ "af_del filter_name" will unload the first audio filter with the
> given name (for instance "ad_del scaletempo" will remove the first
> instance of scaletempo filter).
> 3/ "af_clr" unloads all loaded filter.
>
> Notes:
> I) af_add and af_del can be given only one filter at a time. It would
> be interesting to be able to load several filters at the same time,
> like in the command line. I may enable this as a second step.
>
> II) I wanted to have an af_add command to append to the filter list
> and an af_pre to prepend (like on the command line) but the functions
> to append and prepend audio filters are private and the only public
> function to add a filter (af_add in libaf/af.h) states:
>
> * The filter will be inserted somewhere nice in the
>  * list of filters (i.e. at the beginning unless the
>  * first filter is the format filter (why??).
>
> So couldn't it be interesting to make af_append and af_preprend (from
> libaf/af.c) public as well?
>
> III) I was thinking it could be interesting to have a bare "af"
> command which would override current audio filters with a new list,
> like in the command line, (as in command line, both method --
> add/remove and af methods -- could be available).
>
> IV) As I was only interested in audio filter, I implemented this only
> for audio filters, but if the video filters are implemented a similar
> way (I have not looked the code for video filters), I can easily make
> commands for video filters as well.
>
> As a conclusion, the diff is attached to this email. I hope you are
> interested to add this upstream because for me this functionnality is
> interesting (and hopefully I am not alone) and I really won't maintain
> any kind of fork-like of mplayer... :-)
> Thanks for this great software anyway.
>
> Jehan
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-af-commands.diff
Type: text/x-patch
Size: 3004 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100329/0f4fe3ea/attachment.bin>


More information about the MPlayer-dev-eng mailing list