H.264 baseline GPU accelerated encoder

[TEB]

http://elementaltechnologies.com/products.php

Man.. Quad 8800GT sli encoder ;) yummy! ;)

[Atak_Snajpera]

Baseline? Is this a joke? :) People use high profile.

[Stakiman]

Sounds crazy, but I don't think the quality would be superb.
Still worth trying, though. ;-)

[TEB]

Baseline? Is this a joke? :) People use high profile.

Yea my thoughts exactly.. But nevertheless.. i wonder if they will present some benchmarks soonish.. Intresting to see how much faster and with what features turned on..

[deekey777]

Nvidia Analyst Day: Biting Back at Intel (http://www.bit-tech.net/hardware/2008/04/14/nvidia_analyst_day_-_biting_back_at_intel/4)

One software application that was shown off during the Analyst Day was RapiHD – a video encoder designed to run on the GPU using CUDA. Sam Blackman, CEO of Elemental Technologies, the company behind RapiHD, showed a GeForce 8800M GTS running an h.264 video encode completing around 10 times faster than a quad-core Intel CPU. The software will be available in August or September and will be price competitive with current video encoders – expect it to be around $50 US for the standard version.
...

Standard version = baseline profile?

[Inventive Software]

If the GPU can do 1080p encoding in real-time, that's a great step forward. If it can do High Profile 1080p encoding in real-time, that's the cue for me to upgrade. ;)

[CruNcher]

Eh i think it will be at least Main Profile up to Level 4 supported by then :) and for sure others will follow Dirac seems to be one of the Next Generation Codec's that also already has a GPU Decoder in the works (not only H.264) and for sure GPU Encoding is next (btw not Nvidia showed this first AMD did on Siggraph last year with Mpeg-2 720p Realtime Encoding on the Radeon sure H.264 is a higher level but from the key points not very different, the only barrier is the Bus transfer speed)
Looking @ the Blu-Ray Bitstream Decoding results (now even 2 streams @ once) and fft3dgpus amazing speed (Realtime 1080p on the G92) is just wow (also Nvidias Gelato GPU Rendering is already impressive).
But i think everything should be taken into account and also Power Consumption should be further investigated in the Future and compared to solutions like the Cell or Toshiba's new low power Cell solutions, it's easy to say hey our stuff does this and this but without knowing how efficiently it does it and which power it needs compared to a CPU/DSP/FPGA to achieve it is odd (and you never see those information in such slides). Tough it's also true that for the PC End consumer Cell and DSP's Play no real role yet and Nvidia and AMD are currently leading this on the PC platform, but other companies also support this kind of Encoding Accelleration in their H.264 Encoders via external DSP Hardware (like Mainconcept), but for the End consumer such solutions are very expensive compared to buying 1 card and do several things with it (not only Video Encoding).

PS: I think everyone here knows how hot ATI and Nvidias GPUs get (Energy waste) when they really work (100% utilization), and how loud the enviroment can become then ;)

[tre31]

the only barrier is the Bus transfer speed)

actually I think they will succeed in this respect as they have thought about it differently, instead of trying too do everything massively parallel, they instead tried multiple serial tasks, read the patio problem in the blog, very interesting.

Although they only have a baseline encoder now, they have (imho) the right methodology too go further with it - and lets all hope they do ;)

gpu video encoding was meant too happen...

[g_aleph_r]

correct me if I'm wrong: baseline profile should be more bandwidth sensitive than High profile:more frame to take care of and less intensive computation.
I hope they get good results(it would be enough for me that they reach the same speed of a 4core on a 8800gt), and I would be very happy if x264 follow soon!

[tre31]

# jesse Says:
April 23rd, 2008 at 8:16 am

Sorry for the late reply, but I’m still recovering from a very successful NAB show.

At the show we demonstrated main profile H.264 encoding at realtime (1440×1080) using an 8800GT or a Quadro 3700. High profile is not as big a delta to main as is to baseline. In other wods, high profile contains only a few more encoding tools compared to main profile and getting these implemented will not take long. The 8×8 transforms in high profile will get us the best “bang for the buck” as far as quality goes. We plan on releasing high profile sometime late this fall.

If you are curious about the profiles, the wikipedia (as usual) has a great description and comparison of Main vs Baseline, vs High, vs High422, etc.
http://en.wikipedia.org/wiki/H.264

Thanks for reading, and keep the questions coming!

[Dark Shikari]

The real questoin is whether they'll have it done before x264's is done ;)

[TEB]

