I found the best results with only mplayer itself, without any wrapper like smplayer - those pass tons of arguments and sometimes it seems those have detrimental effects.
Interestingly, just looking at one facet, when I did some testing several months ago, I was actually able to get better cpu utilization results from the umplayer frontend over bare mplayer. IIRC smplayer didn't vary much from the mplayer results.
I updated vlc to 2.1 last night and, in testing, I received those same three std_error lines on every file I attempted playback with ... (the only change being the decoding profile portion of the message being accordant to video resolution of the test file) ... she ain't working .... interestingly, it really didn't like the dvd test sample (from mplayer IIRC), as cpu went high on that one, whereas utilization for 1080 material was much lower and in accordance with what would be expected for software decoding of that res and the given bitrates
Thanks. Nice to know i am not alone in this. But is the problem on the VLC side or it has to do with radeon?
But is the problem on the VLC side or it has to do with radeon?
I do not know, but it is a good question. If its on the radeon side of the fence, perhaps its an issue that may have already been corrected in the new kernel RCs (I should have mentioned that I'm using a 3.11 and fairly recent builds of the userspace stuff).
That said, I was also testing xine based apps a couple of weeks ago, and they fail too ... in xine's case, IIRC, there is something about libvdpau_r600 that xine doesn't like in regards to supported colourspaces ... which is funny because I don't recall having any such problem between the two when I had previously tested in the case of shaders (as opposed to via UVD), though I could just be mis-remembering things .... and the later might be the case, as I did find an old message by Christian on one of the mailing lists, in which he mentions that he couldn't figure out what xine was doing, so perhaps a problem does indeed persist... have not gotten back to looking into it since (nor have any pressing need to).
So, in summary, from what I've dealt with so far, mplayer works fine for me (and any such frontend for that that I've tested with) ... have not tested mplayer2, let alone mpv
Basically, the driver had hard-coded profiles. Since Mplayer does not check for them, it worked while VLC, which does check them failed. The bug has been fixed in August.
But that's not the end of it, at least for me. With the above fix, I could play MKV h264 files usig VDPAU with VLC on a E350, but it stutters. I open a bug on VLC :
But according to the developer, there are many issues first on the state tracker side that must be fixed before even trying to investigate in VLC. VLC VDPAU implementation is apparently working with the NVIDIA binary driver, and using the mesa VDPAU state tracker with UVD seems to be a very untested path.
Mplayer kind of works but apparently because it doesn't implement all the VDPAU API. That may be the reason why some people experience asynchronized sound with mplayer and VDPAU.
So I openned a bug for mesa :
But nobody has taken it over yet. To be honest, it's quite a messy bug report, and one devs probably dont't know / don't want how to address. I have'nt tested mesa-git since then so it may have improved.
Can somebody with a GPU that has UVD 2.2 test this sample file for me and tell me if you get any lags
with vdpau(UVD)? I want to know if the lags I get might be a bug in UVD2.2; somebody who has UVD3 gpu was able to play the file just fine.