Announcement

Collapse
No announcement yet.

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

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

  • vlc needs more cpu power, but basically it is low enough, with high bitrate content it is very low compared to cpu.

    Comment


    • VLC copies the decoded video back to the CPU before displaying it, while other programs just pipe the output straight to the monitor.

      This was done intentionally, so that they can send the decoded video through their whole existing pipeline of filters, etc., and doesn't just do a dumb display to the screen.

      For most people that's not very important, but it is nice for some.

      Comment


      • Hello,

        (i'm german, hopefully my english is understandable...)

        Maybe there is a bug in xvba while destroying surfaces.
        You can reproduce it with mplayer-vaapi. Create a playlist with some entrys and play it. Look at memory-usage, everytime a new file will be played (skip in playlist), the memory-usage is increased.

        I wrote a test-app, where, while playing a file, every x frames i destroy surface(s) and create new with same effect as above.
        It seems, as vaDestroySurface does not really freeing resources.

        Thanks for reading,
        Thomas

        Comment


        • Originally posted by tbshl-vdr View Post
          Hello,

          (i'm german, hopefully my english is understandable...)

          Maybe there is a bug in xvba while destroying surfaces.
          You can reproduce it with mplayer-vaapi. Create a playlist with some entrys and play it. Look at memory-usage, everytime a new file will be played (skip in playlist), the memory-usage is increased.

          I wrote a test-app, where, while playing a file, every x frames i destroy surface(s) and create new with same effect as above.
          It seems, as vaDestroySurface does not really freeing resources.

          Thanks for reading,
          Thomas
          Thomas, you are correct. I have noticed this from running mplayer-vaapi through gnome-terminal, and opening consecutive files. Perhaps there is a memory leak?

          Comment


          • Well i tested vlc+gl output with a slower system (E8400+HD4550) then the systemload was really too high. A i7-880+HD5670 does not really need video accelleration but it worked however. opengl video output is something to avoid with vlc, xv (which works with nvidia) is much faster - for dvd size it is fast enough with gl. Basically with a fast cpu the open source driver + xv is less problematic. When you have the direct comparision of nv and ati cards in the same system you know definitely what works better - just that even chip cpus are getting so fast now that gpu accelleration is less important than before.

            Comment


            • Seems that 10.10-444 ubuntu driver with xorg 1.9 is working a bit more better for hw accelerated h264 playback on my HD 5650 card, at least now the picture is recognizable even if its still garbled... Hope to see a release that actually works... anyone else withe evergreen and better luck?

              Screen shot:
              http://ompldr.org/vNW44cA

              Comment


              • Originally posted by tbshl-vdr View Post
                I wrote a test-app, where, while playing a file, every x frames i destroy surface(s) and create new with same effect as above.
                Could you please send your test file & source?

                It seems, as vaDestroySurface does not really freeing resources.
                Yes, the actual XvBA resources are retained until the context they are associated with is destroyed. This is some particular design of XvBA, but it could also be a regression when I cleaned up the code.

                Comment


                • @krionius

                  You have to use vlc. mplayer is not possible.

                  Comment


                  • Originally posted by gbeauche View Post
                    Could you please send your test file & source?
                    I can't attach files (why?), so you can find it here:
                    http://www.vdr-portal.de/board/threa...496#post943496

                    Testfile - i have no special file, it should be reproducable with any format.

                    Originally posted by gbeauche View Post
                    Yes, the actual XvBA resources are retained until the context they are associated with is destroyed. This is some particular design of XvBA
                    Wich context is meant here, especially surfaces in case of software-decoding?
                    If hw-decode is used, context (from vaCreateContext) is destroyed before creating new surfaces.

                    In my test-app, with key 'r' you can "restart" playing (line 1467), or uncomment #define at line 1440, wich will simulate this.
                    When uncommented #define in line 1276, only surfaces (and images) are recreated, no context - i used this for sw-decoded content (or uncommntet line 678 to force sw-decoding).

                    If i run the app and use 'r' to "restart", after about 15 times, screen remain blank, and a few loops later, vaPutSurface gives me an error.
                    This is not the case, if i (re)open XDisplay (in init_wnd uncomment line 1537, also in destroy_wnd line 1624, in main, comment line 1654).

                    Btw., with xvba 0.7.4 and Catalyst 10.9, i can't play files using hw-decoding, must go back to 10.7.

                    Hope you can do something with this infos, if questions, please tell me.

                    Comment


                    • Originally posted by Kano View Post
                      Basically with a fast cpu the open source driver + xv is less problematic. When you have the direct comparision of nv and ati cards in the same system you know definitely what works better - just that even chip cpus are getting so fast now that gpu accelleration is less important than before.
                      To a certain extent, I agree with you. However, with mobile computing, XvBA is essential for power conservation. For example, if I can keep my dual-core down to 800mhz while watching 720p content, my notebook will not get as hot and will be much more energy efficient.
                      With fast cpus on my desktop, I don't care much for power conservation nor do I need gpu-accelerated video; ffmpeg-mt takes care of all that.

                      Comment


                      • Originally posted by tbshl-vdr View Post
                        Wich context is meant here, especially surfaces in case of software-decoding?
                        Underlying XvBA context. You can't create an XvBA surface without a context. But this is an implementation detail you don't need, neither care, to know about.

                        If hw-decode is used, context (from vaCreateContext) is destroyed before creating new surfaces.

                        In my test-app, with key 'r' you can "restart" playing (line 1467), or uncomment #define at line 1440, wich will simulate this.
                        When uncommented #define in line 1276, only surfaces (and images) are recreated, no context - i used this for sw-decoded content (or uncommntet line 678 to force sw-decoding).
                        In summary, the files you provided exhibit the problem without uncommenting anything, i.e. as is included in the sources?

                        Btw., with xvba 0.7.4 and Catalyst 10.9, i can't play files using hw-decoding, must go back to 10.7.
                        On which GPU?

                        Comment


                        • Originally posted by tbshl-vdr View Post
                          In my test-app, with key 'r' you can "restart" playing (line 1467), or uncomment #define at line 1440, wich will simulate this.
                          I am sorry but I get a crash instead:

                          0x08049868 in av_release_buffer (avctx=0x8071430, pic=0x808c870) at va.c:326
                          326 if(ctxt->surfaces[i].id == sid)
                          (gdb) bt
                          #0 0x08049868 in av_release_buffer (avctx=0x8071430, pic=0x808c870) at va.c:326
                          #1 0x004b5e7f in MPV_common_end () from /usr/lib/i686/cmov/libavcodec.so.52
                          #2 0xbffff8b8 in ?? ()

                          Comment


                          • Originally posted by gbeauche View Post
                            I am sorry but I get a crash instead:

                            0x08049868 in av_release_buffer (avctx=0x8071430, pic=0x808c870) at va.c:326
                            326 if(ctxt->surfaces[i].id == sid)
                            (gdb) bt
                            #0 0x08049868 in av_release_buffer (avctx=0x8071430, pic=0x808c870) at va.c:326
                            #1 0x004b5e7f in MPV_common_end () from /usr/lib/i686/cmov/libavcodec.so.52
                            #2 0xbffff8b8 in ?? ()
                            Here is a better trace.

                            Program received signal SIGSEGV, Segmentation fault.
                            0x08049868 in av_release_buffer (avctx=0x80713d0, pic=0x808c890) at va.c:326
                            326 if(ctxt->surfaces[i].id == sid)
                            (gdb) bt
                            #0 0x08049868 in av_release_buffer (avctx=0x80713d0, pic=0x808c890) at va.c:326
                            #1 0x004b5e7f in free_frame_buffer (s=0x80a4ec0) at /home/gb/svn/packages/build-area/ffmpeg-0.6/libavcodec/mpegvideo.c:206
                            #2 free_picture (s=0x80a4ec0) at /home/gb/svn/packages/build-area/ffmpeg-0.6/libavcodec/mpegvideo.c:331
                            #3 MPV_common_end (s=0x80a4ec0) at /home/gb/svn/packages/build-area/ffmpeg-0.6/libavcodec/mpegvideo.c:746
                            #4 0x003d8599 in ff_h264_decode_end (avctx=0x80713d0) at /home/gb/svn/packages/build-area/ffmpeg-0.6/libavcodec/h264.c:3365
                            #5 0x005785da in avcodec_close (avctx=0x80713d0) at /home/gb/svn/packages/build-area/ffmpeg-0.6/libavcodec/utils.c:710
                            #6 0x0804a711 in close_avctxt (ctxt=0xbffffa08) at va.c:574
                            #7 0x0804cdb7 in playfile (fname=0xbffffde6 "/mnt/videos/cavium/dirt2.480p30.2Mbps.264", dpy=0xbffffbd4, vadpy=0xbffffbd0,
                            drawable=0xbffffbcc, wnd_w=1920, wnd_h=1080) at va.c:1470
                            #8 0x0804d229 in main (argc=<value optimized out>, argv=0x804d356) at va.c:1658

                            Comment


                            • Originally posted by tbshl-vdr View Post
                              In my test-app, with key 'r' you can "restart" playing (line 1467), or uncomment #define at line 1440, wich will simulate this.
                              When uncommented #define in line 1276, only surfaces (and images) are recreated, no context - i used this for sw-decoded content (or uncommntet line 678 to force sw-decoding).
                              BTW, just before the crash, I could notice that, on my side (xvba-video), all surfaces are destroyed:

                              destroying surface 0x03000000
                              xvba_video: XVBADestroySurface(): surface 0x9165730
                              destroying surface 0x03000001
                              xvba_video: XVBADestroySurface(): surface 0x9165a48
                              destroying surface 0x03000002
                              xvba_video: XVBADestroySurface(): surface 0x9165d60
                              destroying surface 0x03000003
                              xvba_video: XVBADestroySurface(): surface 0x9166078
                              xvba_video: XVBADestroySurface(): surface 0x94d69a8

                              Comment


                              • Hello,

                                My hardware setup:
                                P4 2.6 GHz HT (s478)
                                ATI HD3450 AGP
                                1 GB RAM (DDR1)

                                I'm trying to play H264 movies with this setup, up to 1080p. CPU simply isn't fast enough to do this so for last three days I've been trying to make some use of GPU acceleration.

                                I was kinda green in the matter so I started with reading/learning and from what I have read my GPU card has UDV (not UDV2) but it's working OK for some people.

                                For example I found this solution:
                                http://oscarbg.blogspot.com/2009/11/...i-backend.html

                                So at this point I knew I have to use xvba + vaapi and some player that can use it, preferrably old good mplayer.

                                I compiled mplayer with vaapi support plus all required stuff. When I run vaapi it gives me such output:

                                Code:
                                libva: libva version 0.31.1-sds1
                                Xlib:  extension "XFree86-DRI" missing on display ":0.0".
                                libva: va_getDriverName() returns 0
                                libva: Trying to open /usr/lib/va/drivers/fglrx_drv_video.so
                                libva: va_openDriver() returns 0
                                vainfo: VA API version: 0.31
                                vainfo: Driver version: Splitted-Desktop Systems XvBA backend for VA API - 0.7.4
                                vainfo: Supported profile and entrypoints
                                      VAProfileMPEG2Simple            : VAEntrypointIDCT
                                      VAProfileMPEG2Main              : VAEntrypointIDCT
                                      VAProfileH264High               : VAEntrypointVLD
                                      VAProfileVC1Advanced            : VAEntrypointVLD
                                Looks ok to me.

                                So I tried to run some H264 video files with compiled mplayer:

                                mplayer -vo vaapi:gl -va vaapi video.m2ts
                                mplayer -vo vaapi -va vaapi video.m2ts

                                I tried all of this using Ubuntu 9.04, 9.10 and 10.04 plus newest Catalyst Drivers (10.9).

                                The result?

                                @Ubuntu 9.04 and 9.10 I got mplayer crashing whole system after 1-2 seconds, I wasn't even able to see the picture (black sreen only).

                                @Ubuntu 10.04 I got mplayer running for 1-2 seconds and then it freezes, black screen. The system doesn't crash so I'm able to kill mplayer but then it eventually crashes anyway.

                                Of course mplayer gives me some output - I can see VA-API Acceleration is being used.

                                When it's not used mplayer doesn't crash and movies are played normally (up to 720p).

                                I've tried to read this topic (well, it's got 93 pages, I've read about 50% so far) and google for another answers but no luck. Since I've lost 3 days already for now I'd only like to know one thing - am I doing something that's not possible to accomplish with my hardware setup or software? Are all these success reports false or is it just my badluck? Maybe I have to use another versions of software? Could anyone post the versions that work together? Perhaps older Catalyst? :/

                                I also tried to compile vlc with --fmpeg-hw option (./configure --enable-libva --without-kde-solid) but I got errors during ./compile:

                                Code:
                                ERROR   : avio.c: 55:  expected specifier-qualifier-list before 'URLContext'
                                avio.c: In function 'OpenAvio':
                                ERROR   : avio.c: 78:  implicit declaration of function 'av_register_all'
                                ERROR   : avio.c: 96:  implicit declaration of function 'url_open'
                                (..much more here, all with avio.c..)

                                Comment

                                Working...
                                X