[MPlayer-G2-dev] Re: G2 CLI/GUI

[Andriy N. Gritsenko]

    Hi, Arpi!

Sometime (on Monday, May 12 at 19:03) I've received something...
>> P.S. By next step I want to apply new API to -vf option (and to -ovc of
>>  mencoder-g2, of course) to get it fully configurable. :)

>i wanna see how does vf configuration will work with this api.

    It isn't ready yet in code, just drafts but it will work by the ways
we discussed before.

>> P.P.S. CONF_TYPE_POSITION CONF_TYPE_CHOOSE CONF_TYPE_LIST CONF_TYPE_CHAIN
>>  types and save_config() function are not implemented in cfgparser.c yet.

>is it supposed to handle the multifile configuration?
>(like playtree was in g1, but i always liked the method used in
>g1's parse-mecmd.c better)

    Of course, it will handle multifile configuration. See the function
pli->f->uninit() for restoring old values from before. Just isn't ready
yet, but it's only config parser function, end application don't have to
know it's implementation, just standard calls:

pl_instance_t *cfgparser;
.....
while(*filenames) {
  .... get config name
  cfgparser->parse(cfgparser, mconfig, 1, &configfilename);
  .... open video file
  {
    .... play video file
  }
  cfgparser->uninit(cfgparser, mconfig);
  .... close video file
}

>what i mean: when there are multiple files, one with their own commandline
>(or configfile) options, are you able to parse them separated, even in
>parallel?

    Current way of commandline parsing doesn't allow to have multiple
configuration. But don't take offence, please - I didn't improve the file
cfgparser.c yet, I only made that API and applied it to cfgparser.c. That
parser-mecmd.c is very improved version of old cfgparser.c, isn't it? :)

>an example: i want to mux an audio, a video and a subtitle file together
>with mencoder-g2. so i need to open 3 streams, and 3 demuxers for them, in
>parallel. they probably have different options.

    No problem with it. Only thing that you have to have is UI that will
support that mode. It may be text UI, Gui, even improved version of that
cfgparser.c, you don't have to change your application or anything to
have it. I mean if you want that multiple configuration and parallelism
then just improve cfgparser and nothing more - that API allows it without
knowing implementation.

>btw it would be better to have the options (be it some global one, or
>demuxer/vfilter/etc specific) in dinamically allocated structurs, instead of
>in globals.

    You mean options or variables? If you mean options then they already
will be passed into dinamically allocated tree. If you mean variables
then any application (user-end, filter, etc.) must at first allocate it
then register it then use. No problem but it will take more memory, time
of execution, additional API call, and code will be harder. :)

>actually i can't see your new cfg api solving either globals, or multiple
>files problem, not i can see how makes it modules (filters etc)
>configuration cleaner.

    Heh. You want me to do all work at once. :(  Sorry, but it was only
API yet. API must be in the first place to prevent a mess in the future.
Do you understand me? I'm sorry, my English is too bad sometimes. :/

>btw, about dinamically loaded plugins: the cfg parser shouldn't know about
>them, esp. about their internal details, or loading them.

    It seems I expained it poorly, sorry. I've done that plugins API only
because I planned to make CONF_TYPE_CHAIN option type. Current way of -vf
is to have it as plain text until you open filter. It will be parsed then
and only then when you open filter so you cannot pass it to any UI to
preconfigure, UI will see only string "opt=param:..." but UI will don't
know what are these opt's. It's not good so I wanted to some API to get
these options and create a chain of filters by UI (as control interface,
at least). That plugins API isn't really depend on config API, config API
just will use two calls of it - pl_get_plugin() and pl_open_plugin(). I
did it because I hoped it will start loadable modules support in G2. Do
you against of loadable modules concept at all? If you do then I could
remove the file cfg-plugin.c and all that API calls. Then UI's will be
never unified but it's ok with me, we can always make bunch of functions
alike parse_command_line() for each subtype of UI. :)

>when the user enables a filter by -vf foobar, then the vf layer will try to
>open the vf_foobar.so, same for codecs (base don codecs.conf)

    Certainly, it will. That plugin API is only wrapper to all different
functions since I don't like to let any UI know what to do with each
class of objects (vf, codecs, etc.). If you like to have many #include's
in each UI/parser - ok, we will.

>don't do the same as xine (it loads all plugins at startup).

    Sure, it's ugly. We have to load plugins when they are needed. I
wanted it so I've developed that plugin API to control it, to don't load
all plugins at once.

    Be sure, what I've proposed will easy solve all problems you did
mention above without any dependencies (it's my first goal!) but it will
take a time, unfortunately, I cannot write and check the code too fast.
BTW, if anyone wants to be volunteer to help with that, it will be just
great.

    With best wishes.
    Andriy.