Announcement

Collapse
No announcement yet.

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

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

  • That happens with h264 movies here too. Only way to get rid of it is not to use xvba in that case (as you already did). vc1 seems to work better. I see no hope for this until ati officially begins to fix those issues.

    Comment


    • Originally posted by Saphy View Post
      Does anyone know why when playing video with XvBA, the colour in video will get slightly distorted/pixelated? Or am I the only one experiencing this problem? Strange colour block tends to appears in frames where the motion is slow, sometimes to the point where it becomes obvious. When playing with only software acceleration, the colour is fine.
      There are several problems, I don't know which one you are facing though.

      1. UVD2 only supports H.264 high-profile @*L4.1 (Blu-ray specs) with up to 4 reference frames at 1080p. Slightly more as the resolution decreases, just do the math. For clips with more reference frames, you will see some blocks of data.

      2. Colors are not correctly rendered on certain clips. Yes, it's a pain but hopefully this would be fixed in a future release... On some clips, colors are totally non-sense (e.g. Pirates BD dump).

      3. There seems to be decoding problems with Radeon HD 58xx cards. Videos are decoded but blocks are not put together in the right order, for some reason. That's very weird as this affects only OpenGL rendering, not PCOM. It's fine with other chips.

      The video will not appear in the screenshot, so I have no idea how I can show this problem pictorially.
      Can you provide a link to the video?

      Comment


      • It doesn't work very well here. At first all videos looked like some really bad cubism painting. For some reason it works now but all videos play back too fast, adding -nosound seems to fix this, but videos without sound are kind of boring. Also the CPU usage is very high for something that's supposed to be GPU accelerated. Scaling also doesn't work here, so a 720p video will be displayed at the top left corner and the remaining part of the screen is black.

        On the bright side, Bioshock with high settings looks absolutely stunning with fglrx, that is until the oom-killer kicked in and ruined my game.

        In short: Fglrx devs should really be ashamed of themselves for releasing such a lousy driver. I hope we'll soon see some evergreen support on the open source side.
        Last edited by monraaf; 19 January 2010, 01:32 PM.

        Comment


        • First of all thank you gbeauche for such an awesome patch, now at least some of my 1080p files are playable.

          Unfortunately whether or not something will play is still hit-or-miss with at least one causing the entire system to freeze.

          I haven't tried too many but here are the results I've come up with so far:
          Maybe a fifth of h264 files play perfectly.
          Another bunch have somewhat annoying color issues (red or blue tints usually, only noticeable in scenes where not a lot is happening).
          Others have extremely annoying decoding artifacts, in at least one instance I get opaque purple or yellow blocks scattered around the image and the decoding quality is incredibly low (may as well not be HD) and with weird blocky bits. This makes it pointless to try and watch these files.
          And, as I said, in at least one instance the video window (or screen if in fullscreen mode) fills with alternating white and black vertical lines and the whole machine stops (sometimes the mouse is fine, others it's frozen as well).


          I'm using Ubuntu Karmic with the fglrx drivers (currently using the hotfix but am going to try the regular drivers again to see if the color issues go away, and besides the "testing use only" thing is annoying).

          While it would be great to be able to watch all files perfectly, but for the time being it would be nice if it didn't bring down my system by simply playing a video...

          Comment


          • You just need to use /etc/ati/signature and sometimes /etc/ati/control from the default driver to get rid of the watermark.

            Comment


            • Originally posted by Kano View Post
              You just need to use /etc/ati/signature and sometimes /etc/ati/control from the default driver to get rid of the watermark.
              Ahh awesome, thanks. Turns out the non-hotfix version doesn't work at all (mplayer crashes).

              Now, any way to stop it from blowing up and killing everybody when I load certain files?

              Anyone got an idea about where the colors and artifacts are coming from? Is it VA API, XvBA, UVD, fglrx, or the hardware itself?

              Comment


              • xvba-video 0.6.4

                A new version of xvba-video (0.6.4) is now available:
                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!


                Version 0.6.4 - 20.Jan.2010
                * Fix vaGetImage() with YV12 format
                * Fix vaPutSurface() to only draw the requested source region
                * Fix rendering of subpictures with size different from parent surface's

                VLC should now have the right colors.

                Comment


                • Originally posted by StarkRG View Post
                  Anyone got an idea about where the colors and artifacts are coming from? Is it VA API, XvBA, UVD, fglrx, or the hardware itself?
                  VAAPI and XvBA are just APIs. So, we are left with UVD or fglrx. The most likely cause is the driver not using a correct color matrix? If you can reproduce the bug on Windows, this reduces the chances that fglrx is guilty. Have you tried on Windows?

                  Comment


                  • Originally posted by gbeauche View Post
                    VAAPI and XvBA are just APIs. So, we are left with UVD or fglrx. The most likely cause is the driver not using a correct color matrix? If you can reproduce the bug on Windows, this reduces the chances that fglrx is guilty. Have you tried on Windows?
                    I haven't been able to get UVD working under windows (at least I hope I haven't as all my tests have worked like it wasn't, slow with many framedrops). I'll let you know once I do, however my guess is that it will work.

                    I'll try out the new XvBA and let you know what effect that has.

                    Comment


                    • For those interested in testing vlc:

                      Since today a configure fix is in git that allows the use of locally installed ffmpeg for vaapi. Use the comments in the script as root and execute the script itself as user.



                      It is required that you install vaapi before, most simply using my mplayer script (good to compare too) - you should REALLY execute it first as it updates xvba-video (or vaapi-video for nvidia) too or just fetch the latest versions of those manually.



                      It can happen that you see only green with --ffmpeg-hw enabled and xvba, just try. It works a bit better with vdpau-video. There "only" a green line was below the video. Error looks like:

                      xvba_video: XVBA_GetSurface(): status 2

                      Using:

                      libva: libva version 0.31.0-sds4
                      libva: Trying to open /usr/lib/va/drivers/fglrx_drv_video.so
                      vainfo: VA API version: 0.31
                      vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA API - 0.6.4
                      Last edited by Kano; 20 January 2010, 07:28 PM.

                      Comment

                      Working...
                      X