Announcement

Collapse
No announcement yet.

Radeon UVD problems.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.

    Comment


    • #12
      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?

      Comment


      • #13
        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

        Comment


        • #14
          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

          Comment


          • #15
            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 :



            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 :

            I have a system with an AMD Brazos processor that recently got support for the on-chip UVD decoding device with Linux. It is supposed to be accessed using...


            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; 04 October 2013, 01:46 AM.

            Comment


            • #16
              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.

              Comment


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

                Comment


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

                  Comment


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

                    Comment


                    • #20
                      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.

                      Comment

                      Working...
                      X