Re: Re: Limitations in vo2 api :(

On Fri, Dec 19, 2003 at 04:49:11PM +0200, Andriy N. Gritsenko wrote:
> >Also, as i already said on irc, we should IMHO integrate the
> >vo api into the vp and drop it. It would get us one api less
> >to document/learn and also remove some duplicated work as
> >a vo modules is much like a vf w/o an output.
> 
>     In addition to that we will have unified API for muxer too, i.e.
> muxer will be "connected" to vp API the same way as vo and this will
> help a lot. :)  Encoder software will just make that "connection" and
> do a-v sync. I think it may be done alike mplayer do it but instead of
> real time for sync it must be audio PTS.
>     So add my vote for unifying vo and vp APIs. :)

I'm still not sure about this. There are two sides to it:

On the one hand, unified api means fewer apis to learn and document,
less wrapper code, and simpler implementation for the player app.

On the other, having separate apis means you can take the layers apart
and use one without the other. For instance, demuxer and muxer layer
could be used without any codecs or video processing to repair broken
files, or to move data from mkv container to nut container (hey, I
guess that also qualifies as repairing broken files :)))).

Actually I'm somewhat inclined to integrate more into the vp layer
directly, but certainly not until after the audio subsystem has been
overhauled too. And I _don't_ want a repeat of the "let's make
everything part of the config layer!!" fiasco...

IMO the vp/vo/muxer[/demuxer?] integration is only appropriate if it
can be done at a level where the parts share a common api, but don't
in any way depend on one another -- so they can still all be used
independently.

Rich