(In reply to comment #4)
> mplayer2 uses advanced VDPAU functionality that mplayer does not use - the
> presentation queue. This works fine with Nvidia's implementation. Likely the
> bug is in Mesa's implementation of the presentation queue.

Maybe, but maybe it's something as simple as the fact (or way) that mesa vdpau
is vsynced.

Some further testing results -

Use VDPAU_TRACE=1 and grep/awk/bash to get the diffs from the timestamps
mplayer2 uses on vdp_presentation_queue_display.

Playing 25 fps on a 60Hz screen looks OK ish for a while -

50030334
33349000
50022000
33350000
50022000
33348000
50023000
33349000
50022000
33349000
33356334
33333332
50029334

but then when it starts lagging mplayer2 is asking for longer intervals -

100052334
16682334
100046000
16673000
100046000
16674000
83333330
66728336
83371000
66697000
83372000
66697000
83370000
66699000
83370000

First thought it's trying to framedrop - maybe my GPU is too slow (it's
powerful but set to low).

Turn it up and no lag - me thinks that's it then, but then mplayer works so
another test.

GPU on low again but screen @120Hz also = no lag, so it's not just perf.

If you know mplayer2 code well perhaps that will tell yoou something.

Another separate observation SD or HD just -vo seems to work but the %cpu shown
for vo rises. It seems it's rate of rise decreased as it gets higher so I don't
know if it will ever get to 100 and start lagging.