Mailing List Archive

New plugin scheme / Filter selection interface?
Judging by the ongoing thread about documenting filters, it seems to me
that (aside from lack of documentation) there are 3 basic problems with
the current method of setting up filters (more specifically, playback
filters):

(1) the "Deinterlace Playback" checkbox 'invisibly' puts linearblend at
the head of the filter chain. If you prefer kerneldeint, you have to
un-check "Deinterlace Playback" and manually specify kerneldeint in the
playback filter chain. This is rather counter-intuitive.

(2) The user is not presented with any options as to what the available
filters are; merely a text box for free-form text entry

(3) Related to (2) (which will be partially solved by the forthcoming
docs (thanks, Andrew)): it's rather difficult for folks using a remote
as their primary Myth input device to type in filter names (this same
issue applies to the visualizations in mythmusic)

I'd say it's high-time for a reasonable GUI interface for building
playback filter chains. I'd say at minimum what would be required
would be:

- self-discovery of available filters
- method for enabling/disabling any individual filter
- method for changing the order of filters in the chain
- (optionally) method for configuring filter-specific options (more
self-discovery)

A quick look at the above list suggests (to me) that some sort of plugin
architecture for filters is called for. A filter plugin could expose:
- name
- description/help text
- number & types of configuration options

The same sort of plugin architecture could be applied to any number of
things within Myth... music visualizations, mythgallery transitions,
mythmusic ripping containers & codecs... the list goes on.

Maybe what's called for is a more generic plugin system, where we would
have the concept of a plugin type. The main type of plugin that we
have now would be a MODULE plugin, then we'd have VIDEOFILTER,
MUSICVIS, GALLERYTRANSITION, etc. Any module or screen that was
interested in a certain type of plugin would simply scan the plugin
directory for plugins of that registered type. This might also open up
more possibilities of plugins not being restricted to their original
modules. For instance, the main menu system could use the transition
effects from MythGallery.

Anyway, I just thought I'd throw this idea out there and see if there's
any interest/thoughts/suggestions.

-JAC
Re: New plugin scheme / Filter selection interface? [ In reply to ]
On Friday 30 January 2004 10:07, Joseph A. Caputo wrote:
> (3) Related to (2) (which will be partially solved by the forthcoming
> docs (thanks, Andrew)):

Sorry, I meant "thanks, Bruce"

-JAC
Re: New plugin scheme / Filter selection interface? [ In reply to ]
On Friday 30 January 2004 10:07 am, Joseph A. Caputo wrote:
> - self-discovery of available filters
> - method for enabling/disabling any individual filter
> - method for changing the order of filters in the chain
> - (optionally) method for configuring filter-specific options (more
> self-discovery)
>
> A quick look at the above list suggests (to me) that some sort of plugin
> architecture for filters is called for. A filter plugin could expose:
> - name
> - description/help text
> - number & types of configuration options

The video filters basically already do all this. All it really needs is for
someone to write a selection/option ui.

Isaac
Re: New plugin scheme / Filter selection interface? [ In reply to ]
On Friday 30 January 2004 12:40, Isaac Richards wrote:
> On Friday 30 January 2004 10:07 am, Joseph A. Caputo wrote:
> > - self-discovery of available filters
> > - method for enabling/disabling any individual filter
> > - method for changing the order of filters in the chain
> > - (optionally) method for configuring filter-specific options (more
> > self-discovery)
> >
> > A quick look at the above list suggests (to me) that some sort of
> > plugin architecture for filters is called for. A filter plugin
> > could expose: - name
> > - description/help text
> > - number & types of configuration options
>
> The video filters basically already do all this. All it really needs
> is for someone to write a selection/option ui.

Cool, I'll have a look at it.

-JAC
Re: New plugin scheme / Filter selection interface? [ In reply to ]
Joseph A. Caputo wrote:
> Judging by the ongoing thread about documenting filters, it seems to me
> that (aside from lack of documentation) there are 3 basic problems with
> the current method of setting up filters (more specifically, playback
> filters):
>
> (1) the "Deinterlace Playback" checkbox 'invisibly' puts linearblend at
> the head of the filter chain. If you prefer kerneldeint, you have to
> un-check "Deinterlace Playback" and manually specify kerneldeint in the
> playback filter chain. This is rather counter-intuitive.

The docs are being updated to clarify this but continue with
your case for a GUI ;-)...

>> (3) Related to (2) (which will be partially solved by the forthcoming
>> docs (thanks, Andrew)):
>
> Sorry, I meant "thanks, Bruce"

Andrew provided all the core info, D Banerjee filled in his
parts, a half dozen people sent contributions off-line and
Robert polished it and put it in. A group effort, really.

> Anyway, I just thought I'd throw this idea out there and see if there's
> any interest/thoughts/suggestions.

Great idea. Go for it! Filling a ComboBox with the discovered
filters shouldn't be hard but filling the GUI widgets for the
per-filter parameters I suspect will be trickier. However, having
help text for each parameter would be really cool.

-- bjm
Re: New plugin scheme / Filter selection interface? [ In reply to ]
On Fri, 30 Jan 2004 13:02:17 -0500, "Joseph A. Caputo"
<jcaputo1@comcast.net> said:
> Cool, I'll have a look at it.
>
> -JAC

