Announcement

Collapse
No announcement yet.

XvBA on Evergreen

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

  • #11
    @bridgman
    do you man -vo vaapi:gl -va vaapi ?
    Since that along with "-vo vaapi -va vaapi" is what i tested and both just display all jagged up stuff.. nothing good to say the least

    Comment


    • #12
      That (or something like it) is what I mean by the GL output path.
      Test signature

      Comment


      • #13
        Originally posted by bridgman View Post
        That (or something like it) is what I mean by the GL output path.
        Like i said, both paths:
        "-vo vaapi -va vaapi"
        and
        "-vo vaapi:gl -va vaapi"

        give me the exact same issue.
        So, if the first option "-vo vaapi -va vaapi" uses another code path (not gl) then i guess there is another bug somewhere in that XvBA as well.

        Any time table on which we can see a version that at the very least workso n 5xxx cards? 10.7 driver?

        Comment


        • #14
          There is no diff for fglrx without :gl, it is just implicit opengl code used. With nvidia and others there is no implicit opengl usage.

          Comment


          • #15
            Originally posted by markg85 View Post
            @bridgman
            do you man -vo vaapi:gl -va vaapi ?
            Since that along with "-vo vaapi -va vaapi" is what i tested and both just display all jagged up stuff.. nothing good to say the least
            same happens to me, Ubuntu 10.4, 2.6.34 kernel + 10.6 fglrx
            and mplayer + vlc compiled with kano's scripts

            Comment


            • #16
              Originally posted by Kano View Post
              Do you think it logical to use NDA for xvba? I don't think so. Nvidia does not need that for vdpau too. With an open sdk mplayer could at least use the working code path.
              To ATI's defense, they normally support the whole Bluray playback stack on Linux, with various other backends or API. Besides, this kind of stuff is governed by AMD Legal. The secure/protection chain must be maintained. Should there be a breach, they probably could get their license revoked. So, this is reserved to embedded applications, and this can also have an impact on the way HW is designed.

              BTW, getting allowed to release "xvba-video" in this limited version was a 6 month process... "xvba-video" in this public form serves several purposes:
              - allow users to have some sort of video decode acceleration on Linux
              - allow AMD and us to test further on real people videos...

              For sure, that version is pretty incomplete. e.g. missing advanced post-processing features, which can only be available/enabled with the other backend. There are also other serious bugs, but you won't get details here. ;-)

              Comment


              • #17
                hello gbeauche
                Originally posted by gbeauche View Post
                missing advanced post-processing features, which can only be available/enabled with the other backend.
                Do you think of bob deinterlacing for that matter? It's still broken in 10.6 - can you comment on when this will be fixed? I know bob deint is not the world when it comes to deinterlace strategies, but it would be nice to have at least *some* strategy usable on 1080i channels...

                Comment


                • #18
                  Originally posted by Tuxoholic View Post
                  Do you think of bob deinterlacing for that matter? It's still broken in 10.6 - can you comment on when this will be fixed? I know bob deint is not the world when it comes to deinterlace strategies, but it would be nice to have at least *some* strategy usable on 1080i channels...
                  It was supposed to be fixed, with some changes to xvba-video, in the 10.5 driver. If it's not, well, you understand why I got bored. I will probably check some day when I use an ATI card again. I need to do some other development. And since I want reliable drivers, I chose something else for now.

                  Some other media devs say it's better to do deinterlacing on NV12 components instead of RGBA. So, I don't think I will invest much time into this approach anyway. I will check that later, later.

                  Comment


                  • #19
                    I actually see a lot of the rendering problems with the XvBA using a radeon hd 5770 here.

                    The Test software I am using is the latest subversion releases of XBMC and i noticed that xvid/divx works (h264 4.1 profile) however the x264 encodes do not work (garbled render) (h264 5.1 profile).

                    Comment


                    • #20
                      Originally posted by Dandel View Post
                      The Test software I am using is the latest subversion releases of XBMC and i noticed that xvid/divx works (h264 4.1 profile) however the x264 encodes do not work (garbled render) (h264 5.1 profile).
                      xvid/divx is not h264 HP @ L4.1. This is MPEG-4 Part-2, in particular the advanced simple profile of that standard.

                      That said, you are facing several problems:
                      1) XvBA/GL is not working on Evergreen chips. The video is decoded correctly but copying to the GL texture fails.
                      2) XBMC exposes another bug in the driver. This has something to do with FBO. The funny part is this also happens on Windows with DXVA2. Hence, I strongly suspect an FBO problem. However, XBMC codebase is huge and streamlining the problem is not trivial.
                      3) This is not really a problem but some people might see problems with h264 HP @ L5.1 depending on the driver and his configuration.

                      Comment

                      Working...
                      X