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

Andriy N. Gritsenko andrej at lucky.net
Fri Dec 19 15:49:11 CET 2003

    Hi, Attila Kinali!

Sometime (on Friday, December 19 at 13:19) I've received something...

>(First: dont assume that i understand anything about the vp/vo layer
>at all. This here is just a random blurb)

>On Fri, 19 Dec 2003 03:44:48 -0500
>D Richard Felker III <dalias at aerifal.cx> wrote:

>> I tend to think that the vp layer should call the vo layer's
>> get_buffer and release_buffer every time it wants to use buffers,
>> rather than just getting them all at the beginning. This way, the vo
>> driver would be free to decide when it can or can't give you buffers.
>> But right now, the vo drivers are NOT written to support that sort of
>> use. For example, the x11 driver allocates an image when you call
>> get_buffer, and frees it when you call release_buffer -- very
>> inefficient!

>Imho this can be easily solved on x11's side by allocating some
>buffers (X11images) before hand and manage them with get/release_buffer.
>Every X11 programming book tells you anyways to allocate everything
>you need at the beginning of your programm to allow caching at the
>server side.

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

    With best wishes.

More information about the MPlayer-G2-dev mailing list