Announcement

Collapse
No announcement yet.

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

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

  • @gbeauche

    Besides the colours being off sometimes, it works fine for me. Perhaps you can update the table on http://www.splitted-desktop.com/~gbe...ne/xvba-video/

    Radeon HD 4850
    RV770
    Debian 'Squeeze'
    amd64
    10.4

    Comment


    • Originally posted by benoe View Post
      Oh, I already have hdmi-hdmi cable.

      With the previous fglrx driver (ubuntu 9.10 default) it was ok.
      I found a workaround for overscan problem here:
      So, I just bought a 32" Panasonic LCD (1080p) and have decided to use that as my main monitor. Unfortunately, when I hooked it up to my computer, I had under-scan with both Windows 7 x64 and Ubuntu Karmic x64 (using a Radeon HD 4870 1GB). In Windows, there was a simple slider in the Catalyst Control Center to fix the under-scan issue. Unfortunately, the same option wasn't available with the Linux counterpart. I searched online for some answers, but all the ones I found seemed outdated, or



      Now just the coloring issue (and many other things, of course) need to be fixed.

      Kano, do you have a hint how it will be fixed soon?

      Comment


      • Gbeauche, any chance we might see updated .debs for libva, xvba-video and new .tar.bz2 for mplayer-vaapi? Thanks,

        Comment


        • Color and shaking issues with current drivers

          I am attempting to get xvba and vaapi working with my RadeonHD 3200-based system. When I try to watch some H.264-encoded videos with mplayer-vaapi, the video shakes back and forth. The images are clear, but they rapidly oscillate forward and backward in the video. This doesn't happen continuously through the video, but it is repeatable at the same intervals within the video. If I had to guess, I would say that the bidirectionally-predicted frames are being rendered in bitstream order rather than presentation order. Of course I am just an armchair codec enthusiast, so I could just be talking out of my butt.

          The OS is vanilla Debian amd64, running Sid.

          I'm not sure which sub-version of the GPU core I have on this computer, its integrated into the motherboad. If it helps, fglrx reports in Xorg.0.log that the chipset ID is 0x9610, with PCI Subvendor 0x1458 and PCI Subdevice 0xd00, identified as "ATI Radeon HD 3200 Graphics", RS780.

          From splitted-desktop, I have installed xvba-video 0.6.11-1, libva 0.31.0 +sds13, libva-dev 0.31.0+sds13, and mplayer-vaapi 20100414-FULL (compiled locally for AMD64 from splitted-desktop's sources).

          Running vainfo oddly reports that my libva version is 0.31.0-sds6, but ldd clearly shows that it is linked against the libraries supplied by 0.31.0+sds13, and I haven't installed libva from any other source.

          fglrx is version 10.4, installed from within Debian.

          I also have a sample video from "Harry Potter and the Sorcerer's Stone" that exhibits absolutely horrendous color reproduction for near-gray colors. The file is wrapped up in the Matroska container. Colors shift towards blue, red, or green depending on where it is in the frame, but only when rendered with -vo vaapi. If played with -vo xv, the colors look fine. This video does not have the shaking problem. I transcoded the file myself with x264, using the following settings, and if it helps I can directly provide a fragment of the file that exhibits the problem.
          $ x264 --threads 2 --crf 20 --bframes 4 -A all --b-pyramid --b-adapt 2 --weightb --8x8dct --ref 4 --subme 6

          I also have a locally transcoded copy of Shrek that doesn't have the color reproduction issue, although it appears to be transcoded with similar options. This copy is in AVI container format, and was encoded directly with mencoder using the following options:
          -ovc x264 -x264encops crf=21:b_pyramid:frameref=3:bframes=4:8x8dct:subq= 9:weight_bartitions=all:trellis=1:mixed_refs

          So, any clues on the color or shaking issues?

          Comment


          • Originally posted by jbrandmeyer View Post
            I am attempting to get xvba and vaapi working with my RadeonHD 3200-based system. When I try to watch some H.264-encoded videos with mplayer-vaapi, the video shakes back and forth. The images are clear, but they rapidly oscillate forward and backward in the video. This doesn't happen continuously through the video, but it is repeatable at the same intervals within the video. If I had to guess, I would say that the bidirectionally-predicted frames are being rendered in bitstream order rather than presentation order. Of course I am just an armchair codec enthusiast, so I could just be talking out of my butt.

            The OS is vanilla Debian amd64, running Sid.

            I'm not sure which sub-version of the GPU core I have on this computer, its integrated into the motherboad. If it helps, fglrx reports in Xorg.0.log that the chipset ID is 0x9610, with PCI Subvendor 0x1458 and PCI Subdevice 0xd00, identified as "ATI Radeon HD 3200 Graphics", RS780.

            From splitted-desktop, I have installed xvba-video 0.6.11-1, libva 0.31.0 +sds13, libva-dev 0.31.0+sds13, and mplayer-vaapi 20100414-FULL (compiled locally for AMD64 from splitted-desktop's sources).

            Running vainfo oddly reports that my libva version is 0.31.0-sds6, but ldd clearly shows that it is linked against the libraries supplied by 0.31.0+sds13, and I haven't installed libva from any other source.

            fglrx is version 10.4, installed from within Debian.

            I also have a sample video from "Harry Potter and the Sorcerer's Stone" that exhibits absolutely horrendous color reproduction for near-gray colors. The file is wrapped up in the Matroska container. Colors shift towards blue, red, or green depending on where it is in the frame, but only when rendered with -vo vaapi. If played with -vo xv, the colors look fine. This video does not have the shaking problem. I transcoded the file myself with x264, using the following settings, and if it helps I can directly provide a fragment of the file that exhibits the problem.
            $ x264 --threads 2 --crf 20 --bframes 4 -A all --b-pyramid --b-adapt 2 --weightb --8x8dct --ref 4 --subme 6

            I also have a locally transcoded copy of Shrek that doesn't have the color reproduction issue, although it appears to be transcoded with similar options. This copy is in AVI container format, and was encoded directly with mencoder using the following options:
            -ovc x264 -x264encops crf=21:b_pyramid:frameref=3:bframes=4:8x8dct:subq= 9:weight_bartitions=all:trellis=1:mixed_refs

            So, any clues on the color or shaking issues?
            I'm in the same boat!
            (su) vainfo - shows libva version 0.31.0-sds6, although Driver version shows: Splitted-Desktop Systems XvBA backend for VA API - 0.6.11
            Perhaps since we are both using older chipsets, myself with an HD2600 and your with an HD3200, the latest mplayer-vaapi and the latest xvba-video, I can only conclude that libva defaults to an earlier version if it detects "older" hardware such as ours. Gwenole?

            Comment


            • For color fix you just need to update to 10-5. But xbmc svn seem still be broken via vaapi.

              Comment


              • Originally posted by Kano View Post
                For color fix you just need to update to 10-5. But xbmc svn seem still be broken via vaapi.
                Yes this is also my experience. Your scripts are workig great, even mplayer-vaapi, but xbmc produces these shakes what jbrandmeyer just mentioned.

                Comment


                • If I increase the volume, I get an overlay showing how high it is. When I'm playing something through vaapi the video stutters during and shortly after the overlay was on screen. mplayer complains that my system is too slow, and then it all catches up and runs fine again.

                  The stutter looks very much what jbrandmeyer and benoe are describing.

                  Comment


                  • Originally posted by RemcoL View Post
                    If I increase the volume, I get an overlay showing how high it is. When I'm playing something through vaapi the video stutters during and shortly after the overlay was on screen. mplayer complains that my system is too slow, and then it all catches up and runs fine again.

                    The stutter looks very much what jbrandmeyer and benoe are describing.
                    I also briefly see this stutter, but it is not what I was complaining about. The stutter has to do with the way the desktop's volume control application is compositing the volume control OSD with the video screen. It makes the video choppy, but it still makes forward progress. The shaking back-and-forth looks like a rapid reversing of the video over time (maybe 5-10 Hz or so?), and is completely repeatable with respect to its position in the video.

                    I'll try to give fglrx 10.5 a chance this weekend and see how it goes.

                    Comment


                    • Originally posted by Kano View Post
                      For color fix you just need to update to 10-5.
                      The upgrade did address the color issue. I managed to address the shaking as well. I set the cpufreq kernel governor to performance instead of ondemand, and that addressed the problem.

                      Comment

                      Working...
                      X