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

[D Richard Felker III]

On Wed, May 14, 2003 at 12:28:37AM +0200, Arpi wrote:
> > 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.

I'd really like to see this in g2, so do you mind discussing some of
the difficulties you see? To me, it seems pretty simple.

1. If a filter has multiple outputs by nature (e.g. splitting fields
   to process separately, maybe even to encode as two separate files
   to save disk space), it just runs the config chain for each output
   path, and it will have to know what to do with each one.

2. If a filter has multiple inputs (e.g. cross fade), it obviously
   needs to expect a config from each one, and handle them in some
   sorta sane way.

Both of these cases could get messy in some details, but that's a
problem for the filter author (mostly), not for the filter
architecture. The last case...

3. An ordinary filter with one output (and one or more inputs) needs
   to be connected to multiple outputs (e.g. to watch tv while
   recording).

...is a bit tougher. IMO the correct way to handle it is not to handle
it. Instead, have a filter vf_tee that takes an input an splits it
into multiple outputs. Then vf_tee is responsible for all the logic
with handling DR. But, even nicer, we don't have to implement vf_tee
to begin with. :)) As long as the overall filter architecture design
is ok, it can be done later without affecting anything else.

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

Well, it sounds a bit ridiculous for simple chains. But for a tree
system like I'm talking about, it might be sort of reasonable. You
could even consider the case of a graphical editing program, where you
tell it to edit/encode for some duration of time, then stop to let you
edit the filter chain (to start a new scene or something).

Personally, I would want to do this with a script, but I can see how
newbies might prefer to have a graphical approach.

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

I hope we can do it without many requirements on the actual filter
system, so it can be added painlessly without another
rewrite-from-scratch. Or maybe you intend g3 to be more incremental,
as opposed to g2 which is lots of rewrites.

Rich