[MPlayer-G2-dev] Re: G2 CLI/GUI and config API again - a little request.
Andriy N. Gritsenko
andrej at lucky.net
Tue May 13 10:12:33 CEST 2003
Hi, Arpi!
Sometime (on Tuesday, May 13 at 8:48) I've received something...
>> 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"
Yes, I've seen test-play.c many times, it has:
static char** video_driver_list=NULL;
static char** video_filter_list=(char**) NULL;
etc.
With that statement you will never can get more than one video stream
(the same for audio) - you just fixed yourself on the one and it's all.
You want to live with that limitation forever? I don't want but you let
me change nothing, unfortunately.
Ok, I know, my English is bad. I'll try to describe the problem in
details. Player (or encoder, or smth else) never know what to play. Just
think about it and you cannot deny it. Only parser (or UI, the same) may
tell the player what and how to play. But player have to give the UI some
variable(s) where UI will put that info. Currently it's static vars. I've
proposed some play_context array for this and pass it to parser/UI. If
you don't want to play more that one video and audio then leave it as
static. If you want to play more then you have to develop some structure.
Sorry but you have no choice.
>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.
See what I've said above. I hope I've said it clearly.
>> >> 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?
See what I've said above. Only parser can tell you if you need to
load that plugin or not. Anyway I've described then _not config_ work but
all plugin load sequence - no difference who will call it in details, or
test-play.c, or something else.
>> 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?
Pass where? I don't said to pass, I've said to keep parameters inside
of filter (BTW, you've written it yourself as vf->priv in your examples).
If you will dislike to keep these parameters in vf->priv then you could
make new struct vf->params or something else.
>> 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 :))))))))))))
It's not cool, it's c00l. ;)))
>> But how? You seem to dislike everything now. ;)
>yes
Get rid of your bad spirit - join a party, go to the nature, see the
nice movie, etc. - do what you want. :) It's bad to be in bad mood. :)
BTW, I already tired of all that - you're saying your thought, I'm
trying to do it, asking for details, you're aborting what you said before
- if that will keep forever, I'll just give up. I really tired, sorry. :(
With best wishes.
Andriy.
More information about the MPlayer-G2-dev
mailing list