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

[D Richard Felker III]

On Tue, Jun 18, 2002 at 12:58:03PM +0800, Anders Johansson wrote:
> Design:
> 3 types of plugins input, effect and output.

Hmm, why? Treating all the filters the same works fine for video; I
don't see why it should be any different for audio...

> 1. Input plugins
>    1.1 Format conversion always converts to one of the following:
>        Signed 16 bit Little endian integer (for slow systems, will be
>        removed in the future)
>        Signed 32 bit Little endian Floating point 

Removing integer is silly, as is using little endian. Preferred sample
format should be host byte order for maximum speed in 'effect
plugins'. Ideally, however, most if not all plugins should accept
input in all (common) formats so as not to hinder performance.

As for dumping integer, why?? It's much faster and for lots of
plugins, processing samples as integers is perfectly fine.

> The effect plugins are runtime pluggable and user selected, many of
> them has GUI. Store in a linked list and must be able to adopt to

Bleh, I hope they're also nice and functional without gui...

> changes in the data stream. This is one of my problems how should they
> be initialized? One idea is to not have any init function by probe the
> data stream in the run function when they are called and reinitialized
> if necessary. Please advise me on this one.

Probably use a config() call like vo/vop. Just make sure it's safe to
be called multiple times, unlike in most of the vo drivers.

> Output plugins reads the capabilities of the hardware during startup
> and are always called in the same order. These plugins must also
> auto-configure cause the data stream coming from the Effect plugins
> can change.

Why not just do like video filters and auto-add a format-fixer plugin
when the ao device can't handle the output format of the last plugin
in the chain?

> An other issue is AC3 - personally I want to have AC3 pass-through and
> never touch the data stream, same goes for MPEG audio.

Sounds like it could be modelled directly after mpegpes in the vo
system.

> Also do we want closed source plugins to be loadable like they are in
> xmms? I guess no???

I would say no, but Arpi and others would probably eventually like it.
This probably doesn't need to be core to the design though; instead,
there could just be a special binary-loader aop filter that would load
and interface with the particular binary filter types you want to
support. For example, -aop xmmsplugin=blah.so:opt1:opt2:...


Rich