Is CUDA open as in the Open Source community could do a x264 port to it ? Or is this far fetched as my dreams are ? ;)

[Dark Shikari]

Is CUDA open as in the Open Source community could do a x264 port to it ? Or is this far fetched as my dreams are ? ;)Yes, CUDA is open. And its being done, but not by the open source community; I have a copy of some prototype SAD code, but it won't be GPL'd until its done and ready.

[CruNcher]

Yes, CUDA is open. And its being done, but not by the open source community; I have a copy of some prototype SAD code, but it won't be GPL'd until its done and ready.

Yipeee yah yeah :D

[tre31]

Yes, CUDA is open. And its being done, but not by the open source community; I have a copy of some prototype SAD code, but it won't be GPL'd until its done and ready.

Nice, but is it only going too be for nvidia or will there be ati support as well (via AMD CAL and Brook+)?

Considering I am fan of ati for video based things (more stable dvb over longer periods, perhaps they solved the purevideo1 crashing dilemna with purevideo2, but dvb apps that I used with purevideo were very instable, sometimes causing whole system freeze, and no it wasn't the system, since I now have an ati HD2600XT and its better than ever) it would be awesome if you managed too do gfx accelerated encoding for ati hardware (within reason, probably only worth it on the recent cards that DO have the stream processors).

Anyway good too see x264 is looking towards utilising the power just idleing there.

[Dark Shikari]

Nice, but is it only going too be for nvidia or will there be ati support as well (via AMD CAL and Brook+)?

Considering I am fan of ati for video based things (more stable dvb over longer periods, perhaps they solved the purevideo1 crashing dilemna with purevideo2, but dvb apps that I used with purevideo were very instable, sometimes causing whole system freeze, and no it wasn't the system, since I now have an ati HD2600XT and its better than ever) it would be awesome if you managed too do gfx accelerated encoding for ati hardware (within reason, probably only worth it on the recent cards that DO have the stream processors).

Anyway good too see x264 is looking towards utilising the power just idleing there.It will be nVidia-only, unfortunately. Unless ATI decides to support CUDA ;)

[tre31]

It will be nVidia-only, unfortunately. Unless ATI decides to support CUDA ;)

Well hopefully once the code stabilizes and you get it out there (gotta love open source ;) ), another gpgpu genius with some CAL/Brook+ experience will pick up the slack, I have the libraries myself but have limited experience of the intensity that would be required too undertake a project of this magnitude.

I'm guessing the person(s) involved only have nvidia hardware and some experience with CUDA. Just browsing round various articles it doesn't seem like the differences are all that major - ie. the algorithm's involved being sent too the gpu would be pretty similar, its just the implementation that would differ. It might even be worth contacting AMD, they might be able too help - considering what a worthy project x264 is - and the good publicity it would ensure for their products, how could they resist?

Maybe possibility for future Google Summer of Code?

[Dark Shikari]

Well hopefully once the code stabilizes and you get it out there (gotta love open source ;) ), another gpgpu genius with some CAL/Brook+ experience will pick up the slack, I have the libraries myself but have limited experience of the intensity that would be required too undertake a project of this magnitude.

I'm guessing the person(s) involved only have nvidia hardware and some experience with CUDA. Just browsing round various articles it doesn't seem like the differences are all that major - ie. the algorithm's involved being sent too the gpu would be pretty similar, its just the implementation that would differ. It might even be worth contacting AMD, they might be able too help - considering what a worthy project x264 is - and the good publicity it would ensure for their products, how could they resist?

Maybe possibility for future Google Summer of Code?The main issue is that graphics card programming, especially with CUDA-like APIs, tends to have very specific idiosyncrasies that make it overly difficult in the first place and probably annoying to port.

We did have an application for GSOC to port the motion search to Closer To Metal, ATI's API, though we didn't have enough slots to accept it.

The reason its CUDA is because a certain someone is paying a very large amount of money so that they can make use of 8800GTs on a large number of realtime encoding servers :p

[tre31]

The main issue is that graphics card programming, especially with CUDA-like APIs, tends to have very specific idiosyncrasies that make it overly difficult in the first place and probably annoying to port.

We did have an application for GSOC to port the motion search to Closer To Metal, ATI's API, though we didn't have enough slots to accept it.

The reason its CUDA is because a certain someone is paying a very large amount of money so that they can make use of 8800GTs on a large number of realtime encoding servers :p

