[MPlayer-G2-dev] Re: Limitations in vo2 api :(

[D Richard Felker III]

[bounded once, resending]
On Sun, Dec 21, 2003 at 03:52:49PM +0200, Andriy N. Gritsenko wrote:
>     Hi, D Richard Felker III!
> 
> Sometime (on Saturday, December 20 at 21:53) I've received something...
> >> As I said before chains must be supported by application only so it's not
> >> layer's care to keep all subchains in mind. :)
> 
> >Actually the layer needs to know about the whole thing to make
> >rendering work. It has to walk the whole chain to get source frames as
> >filters need them.
> 
>     Each filter has all it's own previous nodes so it'll just pull out
> frames from those and it's all. It even don't need to know if previous
> nodes are filters or decoders.

Of course not. Isn't that obvious?

> > Also you forgot to consider the most fun example:
> 
> 
> >-------> vf_subfilter ------>
> >          |      /|\
> >         \|/      |
> >   your_favorite_filters_here
> 
> >Where vf_subfilter is a filter that processes a subsection of the
> >image with whatever filters you hook up to its auxiliary output/input.
> >This example shows why it's not good to think in subchains/subtrees:
> >the filter pipeline can have loops!
> 
>     Filter vf_subfilter may have loops only if it may mix main input with
> looped input so we free to call link_video_chain(vf_instance,vf_instance)
> i.e. prev node == next node.

This is nonsense!!

The whole point is that there are _different_ inputs and outputs of
each node; they're not interchangible! So link_video_chain() api is
dumb!

If you want to know how it actually works in g2 vp code, you could
RTFS. Normally for filters you call vp_insert_filter on an existing
link, and the link forks to insert the filter in the middle. This also
works fine on something like vf_subfilter, which would by default have
a looped link to itself.

For split/merge type filters, different api is needed to manipulate it
interactively. And of course it has to protect against idiotic
infinite loops and such. Designing the api for this isn't a priority
right now since I just want to get g2 working... :)

> It will work anyway since all I said doesn't deny it. :)

Last I checked you weren't writing this, so what you say doesn't
really have anything to do with whether it works.

>     Exactly what I said - application must be aware about common part of
> nodes, not about layer-specific part.

OK, by "layer-specific" part, you mean the internals. To me,
layer-specific would mean the things that hold for one layer and not
another, e.g. audio vs video. So there's where our misunderstanding
was.

> It will know nodes pointers itself
> and keep all link structure in some own form (it may be some tree and so
> on in GUI or anything), independently from nodes structure. Why it must
> be so - tree of chains may contain not only nodes pointers but some GUI
> info and may be much of other. And layer-specific part (that including
> node-to-node pointers) must not be touched by application. But on other
> hand, full structure (parallel chains, crossed chains, mixed or splitted
> chains, sources and destinations) has no need to be known to layers. So

The internal vp code has to be able to walk the pipeline for
rendering, so it needs to know something...

> it's all I think. I hope I wrote it understandable. :)

Better now.

Rich