Announcement

Collapse
No announcement yet.

AMD's UVD2-based XvBA Finally Does Something On Linux

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

  • You don't need hw accelleration for ard/zdf hd, use xmbc (try my new script), set it to arb (because glsl is broken with fglrx), thats the best client for vdr.



    720p with 13 mbps max is really no problem...

    Comment


    • Originally posted by Kano View Post
      You don't need hw accelleration for ard/zdf hd, use xmbc (try my new script), set it to arb (because glsl is broken with fglrx), thats the best client for vdr.



      720p with 13 mbps max is really no problem...
      I use teh normal PVR Branch for xbmc+vdr and ZDF HD works really nice without any manual compile- what the differect in your script? Does GIT source use XvBA?

      Comment


      • No xvba, the pvr branch is completely outdated. When you don't use videotext then the normal git (which is a clone of svn) is much better. I use that tricky wget contruction as thats definitely the fastest way. A svn clone takes ages compared to that. Nobody needs xvba for 720p.

        Comment


        • Yes, i also got no problems with performance on HD channels. But is it only performance improvents, what aboud picture quality?

          I think i wil try your script on teh weekend- did you do any other things to improve picture quality? ah, and what about xbmc-live? Is it included?

          Comment


          • The picture is ok. You have to use opengl vsync as usual. xbmc-live is a live image, why should that be "included"???

            Comment


            • Originally posted by gbeauche View Post
              A new version of xvba-video, the XvBA backend to VA-API, is now available at:
              splitted-desktop.com is your first and best source for all of the information you’re looking for. From general topics to more of what you would expect to find here, splitted-desktop.com has it all. We hope you find what you are searching for!
              Not that it matters much, as it 10.2 doesnt really work for udv2 hw decoding on 5xxx cards, but this version is failing to give any kind of output with 10.2 on my hd5650 (it was outputting garble before, now it has only errors):

              [vo_vaapi] vaCopySurfaceGLX(): resource allocation failed

              Also the hwdecode vaapi programs dont work any more:

              [hwdecode_demos] Decoded surface size: 320x240
              [hwdecode_demos] 4 profiles available
              [hwdecode_demos] VAProfileMPEG2Simple
              [hwdecode_demos] VAProfileMPEG2Main
              [hwdecode_demos] VAProfileH264High
              [hwdecode_demos] VAProfileVC1Advanced
              [hwdecode_demos] 1 entrypoints available for VAProfileH264High
              [hwdecode_demos] VAEntrypointVLD
              xvba_video: XVBA_CreateGLSharedSurface(): status 11
              [hwdecode_demos] vaPutSurface(): resource allocation failed
              ERROR: display failed

              Comment


              • Originally posted by xipu View Post
                Has anybody else noticed video scaling problems with mplayer-vaapi and xvba? It's cropping out the bottom 8% or so of videos for me. Using this test video, it's pretty easy to see XvBA's cropping. I first noticed it when some subtitled seemed misaligned, but then I realized that they were hard subs embedded in the video stream..

                Here are comparison screenshots of the video playing at native res (640x480):
                Software rendering
                XvBA rendering

                I'm using:
                mplayer-vaapi-20091127
                xvba-video-0.5.4.x86_64
                libva-0.31.0
                Catalyst 9.10
                ATi HD4870
                I still see this with xvba-0.6.7, mplayer-vaapi-20100212, and Catalyst 10.2. Comparing the 2 screenshots, just about 32 rows of pixels are missing from the bottom of the image in vaapi mode (and the rest of the picture is scaled to compensate). I also compared video output with a different 720p sample video with a static scene (to make comparison easier), and I found that in this case, ~48px are missing from the bottom of the video when using vaapi.

                Comment


                • Originally posted by xipu View Post
                  I still see this with xvba-0.6.7, mplayer-vaapi-20100212, and Catalyst 10.2. Comparing the 2 screenshots, just about 32 rows of pixels are missing from the bottom of the image in vaapi mode (and the rest of the picture is scaled to compensate). I also compared video output with a different 720p sample video with a static scene (to make comparison easier), and I found that in this case, ~48px are missing from the bottom of the video when using vaapi.
                  I didn't see anything in the past (older driver) and I still don't see any difference with a more recent (beta) driver. Did you test windowed/fullscreen mode? Any other particular option (command line, config, etc.)?

                  Comment


                  • Originally posted by gbeauche View Post
                    I didn't see anything in the past (older driver) and I still don't see any difference with a more recent (beta) driver. Did you test windowed/fullscreen mode? Any other particular option (command line, config, etc.)?
                    Clearing /etc/mplayer.conf and ~/.mplayer/config and running mplayer with only '-va vaapi -vo vaapi' produces the original results that I described.


                    I can repro with either windowed or fullscreen mode. Note that if I launch mplayer-vaapi with '-fs' to launch in fullscreen mode, the image isn't initially scaled (e.g. a 640x480 video with '-fs' will render a 640x480 area in my screen's upper-left corner with the rest of the screen black), but toggling fullscreen enables proper fullscreen scaling.

                    Comment


                    • Originally posted by xipu View Post
                      Note that if I launch mplayer-vaapi with '-fs' to launch in fullscreen mode, the image isn't initially scaled (e.g. a 640x480 video with '-fs' will render a 640x480 area in my screen's upper-left corner with the rest of the screen black), but toggling fullscreen enables proper fullscreen scaling.
                      Er, I should add that I consider this a minor issue (because I can just press "f" twice to enable proper fullscreen scaling), which is separate from the overscan problem.

                      Comment

                      Working...
                      X