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

Andriy N. Gritsenko andrej at lucky.net
Mon Dec 22 12:51:16 CET 2003


    Hi, D Richard Felker III!

Sometime (on Saturday, December 20 at 21:56) I've received something...
>>     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

>I created the idea of primary input/output on purpose. A filter that
>doesn't want to distinguish is free to ignore the difference, or to
>use only secondary links if it prefers.

    Yes, I thought the same - main (layer-specific) node structure have
only one link pointer and if filter may have more that one link here it
will use own private array anyway and it may use or may use not that link
pointer. Otherwise we will have some add_input() stub (default proc) that
will use that only link ptr. :)

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

>Something like that.

    I'm glad we agree with that. :)  So as resume - we don't need to have
prev/next pointers in main (common,public,etc.) node structure since no
application may use it.

    Summary of arguments to have layer-independent node structure:
1. Application will not see layer-specific data.
2. Application cannot alternate links pointers so we get rid of bad
 developers who may want to manipulate it but they will use (un)link_*
 functions instead.
3. Application's developers will see less docs so it will be simpler for
 they.
4. We will have only one node structure instead of 5 (1: compressed (or
 undefined) stream between demuxer and decoder or between codec and muxer,
 2: video, 3: audio, 4: text/sub, 5: menu/etc.) so will have less of mess.

    Do you see any arguments against it?

    With best wishes.
    Andriy.




More information about the MPlayer-G2-dev mailing list