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

[Eric Lammerts]

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.

> 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.

Eric