More Details on Elemental's GPU Accelerated H.264 Encoder
by Anand Lal Shimpi on June 23, 2008 10:52 PM EST- Posted in
- GPUs
Tucked away in our NVIDIA GT200 review was a bit of gold. Elemental Technologies has been developing, in CUDA, a GPU-accelerated H.264 video transcoder.
If you've ever tried ripping a Blu-ray movie you'll know that just a raw rip of just one audio and one video stream can easily be over 20 - 30GB. I've been doing a lot of this lately for my HTPC and even without 8-channel audio tracks, my ripped movies are still huge (Casino Royal was around 27GB for the 1080p video track and 5.1-channel english audio track). On a massive screen, you'll want to preserve every last bit of information, but on most displays you could actually stand to compress the video quite a bit.
Using the H.264 codec (or the open-source x264 version), it's very easy to preserve video quality but reduce file size down to the 8 - 15GB range - the problem is that it requires a great deal of processing power to do so. Transcoding from a H.264 encoded Blu-ray to a lower bitrate H.264/x264 can often take several hours, if not over a day for a very high quality re-encode on a fast dual or quad-core system.
Right now transcoding Blu-ray movies isn't exactly at the top of everyone's list, but using H.264/x264 you can significantly reduce file sizes on any video. x264 is the new DivX and its usefulness extends far beyond just ripping HD movies. Needless to say, its use isn't going to increase unless encoding using the codec gets faster.
Elemental Technologies has been working on a technology they called RapiHD, which is a GPU-accelerated H.264 video encoder and the consumer implementation of RapiHD is a software application called BadaBOOM (yes, that's what it's actually called, there's even a video).
RapiHD and thus BadaBOOM are both CUDA applications, meaning they are written in C and compiled to run on NVIDIA's GPUs. They won't work without a CUDA-enabled GPU (GeForce 8xxx, 9xxx or GTX 280/260) and they won't work on AMD/ATI hardware.
Elemental allowed NVIDIA to use a very early beta of BadaBOOM in its GT200 launch, which meant we got access to the beta. We could only transcode up to 2 minutes of video and we weren't given access to any options, we could only choose a vague output format and run the encode.
BadaBOOM uses its own H.264 codec that Elemental developed, we were forced to compare it to the open-source x264 in our tests since Elemental's software won't run without GPU acceleration. We used AutoMKV and played with its presets to vary quality. Even with the awkward comparison, the advantage of GPU-accelerated H.264 encoding was obvious:
Those numbers are compared to an Intel Core 2 Extreme QX9770, the fastest quad-core CPU available today. In the worst case scenario, the GTX 280 is around 40% faster than encoding on Intel's fastest CPU alone. In the best case scenario however, the GTX 280 can complete the encoding task in 1/10th the time. We're not sure where a true apples-to-apples comparison would end up, but somewhere between those two extremes is probably a good guesstimate.
Given the level of performance we saw with the GeForce GTX 280, we scheduled a meeting with Elemental's CEO, Sam Blackman to learn more about BadaBOOM as his application has the ability to truly revolutionize video encoding performance for the masses.
Facebook
Twitter
RSS
50 Comments
View All Comments
tuteja1986 - Tuesday, June 24, 2008 - link
err :( IQ testing needed. Anyways , I use AVIVO converter to do quick conversion for my zen. Its takes me 3mins to do a whole 40min episode of a TV show or 6mins for a movie.rhangman - Tuesday, June 24, 2008 - link
You would need to at least compare profiles. How many reference frames, etc. More advanced settings require more resources to encode (and decode).Really comes down to actually viewing the encodes though. If it can't touch x264's quality, then it doesn't matter how much faster it is. The scene will stick with x264 anyway just like they did with Xvid over DivX, 3ivX, etc. So it is x264 selling players, hardware decoding graphics cards, etc. just like it was Xvid selling Standalone DivX players.
JonnyDough - Wednesday, June 25, 2008 - link
Agreed. I don't rip CDs to my computer at low bit rate either. The higher the quality (even if you can't see it) the better. Just because your computer monitor can't display uber-high res doesn't mean that the massive tv set or projector you buy a few years down the road can't. There's simply no point in building a library of movies and music if you aren't going to rip it in the highest quality possible. If you need to transfer it to a limited sized mobile storage device THEN you convert it on the fly. With larger than 1TB hard drives on the way I don't see who wouldn't want to store their movies in the sharpest image possible.7oby - Tuesday, June 24, 2008 - link
[quote]You would need to at least compare profiles. How many reference frames, etc. More advanced settings require more resources to encode (and decode).[/quote]The bitrate hardly has an impact on encoding speed. As far as I understood CABAC is done on the 30% loaded CPU here. That means if you change the bitrate, the quality will change, but the encoding speed should basically be the same.
As you said: profile comparision gives some more information. I expect Baseline Profile at most since it's a derived product:
http://elementaltechnologies.com/products.php?id=4">http://elementaltechnologies.com/products.php?id=4
Maybe it's only intra frame:
http://elementaltechnologies.com/products.php?id=1">http://elementaltechnologies.com/products.php?id=1
One would need more advanced quality tests to tell e.g. how good the motion estimation works. If this one is bad, you will need additional bandwidth to compensate.
In any case: I think this is an innovative product for the intended target use case of transcoding movies for iPhones, PS3, HTPC etc.
x264 developers recently turned away from CUDA, although they started experimenting in December 2007:
http://forums.nvidia.com/lofiversion/index.php?t53...">http://forums.nvidia.com/lofiversion/index.php?t53...
Anand Lal Shimpi - Tuesday, June 24, 2008 - link
The problem is that the beta of BadaBOOM doesn't expose any of what it's doing to the end user, we'll have to wait for the pro-version for that it seems.-A
rhangman - Tuesday, June 24, 2008 - link
Should be able to extract the raw video stream and do some analysis on it though. Get an idea what the encoder is doing. For a visual comparison you don't need to know anyway.At any rate, in terms of encoding, speed is only half the equation.
Anand Lal Shimpi - Tuesday, June 24, 2008 - link
Agreed :) Working on that part, I may wait until the next beta though so we have the latest code at our disposal.-A
Rainman200 - Tuesday, June 24, 2008 - link
That great news thanks Anand, also do compare with Ripbot as well as it uses more bleeding edge versions of x264 with patches for film grain optimization and more.Also a comparison against the constant quality mode would be interesting, I use Ripbot (default high profile) with a setting of 18 and with most movies I can barely tell the difference on the HDTV vs the original. On a 3Ghz quad core 2 it takes at worst about 1 hour 30mins on average for a film, usually shorter but noisy/grainy movies like Downfall or Minority take that little bit longer.
Will be very interesting to see how RapiHD fares against in terms of image quality.
SlyNine - Tuesday, June 24, 2008 - link
Make it support other transcodeing functions, like for audio WMA-MP3. I know that for the most part the only thing that really needs this type of boost is HQ H.264 Blue Ray movies ( and HD-DVD).But it would be awesome to accelerate the other stuff as well.
icrf - Tuesday, June 24, 2008 - link
Those are pretty lighweight, compared to H.264 so there's probably little reason. Besides, writing a codec in CUDA is no small task. I think they should focus on making the H.264 encoder as flexible as possible.I assume the feature request is more to do with features of the application doing the encoding, and not about what code to run on the GPU itself. My encoding settings of choice tend to be a Level 4.1 compliant MPEG4 file, H.264 video and 5.1 AAC-LC audio. Ideally, it should use any VFW codecs installed and dump to the various common containers (avi/mkv/mp4/ogm with things like mov/wmv being distant seconds).