[MPlayer-dev-eng] Re: MPlayer G2

[Andriy N. Gritsenko]

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

    With best wishes.
    Andriy.