Re: Limitations in vo2 api :(

    Hi, D Richard Felker III!

Sometime (on Saturday, December 20 at 20:04) I've received something...
>On Sat, Dec 20, 2003 at 06:35:04PM +0200, Andriy N. Gritsenko wrote:
>>     Hi, D Richard Felker III!
>> 
>> Sometime (on Saturday, December 20 at 17:40) I've received something...
>> [...skipped...]
>> 
>> >This is the same as what I said in approach 1. And here's where it
>> >gets messy: In order to be useful to the common api layer, the common
>> >structure at the beginning needs to contain the pointers for the
>> >node's inputs and outputs. Otherwise it won't help the app build
>> >chains. So inside here, you have pointers to links. But to what kind
>> >of links? They have to just be generic links, not audio or video
>> >links. And this means every time a video filter wants to access its
>> >links, it has to cast the pointers!! :( Very, very ugly...
>> 
>>     Hmm. And how about to put these pointers in layer-specific part of
>> the structure (outside of common part) while any layer has it's own type?
>> I don't think application anyway will want these pointers since they

>These pointers are _exactly_ the thing the app will want to see, so it
>can build the pipeline. How can you build the pipeline if you can't
>connect pieces or tell when pieces are connected? :)

Here goes the example:

typedef struct {
  int (*add_out) (struct vp_node_t *node, struct vp_node_t *next, .......);
  int (*rm_out) (struct vp_node_t *node, struct vp_node_t *next, .......);
  vp_frame_t *(*pull_frame) (struct vp_node_t *node, .......);
  .......
} vp_funcs;

typedef struct vp_node_t {
  node_t n;
  struct vp_node_t *prev;
  struct vp_node_t *next;
  vp_funcs *func;
  .......
} vp_node_t;

So when we call link_video_chain(node,next) it will at first test if
node->func->add_out() exists and call it, otherwise if node->next was
filled then return error, else set node->next. After that do the same for
node next. If there was no errors then we assume nodes are linked. For
example, on pull_frame(node) we could pull frame from previous node by
node->prev->pull_frame. Calling unlink_video_chain(node,next) we will
do the same thing as on link_video_chain(). Since node_t is part of
vp_node_t and pointed to the same then both structures above may be only
in video_internal.h - application will know nothing about it but it will
work anyway. :)

>> I don't see any example when two the same filters may have more than one
>> connection in the same chain so it's easy.

>Hrrm, that's the whole point. The speech synth thing was just for fun.
>Normally multiple inputs/outputs WILL be in the same chain, e.g. for
>merging video from multiple sources, processing subimages of the
>video, displaying output on multiple devices at the same time,
>pvr-style encoding+watching at the same time (!!) etc.

    Multiple sources are really multiple subchains so we have:

-----> vf_aaa -.  [node 1]
 [subchain1]    \     [node 3]
                vf_mix ----->
                /
-----> vd_bbb -`  [node 2]
 [subchain2]

             ,----> vo1   [node 2]
            / [subchain1]
-----> vf_split           [node 1]
            \ [subchain2]
             `----> vo2   [node 3]

As I said before chains must be supported by application only so it's not
layer's care to keep all subchains in mind. :)

About muliple links between nodes - you are really suppose that may be
something alike that:
 
               /----------\  [subchain one]
-------> vf_a [node 1]   vf_b [node 2] ------->
               \----------/  [subchain two]

All other causes will be just partial subchains which will be handled by
filters. :)

>In any case, I was talking about all the links including primary input
>and output, not just the extras.

    See my explanations above. :)

>> API just will have some proc alike (assume that stream_t is common
>> node structure, I don't make smth better yet):
>> 
>> stream_t *open_video_filter(char *name);
>> int link_video_chain(stream_t *prev, stream_t *next);
>> int unlink_video_chain(stream_t *prev, stream_t *next);

>If these functions have _video_ in their name, there's no use in
>having a generic "stream" structure. vp_node_t is just as good!

    But what I said before is just simple structure for application's
developers so we prevent all level-specific data from touching by
application and application's developers will learn only common API. :)

    With best wishes.
    Andriy.