https://bugs.freedesktop.org/show_bug.cgi?id=55913
--- Comment #5 from Andy Furniss lists@andyfurniss.entadsl.com --- (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.