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

[Reimar Döffinger]

On Thu, Sep 06, 2012 at 09:05:52AM +0800, Xidorn Quan 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.
> > 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.

First: I realized it doesn't really matter since it will only be an
issue when someone uses -dr explicitly, so that's not a reason to stop
the patch.
However I disagree with the argument for a few reasons:
1) the risk for artefacts depends on how long the operation writing
into the shared buffer takes. For the memcpy that probably is around
1%, for decoding into the buffer than can easily go up to 80%
2) The artefacts of a partially decoded frame are much worse: instead
of a horizontal line it will be a "step" around some macroblock.
In addition when decoding e.g. H.264 slice parallel, there can be
e.g. 8 instead of just 1. (and one could imagine decoders where
the intermediate results would look even worse than that)