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

Arpi arpi at thot.banki.hu
Wed May 14 14:46:32 CEST 2003


Hi,

>     Ok. I'll try to explain you with an example. You have a Gui encoder.
> You didn't started encoding yet. You opened dialog box for filters. Are
> you surprised with that? Do you still think if Gui may only have string
> input for the filters? If you think so then Gui is just graphic command
> line for you and users will call us hellmakers.
>     So we are in that dialog box. It consists of two panels: on left we
> have created filters chain, on the right we have full filters list. What
> I want (I'm there an user)? I want take a filter in the right pane then
> drag it in selected place in the left (not only to end of list but in the
> some place there), drop, and after that doubleclick on it to configure.
> Any other behavior isn't understandable for me.
>     So our concept _must_ allow that. We _must_ allow get a command from
> UI to insert or delete filter in the any place then return to UI but
> don't start encoding yet. Do you understand me?

yes, but you don't seem to understand the video filter layer at all.
in gui, you build a list (be it a string list or config_t list) of filters
and its parameters, but it doesn't mean you call filters' open() at all!
you cannot even call filters' open() at this level, you can do it only
after tail filter (encoder/vo) is prepared, and teh codec is initializing
(the filter chain is opened from the top filter, ie vf_vd, after colorspace
etc autonegotiation initiaetd by the codec!)

Gui's work is to let user select filters from a combobox (drag'n'drop from
right to left in any order, move/remove it from left list etc) but it's
about a list of strings, not about actual filter code!

At teh end teh gui will pass this array of filters/configs to the video core
togethwer with codec info and tail filter (encoder/vo) and get the chain
stabilize and open. it's far not the job of any config layer!

> >> 4) With that in mind, I think it might make more sense for the config
> >>    system not to handle filters at all during the initial parsing
> >>    phase, but just store filter chain strings provided from the
> >>    command line or whatever. Then, when we get to the relevant file in
> >>    the playtree, the player can split up the filter chain/tree, load
> >>    the appropriate filters and connect them, then call the config code
> >>    *again* with the config strings it has for each filter to
> >>    initialize them.
> 
> >this is what i want, and described in a long mail sent 3 mins ago.
> 
>     If we talking about command line interface only then this is ok. For

no

> UI it's bad - why user have to close dialog box to let player create all
> chain then open it again to configure filters? It's hell for the user. Do
> you want to deny Gui at all or you think Gui isn't like a parser?

no

may i ask such a silly question, too?
do you want to implement a whole encoder/player gui called as config layer?

> >> 5) Perhaps you'll also consider this part of the config code, but it's
> >>    very different from the main options parser, IMO: There needs to be
> >>    code somewhere to allow interactive editing of the filter tree, so
> 
> >it's planned via control()
> 
>     How you plan to use that control() if you disallow UI/parser to know
> that control() exists?

since when i disallow that UI know it?
i disallow parser know it, but it's not the job of any parser.
parser's job is to do parsing. surprise?

> >but i guess stream path merging/splitting and graphedit cannot be expected
> >before g3. first we should cleanup g1 (actually reproduce some parts, port
> >the rest) to have something we can play (and not suck) with.
> 
> OOPS... we plan to deny API for UI before g3? It's too sad, we can die
> before that and don't see API for UI... :(((  All we need is to create an
> API function to pass these insert/delete commands to vf or af engine. Is
> that too hard? Only one function will solve all problems so UI can do
> callback without exiting.

lol


A'rpi / Astral & ESP-team

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



More information about the MPlayer-G2-dev mailing list