Page 2 of 5 FirstFirst 1234 ... LastLast
Results 11 to 20 of 44

Thread: Radeon UVD problems.

  1. #11
    Join Date
    Sep 2012
    Posts
    88

    Default

    Quote Originally Posted by gradinaruvasile View Post
    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.

  2. #12
    Join Date
    Jan 2009
    Posts
    1,603

    Default

    Quote Originally Posted by Tyler_K View Post
    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?

  3. #13
    Join Date
    Sep 2012
    Posts
    88

    Default

    Quote Originally Posted by 89c51 View Post
    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

  4. #14
    Join Date
    Oct 2012
    Posts
    182

    Default

    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

  5. #15
    Join Date
    Jan 2008
    Posts
    150

    Default

    Quote Originally Posted by 89c51 View Post
    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?
    Probably a bit of both, but more on mesa's side. There's a bug that I've reported to the Mesa team :

    https://bugs.freedesktop.org/show_bug.cgi?id=67530

    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 :

    https://trac.videolan.org/vlc/ticket/9281

    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 :

    https://bugs.freedesktop.org/show_bug.cgi?id=68792

    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.

  6. #16
    Join Date
    Jun 2013
    Posts
    48

    Default

    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.

  7. #17
    Join Date
    Jun 2013
    Posts
    48

    Default

    My problem vanished after upgrading to kernel 3.11.3.
    The bug was related to UVD.

  8. #18
    Join Date
    Jul 2009
    Posts
    90

    Default

    Well not for my GigaByte 6870, it still has problems with UVD when dpm is enabled.

  9. #19
    Join Date
    Sep 2012
    Posts
    88

    Default

    This thread indicates there might be some development on the colourspace issue front soon: http://lists.freedesktop.org/archive...er/045811.html

  10. #20
    Join Date
    Jan 2008
    Posts
    150

    Default

    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •