Announcement

Collapse
No announcement yet.

XvMC support

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

  • #31
    Details?

    Originally posted by Dieter View Post
    >
    Out here in the real world, normal people don't buy a new computer
    every three months to get the latest ueberphemon3++ 5.72 Ghz x16.
    Full bitrate HD takes a lot more CPU than SD and computers in
    the real world have trouble with it or can't do it at all.
    I've heard several general complaints about this, but not a single hard number. I would have guessed a Pentium 3 would have enough juice for this - can you definitively state which CPU you have in your computer that isn't fast enough? If there are P4's that can't keep up that's one thing, but it's very different if it's just P2's that need to be upgraded. I don't really have an old computer lying around to test myself.

    Personally, I would love XvMC support. But not at the expense of just about any other feature I can think of. It's got to be right at the very bottom of almost everyone's list. Hopefully someone can build some generic support into Gallium3D and we won't have to always keep waiting for specific drivers to get supported.

    I'm sure it sucks to be among the few who need it, but as had been said: the specs are available and someone just has to step up and do the work. That's the beauty of open source

    Comment


    • #32
      I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.
      There is another reason why having accelerated MPEG2 would be nice : professional HD codecs. Most of them (HDV, HDCam, XD-Cam) are still MPEG-2 based and it's quite nice to be able to work natively with them at full resolution. Blue Ray is still MPEG2 also, AFAIR.
      But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
      Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?

      Comment


      • #33
        I don't know if H264 and small fits in the same sentence But of course a generic solution using OpenCL for example would be very interesting.

        Comment


        • #34
          Originally posted by Kano View Post
          I don't know if H264 and small fits in the same sentence But of course a generic solution using OpenCL for example would be very interesting.
          H264 is designed to be scalable and has several different profiles. AFAIK most flash based web videos are based upon h264, and it can offer a very good tradeoff on bitrate vs quality,especially in comparison to mpeg2 and mpeg4 asp.

          Comment


          • #35
            Originally posted by Kano View Post
            I don't know if H264 and small fits in the same sentence
            Oh yes, it does! In fact, that the most important thing about H.264 for, uhm, file sharers

            Also, converting a DVD (MPEG2) into a single 700MB H.264 video with no loss of quality is another thing that makes "H.264" and "small" really fit together. Same quality but with an order of magnitude smaller size.
            Last edited by RealNC; 12-31-2008, 08:40 AM.

            Comment


            • #36
              Originally posted by rvdboom View Post
              I have a 2GHz Opteron and it cannot deal with HD contents, either in MPEG4, MPEG2 or any other codec. And yes, I use overlay.
              If 1080p30 MPEG-2 and MPEG-4 ASP are problematic for your CPU, you are either dealing with very high bitrates (> 30 Mbps) or there may be something wrong with your player/decoder setup or the graphics driver.

              Blue Ray is still MPEG2 also, AFAIR.
              Blu-ray can carry MPEG-2, but also H.264 and VC-1. MPEG-2 is rarely used in new releases.

              But I think that what should be worked on is a more generic acceleration API than XvMC allowing for several codecs, at least H264.
              Since GPU are programmable now, isn't it possible to provide a generic API allowing to create small decoders in the appropriate programming language?
              A generic API and decoder implementations would certainly be a good idea for the future. Today, the most efficient way to decode MPEG-2, H.264 and VC-1 is by using specialized hardware like AMD's UVD or NVIDIA's VP3. To use these kind of complete decoding solutions, we only need lightweight hardware-specific wrappers and a common API.

              Comment


              • #37
                @ _txf_ and RealNC

                I think Kano was referring to the size and complexity of a fully-featured H.264 decoder implementation, not encoded video.

                Comment


                • #38
                  Originally posted by RealNC View Post
                  Oh yes, it does! In fact, that the most important thing about H.264 for, uhm, file sharers

                  Also, converting a DVD (MPEG2) into a single 700MB H.264 video with no loss of quality is another thing that makes "H.264" and "small" really fit together. Same quality but with an order of magnitude smaller size.
                  I dont knwo if that is entirely accurate. Say you've got a 1:45 hour fourty five minute film and you want to keep the file at around 1500MB. Thats a fairly high bitrate. Even at that bitrate you can still see obvious blocking in dark areas. I have several films that are dark from start to finish, and they are blocky through out the entire film even, even at that bitrate.

                  Comment


                  • #39
                    Blockiness in flat and dark areas at relatively high bitrates can be avoided by using adaptive quantization. In particular, x264 used to suffer from these problems before VAQ was introduced in mainline and turned on by default. If you are seeing problems in encodes made by others, they are either old files or otherwise poorly encoded.

                    Comment


                    • #40
                      Originally posted by deneb View Post
                      Blockiness in flat and dark areas at relatively high bitrates can be avoided by using adaptive quantization. In particular, x264 used to suffer from these problems before VAQ was introduced in mainline and turned on by default. If you are seeing problems in encodes made by others, they are either old files or otherwise poorly encoded.
                      These are my own encodes. I'm curious to hear more about VAQ, Is that somehow related to this patch?

                      http://files.x264.nl/x264_patches/fo...aq_var.48.diff

                      If not then are you talking about Constant Quantizer? If so then what quantizer should I use to get near DVD quality?

                      Comment


                      • #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?

                        http://files.x264.nl/x264_patches/fo...aq_var.48.diff
                        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:
                        Code:
                        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; 01-02-2009, 06:16 AM.

                        Comment


                        • #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

                          PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
                          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 %.

                          Mika

                          Comment


                          • #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.

                            Comment


                            • #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.

                              Comment


                              • #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: http://gatos.souceforge.net/
                                *** 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.

                                Mika

                                Comment

                                Working...
                                X