[MPlayer-dev-eng] [PATCH] vda support for mplayer

[Reimar Döffinger]

On 18 Aug 2012, at 13:23, Xidorn Quan <quanxunzhen at gmail.com> wrote:
> On Sat, Aug 18, 2012 at 5:48 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de>wrote:
> 
>> That is just a bug/bad implementation. I have tried fixing it, but the
>> shared buffer support makes it messy and for me personally -vo gl works
>> so much better I have a hard time caring about the corevideo vo any
>> longer.
>> 
> 
> I suggest we separate shared buffer from vo_corevideo since I found
> that shared buffer is absolutely unrelated with corevideo except that
> they all rely on API of OS X. When shared buffer is enabled,
> corevideo just copy data to the shared buffer and transmit messages
> to the receiver.
> 
> If we don't use the OS X specified IPC, the shared buffer could even
> support all UNIX-like system which support IPC with shared memory.
> Or we can implement an shared buffer vo to support sharing OS X's
> CVPixelBuffer between processes to let players render directly with
> no addition copying. Zongyao Qu told me that he is interested in
> implementing something like that.

I am by all means interested in a better solution, though I don't know how much gui authors will like if you remove a feature they rely on - even if it comes with a better replacement.
For something completely new, I would suggesting thinking of how it should work in detail first.
(I am using the term "GUI" to mean any client app of that shared buffer)
One problem the current code has for example is that MPlayer might overwrite the image before the GUI is done using it.
Due to no double-buffering it also is not possible to give one buffer to the decoder for rendering the next frame while the GUI is rendering the previous one.
Apart from that I'll be of limited help since I only have an old PPC mac, and doing development on something that slow is not especially fun.