Slashdot Mirror
Hardware-Based Video Acceleration Coming To Linux
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."
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.
A-Bomb
... 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.
first 1080p post?
The answer to all your problems
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.
Doesn't XVMC already do this? I know Nvidia & Openchrome do it this way, I don't know about all the others. But with openchrome, xvmc makes a huge impact on CPU usage during video playback on embedded devices. I see that this new solution is better and supports more resolutions & codecs, but I wouldn't say that Linux completely lacks hardware-based video acceleration right now.
Nearly-as-important things like Folding!
My turnips listen for the soft cry of your love
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.
Interested in open source engine management for your Subaru?
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.
Help! I'm a slashdot refugee.
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
how long until
Xine has supported hardware accelerated DVD video (MPEG1/2) decoding using EM8300 based cards 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.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
All the delay is because of manufacturers like nVidia who keep secret the hardware programming documentation. Any hardware vendor who doesn't release hardware programming documentation should be punished for anti-competitiveness because they are forcing customers to choose from a small finite set of OSs.
The largest prime factor of my UID is 263267.
Hardware Accelerated High Definition Pr0n vids Coming To Linux
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.
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 nor CPU load, nor kernel times where displaying any anomaly.
I'd say that problem lies elsewhere and HW accel (though welcome) might not solve the video playback problems.
P.S. At least when there would be HW accel, it would be easier to bash the server/hpc/oracle folks who now monopolize completely LKML. Probably then they would start paying attention to desktop Linux needs. Quoter of the attention they spent discussion fresh Oracle benchmarks would be more than enough.
P.P.S. Tests (actually I was just trying to watch my anime on Linux) where done on AMD 4200+ X2 + nVidia gf7800gt (evil proprietary drivers are installed) + RAM 2GB DDR CL2.
All hope abandon ye who enter here.
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 EEEPC type devices, you're probably better off transcoding since the screen is so small anyway and the storage options aren't enormous. Lastly, Mom-n-Gradma type computers generally have a reasonably fast CPU, but no GPU worth mentioning. If they should ever want to handle HD their computer probably can handle it.
I think the time for hardware accelerated 1080p has already passed, much like the time for DVD accelerators passed fairly quickly.
Even those who arrange and design shrubberies are under considerable economic stress at this period in history.
on gallium3D's website they are talking about exposing hardware acceleration capabilities through a standard API ... isn't it what directfb is all about, centered on the framebuffer ?
i'm definitely not in my field there, can anyone shed some light on the subject ? what is the overlap between those projects ?
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".
The living have better things to do than to continue hating the dead.
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 )
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...
Nullius in verba
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.
In Liberty, Rene
99% of the tech savvy people use PowerDVD anyways. It is quite good in using the hardware acceleration if your drivers are properly updated.
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!
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 ...
AMD/ATI has supposedly released enough docs to implement XvMC. When can we expect to see working code?
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.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
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
I am literally 3000 tokens away from the chaotic crossbow --Stephen
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 connection is to a proper HDCP device (which turns on re-encryption of the uncompressed HDMI stream, which the display device decrypts, so people can't tap into that), and then send the video over to the display. If it is encrypted and if a copy protection flag is set, it would disable any video or audio read-back capability (so the driver can't get a copy of what was decrypted either before or after decoding). While those of us that hate DRM (myself included) would despise the fact that this lets DRM work better, at least it CAN work in BSD and Linux because all the CPU software has to do is just replicate the stream up to the video card as-is (no decrypting, no decoding, etc). It keeps all the naughty DRM in the hardware (and also the patent licensing on the DRM and codecs). The BSD and Linux system can be entirely home-compiled from source with hacks and still let this work.
Actually, it might have been even better if the transport decrypt/decode was done in the monitor, or at least the decode part of this, which would have kept the bit rate over the HDMI manageable, even when we migrate to the Super Ultra Cinema format running at 5120x2160p120 (64:27 aspect ratio, which is the same 4x/3x ratio over 16:9 as 16:9 is over 4:3, and is almost exactly what cinema wide movies do now) in a couple decades. Even dual-link DVI couldn't handle this in uncompressed form. So they would need a whole new display interconnect or just need to retrofit compression into the existing one.
now we need to go OSS in diesel cars
Only gays, hippies, neo-Nazi's and drug addicts use Linux, and of course their 1080p movies are always pirated, so theres no business sense in allowing them to get their dirty hands on Linux complaint hardware decoders.
- A proud sponsor of John McCain. McCain 2009!
convince developers to stop working with directx, which microsoft refuses to release the code to, despite their bullshit claims about interoperability with linux and windows, and progress will begin
nice. now I'm gonna find where you live, rape your whole family, an' slow roast 'em. Stupid git!
I know full well that tobacco is bad for you, so I smoke weed with crack