Well money talks ...
Also why I said actually contacting someone from AMD might be a good option, not only lately do they (even more so than the past) actively get behind open source, they would certainly be able help with porting the code, it is their hardware after all, and they should (well one would hope) know how too do what you want too do - they already made a MPEG-2 gpu encoder and showed it at a demo for their gpgpu technologies, so they would have worked out motion estimation algo's.

Anyway good luck with it all, if no amd I might have too get another video card, anything that gets more speed with x264 = a good thing, encoding HD dvb down too 720p x264 2-pass while looking stunning takes too long.

[CruNcher]

The reason its CUDA is because a certain someone is paying a very large amount of money so that they can make use of 8800GTs on a large number of "realtime" encoding "servers"
That said it all Avail keep on improving the Hell out of X264 as a Broadcast Codec it's worth it and don't hear @ the Analysts, once this is done and ready to be tested be sure many others and i'll be there :D

[kuka2]

If the GPU can do 1080p encoding in real-time, that's a great step forward. If it can do High Profile 1080p encoding in real-time, that's the cue for me to upgrade. ;)

In fact, you have no need in GPU to encode 1080. The latest AVC encoder from Elecard runs in real time full quality 1080i AVC High Profile encoding on Dual Quad Core Xeon 2.6 Ghz at 60-80% CPU usage.

[Dark Shikari]

In fact, you have no need in GPU to encode 1080. The latest AVC encoder from Elecard runs in real time full quality 1080i AVC High Profile encoding on Dual Quad Core Xeon 2.6 Ghz at 60-80% CPU usage.And x264 runs even faster; in my last test x264 beat Elecard by over 40% performance-wise at similar high-speed settings.

[kuka2]

Baseline 1080p with slightly limited features runs in realtime on a single QuadCore 2.6Ghz.
Just tested transcoding 1080p MPEG2 to AVC Baseline on Core 2 Duo notebook 1.83 GHz. 12 fps with "optimal" settings, 17.5 fps with "fastest speed" settings. "fastest speed" gives acceptable quality at 6 MBit VBR

[kuka2]

And x264 runs even faster; in my last test x264 beat Elecard by over 40% performance-wise at similar high-speed settings.

did you test Elecard G4 encoder?

[Dark Shikari]

did you test Elecard G4 encoder?I'm talking about the latest one from their site, Elecard Converter Studio HD Pro.

[kuka2]

I'm talking about the latest one from their site, Elecard Converter Studio HD Pro.

There is no G4 codecs in it. I tested with G4 in grapheditor.
You need to request CS 2.2, it comes with new engines, not sure if it already released.

[audyovydeo]

In fact, you have no need in GPU to encode 1080. The latest AVC encoder from Elecard runs in real time full quality 1080i AVC High Profile encoding on Dual Quad Core Xeon 2.6 Ghz at 60-80% CPU usage.


Dual Quad-Core Xeon is not the average joe's system. It's the kind of system I would buy if I had to encode 24x7. Which is the whole point of having GPU do some work on everyone's PCs (ie the still numerous monocores and the laptops which will be dual-core for some time to come).


cheers
audyovydeo

[RickA]

Greets,

Are they making these to work together - both CPU and vidcard crunching the data? Or is it gonna just be a one or the other kinda deal - just CPU or just vidcard crunching the data? I can see a nice advantage of a quad core and SLI rig all working together to crunch video data.

Cheers,
Rick

[audyovydeo]

Greets,

Are they making these to work together ... or is it gonna just be a one or the other kinda deal


hard to say : they don't say much as they haven't got any product out yet. Still, you gotta love the video clip on their page :

http://elementaltechnologies.com/how_it_works.php


They should put it on their front page to get maximum salivation from the anticipating crowds.

cheers
a/v

[deekey777]

