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

[Reimar Döffinger]

On Wed, Sep 05, 2012 at 03:48:52PM +0800, Xidorn Quan wrote:
> On Wed, Sep 5, 2012 at 3:00 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
> >
> > vo_x11 supports only TEMP image type I think, that problematic behaviour at least for now is constrained to NUMBERED buffers I believe.
> > vo_gl doesn't need to specifically check for it, since get_image uses a separate buffer (the texture) that is not used for a draw_image that did not do a get_image first.
> 
> You said that decoder may requests lots of buffers at the same time,
> so I wonder why the vos not check if get_image is called many times
> before a draw_image is called.

Basically: because it's constrained so that it should currently only
happen for the NUMBERED type, and (except for hardware accelerated
decoding, where it is not an issue either) vo_gl is the only one
supporting that one, and it ensures that there's only one
given out by only ever giving out number 0.
A more general answer however is: Because the whole direct rendering
stuff is broken all over (which is also why it is not enabled by
default) and a good bit of it works just by pure luck.

> And is it ok to make dr for vo_corevideo only support TEMP and STATIC
> images like vo_x11?

Sure, that is perfectly fine.
Some issues though:
1) I suspect that might mean it won't help performance
for the VDA case anymore then, at least not without special hacks.
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.
There actually is quite a risk for that now already so that the memcpy
should probably be moved from draw_image to flip_page (only for the
shared buffer use case of course), however that would make performance
even worse.
Which is why I said it really should be thrown out/replaced, it is
mis-designed and also mis-placed (no good reason to have it in vo_macosx
really).