[MPlayer-G2-dev] Re: VP layer progress [update!]

D Richard Felker III dalias at aerifal.cx
Wed Dec 24 07:56:08 CET 2003


On Tue, Dec 23, 2003 at 06:29:01PM +0200, Andriy N. Gritsenko wrote:
>     Hi, D Richard Felker III!
> 
> Sometime (on Tuesday, December 23 at 17:42) I've received something...
> >On Tue, Dec 23, 2003 at 01:35:12PM +0200, Andriy N. Gritsenko wrote:
> >>     Are you sure vp_node_t must have vp_link_t** pointers? As I may see
> >> some filter may want it as NULL-terminated list, some as counted list
> >> (but there is no counter in the structure so filter will have it in
> >> vp_priv_s), some may want to sort list in own order so have some own
> >> structure for that. So I think you have to remove these xin and xout
> >> pointers from vp_node_t structure since it may be just a waste. If any
> >> filter may have more than one input or output link then that filter may
> >> always have these pointers in vp_priv_s structure. :)
> 
> >Impossible. If the pointers are hidden, vp_pull_frame can't walk the
> >chain! Originally when I was planning for recursive calling, I
> >intended to do something like this, but now I think there has to be
> >some unified structure or else the vp layer and the program that set
> >up the pipeline can lose track of what's in it!
> 
>     How do you plan walk the chain when chain is combined from mixing and
> splitting filters and some filters are not-plain mixer but something with
> interleaving?

RRRR    TTTTTT  FFFFFF  SSSSSS  !!
RR  RR    TT    FF      SS      !!
RRRR      TT    FFFF    SSSSSS  !!
RR  RR    TT    FF          SS  !!
RR  RR    TT    FF      SSSSSS  !!

The code is already there, and it's very short and simple. Walking
starts from an endpoint where you want to get a frame out, and goes
everywhere it needs to. Splitting filters are responsible for
buffering whatever they need so that they can later output to other
outputs when the pull occurrs.

> And if inputs may be added/deleted/stopped/resumed on the fly?

No problem.

> Just keep in mind that G2 may be used for some video editor, for
> example.

Arrggg!!!!!!!!!! RTFMLA!!! This has been my intent from the very
beginning, and why I insisted on replacing vf layer entirely rather
than just slightly improving it like Arpi originally wanted.

> If you don't allow such mixed chains then you just limiting G2
> without real needs. ;)

WTF is a "mixed chain"?

>     About "program that set up the pipeline can lose track of what's in
> it" I'm sure it may happen only if application's developers are too lazy
> to handle that pipeline. :)  I'm still sure pipeline must be controlled
> only by application. Don't overcomplicate layers, please. :)

No, in fact it MUST be controlled by the internal vp code, for
auto-inserting filters when there's a format conflict.

Please, before making any more nonsense posts.... READ THE FUCKING
SOURCE!! **AND** all the relevant proposal docs to the mailing list
(tho some are outdated) **AND** the working docs in my vp-in-progress
dir....

Rich




More information about the MPlayer-G2-dev mailing list