Announcement

Collapse
No announcement yet.

AMD's X-Video Bitstream Acceleration

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

  • #16
    Originally posted by Yfrwlf View Post
    MPEG2? What about OGG, Dirac, Snow, and other open codecs that have no annoying legal issues with implementing acceleration for? Shouldn't those be a much higher priority? I mean, sure, many videos are MPEG as well as H264 and such, but some of the aforementioned open source codecs will greatly challenge them.

    Unrestricted codecs FTW!
    These will come later, probably added by the community. It sounds like they're mirroring what the cards can do in Windows. There the cards have a very specific purpose: allow much slower CPU's to play HD video (of which, H264, VC1, and MPEG2 are the big ones.)

    If they can get this out there, they will blow by Nvidia in a crucial segment: the HTPC one, because now folks can get small fanless motherboards and video cards and let the GPU do all the work.

    Comment


    • #17
      tell me...

      How am I supposed to watch video under Compiz? then we will talk.

      Comment


      • #18
        Originally posted by FunkyRider View Post
        How am I supposed to watch video under Compiz? then we will talk.
        that's an infrastructure problem that doesn't match anything with acceleration of these stuffs...

        Comment


        • #19
          Originally posted by curaga View Post
          Yes, I did, did you?
          I don't care what it is named.

          From those, XvMC already did idct, mc, and deint.
          So then you read XvBA will allow full offload to the gpu for the usual codecs ... Of course it might not do the full deal on linux but it seems a bit silly to create a lib with that name unless they were planning on providing it.

          Unless of course you were talking about support today?

          Comment


          • #20
            I'm just saying, the name of the lib guarantees nothing. It could be named GforceAccel and still not run on Nvidia hw. And that I trust Michael when he says DXVA does those things.

            Comment


            • #21
              With DXVA in MPC-HC in Windows, I watch H.264 1080p movies with 3%-5% CPU utilization (on a Radeon 4870). Without DXVA it's 80%.

              Is this what we're talking about here?

              Comment


              • #22
                Originally posted by RealNC View Post
                With DXVA in MPC-HC in Windows, I watch H.264 1080p movies with 3%-5% CPU utilization (on a Radeon 4870). Without DXVA it's 80%.

                Is this what we're talking about here?
                Yes, you should notice similar results on Linux.
                Michael Larabel
                http://www.michaellarabel.com/

                Comment


                • #23
                  However one should bear in mind that bitstream decoding is generally fairly unforgiving of differences in video encoding. For bitstream encoding many x264 optimizations that people apply "break" bitstream decoding, so one has to bear that in mind. I suspect that for many videos it might be better just to do mc and idct and leave decode for the cpu.

                  Comment


                  • #24
                    Originally posted by n0nsense View Post
                    It is more then sad if i understand it correctly.

                    What I understand is that today, there is no option to decode HD movies on GPU.
                    Recently i have installed Ubuntu on HP's xw4200 which is powered by Intel Pentium 4 551 @ 3.4GHz.
                    This machine is incapable of smooth playback of 720p movie.
                    Hate the idea that i'll have to install XP Media Center
                    Your machine is definitely powerful enough for 720p (unless it's ridiculously high bitrate and encoded with extreme h.264 options). latest mplayer with ffmpeg should work just fine. Just make sure to select your video renderer correctly, and don't run compiz. You should however get an optimized build of ffmpeg for the P4 as it helps in all the filters you would use like sharpening, deinterlacing, etc. (It doesn't help actual decoding though because of the assembly used from what I understand). ffmpeg works just fine on 720p movies on my little P-M 1.6Ghz. On the other hand, for 1080p I have to resort to CoreAVC on all the machines I have.

                    Comment


                    • #25
                      Originally posted by Vighy View Post
                      that's an infrastructure problem that doesn't match anything with acceleration of these stuffs...
                      Really? Ever tried Radeon driver on R500?

                      THAT Compiz and Textured Video magically works together! So where is this architecture change come from?

                      Comment


                      • #26
                        Originally posted by npcomplete View Post
                        Your machine is definitely powerful enough for 720p (unless it's ridiculously high bitrate and encoded with extreme h.264 options). latest mplayer with ffmpeg should work just fine. Just make sure to select your video renderer correctly, and don't run compiz. You should however get an optimized build of ffmpeg for the P4 as it helps in all the filters you would use like sharpening, deinterlacing, etc. (It doesn't help actual decoding though because of the assembly used from what I understand). ffmpeg works just fine on 720p movies on my little P-M 1.6Ghz. On the other hand, for 1080p I have to resort to CoreAVC on all the machines I have.
                        Totem player sucks. It plays 720p movie on a machine with lost a/v sync and a lot of jerkyness, but M-Player, OTOH, handles it very smooth. The machine is a 5 year old P4 3.0C with a single channel DDR-400 and SIS chipset

                        Comment


                        • #27
                          Originally posted by FunkyRider View Post
                          Really? Ever tried Radeon driver on R500? THAT Compiz and Textured Video magically works together! So where is this architecture change come from?
                          I think Vighy was talking about tearing, which requires vblank timing be pushed from drm back up to the X driver, or that *some* command streams from the X driver be blocked by drm until vblank without holding up the *other* rendering. The best way to do that is still being debated, and general consensus is that the right way will be solved in Compiz as much as in the driver (since the real solution is page flipping after composition then flow control back up to the video player apps so that they skip & double frames as needed to stay synced with the compositor's page flipping).

                          The architectural change you are talking about is the ability for Compiz to redirect content drawn via OpenGL and direct rendering (ie Redirected Direct Rendering, which needs DRI2, which needs TTM/GEM, which is being done together with KMS).

                          Comment


                          • #28
                            Originally posted by dashcloud View Post
                            These will come later, probably added by the community. It sounds like they're mirroring what the cards can do in Windows. There the cards have a very specific purpose: allow much slower CPU's to play HD video (of which, H264, VC1, and MPEG2 are the big ones.)

                            If they can get this out there, they will blow by Nvidia in a crucial segment: the HTPC one, because now folks can get small fanless motherboards and video cards and let the GPU do all the work.
                            Looks like they won't be blowing by them quite yet though, since Nvidia has their own acceleration now, though it is close source. Obviously if both are fairly on par with each other feature/quality/performance wise, I'd choose AMD or Intel because of the open source feature.

                            Comment


                            • #29
                              The article says:

                              "From the mplayer source-code run configure with the --enable-xvmc and --with-xvmclib=AMDXvBA arguments."

                              Doesn't work here. I get this:

                              Checking for XvMC ... yes (using XvMCW)

                              and the resulting build can't use XvMC at all. Is "AMDXvBA" the right value for the --with-xvmclib option?

                              (mplayer-1.0_rc2_p28058 with Catalyst 8.12 on Gentoo AMD64 here.)

                              Comment


                              • #30
                                Originally posted by Vighy View Post
                                would be even more sad if that feature will not be backported!


                                I too hope that AMD extends XVBA to more chips than just R700. *AT LEAST* R600 and R500, given that VDPAU works with Geforce 8 and up.(three generations)

                                Even better would be if AMD just open sourced the thing considering that XVMC is somewhat old and completely lacks support for ATi/AMD chips.

                                Comment

                                Working...
                                X