[MPlayer-dev-eng] Fixes/enhancements to vdpau
Dan Oscarsson
Dan.Oscarsson at tietoenator.com
Wed Apr 8 08:48:17 CEST 2009
On 2009-04-07 at 16:11 +0300 Uoti Urpala wrote:
> The user probably doesn't care that much exactly what frame MPlayer
> pauses on - but the VO must show the frame that it is paused on,
> whatever that is. If the VO shows something else that doesn't mean
> MPlayer is "pausing on that frame" - MPlayer is still pausing on another
> frame, with the VO showing the wrong thing.
I think I can make vo_vdpau show the correct frame by redisplaying last
frame when it is informed that video is paused. That should solve your
concern even though the cases where it matters must be very few.
I feel that we talk about different things so I skip trying to clear
that up and just take the most important part.
> >
> > The CPU clock and the card clock do not have the same pace. When I read
> > the time between two vsync:s I get the interval in card time. As mplayer
> > plays videos using system time and I adjust speed of a movie to match
>
> The overall speed is *NOT* based on system time in the usual case, as
> I've already told you a couple of times.
Maybe not, but mplayer manages timing by calling getTimer which follows
system time. Though mplayer syncs video to audio and I suspect audio
runs on audio cards clock which may not follow real time.
> Again, you're measuring the wrong thing for that use.
That may be - but it works for all movies I have viewed.
To better handle the cases where a weak CPU is not enough to decode some
frames/audio in time or to handle temporary system changes that make
some frame decoding take to much time, and to really be able to sync
audio with video, I would want mplayer to be redesigned to have separate
threads that do audio and video decoding queueing both audio and frames,
and an other thread handling the playing of audio and displaying if
frames. That way variations in decoding time could be handled better and
we could sync both audio and video to a suitable clock. But that
requires much greater change in mplayer than by current small
modifications.
More information about the MPlayer-dev-eng
mailing list