Hi, Arpi!
Sometime (on Monday, May 12 at 20:50) 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)
I meant I don't want to link all code together but I want to get it
all independent. :)
About structs - ok, see my previous letter.
[.......]
>> parser-mecmd.c is very improved version of old cfgparser.c, isn't it? :)
>dunno
>i meant the API provided by parser-mecmd.c:
[.......]
>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.
I get it. But I said the same - it's only UI problem! The way it will be
parsed and applied isn't concern of 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.
typedef struct {} cfg_tree_t;
It's exactly what we all need (I've commented it as "module independent
tree of options" in cfg.h).
>> >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?
By the API calls, you said it yourself - "it's UI problem". :P Only
thing that your mencoder-g2 has to allow that parallelism. BTW, I've sent
sync code here that allows multiple streams, with multiple demuxers. :)
>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.
It's almost the same what I thought a hour ago. It was why I've said
"I think I know how to do it" then. :)
>> 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
Complete as before - API was applied to that test cfgparser, nothing
more. I didn't go any further.
>> 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
I'm also! :) But may be anyway we have to scan all available modules
at startup (don't load but check) - I don't think if check only by file
name is enough.
>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.
Good! I could be understandable now! :) It's that I wanted to say:
plugins must be in config tree to allow UI load and configure them. So
way UI will add plugin to list is:
cfg_find(); // find plugin of that type
pl_get_plugin(); // open found plugin
... parse_options ...
Is it ok? Anyway that plugin API is very small (~1.8kB plugin.h in cfg.h
and ~2.5kB plugin.c as cfg-plugin.c) so let us have it to improve with
loadable modules support later.
Also note that your current "-vf" has a static variable (char**) so if
you will build a chain from UI/parser via plugin API then you don't need
to have any statics ("-vf" just creates new chain, we have just associate
that chain with the play context but it will do UI/parser/application by
itself).
>> 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
Why interfaces? It still have struct pl_func_s and struct pl_priv_s. Only
unified thing is prev->pl->next thread and some common calls: open() and
control() - if you look at vf_instance_t and af_instance_t you could see
both these structs have all these things.
>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.
It's hard to Gui (for example) to call all these functions anyway,
because when you want to add
I'm sure any type of plugin must be just registered in tree. For example:
static cfg_t cfg_vf[]={
{"vf",vf_create_chain,CONF_TYPE_PLUGIN_LIST,0,0,0,NULL,"video filters"},
{NULL,NULL,0,0,0,0,NULL,NULL}
};
void vf_register_internal_plugins(cfg_tree_t *tree){
cfg_t *newlist=NULL;
int i=0;
for(...;...;...){
newlist=realloc(newlist,(i+1)*sizeof(cfg_t));
newlist[i].name=vf->info->name;
newlist[i].desc=vf->info->info;
newlist[i].type=CONF_TYPE_PLUGIN;
newlist[i].priv=vf->info->opts;
}
if(newlist){
newlist[i].name=NULL; // termination
cfg_register(tree,cfg_vf,0);
tree=cfg_find(tree,"vf");
cfg_register(&tree,newlist,0);
}
}
It may be done by common call pl_register_plugin(), of course, but we
have to have plugins info unified then.
>> 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? :))))))))
No, thank you! :)))
With best wishes.
Andriy.