[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