No announcement yet.

XvMC support

  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by duby229 View Post
    These are my own encodes. I'm curious to hear more about VAQ, Is that somehow related to this patch?
    Yes, but VAQ has been in the official x264 (git) tree since last spring and it is turned on by default if you use x264 CLI or MEncoder. See:
    x264 --longhelp | grep -A 4 aq
    If not then are you talking about Constant Quantizer? If so then what quantizer should I use to get near DVD quality?
    Always use CRF (constant rate factor) instead of CQ. CRF values of 18 or less should be mostly transparent, but personally I'm quite happy with CRF 22. Try values between 18 and 24 and decide what is good for you given the resulting file sizes.
    Last edited by deneb; 02 January 2009, 07:16 AM.


    • #42
      Originally posted by bridgman View Post
      I read the survey and I saw the
      Both the European and North American TV standards now include MPEG4 as well as MPEG2. The move to MPEG4 seems to be happening very quickly, and right now XvMC only standardizes MPEG2 acceleration.
      My experiences from here in Finland is that all digital terrestrial broadcasting (DVB-T) is today in mpeg2.

      During the time of Peking olympic, there were some HD broadcatings tests in the capital and some commercial channels may start also broadcasting DVB-T2/mpeg4 channels in some good luck within 1-2 year. Reason preventing the move is pretty much political because it is impossible to demand people again to upgrade their set top boxes and TV's which after a lot of complaining are now finally all digital. (and most of them will only support MPEG2)

      Satellites/DVB-S/DVB-S2 are on the other hand moving much more fastly for the digital content, so partially you are right and accelerated MPEG4 is important. In VDR mailing list somebody reported 2 days ago that he was able to watch VOOM HD with 7 % cpu usage with NVidia 8200 chipset based motherboard and AMD4850 cpu thanks for the VPDAU support.

      If I instead use VDR-1.7.2 and mplayer for watching the ArteHD with my AMD780G/4850E system, the top is reporting much worser numbers:

      Tasks: 174 total, 3 running, 171 sleeping, 0 stopped, 0 zombie
      Cpu(s): 71.4%us, 1.5%sy, 0.3%ni, 26.6%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st
      Mem: 1799896k total, 1654508k used, 145388k free, 265404k buffers
      Swap: 8185076k total, 176k used, 8184900k free, 642744k cached

      7761 lamikr 20 0 730m 62m 22m S 120 3.6 3:54.90 vlc
      3004 root 20 0 384m 58m 13m S 21 3.3 2:02.05 X
      5200 lamikr 9 -11 224m 5540 3816 S 2 0.3 0:14.22 pulseaudio
      7746 root 20 0 213m 24m 4460 S 2 1.4 0:04.87 vdr

      With normal arte channel broadcasting MPEG2, my cpu usage according to top is about 25 %.



      • #43
        In Sweden there's one DVB-T channel using mpeg4 at the moment, the experimental channel SVT HD. It is local to the capital area. I've heard rumors that some mpeg4 SD channels will be starting during 2009. But it's only rumors; I cannot give a real source.


        • #44
          In Norway the terrestrial network is H.264. HD satellite TV is H.264. HD cable service is as far as I know also H.264. AVCHD video cameras is H.264. The only use I have for accelerating MPEG2 is my HDV camera but I don't have any use for it.

          So basicly, interest in XvMC if it means extending XvMC to support H.264: High. XvMC MPEG2: None.


          • #45
            I am little confused with terms in X... When this thread talks about whether to support XVMC, does it also mean whether to support XVIDEO/XV?

            I own Wii which does not support direct output to LCD monitors. Therefore I am used to connect my Wii to my LCD monitor with the assistance of video input support in hvr-1300 dvb-t card and linuxtv application which can then show the content.

            This worked very well with my 10 year old Pentium 700mhz with
            integrated intel graphic card but not anymore with ATI drivers on my modern AMD780G system.

            If I try to launch linuxtv I am now getting error:

            [lamikr@tinka szap-s2]$ tvtime
            Running tvtime 1.0.2.
            Reading configuration from /etc/tvtime/tvtime.xml
            Reading configuration from /home/lamikr/.tvtime/tvtime.xml
            xvoutput: No XVIDEO port found which supports YUY2 images.

            *** tvtime requires hardware YUY2 overlay support from your video card
            *** driver. If you are using an older NVIDIA card (TNT2), then
            *** this capability is only available with their binary drivers.
            *** For some ATI cards, this feature may be found in the experimental
            *** GATOS drivers:
            *** If unsure, please check with your distribution to see if your
            *** X driver supports hardware overlay surfaces.

            Some months ago I asked this in irc and heard from somebody that YUV2 support is coming soon once the docs are available.
            Is there any updates for this expected soon? I think this was also not working with ATI's closed source drivers, at least the XV support was missing on last summer.



            • #46
              Good question.

              Everyone agrees that Xv is a must-have, partly since a number of applications more-or-less require it, and partly because Xv significantly helps pretty much every video playback task no matter what video format or resolution is being used.

              This thread is only debating the urgency of building XvMC (Motion Compensation and optionally IDCT) on top of Xv, to offload more CPU work to the GPU when decoding MPEG2 video streams. Our view is that time would be better spent working on an implementation which could also handle H.264/VC-1 as well as MPEG2, which will require either some extensions to the XvMC API or a different API completely.

              Right now Xv is implemented in the open drivers up to the 5xx and RS690 products; the 6xx and 7xx GPUs use an entirely new 3D engine which required a lot more development and documentation work. We released an "almost working" open source Xv implementation for 6xx/7xx into a public branch of radeonhd a few days ago; I imagine it will take a couple of weeks before we have it fully working. The code also needs a bit more work to run on the 780; I don't know exactly how long that will take but I don't think there will be any big delays.

              I believe we added YUY2 support to the closed source drivers during the summer some time -- ah, here we go... looks like it was the June 08 (Cat 8.6) release.
              Last edited by bridgman; 02 January 2009, 01:55 PM.
              Test signature


              • #47
                My take on this is that it is less a question of can the CPU do the work, but can we reduce power consumption by doing it on the GPU and putting the CPU into a lower power state? If power consumption can be reduced, it is worth getting working for the mobile device market, which is battery life sensitive.


                • #48
                  Originally posted by RobbieAB View Post
                  My take on this is that it is less a question of can the CPU do the work, but can we reduce power consumption by doing it on the GPU and putting the CPU into a lower power state? If power consumption can be reduced, it is worth getting working for the mobile device market, which is battery life sensitive.
                  Thats true. It would be nice to know what's the case with NVIDIA/VDPAU drivers. I mean what is the total power consumption of computer in case where you use 90% of your CPU for watching the h264 material compared to situation where the CPU load is only 7 % thanks for the VDPAU but the GPU is on the other hand doing much more work.

                  And is there any easy method/top kind of tool for watching the GPU utilization?



                  • #49
                    Just wanted to add my "case".

                    I'm not interested in MPEG-2 or MPEG-4. GPU decoding of H.264 is something I would love to see. That is the format that really eats my CPU while playing.


                    • #50
                      It would be also nice to see some GPU help for encoding H.264 files with x264...
                      It takes a lot of time even on a dual core system, so it would be very nice if x264 encoding could use third thread and use the GPU to speed up the encoding