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

Andriy N. Gritsenko andrej at lucky.net
Tue Dec 23 17:29:01 CET 2003

    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? And if inputs may be added/deleted/stopped/resumed on the
fly? Just keep in mind that G2 may be used for some video editor, for
example. If you don't allow such mixed chains then you just limiting G2
without real needs. ;)
    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. :)

    With best wishes.

More information about the MPlayer-G2-dev mailing list