Announcement

Collapse
No announcement yet.

Gallium3D VDPAU On Radeon Starts Working

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

  • #61
    Christian, what are the major milestones needed to add h264 support? I'm assuming that much of the stuff can be reused (MC, deblocking, etc.)

    Comment


    • #62
      Originally posted by pingufunkybeat View Post
      Christian, what are the major milestones needed to add h264 support?
      they just wait for the h264 ATI Avivo code. because they know amd open up that stuff.

      Comment


      • #63
        Originally posted by pingufunkybeat View Post
        Christian, what are the major milestones needed to add h264 support? I'm assuming that much of the stuff can be reused (MC, deblocking, etc.)
        I wouldn't start with h264, mpeg4 (divx, xvid) would be the next logical step.

        For this we need at least a new bitstream decoder, and at minimum quite some changes to the mc stage.

        h264 also defines some new form of transformation which needs to be implemented, but to be honest I actually doesn't know much about how h264 works.

        Comment


        • #64
          /me does not understand, if the vdpau one already does more than xvmc, why is it reported as slower than xv?

          Comment


          • #65
            Originally posted by curaga View Post
            /me does not understand, if the vdpau one already does more than xvmc, why is it reported as slower than xv?
            Most people are currently only testing the yuv->rgb and scaling part of vdpau, since this works with all supported codecs.

            This stages of the rendering pipeline are just a bit slower than Xv because of the debugging overhead. If you compile the state tracker without debugging support, it should be slightly faster because we don't need to call the x server to display every frame.

            But the real improvement comes only when you enable more decoding stages, with mplayer provide the "-vc ffmpeg12vdpau" option for example.

            Comment


            • #66
              MythTV / VDPAU / r600g

              Looks like some people have MythTV working using VDPAU over r600g now, albeit playback is a bit jerky:

              http://www.gossamer-threads.com/lists/mythtv/dev/482148

              Comment


              • #67
                Originally posted by Deathsimple View Post
                I wouldn't start with h264, mpeg4 (divx, xvid) would be the next logical step.
                Not really, mpeg4 usually doesn't need any real decode acceleration.

                Comment


                • #68
                  Originally posted by deanjo View Post
                  Not really, mpeg4 usually doesn't need any real decode acceleration.
                  h264 is MPEG4.

                  Also, consider that this is the next logical step for a developer, which is who you are replying to. How can you accelerate h264 if you don't know how to accelerate simpler forms of mpeg4?

                  Comment


                  • #69
                    DivX and XviD are implementations of MPEG-4 Part 2, sometimes referred to as MPEG-4 ASP/SP and closely related to H.263. Decoding it is not a challenge even for low-end CPUs, though hardware acceleration is desirable where battery power must be preserved.

                    MPEG-4 Part 10 or H.264, sometimes referred to as MPEG-4 AVC, is what taxes even modern and fast CPUs. High-bitrate 1080p content usually requires a multithreaded implementation or hardware acceleration.

                    Comment


                    • #70
                      Christian sent an e-mail again about merging pipe-video so let's hope this time everybody will be happy with the interface.

                      *Can't wait h264 decoding -- although I realise that it will still take time.*

                      Thanks again for your work Christian!

                      Comment

                      Working...
                      X