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

Andriy N. Gritsenko andrej at lucky.net
Sat Dec 20 20:22:25 CET 2003


    Hi again.

Additional comments here...

Sometime (on Saturday, December 20 at 21:02) I've written something...

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

    Just keep in mind some filter may have multiple _equal_ inputs or
outputs so there isn't some "primary" input or output node. Also if we
will eventually delete some node which is "primary" but leave "secondary"
ones then it may be full a mess since both application and filters must
reconsider which of "secondary" nodes must be set "primary" after that.
So filters with multiple inputs must handle it internally and node->prev
will be left NULL in that case. So we have no right to application to
manipulate any prev or next pointers - it must be done only by functions
link_video_chain() and unlink_video_chain(). :)

    With best wishes.
    Andriy.




More information about the MPlayer-G2-dev mailing list