Originally Posted by Stephen Warren
I don't think VDPAU needs to expose this information; unless I'm wrong, detailed mode timing information is already available via other X APIs, which MPlayer already uses.
I have not found any for this. You can get some through X APIs but what I get back is 24hz on a 23.976hz rate. Not good enough. To be able to do really good A/V sync handling you need a resolution of at least micro seconds. nano seconds would be better.
My patches get the time between vsyncs by queuing surfaces to the presentation queue and read when they are displayed. Timing over 3 vsyncs I can get micro second precision when overlay is used, and millisecond precision when blitting is used. It would be much easier to have just an api to fetch the time between two vsyncs. With my method there is a delay before vsync timing can be calculated delaying showing of movie.
My patches also uses the time of last vsync (gotten from query time last surface was displayed by the presentation queue) to adjust speed of movie to match speed of display.
Here it also be simpler if a direct call to get time of last vsync existed.
My next planned step is to use my knowledge of when last vsync occurred and time between vsyncs to make better decisions when to queue a frame for display and when to drop a frame. Like uau talked about. To decode more then one frame in advance should also be possible, without changing that much in mplayer. I planned to look at that next.