Comment # 5
on bug 55913
from Andy Furniss
(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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
