[MPlayer-dev-eng] Fixes/enhancements to vdpau

[Jason Tackaberry]

On Tue, 2009-04-07 at 11:26 +0200, Dan Oscarsson wrote:
> Multi-threading would allow an independent frame display thread that can
> match frame displaying to vsyncs. This cannot be handled in main mplayer
> thread as it only calls vo routines when it wants to send a frame to be
> displayed.

As a point of interest, I ended up working a PoC for an out-of-process
renderer that takes a similar approach to retrace-precise frame timing.

MPlayer sends the frames in YV12 over shmem to the render process, which
uses GL to do colorspace conversion and draw the frame.  (Obviously this
means it doesn't work with VDPAU.  I still need to cook up an idea to
deal with that.)

It examines the pts of each frame, and if the pts looks stable (i.e. not
VFR) and the fps derived from the pts is an integer-multiple of the
display's refresh rate (which it calculates rather crudely based on
retrace timings), then it will maintain a queue of 2-3 frames and begin
drawing them at the correct retraces.

If the above conditions aren't met, then the renderer will simply draw
frames as soon as they come in from MPlayer.

The purpose of the frame queue is to smooth out any A-V timing that
MPlayer itself performs.  In principle it's very kludgy, admittedly, but
in practice it works.

It works because of the more narrow context the above logic will be used
in, which is for Freevo 2, where MPlayer is controlled as a slave
process (so we can adjust audio delays through slave commands), and we
basically own the display.

Having the renderer as a separate process obviously lets us make sure
we're flipping buffers at the right time, as you noted previously, and
also vastly simplifies the degree to which we need to hack MPlayer,
limiting things to a fairly straightforward custom VO.  The latter point
is relevant if we ever hope to have those changes merged: experience has
taught me the MPlayer hackers do not like it when patches touch core
areas like timing. :)

Cheers,
Jason.