[MPlayer-dev-eng] [PATCH] reduce flashing on resize with VDPAU

[Dan Oscarsson]

>On 2009-03-23 at 10:26 -0700 Stephen Warren wrote:
> > However, given that, I still think the presentation queue timestamp
> > mechanism should be used to ensure that they actually get presented at
> > the intended time, since this may be a HW operation and subject to less
> > jitter than SW timing. Also the PQ status feedback should be used to
> > determine if display was actually late (due to PQ display call being too
> > late to meet the timestamp, e.g. GPU overloaded, or MPlayer scheduled
> > out for a very long time delaying stream parsing, bad stream timestamps,
> > etc.)
> 
> I did think about using the timestamps and have in my code (not the
> patches just posted) code that correlate timestamp time with system
> time. But did not find a good way to use them without change a lot more
> in mplayer outside the libvo.

As mplayer outputs frames at the wanted rate without regard to vsyncs,
you get a problem for example, when the rate is faster the the vsyncs.
Queueing using timestamps could then result in two frames expected to be
shown within one vsync. As vdpau works now (from what I have seen), the
first fram will be shown at next vsync, and the next frame at next
vsync. Even if timestamps say show at first vsync.

If mplayer had knowledge on vsync interval and when the vsyncs occur, it
could better decide what frames to drop and what frames to show and
when. But this requires quite a lot of change in how mplayer works
today. It would probably need a special thread to handle the frame
show/dropping and mplayer is not multi-threaded enough yet for that.