Announcement

Collapse
No announcement yet.

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

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

  • Sorry for the misinformation in my earlier post popper and vlix
    I saw PlanetEarthBirds.mkv and thought it was the same file I downloaded from way earlier in this thread.

    I was wrong once I downloaded killa.sampla.x264.mkv and tried to play it.
    .. I see the same error as you vlix, using both :
    Code:
    mplayer -vo vaapi:gl -va vaapi killa.sampla.x264.mkv
    or
    Code:
    mplayer -vo vaapi:reflect -va vaapi killa.sampla.x264.mkv
    Code:
    Starting playback...
    Unsupported PixelFormat 61
    [VD_FFMPEG] Trying pixfmt=1.
    Movie-Aspect is 1.78:1 - prescaling to correct movie aspect.
    VO: [vaapi] 1920x1080 => 1920x1080 H.264 VA API Acceleration  [zoom]
    [VD_FFMPEG] XVMC-accelerated MPEG-2.
    [h264 @ 0xbb6fa0]number of reference frames exceeds max (probably corrupt input), discarding one  (multiple times)
    xvba_video: driver does not support H.264 content over HP@L4.1. Please upgrade.
    Given the miracle gbeauche has worked just getting xvba and vaapi into a usable state..I wouldn't hold my breath waiting for AMD to introduce support
    for a new format anytime soon..I don't think it's been announced as officially supported yet, has it ?
    Those who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
    Ben Franklin 1755

    Comment


    • Originally posted by vlix View Post
      mplayer -vo vaapi -va vaapi gives accelerated, but completely garbled video (with the exception of a few keyframes):

      Code:
      VO: [vaapi] 1920x1080 => 1920x1080 H.264 VA-API Acceleration 
      [VD_FFMPEG] XVMC-accelerated MPEG-2.
      xvba_video: driver does not support H.264 content over HP@L4.1. Please upgrade.
      A:  11.9 V:  11.4 A-V:  0.480 ct: -0.080   0/  0 30% 11% 15.5% 60 0
      Given the last xvba-video debug message, the video output you see is then "normal" in your configuration. Only reference frames and other frames that don't rely on reference frames that are still available in the DPB will be showed correctly.

      mplayer -vo vaapi:gl -va vaapi does not work, the relevant part of the error message being:

      Code:
      Could not parse arguments at the position indicated below:
      gl
      ^
      
      -vo vaapi command line help:
      Example: mplayer -vo vaapi:gl
      I guess something is not installed correctly, but what? I would really appreciate any help or hints, thanks!
      You probably have not the VA/GLX support compiled it. Make sure GL and GLU libraries are installed. You can check your mplayer config.log, around "Checking for VA-API (with GLX support)", and see what it tells you is missing.

      Comment


      • Originally posted by DarkFoss View Post
        Code:
        mplayer -vo vaapi:reflect -va vaapi killa.sampla.x264.mkv
        This is not related to your problem but please note that the "reflect" option will only work with the "gl" renderer, thus -vo vaapi:gl:reflect.

        Given the miracle gbeauche has worked just getting xvba and vaapi into a usable state..I wouldn't hold my breath waiting for AMD to introduce support for a new format anytime soon..I don't think it's been announced as officially supported yet, has it ?
        If people are trying to use that, this means this was advertised as such... Since those people don't have any other "better" driver, this is the same that what common users are getting. Anyway, as for other driver features, I don't think there is any official bug reporting system for fglrx on Linux, neither for NVIDIA BTW. So users usually report bugs to their distributor, whom forward to the relevant people @ ATI, IMHO.

        Comment


        • iv been meaning to ask you gbeauche for a while now and seeing the latest news ....

          have you been given access to the new sandy bridge prototypes yet ?


          the news being http://www.phoronix.com/scan.php?pag...item&px=ODY2OQ
          Intel To Have Sandybridge 3D In Mesa Done By Q4
          Posted by Michael Larabel on October 11, 2010

          and it seems AMD's UVD is nearly now as good as dead for end user use ,given the sandy bridge Open Encode/Decode ASIC progress


          Francois Piednoel , (Senior Performance analyst at Intel) says he's beta patched a current x264 master code-base, to give it a lower level access than the new higher level Intel® Media SDK 2.0 has to the new sandy bridge internal Encode/Decode engine and open up some internal routines for direct x264 use as he understands x264 assembly etc and that "the x264 community would not include a call to a DLL without any control of the encoding process."

          he also said in IRC about the x264 patches he's working on right now.

          "2010-10-18 05:58:07 < Dark_Shikari> a) What exactly is this hardware?

          2010-10-18 05:58:12 < Dark_Shikari> Is it a single encoding ASIC that takes YUV in?
          2010-10-18 05:58:27 < Dark_Shikari> Is it a set of asynchronous units, like on the OMAP4?
          2010-10-18 05:58:35 < frpiednoel> it does take YUV in ... and few other formats
          2010-10-18 05:58:40 < Dark_Shikari> Is it a set of synchronous units, accessible via CPU instructions?
          2010-10-18 05:59:18 < frpiednoel> for the moment, we are only supporting windows ... and via DXVA2
          2010-10-18 05:59:40 < frpiednoel> I am the one who is trying to get it out as "hardware" ...
          "
          "
          you ll get access to the motion vector field, you ll be able to use Quanti, inverse quanti, hard Zig Zag, and reserve ZigZag
          2010-10-18 06:02:39 full hard decoder
          2010-10-18 06:02:56 < Dark_Shikari> can it search an arbitrary number of refs?
          2010-10-18 06:02:58 < frpiednoel> and the decoder decode in the L3 cache" so far.

          Comment


          • How about UVD support ?

            I wonder why ATI/AMD doesn't support UVD in fglrx, only UVD2.0? Are those
            two hardware decoders so different that AMD would have to start write
            fglrx driver for UVD support from scratch ?

            Comment


            • Originally posted by popper View Post
              have you been given access to the new sandy bridge prototypes yet ?
              No, but I would like to, it's a real great CPU and GPU.

              and it seems AMD's UVD is nearly now as good as dead for end user use ,given the sandy bridge Open Encode/Decode ASIC progress
              Yes, Intel is already working on VA-API encoding support for Sandy Bridge. I think François Piednoel's effort is different from those of the other division. Just hope we don't end up with two drivers.

              BTW, Intel is also working on a DRM solution. IIRC, the API already has some provisions for protected content, thus protecting from further vaGetImage() on surface generated from "protected" bitstreams.

              Comment


              • Originally posted by ntt2010 View Post
                I wonder why ATI/AMD doesn't support UVD in fglrx, only UVD2.0? Are those two hardware decoders so different that AMD would have to start write fglrx driver for UVD support from scratch ?
                The word is in *support*. They already don't support correctly current HW, how do you want them to suppport obsolete HW? Actually, older UVD HW also kind of works but no effort will be made in fixing it if it breaks in a new fglrx release. e.g. some people reported success with HD 3xxx, and even some HD 2xxx series, but I do see some troubles with HD 3870.

                Comment


                • Originally posted by gbeauche View Post
                  No, but I would like to, it's a real great CPU and GPU.



                  Yes, Intel is already working on VA-API encoding support for Sandy Bridge. I think François Piednoel's effort is different from those of the other division. Just hope we don't end up with two drivers.

                  BTW, Intel is also working on a DRM solution. IIRC, the API already has some provisions for protected content, thus protecting from further vaGetImage() on surface generated from "protected" bitstreams.

                  when François Piednoel said "2010-10-18 05:59:18 < frpiednoel> for the moment, we are only supporting windows ... and via DXVA2", he was referring to the Intel® Media SDK 2.0 use as most dev's will need to use.

                  http://doom10.org/index.php?topic=717.msg4534#msg4534
                  "...
                  For Most of the world, SandyBridge acceleration will be accessable through mediaSDK , because it is the easiest way to do it.
                  After taking with Loren, one thing was very clear, He was totally clear that the x264 community would not include a call to a DLL without any control of the encoding process. I understood his point, and toke on myself to go and try to get the autorization to turn around MEdiaSDK and give you guys direct access (That mean to the world) to the Magic of SandyBridge...."


                  he went out of his way to stress X264 gets his support directly, and i take that to mean other open dev's such as yourself and your efforts
                  can also benefit, its probably wise if you go on IRC and ask Dark_Shikari for the details in private as i think they went quiet as people where picking up to many interesting hints

                  François Piednoel did say he would sort out access to the chips for Dark_Shikari, pengvado,<Alex_W, and any other x264 dev's interested, so you can too if you ask on IRC, do you hack on x264 patches, or follow the x264 code-base at all BTW ?

                  if you dont have an IRC client handy theres always generic web IRC clients such as http://webchat.freenode.net/

                  enter your required name and #x264dev as the channel your interested in and type the catcha , done

                  Comment


                  • if you dont hack on x264 yet, now might be a good time to start LOL

                    Comment


                    • Originally posted by popper View Post
                      he went out of his way to stress X264 gets his support directly, and i take that to mean other open dev's such as yourself and your efforts
                      can also benefit, its probably wise if you go on IRC and ask Dark_Shikari for the details in private as i think they went quiet as people where picking up to many interesting hints
                      Intel Media SDK 2.0 is a Windows specific API and library. We also want a fully Open Source implementation using the encoder. This is what Intel is working on, for VA-API on Linux. So, the next steps are to extend FFmpeg and other media application to take benefit of it.

                      Actually, they were looking for VA-API application using the encoding API for validation. Something that another Intel division already had (GStreamer plugins)... for GMA 600.

                      Comment


                      • It is just bad that VC1 is not supported on Intel.

                        Comment


                        • Originally posted by gbeauche View Post
                          Intel Media SDK 2.0 is a Windows specific API and library. We also want a fully Open Source implementation using the encoder. This is what Intel is working on, for VA-API on Linux. So, the next steps are to extend FFmpeg and other media application to take benefit of it.

                          Actually, they were looking for VA-API application using the encoding API for validation. Something that another Intel division already had (GStreamer plugins)... for GMA 600.
                          re the Media SDK, Yeah i know, but the x264 dev's have made sure to include and re-enforce FFmpeg as their preferred input/decode option as they also hack on that and have told François to also make sure to include FFMpeg in all this, as the decode part of any patches etc,so im not worried, FFMpeg will get access too.

                          Comment


                          • Originally posted by popper View Post
                            re the Media SDK, Yeah i know, but the x264 dev's have made sure to include and re-enforce FFmpeg as their preferred input/decode option as they also hack on that and have told François to also make sure to include FFMpeg in all this, as the decode part of any patches etc,so im not worried, FFMpeg will get access too.
                            It's midnight in Paris so I will probably join IRC tomorrow if I am not too busy. Anyway, Sandy Bridge is very impressive, and they did a great job on the GPU side. Better than expected.

                            Comment


                            • Originally posted by Kano View Post
                              It is just bad that VC1 is not supported on Intel.
                              well thankfully even MS dont push VC1 (the extended Divx mpeg4 part 2 codec ) and use and advocate AVC/H.264 for general use today , so its not so bad, if dev people really wanted VC1 , then they would and could patch FFMpeg with a VC1 Encoder to make it more viable today OC, but why bother when you now have the option of a commercial x264 licence today.

                              Comment


                              • I am using HD 4650.
                                ati catalyst 10.9
                                libva 0.31.1-1sds4.
                                xvba 0.7.5.

                                I think libva is rightly compiled since i have libva-glx.so libva.so libva-tpi.so libva-x11.so

                                but i got this error when running vainfo.
                                libva: libva version 0.31.1
                                Xlib: extension "XFree86-DRI" missing on display ":0.0".
                                libva: va_getDriverName() returns -1
                                vaInitialize failed with error code -1 (unknown libva error),exit

                                tried playback with mplayer-vaapi -vo vaapi -va vaapi, got that error, and Video: no video error.

                                Any idea ?

                                Comment

                                Working...
                                X