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.
Originally Posted by gradinaruvasile
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?
Originally Posted by Tyler_K
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).
Originally Posted by 89c51
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
At least in Ubuntu, VLC 2.1/2.2 (from videolan's PPA: https://launchpad.net/~videolan/ ) is not being built with support for VDPAU: https://launchpadlibrarian.net/15223...uildlog.txt.gz
Probably a bit of both, but more on mesa's side. There's a bug that I've reported to the Mesa team :
Originally Posted by 89c51
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.
Last edited by rvdboom; 10-04-2013 at 01:46 AM.
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.
My problem vanished after upgrading to kernel 3.11.3.
The bug was related to UVD.
Well not for my GigaByte 6870, it still has problems with UVD when dpm is enabled.
This thread indicates there might be some development on the colourspace issue front soon: http://lists.freedesktop.org/archive...er/045811.html
Yep, a patch has been published on my bug report (see my post above).
Can't test it yet but will try next week-end.
Tags for this Thread