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

[Xidorn Quan]

On Thu, Sep 6, 2012 at 1:19 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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.

Thx for describing that.

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

Yes, I know that. Even if it support other image type like NUMBERED,
it can't help performance without special hacks either. VDA always
generates buffers itself. For the current structure of MPlayer, at
least one copying is necessary. I don't think there is a good way to
solve this problem perfectly. However, it helps performance if there
is any vf inserted, when at least the final copying can be dropped.

However, it won't help performance for decoders which calls get_buffer
before decoding frames if all vfs in between support dr. Well, I think
it would rarely happen because vf_scale is usually required to be
inserted since corevideo only supports a few formats, and vf_scale
doesn't support dr.

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

Since the risk is already there for now, I don't think there is any
difference between using dr or not.

Obviously, sharedbuffer should be separated from vo_corevideo, and
even a better sharedbuffer protocol can be designed. Currently,
someone might have started working on it. In fact I found that
the fork of MPlayer which is named MPlayer 2 had separated them.