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

[Andriy N. Gritsenko]

    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
aren't need for sync and other application-level stuff. If node has two
or more inputs or outputs and we'll need to change some partial link then
it's sufficient to pass two pointers to members of chain to level's API.
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. 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);

so only application will track all changes within that chain. :)  If you
thinks about frame processing then it's not a problem at all. Since we
leave only pull-way getting frames then each last processing unit
(vo/ao/muxer) will have some proc alike:

int vo_process_frame(stream_t *vos, double pts, double duration);

I understand it's defferent from G1's API but it's simpler and more clean
IMHO. I think it also will help a lot to do A-V sync.

    With best wishes.
    Andriy.