Brief Badaboom product information (http://www.badaboomit.com/blog/?p=7)
Badaboom™

- Output video formats supported – H.264 (MP4) Baseline Profile

- Output audio formats – AAC

- Output resolutions supported – Standard definition(720×480p) and below, fixed GUI resolutions supported

Badaboom™ pro



Elemental Technologies’ Badaboom™ Media Converter takes a fundamentally different approach to video format conversion from other solutions. Instead of performing format conversion on the CPU, it harnesses massively parallel GPUs from NVIDIA. By using the power of the GPU, the time required for video conversion is reduced. As an added bonus, you can still use the CPU for normal everyday tasks such as email and internet browsing. Anyone can now painlessly convert video between formats including AVCHD, leaving more time to enjoy the video and eliminating the frustration of video conversion delays. The Badaboom™ pro Media Converter allows full customization of the conversion process and is designed for advanced users or users converting HD content.


- Output video formats – H.264 (MP4) baseline profile

- Output audio formats – AAC

- Output resolutions supported – High definition (1920×1080p) and below, user definable resolutions supported

[audyovydeo]

Brief Badaboom product information (http://www.badaboomit.com/blog/?p=7)

mmmh, months of anticipation, to get this :


> Output video formats – H.264 (MP4) baseline profile

??!!!

I'd understand making a free Baseline / Main profile encoder to hook people to buy the High profile one, but to make both products Baseline-only, and $$$€€€£££, seems equivalent to shooting oneself in each foot.

Curious, I'll keep watching this space.

cheers
a/v

[CruNcher]

looseing the cabac advantage for the Pro version is hard i could understand it for the AVG joe version (as most users gonna use it todo small screen transcoding (to ipods and other mobile devices) but the PRO version that's done for HD hmm i doubt that it will be competitive this way vs other especialy free (CPU) solutions, speed is not everything (and here you can't even talk about a balanced encoder it's totaly optimized for speed currently, ofcourse fits the marketing better) :P.
But even some Mobile Devices are more powerfull then what the Encoder offers here (especialy talking about the PSP wich allows seemles Mobile to TV watching experience in excelent Quality Main Profile Full SD) and you can make use of that Quality with X264 easily on not so expensive hardware in 2x realtime, it will be really interesting to see the ET Quality/Speed in comparision all the AVG joe tests that are out currently are made for Press Marketing usage and are mostly totaly useless (most of the guys that tested it tested it from a AVG joe standpoint wich is "click and go").
And seeing not 1 Guy from ET here on Doom9 (on this marketing run) says allready alot imho ;), but we will see the whole Picture very soon especialy as Cyberlinks solution is also almost ready to hit the Market (and for sure will support both GPUs ATI/Nvidia :)

[deekey777]

http://www.nvidia.com/content/forcewithin/us/download.asp

Because today is a big PhysX day, nVidia made the BadaBoom Converter 0.9 for everyone available. It's a 30 days & 30 convertions limited beta (0.9), but no other restrictions.

[Danisan]

Sweet! :thanks: I'll try it out.

They even have a Folding @ Home GPU client.

[deets]

i tried badaboom for PSP encoding. I would love to tell you how it compares to my own encodes, but sadly the file is utterly unwatchable! its running and skipping and doing all kinda of jazz and of course comes up unsupported on my psp. this was with 2 different avi files, ill try again in a bit with some other formats etc....

was getting about 130 fps on the conversion though, meaningless sadly until either me or they can get it fixed :(

[Atak_Snajpera]

was getting about 130 fps on the conversion though, meaningless sadly until either me or they can get it fixed
I have ~130fps (second pass) on Quad-Core 3Ghz (480x272) He he he he

[CruNcher]

Hey they even made 2 new Tech Demo (or their Partners) i think they wana go against the Cinema 2.0 Demo of ATI that should be around the corner of being released interesting :)

PS: Lol ok no new Official Demo only 3rd Party Demos to show off Physix and 2 Physix Teams old Demos nothing new, so still Medusa has to go against the Cinema 2.0 Demo that'll be a easy win for ATI then :P

BTW: Elemental Technologies has a user Forum now @ http://www.badaboomit.com/?q=forum i hope to see alot of the Doom9 users there, so they can't hide anymore from X264, btw the first thing i saw @ installation was it seems to use ffmpeg on the Decoding side of things ;)

And this is really a good thing it seems they allready found some ffmpeg bugs and for sure they are "forced" now to contribute to it, could be a nice win for ffmpeg (stability) :)


Audio and synchronization problems with some wmv and flash files
Aspect ratio problems with some wmv and flash files

[foxyshadis]

And this is really a good thing it seems they allready found some ffmpeg bugs and for sure they are "forced" now to contribute to it, could be a nice win for ffmpeg (stability) :)

Unless they just used a 3 year old ffmpeg version, as some companies seem to do.

[leiming2006]

Pentium T2390 + nVidia 8400M GS
test clip: anime new power MTV DVD
size: resized to 640x480
CQ,quality Medium
key frame: auto
GPU temperature during encoding: 76
CPU usage during encoding: about 35%
encoding speed: 12.1fps

[Dark Shikari]

I don't have a supporting card, but someone who did tried to encode Touhou with it. the result is, at 1.5 megabits...

http://xs230.xs.to/xs230/08332/snapshot20080813041154710.png

