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

[D Richard Felker III]

On Sat, Dec 20, 2003 at 04:58:15PM +0200, Andriy N. Gritsenko wrote:
>     Hi, D Richard Felker III!
> 
> Sometime (on Saturday, December 20 at 15:52) I've received something...
> 
> [...skipped...]
> 
> >I see two approaches to having a unified api for building the
> >pipelines:
> 
> >1. Storing the linked-list pointers at the beginning of the structures
> >   for each type, and type casting so that they can all be treated the
> >   same. IMO this is a very ugly hack.
> 
> >2. Having a second layer on top of the underlying pipeline layers for
> >   the app to use in building the pipelines. This seems somewhat
> >   wasteful, but perhaps it's not.
> 
> 3. Have some common structure type stream_t. Then, for example, video
>    stream structure will be:
> 
> typedef struct {
>   stream_t st;
>   ....... /* rest are video-specific */
> } video_stream_t;
> 
>     Then just assuming from application point of view some *vidstr1 is
> stream_t*, from video filter (demuxer, vo, etc.) point of view it's
> video_stream_t*. Anyway that video_stream_t may (and must) be created
> only by video layer API so there isn't any problem with that. :)

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

Rich