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

[Arpi]

Hi,

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

last time we discuss it i said i don't like that static struct (nor the way
that it initializes filter's priv struct)

> >> 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);

hmm and where you tell the parser whic file is being played now?
(ie which file-specific options you want)

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

cfgparser.c was dropped in temporary (see changelog), for being able to pass
some args to the test-* files. i didn't meant to keep or modify it for the
final g2. it was just simpler than messing with for, strcmp and atoi in
main() :)

> parser-mecmd.c is very improved version of old cfgparser.c, isn't it? :)

dunno
i meant the API provided by parser-mecmd.c:

typedef struct m_entry_st {
  char* name; // Filename, url or whatever
  char** opts; // NULL terminated list of name,val pairs
} m_entry_t;

// Free a list returned by m_config_parse_command_line
void
m_entry_list_free(m_entry_t* lst);
// Use this when you switch to another entry
int
m_entry_set_options(m_config_t *config, m_entry_t* entry);

m_entry_t*
m_config_parse_me_command_line(m_config_t *config, int argc, char **argv);

so you get an array of files togethwer with their specific options, and you
can select any of them and ask the "system" to set parameters to the ones
belonging to that file.

but imho it's UI problem, not g2 core.
what i want in g2 is a simple struct where i can tell the UI the available
options, and i'll receive a struct filled with their values at init.

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

great. how?

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

aren't they the same? i mean values of the options
so insteda of still messing with static globals, i want dinamically
allocated structs filled by the values (be it default or the one set by
various ui options, confifile etc). so i could even have different sets of
configuration values in parallel.

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

why?
i could imagine that an app/plugin defines a struct to keep configuration
variables. it also defines a cfg_t table describing these fields.
and then export (register?) this info for the config parser.

hmm, maybe your idea with static struct in vfilters isn't that bad,
if you use it a bit different way:

that static struct in the plugin code is read-only, ie modification is not
allowed. it serves as storage of the default values, and struct layout.
you export the cfg_t struct (with pointers into that static struct) and
the static structs parameters (pointer to it and sizeof it), and you'll
receive a dinamically allocated copy of it, fields may be overwritten by
the ones from commandline/config/ui/etc options.

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

ok...
you send it as being almost complete code

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

no
but i'm against load-all-modules-at-startup concept

btw what you say about UI have some sence.
ie. ui's "configure plugin" (be it builtin or dyn-loaded) should work,
without starting the playback, so the UI have to be able to open plugin by
name and receive its configuration structures.

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

dunno
i still don't think that we should (can) unify all the plugin interfaces

what you want is proabbly a function to 'enumerate' the available plugins in
a common structure, into each layer.

like plugin_list_t* vo_get_plugins();
will return a struct filled by the plugin name, description and config
struct pointer. it's required anyway by the GUIs for the plugin selection
comboboxes.

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

Albeu? :))))))))


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu