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

[D Richard Felker III]

On Tue, May 13, 2003 at 03:30:30AM +0300, Andriy N. Gritsenko wrote:
>     Hi, Arpi!
> 
> 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.

The config system should just manage querying and setting options in
tree and chain structures. It doesn't need to know anything about
movie playing.

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

Why do you need to have an associated stream to configure a filter
chain? The caller can keep track of a config context as needed. If
you're doing runtime configuration, the filters are already
'connected' to the stream by the player, and this has nothing to do
with the config system, but the filters could presumably use the
current stream attributes to limit configuration options. On the other
hand, if you're configuring offline before anything is being played,
then the filters will have to accept any options that might make
sense, then sanitize them when the chain gets configured at playtime.

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

I think Arpi was saying we could read the properties table without
calling dlopen (may be slow) for cases where we just need to know what
config variables are available, but not actually load the module.

Rich