Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Graphics Software Linux

Hardware-Based Video Acceleration Coming To Linux 143

Posted by kdawson from the buh-bye-frame-skipping dept.
sammydee writes "Phoronix reports that GPU based video decoding acceleration will be implemented in Gallium3d sometime this year. Drivers currently using Gallium3d include the open source nouveau driver for NVIDIA cards and experimental Intel GMA drivers. This is definitely good news for anybody who has ever tried to play high-definition 1080p content on any CPU older than about a year."
This discussion has been archived. No new comments can be posted.

Hardware-Based Video Acceleration Coming To Linux More

Hardware-Based Video Acceleration Coming To Linux

Comments Filter:

  • Extremely stupid (Score:3, Interesting)

    by Bombula ( 670389 ) on Friday July 11, 2008 @08:20AM (#24150719)
    I suppose I'm both ignorant and stupid, having been out of the build-your-own-box scene for more than five years now, because whenever I stroll past the video card section at best buy I swear I read things like, "LIGHTNING FAST DVD PLAYBACK AND VIDEO DECODING!" I had no idea video decoding was still CPU dependent. Give the governor harumph, I guess.

    • Re:Extremely stupid (Score:5, Informative)

      by gEvil (beta) ( 945888 ) on Friday July 11, 2008 @08:48AM (#24150947)
      Basically history is repeating itself. When DVDs first came out, MPEG-2 decoding was done on the CPU. Then video cards started having hardware supported MPEG-2 decoding. Now that we have the HD video codecs (AVC, VC-1, hires MPEG-2), we went back to square one (especially with AVC and VC-1, which require some pretty heavy lifting). In the past couple of years, video cards have added hardware support for those tasks, which otherwise would max out a fairly decent processor (~2GHz dualcore) trying to decode a high bitrate 1080p stream.
      • I have an Opteron 165 processor that was released more than 2 years ago. There are articles going back to February 2006 on this chip. Its not even the fastest chip of that time. And it has handled every 1080p file I have thrown at it in software.

        My thoughts on this are that if you want to watch 1080p on your computer, you probably have a fast enough processor by now anyway. If its an HTPC, the power you save on the CPU is just going to be redistributed to the GPU. If you want to play HD content on

        • Re:Not 1 year (Score:5, Informative)

          by sricetx ( 806767 ) on Friday July 11, 2008 @09:58AM (#24151703)
          If you are running Windows and using the manufacturer's drivers for a relatively recent (last few years) video card, then yeah, everything should be peachy. But if you are using open source video card drivers under Linux then good luck. Even with the proprietary Nvidia driver, highdef video playback can max out a fairly new CPU. http://www.mythtv.org/wiki/index.php/HD_Playback_Reports [mythtv.org] will give you an indication about the type of setup you need to get HD video playback to work.

          • Re:Not 1 year (Score:5, Funny)

            by Hektor_Troy ( 262592 ) on Friday July 11, 2008 @11:01AM (#24152601)

            Uhm ... just read through that wiki entry a few times, and it gave me absolutely no information about the quality of the playback. Two of the comments in the "report" are usefull - the rest are quite literally useless when it comes to judging the playback ability. I.e

            CPU: Intel Core2 Quad CPU Q6600 @ 2.40GHz
            Speed: 2400.000 MHz
            Memory total: 4050584kB
            Kernel: 2.6.22-14-generic
            Video codec/container: h264 / m2ts
            Resolution: 1920x1080
            Bit rate: 32469 kb/s
            Comment: Blu-ray rip of "Casino Royale."
            Media player: mplayer

            Wauw. How about ... video frame rate vs playback frame rate? The above comment just tells me that the guy ripped Casino Royale. However, if the video frame rate is 29.97 fps, but only plays back at 19.87, the CPU isn't usefull for that particular application.

            • Re: (Score:2)

              by Orphaze ( 243436 )

              You may need to improve your reading comprehension.

              "Find the file that is most taxing to play while still playing smoothly and run the script on this page with it."

              So, what the page allows you to do is say this file, of X resolution, of Y fps, with a bitrate of Z plays perfectly on my system $SPECS.

          • Re: (Score:2)

            by Khyber ( 864651 )

            That's Because MythTV sucks. Just straight mplayer with Ubuntu 6.10LTS on my old 1.8GHz P4 did 1080i HD DivX without much of an issue. Bear in mind this was the first-gen P4 with a measly 256KB of L2 cache, as well, running on a paltry 64 meg GeForce2 MX400 (the crap of the line card for the day) and a half gig of PC2700.

            • Re: (Score:3, Insightful)

              by PitaBred ( 632671 )

              MythTV uses mplayer to play the videos. So really, your solution is exactly what MythTV uses, except MythTV gives you a nice interface for a TV set.

              And 1080i is about half the bandwidth of 1080p. There's a big difference between decoding the two.

              • Re: (Score:2, Informative)

                by Anonymous Coward

                No, MythTV uses it's own built-in player (which I think is based on ffmpeg) for playing videos which definitely isn't mplayer. Now, you can set it up to use external players (such as mplayer) if you want to, but that isn't the default option.

            • DivX and AVC are vastly different codecs. That's part of the difference here.

        • Re: (Score:3, Informative)

          by neumayr ( 819083 )
          Hm. My 2x2.6ghz AMD64 CPU can't do it. On Linux, with Nvidia's GPU driver.
          Don't know if I've missed something, but it seems your video decoding is GPU accelerated.
        • I downloaded Big Buck Bunny [blender.org] 1920x1080 to test PureVideo on my new 8600GT only to learn that this feature isn't supported in linux.

          The h264 and ogg files play with lots of interruptions in the video (but not the audio). The avi plays smoothly with some tearing.

          This cpu is currently OCed to 2363MHz and the avi still shows some tearing. vlc seems to perform slightly better than totem-gstreamer using the latest blob from nvidia.

          db

      • Re: (Score:3, Interesting)

        by MBGMorden ( 803437 )

        Actually, there's an extra flip-flop step in there. When DVD's FIRST came out, hardware decoders were quite common. I remember DVD drives commonly coming with PCI hardware decoders (the RealMagic Hollywood+ was common) because at the time, many home computers simply didn't have the horsepower to pull off real-time MPEG2 decoding. My computer system when I got my first DVD drive was an AMD K6-2 450Mhz and software encoders couldn't keep up and I'd get occasional video stuttering. My hardware DVD decoder c

        • Re: (Score:2, Interesting)

          by MilesAttacca ( 1016569 )
          And those hardware encoders are still godsends. I picked up a 500MHz Pentium III ThinkPad and a Margi PCMCIA decoder card for about $100, which gives me two hours' battery life and a 13.3" screen -- which respectively equal and thrash your average portable DVD player. When I'm not playing movies I can use the same device to check my e-mail, and when I am watching movies, I can even use a dongle to hook it up to a bigger screen and use it as my only DVD player. The downside is that I have to dual-boot becaus

        • Re: (Score:3, Informative)

          by serviscope_minor ( 664417 )

          Actually, there's an extra flip-flop step in there. When DVD's FIRST came out, hardware decoders were quite common. I remember DVD drives commonly coming with PCI hardware decoders (the RealMagic Hollywood+ was common) because at the time, many home computers simply didn't have the horsepower to pull off real-time MPEG2 decoding. My computer system when I got my first DVD drive was an AMD K6-2 450Mhz and software encoders couldn't keep up and I'd get occasional video stuttering. My hardware DVD decoder card

      • Umm. (Score:2)

        by Khyber ( 864651 )

        For playback of a 1080 DivX file, I only needed 512 megs of RAM, windows XP, and a 2.0 GHz single core Athlon64. That was well more than three years ago. Actually my old 1.8GHz P4 handles it, with just a tiny bit of stuttering when seeking in VLC.

    • Re:Extremely stupid (Score:5, Informative)

      by somersault ( 912633 ) on Friday July 11, 2008 @08:49AM (#24150959) Homepage Journal

      I think the point is that it is CPU dependent if you don't have any assistance from video hardware acceleration, as is the case if your video drivers are incomplete.

    • Re: (Score:3, Informative)

      by LarsG ( 31008 )

      That the hardware supports it does not mean that the driver supports it.

    • Re:Extremely stupid (Score:5, Interesting)

      by jonwil ( 467024 ) on Friday July 11, 2008 @08:58AM (#24151047)

      Part of the problem with hardware accelerated video decoding on Linux is that because Windows uses the accelerated video decoding to play back DRM protected media, the hardware companies cannot reveal how the video decoding part works (since it would presumably allow someone to grab the unencrypted-but-compressed video for various DRM protected video files by writing a windows driver or something)

      • because DRM is soo effective, that they'd have to resort to that. lol

        • It's not about the practical matter of how effective DRM is. In theory, DRM is effective. That's how the law treats it, and that's how companies market it. Hardware companies have to play along with the charade, or find themselves unable to obtain the necessary licenses for whatever the new whiz-bang entertainment technology is in a few years.

      • Part of the problem with hardware accelerated video decoding on Linux is that because Windows uses the accelerated video decoding to play back DRM protected media, the hardware companies cannot reveal how the video decoding part works (since it would presumably allow someone to grab the unencrypted-but-compressed video for various DRM protected video files by writing a windows driver or something)

        However, the hardware could have been designed to merely decrypt, decode, check HDCP, and play, all in one. That is, one merely sends the A/V transport/container stream, in its encrypted form if not originally in the clear, to the video card (once it is set to operate in this mode). The video card will decrypt (if it has the appropriately licensed built-in key to enable this) the encrypted bits of the stream, do the (now clear) codec decoding (by whatever codec is involved), check to make sure the connect

  • Don't know what to say ... (Score:4, Interesting)

    by Swizec ( 978239 ) on Friday July 11, 2008 @08:20AM (#24150723) Homepage
    ... you mean we can do all the fancy stuff windows can, and better. But playing videos efficiently was the one thing we couldn't do? We had fancy GUI effects long before windows, we had efficient RAM usage, great file systems, but we had trouble playing a fucking video?

    Wow, wish I'd known.

    • Re:Don't know what to say ... (Score:4, Informative)

      by Fweeky ( 41046 ) on Friday July 11, 2008 @08:43AM (#24150909) Homepage

      If it's any consolation, GPU accelerated playback on Windows doesn't work all that often, and open source codecs/players tend to be the better ones there speed and support wise, acceleration or no.

    • Re:Don't know what to say ... (Score:5, Informative)

      by Anonymous Coward on Friday July 11, 2008 @09:53AM (#24151613)

      Playing a video is no problem.

      The problem is that a high-bitrate 1080p video stream requires a lot of CPU time to decode, and then you have to transfer the whole uncompressed frame out to the video card.

      Unless you have a really high-end CPU, there are no Windows-based video players capable of doing this with just software. They all require some kind of hardware acceleration. The specs for all this are nicely closed up, and are known only to Microsoft, video card manufacturers, and the few companies that implement video decoders (which is probably Microsoft again).

      Video card manufacturers like nVidia have refused to implement any kind of video decoding in their Linux drivers until there's an appropriate spec. They won't tell anyone what they're hardware is actually capable of, so nobody else can write a spec. We can't even reference Microsoft's basic design, because it's all closed off and secret.

      Oh, and most of it doesn't even work properly in Windows either. I've never managed to get it to work at all, and benchmarks I've seen seem to suggest that it's really only offloading 10% or so of the workload. Just enough to make the difference between working and not working, but not as much as it could be.

      The Gallium guys are planning to implement the entire thing in their video drivers, using only the 3D capabilities that video cards are known to have. That neatly bypasses the whole thing, but required that we have a single base driver to work with (which Gallium provides), and one or more video drivers actually using it (which, again, Gallium provides).

      I kind of hope that Gallium implements something similar to nVidia's CUDA - a programming model for running stuff on graphics cards that doesn't rely on graphics-related stuff like textures or polygons. That way, we'd have a way to implement different kinds of video decoders, encoders, or even things like physics simulations. Bonus points if it can be made compatible with something available on Windows...

      That said... Linux video players tend to be a hell of a lot quicker than Windows video players. I've played videos in Linux that were impossible to play in Linux.

  • 1080p? (Score:2, Funny)

    by willie3204 ( 444890 )

    first 1080p post?

  • Looks like this would be an important step forward for running Windows games. From the wikipedia link:

    Gallium 3D will provide a unified API exposing standard hardware functions such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single back-end, called state tracker, targeting Gallium 3D API.

    • Nearly-as-important things like Folding!

    • That would be the crushing blow to all gaming for windows if it works as you are suggesting. I don't know enough about software to make a statement on it.

      Also though, doesn't VLC linux handle H.232 or whatever it's called and other 1080p stuff?

      • Re: (Score:3, Insightful)

        by somersault ( 912633 )

        The point isn't that Linux doesn't have codecs to play play hi-def content, the point is that there apparently are no Linux drivers out there that make use of the HD video acceleration hardware that is currently available.

        As for having yet another API to go through, I fail to see how it would be a 'crushing blow to all gaming for Windows', since even if it did have perfect Direct3D compatibility, it would simply make it easier to port Windows games to Linux. We already have Direct3D support through WINE, an

        • Re: (Score:2)

          by Khyber ( 864651 )

          Recently I gave up on my PS3. Even Assassin's Creed on my LAPTOP at 1440x900 (and laptops are known for not having good graphics) runs smoother than the PS3 playing the same game in standard definition. It's sad when a gaming console gets beat out by an all-purpose machine. A PORTABLE ONE, at that.

          • Send it to me? I'll even pay shipping ;)

          • Sounds more like an issue with the game than the console. I didn't buy Assassin's Creed because while it sounds cool, it's apparently very repetetive and gets old fast. Half-Life 2 is meant to be awful on the PS3 because the port wasn't done by Valve themselves. Seeing as Assassin's Creed was quite an early PS3 game as well, you can't expect the developers to be as familiar with the system as they will be in a couple of years. Games usually look better and better throughout a console's lifespan. My laptop c

      • Re: (Score:3, Informative)

        by WaroDaBeast ( 1211048 )
        I think you meant h.264 -- you were probably thinking about RS-232 for the number.

        And yes, VLC Linux does support h.264 playback, but 1080p videos are likely to display stuttering if not GPU-accelerated: I tested it on my machine, CPU is an Athlon X2 5600+ and GPU is a Geforce 8800GTS; anything up to 720p was fine, but 1080p was unwatchable prior to installing nVidia Purevideo [wikipedia.org].


        P.S.: Seems 1080i is fine too if not GPU-accelerated.

        • Weird... I have an Athlon X2 4600+ and just an embedded AMD x1250 (RS690 chip), and it plays 1080p quite well on my MythTV media center. But I use mplayer as the backend. Perhaps your drive wasn't up to the reading speed necessary, or VLC is just crap at HD video? Because the only stuttering or weird stuff I get is when I pause and start or skip around in the file, and that's only for less than a second while things sync back up.

          • Were you playing 1080p MPEG2 or 1080p MPEG4/h.264? Worlds of difference. I've got a 4400+ with MythTV and can playback 720p and 1080i h.264 no problem, but 1080p drops lots of frames...
            1080p Mpeg2 plays back easy...

            • [mkv] Track ID 2: audio (A_AC3) "English (AC3)", -aid 0, -alang eng
              [mkv] Will play video track 1.
              Matroska file format detected.
              VIDEO: [avc1] 1920x800 24bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
              ID_FILENAME=The Fifth Element - HD1080p.mkv

              I'm pretty sure that [avc1] is H.264, so yes, it is H.264. Didn't realize it was only 800px high, though. I thought it was 1080. Whoops.

              • Hate replying to myself:

                Just for some more info, it's a 4600+, an AMD RS690 video card (integrated X1250), 2GB of 667MHz DDR2 (I think... it may be 800MHz), and all the video data is on a software RAID5 array of 250GB SATA 1.5Gbps disks. The display (61" Samsung LED engine DLP) is detected at 1920x1080, so there's no downsampling or anything of the video going on. I have noticed a "tear" or two going on every now and then, but that's it. I haven't explicitly checked for dropped frames, but the quality of

    • I think it would be a great thing for linux but enough with those Windows only game. The only reason I still run XP / Vista is that i'm a gamer.
      I found replcament for pretty much everything on the linux side for what I do at work but I have to install XP / Vista because Steam is just to handy now and my collection of PC game is getting too big to even think about sitting in front of my computer and start configuring Wine for each of them.

      Wine is a nice concept but just to freaking painfull to configure

      • Re: (Score:1, Informative)

        by BhaKi ( 1316335 )
        Steam, Half-life and Counter-Strike are running excellently in wine 1.0, with higher stability and performance in wine than in windows!!! Just remember to use the openGL mode, not DirectX mode.

        • Re: (Score:2)

          by BrentH ( 1154987 )
          It runs, if you're happy with DX8.1 effects and breakage from time to time. Neither of those appeal to gamers, not even gamers that like Linux.

  • Already there (Score:5, Informative)

    by bconway ( 63464 ) on Friday July 11, 2008 @08:34AM (#24150833) Homepage

    nVidia's binary drivers and X.org's Intel drivers have had XvMC support for well over a year. I've been using both card successfully with Xine and accelerated 1080p video. I think the news here is that the nouveau project is catching up, but that's hardly clear from the article.

    • Speaking of Xine (Score:5, Informative)

      by DrYak ( 748999 ) on Friday July 11, 2008 @08:47AM (#24150945) Homepage

      Xine has supported hardware accelerated DVD video (MPEG1/2) decoding using EM8300 based cards [sourceforge.net] like Sigma Design's Holywood+ and Creative's DXR3, since about 2000.
      (But that was done using an ad-hoc module inside Xine, not using generic APIs like XvMC or the future Gallium3d video)

      The Gallium3D Video API is a good news, because it'll probably be able to address shortcommings that XvMC has [wikipedia.org].

    • Re: (Score:3, Informative)

      by krgallagher ( 743575 )
      "I think the news here is that the nouveau project is catching up, but that's hardly clear from the article."

      I copied this from Wikipedia:

      Gallium 3D will provide a unified API exposing standard hardware functions such as shader units found on modern hardware. Thus, 3D APIs such as OpenGL 1.x/2.x, OpenGL 3.x, OpenVG, GPGPU infrastructure or even Direct3D (as found in the Wine compatibility layer) will need only a single back-end, called state tracker, targeting Gallium 3D API. By contrast Mesa 3D requires a

      • Re: (Score:3, Interesting)

        by samkass ( 174571 )

        The LLVM approach is interesting. They're basically following Apple's lead here, whose drivers use LLVM intermediate bytecode to compile shaders to either a GPU or CPU depending on hardware availability and heuristics. It basically makes it easier to support new hardware and provide relatively high-performance fallbacks in the case specific hardware capabilities are not present. All using a common architecture instead of one-off development.

    • Re: (Score:3, Interesting)

      by hummassa ( 157160 )

      1080p with XvMC and which codec? I thought XvMC didn't do x264, for instance.

      • 1080p with XvMC and which codec? I thought XvMC didn't do x264, for instance.

        You mean h.264. h.264 is the format, x264 is an encoding library.

    • Was there, nearly gone (Score:4, Informative)

      by Jo Deisenhofer ( 25198 ) on Friday July 11, 2008 @09:20AM (#24151269)

      XvMC does only accelerate MPEG-2, and not many use it, because the de-interlacing you can get sucks. And for MPEG-2, you usually don't need hardware acceleration anyway.
      nVidia, like ATI, are moving away from video overlays and have some pretty nice GPU-based video decoding built into their cards using the GPU (most of it probably implemented as shader programs).
      But you can't use any of that with linux, you are basically down to hardware video scaling, which the newest cards no longer really support.
      It is high time for a new, industry standard API for video. I hope that's what they are doing.

    • Yes, but if it is implemented in gallium3d, this means that:

      1) Any driver using gallium3d will automatically support video decoding
      2) It is very easy to add extensions to the protocol, ie finally support something other than mpeg2 which is very outdated now anyway.

      Sam

      • Re: (Score:2)

        by Big Boss ( 7354 )

        MEPG2 might be a little outdated on the internet, as most things older than about 5 minutes are. But it's still the standard for OTA HDTV. If you use an antenna for HDTV, you use MPEG2. And many people still do it for local channels as Cable and Sat operators are starting to re-compress the data enough that people with large sets are noticing a quality difference.

        And it's free, so why not use it? :) Not that I have a problem with supporting more codecs with hardware accelerated decode. May as well have that

    • Re: (Score:3, Interesting)

      by roystgnr ( 4015 )

      nVidia's binary drivers and X.org's Intel drivers have had XvMC support for well over a year.

      I'm confused - what happened a year ago? nVidia's binary drivers have had XvMC support for their older cards for many years, whereas for the 8xxx series of cards their drivers lack XvMC support *still* (at least as of the version 173.14.05 I installed a couple months ago).

  • Google summer of code... (Score:5, Informative)

    by MMC Monster ( 602931 ) on Friday July 11, 2008 @08:36AM (#24150865)

    This is apparently a google summer of code project.

    While I am hopeful, let's not write this one on stone until it's released.

  • Not really (Score:5, Interesting)

    by JamesP ( 688957 ) on Friday July 11, 2008 @08:38AM (#24150879)

    This is definitely good news for anybody who has ever tried to play high definition 1080p content on any CPU older than about a year.

    Actually, one of the most preeminent examples of HW decoding of video nowadays is the Intel Atom processor, not really old processors.

    Video accel. is inside the chipset for this one.

    And yes, it is available in Linux, you will probably be able to watch h264 movies in your new EEEPC

    • Re: (Score:2)

      by MrHanky ( 141717 )

      If you actually could read, you'd notice that it says "on any CPU older than about a year", i.e. not Atom or any other CPU fast enough to decode 1080p h264. You know, Celerons and stuff.

    • Re:Not really (Score:4, Funny)

      by WaroDaBeast ( 1211048 ) on Friday July 11, 2008 @09:33AM (#24151413)

      And yes, it is available in Linux, you will probably be able to watch h264 movies in your new EEEPC

      Yay, 1080p movies on my seven inch screen! Plus I can even hook it up to my newly acquired 35:000 contrast ratio, 24p capable, 1080p fifty-two inch flat TV through a VGA connexion! HURRAY!


      Relax, I'm just poking fun. ;)

      • VGA is analog but aside from that it is great.
        Quite capable of crystal clear 1080p and higher.

        • Seconded. I've got my MythTV box hooked up through VGA to my 61" LED Samsung DLP, and 1080p works pretty well. Just gotta beware of the little bits of noise VGA cables can pick up from other cables running near them. I'll get an HDMI cable eventually.

    • For the record, mplayer on my EeePC 900 has no problem decoding H264 at standard def PAL rates (720x576 at 25fps), which is a good match for the 600 line display that the machine actually has ...

  • Last time I was trying to play HD video on my Ubuntu - with both Xine and Mplayer - I hadn't noticed that there was performance problem related to lack of HW acceleration. (I didn't tried VLC - it can't even playback smoothly HD video on Windows where such acceleration is already available.)

    While CPU load was remaining low (~25% on dual core CPU), 720p video still was playing with terrible jitter. In Mplayer few minutes later A/V sync (as usually) went south. Xine started dropping frames. All that while

    • Re:What about software? (Score:5, Informative)

      by puto ( 533470 ) on Friday July 11, 2008 @10:37AM (#24152217) Homepage

      VLC works great for me on the windows boxes I use for my home media system. Plays HD contect fine.

      The one in the living room is a Core2 1.8 with 1.5 of ram with an ATI 2400 HD card and no problems with HD acceleration in XP.

      I do not game much, so this 59 dollar HD card has been great.

      Workstation is same setup, with two gigs of ram and vista, no problems with HD video.

      Server side is a linux box which runs headless. /all rooms have a pc attached to the tv /my guests can surf the web, watch movies, videos /or grab a wireless rumblepad and play any mame game of their choosing.

    • Re: (Score:2)

      by Big Boss ( 7354 )

      With MythTV I can play 1080i or 720p (output to the TV over component at 720p as that's the TV's native res). Hardware is an Athlon X2 3800 (I think) with 1GB RAM and embedded video (GF6450 based).

      I don't use any hardware accel, and am doing deinterlacing (BOB2x IIRC). I use about 30% CPU and notice no playback issues.

      Playback also works well on Windows with VLC on similiar hardware. This is all with ATSC sourced MPEG2 video.

    • Since I started playing HD video I have found that things can get quite finicky.
      different codecs and container formats perform differently and there are some tricks.

      One problem I experienced was jittery video with low cpu usage with certain container formats.
      have you tried the -nocorrect-pts command line option with mplayer?

    • Re: (Score:3, Informative)

      by PitaBred ( 632671 )

      It may be with your filesystem, drives or possibly just NVidia. An Athlon X2 4600+ drives 1080p video for me fine, but I use an RS690 embedded chip (AMD x1250).

    • Try adding the line lavdopts=threads=2:fast=1:skiploopfilter=nonref to ~/.mplayer/config.

  • Both of these are relatively new projects. From what I've seen, neither has any sort of releases or snapshots, you build from a checkout.

    Any idea when I might be able to get a Jocular Jaguar (or Kooky Kangaroo or Languid Lemur) LiveCD and have them part of the base install? Or for that matter, have 'emerge --sync && ARCH="x86" USE="gallium3d" emerge nouveau' install them as "stable".

  • I'm not sure, but I've heard that a lack of hardware video acceleration is one of the factors which currently limits the capabilities of the PS3 as a linux machine (along with memory support and lack of emulators for the cpu architecture). This article gives me a bit of hope that we might see advances in the capabilities of the PS3 under Linux. ( http://ubuntuforums.org/showthread.php?t=624865 [ubuntuforums.org] )

    • Re: (Score:3, Informative)

      by Slashcrap ( 869349 )

      PS3 Linux has slow video because Sony blocks access to 2D and 3D acceleration on the Nvidia chipset. This project uses 3D shaders to accelerate video decoding. So I'm struggling to see how using advanced 3D functionality that PS3 Linux doesn't have to replace basic 2D functionality that PS3 Linux doesn't have is going to help.

  • Gallium running out (Score:5, Funny)

    by bugs2squash ( 1132591 ) on Friday July 11, 2008 @12:35PM (#24154097)
    I though it was only a few days ago that /. reported that gallium is in short supply. Now we're blowing our precious reserves on frivolous video decoding.

    Have some respect for Mother Earth...

  • Er, Via's nano-ITX offerings with a C3 processor, CN400, and VT1625 has been capable of this for at least two years now. The OpenChrome project provides for the accelleration: hardware MPEG2 decoding with XvMC. glxgears does about 500 fps on an 800 Mhz fanless cpu, closer to 700 on a 1.0 GHz CPU.

    Been running this for a couple of years now in a Silverstone LC08 case.

    • RTFA, we are not talking about just MPEG2 here. The main thrust is for Mpeg4/h.264 support, but this should work for hardware accel of any codec.

  • Modern CPU's are more than fast enough to do 1080p h264 decoding. 2 years ago hardware decode would of helped, now it's a moot point.

    I want to see hardware acceleration of encoding from my graphics board. Encoding multi-pass h264 using ffmpeg with the quality options just freaking takes forever!

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close