The filters README should have everything you need for this, but if I
missed anything in there, just ask. It's a pretty simple interface,
the FilterManager class has a method that provides a list of
FilterInfo structs.

Keep in mind also that it may not simply be a matter of
enabling/disabling filters and specifying an order for them. It is
perfectly valid to have multiple instances of a filter in the filter
chain, so we need something along the lines of being able to select
any available filter, add parameters to it, and insert it into the
filter chain.

As far as a GUI for parameters, I'd like to come up with a reasonably
flexible standard way for filters to describe their options. I think
most options could be handled by the following types:

boolean: GUI would display as checkbox

integer: filter provides valid range, GUI would display a slider
or a spinbox

float: filter provides valid range, GUI would display as slider

enum: filter provides a list of string values, GUI would display
as combobox

A default value should also be provided for each option, and the GUI
should display a "reset to default" button. Any thought on the best way
to describe these? I'd like something compact that can get stuffed into
a string in the FilterInfo structure. I think the GUI could be set up to
create colon-delimited lists of options, as used by many filters already.
I could set up some convenience macros for parsing such lists in
filter.h, although it shouldn't really be necessary. I'm guessing from
the way that video codec options seem to work that building a GUI from a
list of options as described above shouldn't be too hard, right?
--
Andrew Mahone
andrewmahone AT eml DOT cc

--
http://www.fastmail.fm - mmm... Fastmail...
Re: New plugin scheme / Filter selection interface? [ In reply to ]
On Friday 30 January 2004 19:46, Andrew Mahone wrote:
> On Fri, 30 Jan 2004 13:02:17 -0500, "Joseph A. Caputo"
> <jcaputo1@comcast.net> said:
> > Cool, I'll have a look at it.
> >
> > -JAC
>
> The filters README should have everything you need for this, but if I
> missed anything in there, just ask. It's a pretty simple interface,
> the FilterManager class has a method that provides a list of
> FilterInfo structs.
>
> Keep in mind also that it may not simply be a matter of
> enabling/disabling filters and specifying an order for them. It is
> perfectly valid to have multiple instances of a filter in the filter
> chain, so we need something along the lines of being able to select
> any available filter, add parameters to it, and insert it into the
> filter chain.
>
> As far as a GUI for parameters, I'd like to come up with a reasonably
> flexible standard way for filters to describe their options. I think
> most options could be handled by the following types:
>
> boolean: GUI would display as checkbox
>
> integer: filter provides valid range, GUI would display a slider
> or a spinbox
>
> float: filter provides valid range, GUI would display as slider
>
> enum: filter provides a list of string values, GUI would display
> as combobox
>
> A default value should also be provided for each option, and the GUI
> should display a "reset to default" button. Any thought on the best way
> to describe these? I'd like something compact that can get stuffed into
> a string in the FilterInfo structure. I think the GUI could be set up to
> create colon-delimited lists of options, as used by many filters already.
> I could set up some convenience macros for parsing such lists in
> filter.h, although it shouldn't really be necessary. I'm guessing from
> the way that video codec options seem to work that building a GUI from a
> list of options as described above shouldn't be too hard, right?

Not really... I'd want to just get the basic add/remove/reorder filters GUI
working first, with hardcoded default parameters (or none). Later we could
add configuration screens.

-JAC
Re: New plugin scheme / Filter selection interface? [ In reply to ]
On Friday 30 January 2004 19:46, Andrew Mahone wrote:
> On Fri, 30 Jan 2004 13:02:17 -0500, "Joseph A. Caputo"
> <jcaputo1@comcast.net> said:
> > Cool, I'll have a look at it.
> >
> > -JAC
>
> The filters README should have everything you need for this, but if I
> missed anything in there, just ask. It's a pretty simple interface,
> the FilterManager class has a method that provides a list of
> FilterInfo structs.
>
> Keep in mind also that it may not simply be a matter of
> enabling/disabling filters and specifying an order for them. It is
> perfectly valid to have multiple instances of a filter in the filter
> chain, so we need something along the lines of being able to select
> any available filter, add parameters to it, and insert it into the
> filter chain.
>
> As far as a GUI for parameters, I'd like to come up with a reasonably
> flexible standard way for filters to describe their options. I think
> most options could be handled by the following types:
>
> boolean: GUI would display as checkbox
>
> integer: filter provides valid range, GUI would display a slider
> or a spinbox
>
> float: filter provides valid range, GUI would display as slider
>
> enum: filter provides a list of string values, GUI would display
> as combobox
>
> A default value should also be provided for each option, and the GUI
> should display a "reset to default" button. Any thought on the best way
> to describe these? I'd like something compact that can get stuffed into
> a string in the FilterInfo structure. I think the GUI could be set up to
> create colon-delimited lists of options, as used by many filters already.
> I could set up some convenience macros for parsing such lists in
> filter.h, although it shouldn't really be necessary. I'm guessing from
> the way that video codec options seem to work that building a GUI from a
> list of options as described above shouldn't be too hard, right?


Just thought I'd give an update... I'm building a new Myth box, so I'm a bit
short on time. The new box will have HW MPEG encoders and use XvMC on its
output, which makes anything filter-related rather low-priority for me...
anybody else interested in picking this up?

-JAC