[MPlayer-dev-eng] [PATCH] DR support for vo_corevideo

[Reimar Döffinger]

On Thu, Sep 06, 2012 at 11:17:23AM +0000, Zongyao Qu wrote:
> > 2) Since there is neither double-buffering nor a way to wait for the
> > application to finish processing for shared_buffer, you can't use
> > direct rendering with it, it would cause a significant risk of tearing
> > or even worse artefacts due to the decoder already drawing the next
> > frame into it before the application finished process.
> 
> lacking of double buffering is a big problem, so I made a patch for
> myself.
> 
> https://github.com/niltsh/mplayer-for-
> MPlayerX/commit/a8e911716d0362500f3455f30f2d7b2129164e6b
> 
> But in this patch, the Protocol for buffer sharing is not compatible
> with previous, so I'm afraid it will make many mplayer frontend
> developer angry.

I don't think that should be a huge problem, we could for example
support the old protocol with -nodouble and choose a completely new
protocol if -double is used.
That probably will break frontends, but at least the fix would consist
only of adding -nodouble to the config until the new protocol is
supported.
Maybe it's even possible to auto-detect the protocol used.
However it might make sense to just start from scratch with a new vo,
since I think your approach isn't really going far enough.
For example it should be possible to just let the application on
the other side handle the query_format, so that it is possible
to pass on other formats like YV12 directly if the application
on the other side can support it (but without _requiring_ the application
to support all possible formats).
Generally I think it would need a good bit of design work, thinking
through all that might make sense to support, but also looking
at how much of a pain this would be to actually use.
(another question would also be whether this makes sense/should be
OSX specific really - also keeping in mind that there are a lot
fewer people that can maintain, test, fix,... any OS X-only
functionality).