[MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request.

[Arpi]

Hi,

> Sometime (on Tuesday, May 13 at  2:16) I've received something...
> >>     Why I want that API? I want to add play_stream* to pl_instance_t so
> >> we could have another config context for each stream and any parsing
> >> function will know it's context - I mean vf_create_chain() from my
> >> previous letter to add new filter in the filter chain. So config belongs
> >> to play context and play stream has only one play context.
> 
> >no, forget this mess
> >it's getting the same cross-dependency everywhere as it was with playtree
> >code
> 
>     Where did you see cross-dependency? Tell me, please.
> 
> >don't mix player contexts (don't even define them yet, it's UI thing for
> >sure) with underlaying layers and config api, please!
> 
>     Ok. How do you propose to pass what of streams do you want to
> configure from UI to vf,etc. ? Using statics for it isn't acceptable -
> you are one who wants to avoid statics. You may have many streams (for
> example, 3 mixed videos and 2 audios from different files) and you have
> to configure each of it. If you want to dislike all I've proposed there
> then, please, tell me the other way. But we __have__ to pass some stream
> pointer from UI/parser to vf_open_filter(). Or you want to give up the
> multistreaming idea, eh?

have you ever looked at test-play.c ?

no streams and such things passed (directly) to vf_open_plugins()
yes it's passed to vf_open_filter when opening special filter "vd"

i can't see where UI plays or why do you want to introduce more structs here

yes, the a-v sync engine surely needs some struct to keep stream state info
(pts, etc), but it's another game, not related to filters or config layer.

> >>     So with that API we will get what you want and UI will create chain
> >> by itself. Each time any UI/parser can parse input in only one stream
> >> context, isn't it? Initiating new filter will work in order:
> >> 1) parse input in current stream context (directly from Gui or for
> >>     current input file/sid from config parser);
> 
>     UI/config parser have to parse it's input, isn't it? What's wrong?
> 
> >> 2) load loadable plugin if need and get it's config structure;
> 
>     If we have that plugin loadable then how we can call open() if we
> don't dlopen() it? What's wrong?

why do you want to call its open() in config level?

> >> 3) call vf_create_chain() - it is vf_open_filter() but for plugin API;
> >> 3a) vf_open_filter() calling vf->open();
> >> 3b) open() creating new params instance with defaults or previous
> >>     settings (in depending of config variable alike "persistent_filters",
> >>     some people will like one way, some other);
> >> 3c) open() calling cfg_parse_config() for that play_stream and own params
> >>     instance;
> >> 3d) cfg_parse_config() setting parameters for instance;
> >> 4) continue parsing... :)
> 
> >what a mess
> 
> It's what _you_ said before. Cite with comments at right:
> 
> ----
> vf_foobar_open(vf_instance_t* vf, void* args){          <-- 3a)
>     vf->priv=calloc(sizeof(priv_st),1);                 <-- 3b)
>     if(!cfg_parse_args(vf->priv,config)) return 0;      <-- 3c) 3d)
>     ...
>     return 1;
> }
> ----
> 
> What's wrong when I've written it in words?
> 
> >> Runtime change of parameters:
> >> some UI calls vf->control(vf,VFCTRL_SET_PARAMS,NULL); that control() call
> >> will do:
> >> 1) create new copy of vf->priv;
> 
> >PLEASE!
> >it's called priv (_P_ _R_ _I_ _V_) as it's from _PRIVATE_.
> >It means it's not your business, you don't even know what is it. ok???
> >forget priv, please.
> >priv may contain pluginspecific data types, big arrayes, whatever.
> >don't mess it with configure, ok?
> 
> OK, OK, I don't mind if we create new type of structure and add it in
> vf_instance_t.

why to add it? why can't you pass it as a parameter, in place if char** args?

> I've wrote vf->priv since vf->priv _already_ have the
> configuration variables _everywere_. So don't blame me for that, please.
> 
> >keep config layer separated, as we defined as one of teh main goals.
> 
>     Without any API at all? :)))))))  May be we have to forbid any UI or
> parsers for G2 at all? :)))))))  Gui is the worst! Commandline deprecated
> too! Nothing is the best! :)))))))

cool, we finally agree on something :))))))))))))

> >ie. pass a clean, config-variables-only structure to the open() functions,
> >and let them decide what and how they will use from it.
> >forget messing with priv, forever.
> 
> >>     I hope it's the best way that can get rid of statics at all. Arpi,
> >i doubt
> 
>     I don't doubt, sorry.
> 
> >> please, correct all what you don't like in these structs and that scheme
> >== rewrite it
> 
>     But how? You seem to dislike everything now. ;)

yes

> >> (but I hope that scheme is already what you wanted :) and I will apply it
> >not really...
> 
> >sorry.
> >it seems we should (re-)discuss the goals and possible implementation ways
> >first. probably all goals cannot be reached at the same time, so we have to
> >decide which ones are less important, and remove them.
> >then define how and what to implement to reach the rest.
> >this ad-hoc coding doesm't seem to perform well...
> 
>     Tell all goals you see. I already don't know what you want to see

i'll do that soon

> from config API at all, sorry. I wrote what I read from you - you calling
> it a mess, I proposed to have strict API - you say all API is parser
> specific. I don't know what you want. Sorry. :(

neither i know
if i would know, i would already implement it.

>     I'm afraid we will never get good API that way... :(

what way? by thinking & design first?


A'rpi / Astral & ESP-team

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