[MPlayer-dev-eng] Re: MPlayer G2

[Anders Johansson]

Hi Andriy,

>     Hi, Anders Johansson!
> 
> Sometime (on Tuesday, April  1 at  7:10) I've received something...
> >> > > As I promised when I announced my leaving of the project maintainership,
> >> > > I started some new video player project (nearly) from scratch.
> >> > > For now I call it MPlayer G2 (as generation 2).
> 
> >> > How are you planning to design the startup and runtime user control
> >> > interface for pluggable modules inside the player?
> 
> >> Actually I didn't think of that yet. I have no idea...
> >> Any good idea welcomed (but no XML please:))
> 
> >> For now I'm rtying to encapsulate every neede dinfo into the URL,
> >> it works for stream layer most time.
> >> (like dvd://titleno[.chapter-range]:[angle][/device])
> 
> >> > The reason I am asking is that I have a similar problem in two other
> >> > projects I am involved in (one software radio project and a VOIP
> >> > project). My idea is that there isn't any difference between startup
> >> > and runtime configuration and they should therefore be handled in the
> >> > same way. One project that does this is ALSA but I couldn't rip out
> >> > the communication lib cleanly cause the communication went back and
> >> > forth from kernel to user space. 
> 
> >> I don't want to overcomplicate this. Maybe a simple struct like our
> >> config_t now, usable to export any parameters from the libraries for
> >> the UI. For the runtime configuration changes there will be a control()
> >> function for each API.
> 
> >I can not see any difference between startup and runtime
> >configuration. Personally I would like to have a solution where a
> >module could be loaded and unloaded during execution and one could
> >then write applications that interacted with the module loader like
> >user interfaces, configuration file readers and writes, daemons for
> >network transparency or command-line switch readers (for Rich), etc. 
> 
> >This would make it possible to do quite cool things like interactively
> >designing a configuration using the user interface and then saving
> >it. Next time one wants to run the application the user interface is
> >no longer needed (good for impressing on your girlfriend).
> 
> >The problem is that this approach requires an abstraction where
> >instances of a module are somehow uniquely identified. Also it must be
> >possible to handle sub-modules...
> 
>     I thought about the same too when I did my last patch. I think it's
> possible with that config scheme for current MPlayer/Mencoder. It is that
> I called flexible way of config. ;)  About how identify substances - I
> have some solution too, at least I designed loadable modules scheme for
> my own project before. :)

How did you solve it? Which project? do you have a link?

I have been thinking of this for a while but I am not sure how far one
should go in terms of making the interface abstract. The problem gets
tricky one there are more than one process that needs to access the
loaded modules. If one process unloads a module how to solve the
problem of invalid module references (pointers)? 

The solutions I have come up with so far:
1. The use of simple data bases. When a module gets loaded the pointer
   to the module is stored in a hash-table, numbered list or similar
   and the reference is returned to the process that initiated the
   loading. If the module has sub-modules a new level of data base is
   created with identical interface. This way callers only has a
   reference to the modules, so if a module is unloaded it will
   disappear from the data base and graceful exits can be made.

2. Subscription based services: When a module is loaded it is given a
   reference (pid) to the process that initiated the loading. This
   reference is put in subscriber list. Every time a new process wants 
   to control the module a reference to that process is added to the
   list, and when the module is unloaded all subscribing processes in
   the subscriber list are notified that the module is no longer 
   present. A function for removing subscribers from the list has to
   be implemented.

3. A flat (or nested) list (or some kind of table/data base) of valid
   pointers to loaded modules is maintained, and calls are checked
   against the list before they are made. This solution lacks grace,
   and can lead to performance problems, but is quite easy to implement. 


I don't like any of these solutions very much. 

Nr.1 and 2 preserves the order of the modules automagically which is
good when a new process wants to scan the structure.

Nr.2 Lacks overhead for ordinary calls.


All the above solutions requires that modules can report them selves
what every option they take can do (identifier, type, max, min, array,
string, sub-modules, graphical representation, etc), or that there is
a description in every control process of every type of module (ALSA
does this (it is ugly)).


What have you thought of that I haven't?

>     With best wishes.
>     Andriy.

Cheers,
//Anders