[MPlayer-dev-eng] Re: Moving the audio plugins to libmpcodecs - design of plugin management

[Anders Johansson]

Hi,

> On Tue, 18 Jun 2002, Anders Johansson wrote:
> > The reason I want to reduce the number of formats is to make it easier
> > to write new plugins and to reduce user complaints. One reason for the
> > current structure to suck is that there are too many formats.
> 
> If you automatically convert the sample data to the required format,
> this is not a problem anymore. For example, if you have 16-bit integer
> samples and the next plugin requires 32-bit floating point, insert a
> format converter.
> 
> This way, one can write a plugin that supports only one format
> (floating point would be the easiest) and it will always work. If
> someone else thinks it's too slow (and knows how to code the algorithm
> in fixed-point), he can add integer support.

Yes I suppose I will have to solve the problem this way. 

> > With only one format it is possible to concentrate on that one and
> > optimize for it.
> 
> But this might not be optimal for every system (some systems have slow
> floating point). IMHO flexibility is better.
> 
> > > Bleh, I hope they're also nice and functional without gui...
> >
> > I should have said OSD or GUI. Some plugins becomes a bit hard to use
> > without visual feedback like for example EQ and multi channel volume.
> 
> What I would like is the possibility for a standalone program to
> connect to mplayer and change settings like volume, EQ, do seeks, get
> status info etc., so you can control mplayer from a different display
> or computer.
> 
> Plugins should not have GUI of OSD support hardcoded in them, but
> instead export a list of parameters with name, type, range info, and
> an interface to change them on-the-fly.

All configuration of the plugins will be done through
control(). Actually I would like move commandline switches to
somewhere outside the plugins as well (if noone objects) and do
required configuration automatically based on system specifications
and user overrides.

Preferably I would like to see some type of configuration interface
which could get and set data using the following sources:
1. Config file 
2. External program 
3. OSD
4. GUI
5. Network socket ?

This is however completely outside things that I am planing to do and
I'll will leave it here as an idea.

> Eric

//Anders