[MPlayer-dev-eng] XvMC simplify

Reimar Döffinger Reimar.Doeffinger at gmx.de
Mon Apr 25 22:43:44 CEST 2011


On Mon, Apr 25, 2011 at 11:33:29PM +0300, Ivan Kalvachev wrote:
> I prefer a different approach, that I find simpler. Resurrect the
> xvmc_render struct and made its first member hold the shared
> xvmc_pix_fmt struct. This way they both would share pointer and could
> be assessed just by cast. Same trick is used in FFmpeg for the
> MpegEncContext.

I agree, I just for some reason didn't think of it.

> On side note. Reimar, good work with the mpi->usage_count.

It doesn't really quite work, ideally you could just use the
index the get_image function is passed, but that requires the
usage_count to be split, basically in a "hard" and "soft"
usage count, where "soft" usage means if we run out of
surfaces we can reused it even if the usage count is not 0.

> I would like you to give a little thought on general code for the
> other video outputs.
> Basically mpi should be marked as used while it is visible, with
> special case when there is only one available buffer. (this all is
> about -dr mode).

Currently it pointless, since usage count is only really used
with the buffer types VDPAU and XvMC use.

> In the XvMC (and probably other vo's like svga) the problem is that
> the switch of the visible buffer doesn't happen with the issue of the
> new display command. It is delayed until the actual retrace. So
> freeing(usage_count--) may be a little tricky.

The more messy thing about it is that we don't really want to
use usage_count for that, in the worst case we should still
use this buffer (which also makes the case of only one available
buffer no longer a special-case).
The way that XvMC does it currently means the buffer index
selection is run twice, once in core code and once in the vo.

> I'll commit in few days if there are no objections.

Looks ok to me, assuming you were able to test.


More information about the MPlayer-dev-eng mailing list