| Priority | medium |
|---|---|
| Bug ID | 55913 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Vdpau driver lag |
| Severity | major |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | markurujapan@gmail.com |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | git |
| Component | Drivers/DRI/R600 |
| Product | Mesa |
Created attachment 68485 [details]
vdpau output
You said was now ready vdpau but when I try to watch a movie with this output
on my radeon 4650 , the video run with some lag :(
| What | Removed | Added |
|---|---|---|
| Priority | medium | high |
| What | Removed | Added |
|---|---|---|
| Component | Drivers/DRI/R600 | Drivers/Gallium/r600 |
(In reply to comment #0) > Created attachment 68485 [details] > vdpau output > > You said was now ready vdpau but when I try to watch a movie with this > output on my radeon 4650 , the video run with some lag :( R600 vdpau decode isn't perfect, depending on content you may notice some inaccuracy. With x86, it probably won't beat CPU decode unless you have something old/slow and single core. The lag you see I can recreate - it seems to be a mplayer2 issue, "real" mplayer works OK for me.
Yes, really, is a issue of mplayer2, with mplayer I don't have any problem, you can close this bug. Xv is more efficient on my pc.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | NOTOURBUG |
Xv is a bit faster for me, but software decode + -vo vdpau can give a better vsync than Xv in some circumstances.
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | REOPENED |
| Resolution | NOTOURBUG | --- |
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.
(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.
| What | Removed | Added |
|---|---|---|
| Status | REOPENED | RESOLVED |
| Resolution | --- | MOVED |
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this = link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/424.