Announcement

Collapse
No announcement yet.

XvBA on Evergreen

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

  • #51
    Depends no your cpu and the content you want to watch. If you only watch lower bitrate content you don't need vaapi/vdpau so much.

    Comment


    • #52
      I think the bigger problem here is that there are no incentives for ATI to do the right thing. This closed API is merely taking something that was already closed and making it even more closed. There is no license that prohibits that, and there's nothing you can do about it.

      I would love the idea if kernel devs started locking down the kernel against such abuse. I think this can be done by making the kernel symbols they are using in their proprietary driver GPL_ONLY. Give companies such as AMD a grace period of 2 years and if not fully open source by that time GTFO.

      But since I don't see that realistically happening, I will save my own money for more open source friendly companies such as Intel.

      Comment


      • #53
        It is basically possible to replace gpl only symbols by the ids and link against that. At bit tricky however

        Comment


        • #54
          Originally posted by Kano View Post
          It is basically possible to replace gpl only symbols by the ids and link against that. At bit tricky however
          I think that would be called "willful infringement"

          Comment


          • #55
            Originally posted by Kano View Post
            What would happen when the xvba sdk would be leaked and amdpcom.h/amdxvba.h would be public?
            I don't see how since we are the only users left in the game... And since colleagues don't even know where I hide those, this cannot happen unless I am terribly drunk.

            Would amd shares lose value? When pcom works why don't allow the use of it? One command can be guessed by the hwdecode demos configure script btw. - the rest was removed.
            I have checked the configure script, there is nothing PCOM related. Anyway, you can get all PCOM functions available from the XvBA libraries...

            That's pure ATI/AMD logic. You can NOT release something that WORKS...
            It works *better*, I wouldn't say it just works. Sure, in my experience this is tear-free, but it has some other problems that access well (or not) the recovery capabilities of the driver...

            Now, I could buy some G210 gfx. Or I could wait a little bit. Should I? ;-)
            Just buy a G210 now, mine is a Gigabyte fanless one. It does the job unless you try new features from the 256.xx NVIDIA series driver...

            Comment


            • #56
              Tearfree, Evergreen support, do we expect h264 l5.1 from pcom too

              Comment


              • #57
                Originally posted by Kano View Post
                Tearfree, Evergreen support, do we expect h264 l5.1 from pcom too


                BTW, PCOM is just about presentation, i.e. displaying the decoded frames onscreen. This is the 2D alternative to OpenGL. The rest is common and a subset is even shared verbatim with Windows... So core decoding capabilities are the same, be it PCOM, OpenGL or something else used to present the result. This is what I would assume though.

                Comment


                • #58
                  Originally posted by bridgman View Post
                  You might want to play with gl sub-options as well. Maybe try something like mplayer -vo gl:yuv=2:rectangle=1..

                  The first option should reduce CPU load by doing YUV-RGB conversion on the GPU rather than the CPU, second option should reduce memory usage by using non-power-of-two textures. Default for both of the sub-options is 0.
                  Do you mean that even with GL_texture_non_power_of_two, GL_TEXTURE_2D textures may be oversized to 2^n dimensions? Would you know the actual threshold? One of the XvBA bugs tends to confirm something like a threshold to keep using 2^{n,m} textures for small textures that are not a power of two in size.

                  Comment


                  • #59
                    Can you explain what you mean by "oversized" here - I might be oversimplifying your question.

                    IIRC the "rectangle=1" setting uses the GL_ARB_texture_rectangle extension rather than GL_ARB_texture_non_power_of_two but I haven't heard about any problems with that option up to the hardware limits of the GPU (8K x 8K on 6xx/7xx I think). I don't remember trying rectangle=2 though...

                    Comment


                    • #60
                      Originally posted by curious.developer View Post
                      Hi

                      To mr. Bridgman - is there any real chance to get XvBA on Linux? How much? 100%? Probably yes? Dunno? Probably not? Any timeframe?

                      ATM I'm building a HTPC solution and I've bought HD5450. A grave mistake it looks. My fault anyway.

                      Now, I could buy some G210 gfx. Or I could wait a little bit. Should I? ;-)
                      The main thing to watch out for is the cpu and video card... Most current processors (Like the Athlon II x4) have enough power to stay at the lowest speed stepping and still decode 1080p h264 video with very few dropped frames. Anyways, It'd be interesting to see 1080p and 720p videos that are encoded with h264 ( or AC1) be able to be decoded with the radeon hd 5000 series graphics card.

                      Anyways, with that said, i would fully call my desktop fully ready as a htpc solution. Of course, i would also like to state that if your using xbmc make sure it's newer than revision 30566 because that specifically fixes the bugs with the texture matrices and glsl.

                      Comment

                      Working...
                      X