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

[Arpi]

Hi,

> On Tue, May 13, 2003 at 08:20:02PM +0300, Andriy N. Gritsenko wrote:
> > Do you have any suggestions to do it without management of plugins by
> > UI/parser? I want to hear it, tell me, please.
> 
> Yes.
> 
> 1) Inserting and removing filters is not the job of the config engine,
>    aside from preparing the config variables for a filter when it's
>    being added.

1000% aggree

> 2) For initializing a chain, the config system can just take in the
>    string, and return a chain of config structures. The player then
>    proceeds to load and initialize the filters along with the codecs.

1000% aggree

> 3) This is a side-note, but I want to make sure that it's possible for
>    mp g2 to support not just filter chains, but filter trees. For
>    example, we should be able to have two video sources and render
>    them side-by-side, or pip. I'm not thinking just of toy-type things
>    in the player, but rather a professional-quality digital filmmaking
>    environment where you need to do cross-fades, overlay special
>    effects, etc.

we (I + dun't remember who, maybe vektor or iive?) already discussed this a
little bit. i didn't plan such thing (filter branching) in g2.
i said that mayeb in g3...

but recently i realized that many users (even including me) wants to see what
is being recorded from tv, for example. it's somehting like mplayer+mencoder
in one, or in simpler form: libvo support in mencoder.
it actually means filter branching, you have to send the same image to both
vf_vo2 and ve_something. and if we already implement such thing, free
branching is not so far. although it raises several problems, related to DR,
slices, colorspace, fps and stride and buffertype autonegitiation...
it's far from being trivial to implement, and i want to avoif this extra
complexity at this moment.
but as g2 is desigend to be clean modular, it will be easy to add later.

stream merging is easier a bit, but not much.


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

> 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()

>    that a gui interface could let you graphically connect the nodes,
>    or or so that a script-based editing system could add and remove
>    filters as needed during editing. (Perhaps some filters would even
lol

>    want to add and remove filters, e.g. a telecine detect filter
>    removing/adding inverse telecine or interpolative deinterlace
>    filters based on the detected content.)
> 
> Arpi, comments?

see above

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.

if we define infinite requirements now, we'll never reach any working code.


A'rpi / Astral & ESP-team

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