Worse than MPEG-2, by a wide margin :p

[CruNcher]

Yes Dark but how does X264 under these restrictions it seems they use no partitions no b-frames it's really plain Baseline, also it seems tough im not yet 100% sure about this to use H.264 domain transcoding (it accepts raw bitstreams) or they accellerate H.264 also @ Decoding (would make sense wouldn't it?).
It cant be that the PC can only decode a H.264 file @ 15 fps (1080p->720p) fps with ffmpegsource and they encode the whole thing @ 36 fps even useing the fastest resizer on earth cant be the cause for this (tough maybe they do it also on the GPU) :)

[leiming2006]

I have tried nearly the same settings as that one on x264, the result is that x264 is faster than it. (one thread)

[Dark Shikari]

Yes Dark but how does X264 under these restrictions it seems they use no partitions no b-frames it's really plain BaselineStill doesn't excuse being much worse than MPEG-2.

[Dark Shikari]

Anaylsis of Baseline encoder, thanks to a stream from Cruncher:

1. No partitions in P-macroblocks. At all. p16x16 only. This seems rather silly given that this thing is marketed as, among other things, an iPod encoder...

2. Pyramidal motion search; the motion in some frames can be distinct inly divided into 16x16 groups of macroblocks, 8x8, 4x4, 2x2, etc.

3. No row-based ratecontrol: I'm not sure how much this impacts VBV. If they had lookahead, this wouldn't be a huge problem, but...

4. Their ratecontrol is completely broken. In static scenes, it will suffer the "waving quantizer effect," where it has a couple huge frames, then a bunch of tiny ones, then a couple huge, etc, repeated continuously until the scene ends. Obviously, this drastically changing quality looks awful visually.

5. No adaptive quantization; I doubt they have any psy-opts at all.

6. I'm going to guess that they do have DCT decimation of some sort, as empty 8x8 CBPs seem to be slightly biased in favor of.

7. No scenecut detection whatsoever.

8. I suspect that they don't have any fast-pskip; this makes some sense, I guess, given that its a graphics card implementation.

9. Their motion search is slightly bugged; in a letterboxed video with a completely black top section, you'll find motion vectors that are purely horizontal. This reminds me of an old bug in the a certain encoder, way back, which omitted checking the predicted motion vector when doing a diamond search, and only searched away from it, resulting in cascading motion vectors pointing in the right horizontal direction. In this case, it could be caused by the pyramidal motion search catching motion from below the letterboxing during the higher-level searches, and carrying it down to the lower-level searches.

10. There is almost surely no RDO in this encoder. In fact, I get an itchy feeling they're using SAD for mode decision, though I can't be sure.

The overall quality, ignoring cases where the ratecontrol decides to bork, is somewhat comparable to x264 on absolute fastest Baseline Profile settings with AQ and all psy-opts off.

[Sulik]

I have tried nearly the same settings as that one on x264, the result is that x264 is faster than it. (one thread)

A 8400GS may not be the ideal GPU to beat speed records with :)
Anyone has perf data with a decent GPU (8800GT) ?

[shon3i]

I just tested on 9600GT Sonic, input VC-1 MKV (1080p extracted from HDDVD), during encode i have constant 20fps, output iz Baseline @ 4.0 with 1920x1080, quality: total disaster.

EDIT: and look this :D

http://www.youtube.com/watch?v=8C_Pj1Ep4nw

[beldoy]

Hi all,

I have done a search and have found that some nvidia geforce graphics cards support this feature. However I have a laptop with an ati one in it and cannot seem to find any info as to if ati's gpu supports encoding.

I guess no info means its not supported.

Anyone know if ati gpu encoding of x264 is supported?

Thanks...

[Atak_Snajpera]

Forget about GPU encoding! Quality is shitty. You'd better buy fast quad-core and use excellent x264 encoder!

[CruNcher]

You don't even need a Quadcore for it my Dualcore AMD 64 (2.2 GhZ) beats my 8800 GT (1.7 GhZ Shader Clock) with X264 (720p) :D
The Encoder has some major performance plus the biggest one would be it accellerates H.264 @ Decoding that way it's much faster then any Software Decoder when Transcoding H.264 Streams directly tough that doesn't change it's quality differential X264 ABR/CRF mode both beat it easily especialy stability wise and in low bitrate conditions.

[Comatose]

Oh wow. That's pretty disappointing. I was expecting it to be at least OK, but it looks like this will have to fall in with the rest of the encoders that are vastly inferior to x264.