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.

[leiming2006]

If there is an encoder making use of both GPU and CPU during encoding...

[deekey777]

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.

But what is the weak point? Is it the GPU (features, which you mentioned, cannot run on GPUs) or their h.264 encoder?

I did compare Badaboom with Nero Record*: Badaboom was on my 8600GT (540/400 MHz) with 35 fps faster than Nero Record on X2 3600+ (2,0 GHz) with 28 fps, but the quality wasn't great.


(First ten minutes of "Serenity" (DVD), 840 kbit/s, iPhoneAVC profile with 640x360, Baseline@L3.1, 1 reference frame; good quality for Nero's encoder)

[Dark Shikari]

But what is the weak point? Is it the GPU (features, which you mentioned, cannot run on GPUs) or their h.264 encoder?I'd say its primarily the encoder itself. They could do a lot better despite being on a GPU.

[edison]

I don't have a supporting card, but someone who did tried to encode Touhou with it. the result is, at 1.5 megabits...
Worse than MPEG-2, by a wide margin :p

does your friend use a very low quality video source to do such encode ?

I had tried the badaboom 0.9 that download from NVIDIA.com, its qulity much better than yours.

http://www.pcinlife.com/ours/edison/badaboom_0.9_1500kbps.png

http://www.pcinlife.com/ours/edison/[1080I] HD Forum Demo.mp-Apple TV.mp4

[shon3i]

OK here is small but deep test.

Source (Terminator 2 BluRay 1080p24)

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/o1.png)

x264 High: avg 1.5fps on AMD Athlon X2 5000+, size 90mb

--pass 2 --bitrate 3521 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --me tesa --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd --b-adapt 2 --ipratio 1.10 --pbratio 1.10

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/s1.png)

x264 Baseline: avg 12fps on AMD Athlon X2 5000+, size 90mb
--pass 2 --bitrate 3521 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 4 --mixed-refs --no-fast-pskip --filter -3,-3 --no-cabac --subme 1 --partitions none --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --me dia --merange 8 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd --b-adapt 2 --ipratio 1.10 --pbratio 1.10

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/s2.png)

Badaboom: avg 14fps on Nvidia Geforce 9600GT, size 128mb, all to best/auto settings

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/e1.png)

Enjoy

If someone need i can upload short samples.

[deekey777]

I'd say its primarily the encoder itself. They could do a lot better despite being on a GPU.

So there is hope that Cyberlink do a better job for their GPU accelerated encoder?
:)

[Dark Shikari]

does your friend use a very low quality video source to do such encode ?

I had tried the badaboom 0.9 that download from NVIDIA.com, its qulity much better than yours.The Touhou source is lossless and available on my website (http://mirror05.x264.nl/Dark/force.php?file=./LosslessTouhou.mkv).

Sure, its rather easy to have tolerable quality if you throw loads of bits at something.--pass 2 --bitrate 3521 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 4 --mixed-refs --no-fast-pskip --filter -3,-3 --no-cabac --subme 1 --partitions none --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --me dia --merange 8 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd --b-adapt 2 --ipratio 1.10 --pbratio 1.10Those are... really... bizarre settings...

[shon3i]

Those are... really... bizarre settings...Yes, but x264 still have better quality (more grain, more sharpness, more details, and even smaler output file) than Badaboom, and almost same speed.

[CruNcher]

OK here is small but deep test.

Source (Terminator 2 BluRay 1080p24)

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/o1.png)

x264 High: avg 1.5fps on AMD Athlon X2 5000+, size 90mb

--pass 2 --bitrate 3521 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-rdo --bime --weightb --direct auto --filter -3,-3 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --me tesa --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd --b-adapt 2 --ipratio 1.10 --pbratio 1.10

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/s1.png)

x264 Baseline: avg 12fps on AMD Athlon X2 5000+, size 90mb
--pass 2 --bitrate 3521 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 4 --mixed-refs --no-fast-pskip --filter -3,-3 --no-cabac --subme 1 --partitions none --vbv-bufsize 30000 --vbv-maxrate 40000 --qcomp 0.5 --me dia --merange 8 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd --b-adapt 2 --ipratio 1.10 --pbratio 1.10

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/s2.png)

Badaboom: avg 14fps on Nvidia Geforce 9600GT, size 128mb, all to best/auto settings

Screenshoot (http://tom.niko.users.sbb.co.yu/T2/e1.png)

Enjoy

If someone need i can upload short samples.

You comparing 1 pass with 2 pass here that's not a fair Speed/Quality comparision in this case.

[edison]

The Touhou source is lossless and available on my website (http://mirror05.x264.nl/Dark/force.php?file=./LosslessTouhou.mkv).

Sure, its rather easy to have tolerable quality if you throw loads of bits at something.Those are... really... bizarre settings...

This video can not be correctly decode by the NVIDIA VP2 decoder that I think the Badaboom use it for the h264 video decode ( AFAIK, the CUDA 2 have VP2 processor support through a API ).

So, I think your example is more like a compatibility problem than a quality problem.

[Dark Shikari]

This video can not be correctly decode by the NVIDIA VP2 decoder that I think the Badaboom use it for the h264 video decode ( AFAIK, the CUDA 2 have VP2 processor support through a API ).

So, I think your example is more like a compatibility problem than a quality problem.No... unrelated. You can decode it first and put it into the encoder however you want; if your decoder doesn't support H.264 lossless mode, that isn't my problem, nor is it Badaboom's problem, since Badaboom is an encoder.

[Sharktooth]

encoders on GPU implementations... they're crap since they're at the beginning. they will need some years to become decent.
in the meanwhile enjoy x264...

[CruNcher]

Another not so funny thing

i put in this Video: HFYU 640x480 60.00fps [Stream 00]
and ETI gave me this Video: MPEG4 Video (H264) 640x480 29.96fps [ETI ISO Video Media Handler] (the motion is decimated)
also the Speed is just disapointing 55.4 FPS with Badaboom and here is the X264 speed encoded 1568 frames, 98.67 fps, 1541.59 kb/s (with the fps decimation useing avisynth changefps 70 fps)

So speedwise it can't really live up to the hype (not with non H.264,Mpeg-2, or VC-1 SD content at least) it becomes more and more efficient when going higher bitrate and higher res useing the Accelerated Video Decoding only there it can beat current X264 Frameworks Speedwise (keep in mind speedwise not quality yet), because of the Drawbacks of Software Decoding but the Speed itself doesn't really comes from the Hardware Encoding @ all.

Tough the Picture Dark showed first of the guy that did the Touhou test is an absolutely wrong subjective interpretation of the encoder (if he didn't used the same exact restrictions) it isn't that bad as Mpeg-2 quality if you set the keyframe interval to the same X264 interval (250) it looks very much compareable visualy to X264 (tough the problems Dark described still exist and don't go away in any case. It seems still heavily bugged (might be ffmpeg input problems) and im sure the ETI guys will have alot of fun fixing all these anoying stuff (it kills frames, it decimates framerate).
It's very hard to compare it when alot of source ways doesn't work or show extreme problems, very buggy this whole thing (talking about the whole application not the encoder core alone).

[crypto]

Another not so funny thing

i put in this Video: HFYU 640x480 60.00fps [Stream 00]
and ETI gave me this Video: MPEG4 Video (H264) 640x480 29.96fps [ETI ISO Video Media Handler] (the motion is decimated)...
It seems you did you leave "3:2 film-mode detect" at Auto.

[CruNcher]

Nope i turned it off :)
i knew this could cause trouble and turned it off before encoding, but it caused trouble anyway (tough it could be also possible that it isn't supporting more then 30fps anyways, especialy in these Level restrictions it would make sense) :)
It still eats frames in the beginning also with this test sample exactly 10 frames go lost all the time (this is really beta) (i guess they didn't test to much with uncompressed huffyuv .avi) wich doesn't suprise as their target is .vob (dvd) and .wmv but i allready found a .wmv problem also wich causes unsync results as i said they will have alot of fun :)
Also seeing that Darks lossless sample is played back fine with FFplay but fails with Badaboom suggests that ffmpeg is either outdated or the way they implement it doesn't work quiet right yet (also for some vfr .wmv that need timecodes being copied or endup with the wrong frame count, result is unsync audio).

Another not so funny thing

also the Speed is just disapointing 55.4 FPS with Badaboom and here is the X264 speed encoded 1568 frames, 98.67 fps, 1541.59 kb/s (with the fps decimation useing avisynth changefps 70 fps)

I have to correct this (dunno why the other badaboom reading was wrong maybe some IO access @ encoding occured from another programm) the speed is almost equal 96.1 Fps Badaboom (tough 10 fps gone defenetly lost) vs 98.67 (no decimation 60 fps) and 70 (with the decimation to 30 fps via avisynth changefps) (Dual Core)

WMV VC-1 Main @ 720p (29.97) 3 mbit->2.5 mbit = 40 fps vs 37 fps (here X264 over the Avisynth framework is slower useing ffdshow as VC-1 Decoder) (10 frames missing with Badaboom again)
Mpeg-2 Main@High @ 1080p (23.976) 22 mbit->3 mbit = 19 fps vs 19 fps (X264 over the Avisynth framework useing ffmpegsource as Mpeg-2 Decoder) (10 frames missing with Badaboom again)


PS: Nope also @ Level 3.1 wich states 720x576@66.7 as maximum it decimates to 30 fps so i guess it's a hardware limitation (no more then 30 fps) or a parser bug, the 10 frames lose seems to be some generic bug

[Dark Eiri]

Just tried Badaboom in PSP format. 58 fps average (8600GT), probably the worst quality I've ever seen. 600kbps looks worse than youtube, even though x264 makes it look impecable (and encodes it about 3x faster, too).

[deekey777]

Badaboom: A Full Test of Elemental's GPU Accelerated H.264 Transcoder (http://www.anandtech.com/video/showdoc.aspx?i=3374)@Anandtech
Image Quality (http://www.anandtech.com/video/showdoc.aspx?i=3374&p=4)

The Badaboom output quality is definitely lower than what x264 was able to produce, but it's close enough for our purposes. Since Badaboom can't really deal with Blu-ray content right now preserving maximum quality isn't a top priority for the application, thus the outputted video is close enough to what x264 was able to produce. Let it be very clear though: in motion the x264 codec did output a superior image.

-------------------------
Final words:
I want a CUDA enabled version of x264 or of the MainConcept H.264 encoder. While it's admirable that companies like Elemental would attempt their own codec and front end, there are better alternatives out there today
There's clearly potential for GPU-accelerated H.264 video encoding, but the first attempt was honestly a bust. Let's hope Elemental or someone else gets it right for round

[shon3i]

Point is:

GPU based baseline encoder is now totaly usless, since everyone now have some dual core processor, and any CPU based encoder in baseline mode can do better job, faster job....

[CruNcher]

Badaboom: A Full Test of Elemental's GPU Accelerated H.264 Transcoder (http://www.anandtech.com/video/showdoc.aspx?i=3374)@Anandtech
Image Quality (http://www.anandtech.com/video/showdoc.aspx?i=3374&p=4)



-------------------------
Final words:

The Anandtech test here can be questioned no info what settings he compared against and also the Energy test becomes questionable then, the whole thing imho falls together, because he doesn't release the X264 settings he used (and VBV restrictions). The only thing i can agree on in his test is the actuall CPU usage of the Badaboom Encoder itself that is around 30% extra and 70% is offloaded to the GPU.

[Shinigami-Sama]

I want a CUDA enabled version of x264 or of the MainConcept H.264 encoder. While it's admirable that companies like Elemental would attempt their own codec and front end, there are better alternatives out there today
There's clearly potential for GPU-accelerated H.264 video encoding, but the first attempt was honestly a bust. Let's hope Elemental or someone else gets it right for round

obviously they don't follow x264 very well

maybe dark or loren should send them an invoice for how much it'd take to make CUDA worthwhile ;)

[Caroliano]

He realised his settings:
compared encode quality on a single-pass of the x264 codec to the output from Badaboom using a couple of settings (5Mbps Xbox 360 profile and 1.5Mbps iPhone profile).
For the handbreak presets: http://trac.handbrake.fr/wiki/BuiltInPresets

They used too slow presets. Acording to this site, the Iphone profile that they used is 4 times slower than the Blind profile.

[MfA]

encoders on GPU implementations... they're crap since they're at the beginning. they will need some years to become decent.
I dunno. GPU coders could perhaps be competetive at ultra-high quality settings, exhaustive/iterative searches for optimum coding parameters suit the GPU. Most of the time you will be skipping encoding steps left and right though, all the various skip mechanisms make the code irregular ... also there is a distinct lack of parallelism in encoding. Slice, frame or GOP level parallelization still work ... but that's only really suited for a couple of cores and clusters, it doesn't really do it for GPUs.

The algorithms for encoding just aren't as regular or parallel as 3D rendering.

That said, I think they could do well at pre-pass ME (a multiresolution search followed by iterative refinement would suit the GPU).

[Ranguvar]

I'd love to be able to offload some of the work my CPU does in --me tesa --merange 32 to the GPU, even if it maxes it out and helps only a little :) Any quick'n'dirty patches to x264 to do that would be welcome, though I don't know how "quick'n'dirty" it can be.

[Sharktooth]

not much quick and dirty...

[Dark Shikari]

I'd love to be able to offload some of the work my CPU does in --me tesa --merange 32 to the GPU, even if it maxes it out and helps only a little :) Any quick'n'dirty patches to x264 to do that would be welcome, though I don't know how "quick'n'dirty" it can be.If by "quick" you mean a couple months, and "dirty" you mean a couple dozen thousand euros...

[7oby]

Anand has an update on the Badaboom Test:
http://www.anandtech.com/video/showdoc.aspx?i=3374&p=1

Someone should have given him comparable x264 settings regarding quality. Actually which encoding settings come closest to badaboom? Or if there are settings which don't have an negative impact on encoding speed, but improve quality compared to badaboom, which are those?

[CruNcher]

The fastest settings for X264 will do fine you can even disable scenecut and adaptive b-frames and will be faster most probably then Etis Encoder then but still have better visual quality :D

[CruNcher]

ETIs Badaboom Encoder has been released in Beta2


Test Machine: (Amd 939 Platform ULI Chipset)
Amd Athlon 64 X2 4200+ (Toledo 2.2 GHz upto 2.8 GHz Possible)
Ram 1 GB Gskill (Running @ 200 MHz upto 250 MHz Possible)
Geforce 8800 GT (G92) MSI (Shader Overclock to 1674 MHz)


GPU 0: NVIDIA GeForce 8800 GT
GeForce 8800 GT GPU selected
Num Multi Proc : 14
Clock rate : 1674000
FATAL:FATAL:Source file's video codec (HUFFYUV)is currently not supported. Please check back for updates.
CPU Logical Processors Detected: 2
CPU Cores per processor: 1
CPU Processors Detected: 2
Transcoding...
Decoding H.264 1920x1080 4:2:0 @23.98 FPS (32 Mbit Max)...
Encoding H.264 1280x720 4:2:0 @23.98 FPS (3 Mbit Max)...

/////////////////////////////////////////////////////////////////
Frames 1563
Total sec 44.24
Frames/sec 35.33
/////////////////////////////////////////////////////////////////


Alot of input formats have been removed (most probably due to being bugy)

Result: Stream ETI (Custom Mediacenter Profile)

real max : 6 298 800
real avg : 3 103 000
real min : 1 292 200

Result Stream X264 (Avisynth Framework Decoding CoreAVC)

real max : 3 918 610
real avg : 2 055 409
real min : 373 867


x264j.exe island.avs --bitrate 2100 --subme 1 --partition i4x4 --keyint 120 --aq-strength 0 --me dia --vbv-maxrate 14000 --no-cabac --vbv-bufsize 2100 --sar 1:1 --no-dct-decimate --threads auto --level 3.1 --no-b-adapt --scenecut -1 --progress -o x264-baseline.264

avis [info]: 1280x720 @ 23.98 fps (2253 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:19 Avg QP:18.26 size: 52548 PSNR Mean Y:48.10 U:51.78
V:52.02 Avg:49.01 Global:48.05
x264 [info]: slice P:2234 Avg QP:20.99 size: 10359 PSNR Mean Y:46.45 U:51.05
V:51.07 Avg:47.48 Global:46.35
x264 [info]: mb I I16..4: 65.2% 0.0% 34.8%
x264 [info]: mb P I16..4: 10.6% 0.0% 3.5% P16..4: 23.5% 0.0% 0.0% 0.0% 0
.0% skip:62.3%
x264 [info]: final ratefactor: 23.24
x264 [info]: SSIM Mean Y:0.9811946
x264 [info]: PSNR Mean Y:46.467 U:51.056 V:51.073 Avg:47.498 Global:46.366 kb/s:
2055.13

encoded 2253 frames, 22.07 fps, 2055.23 kb/s


X264 HD Stream = http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/x264-baseline.264
ETI HD Stream = http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/Eti-Beta2.264


SD test: (Anamorphic no Resizing VOB input no 10 frames killing)

ETI:


CPU Logical Processors Detected: 2
CPU Cores per processor: 1
CPU Processors Detected: 2
Transcoding...
Decoding MPEG2 720x576 4:2:0 @25.00 FPS (10 Mbit Max)...
Encoding RAW 280x194 4:4:4 @25.00 FPS (3 Mbit Max)...

/////////////////////////////////////////////////////////////////
Frames 98 <--------- For what is this short Pre run here ??? (it happens hidden from the user on opening)
Total sec 0.57
Frames/sec 173.00
/////////////////////////////////////////////////////////////////
CPU Logical Processors Detected: 2
CPU Cores per processor: 1
CPU Processors Detected: 2
Transcoding...
Decoding MPEG2 720x576 4:2:0 @25.00 FPS (10 Mbit Max)...
Encoding H.264 720x576 4:2:0 @25.00 FPS (3 Mbit Max)...

/////////////////////////////////////////////////////////////////
Frames 3519
Total sec 44.85
Frames/sec 78.47
/////////////////////////////////////////////////////////////////



X264: (Avisynth Decoder ffmpegsource)

x264j.exe island.avs --bitrate 2100 --subme 1 --partition i4x4 --keyint 120 --aq-strength 0 --me dia --vbv-maxrate 14000 --no-cabac --vbv-bufsize 2100 --sar 64:45 --no-dct-decimate --threads auto --level 3.1 --no- b-adapt --scenecut -1 --progress -o x264--sd-baseline.264

avis [info]: 720x576 @ 25.00 fps (3521 frames)
x264 [info]: using SAR=64/45
x264 [info]: using cpu capabilities: MMX2 SSE2Slow
x264 [info]: slice I:30 Avg QP:23.07 size: 32073 PSNR Mean Y:45.83 U:49.90
V:50.14 Avg:46.34 Global:43.43
x264 [info]: slice P:3491 Avg QP:26.27 size: 10041 PSNR Mean Y:43.21 U:46.67
V:47.11 Avg:43.82 Global:40.76
x264 [info]: mb I I16..4: 44.3% 0.0% 55.7%
x264 [info]: mb P I16..4: 13.0% 0.0% 11.3% P16..4: 35.8% 0.0% 0.0% 0.0% 0
.0% skip:39.9%
x264 [info]: final ratefactor: 25.29
x264 [info]: SSIM Mean Y:0.9683692
x264 [info]: PSNR Mean Y:43.228 U:46.695 V:47.133 Avg:43.844 Global:40.773 kb/s:
2045.77

encoded 3521 frames, 69.42 fps, 2045.87 kb/s

X264 PAL/SD Stream = http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/x264-sd-baseline.264
ETI PAL/SD = http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/ETI-sd-beta2.264


As you can see ETIs Encoder Major Advantage is the GPU based Framework with Accelleration/Resizing of the Decoding (with Huffyuv as input that doesn't work anymore it would look the same speedwise, see Previous Beta1 Results with Huffyuv Input).


Final Speed Result (whole Framework measureing):

X264 720p = 22.07 fps
X264 SD = 69.42 fps
ETI 720p = 35.33 fps
ETI SD = 78.47 fps

PS: There is still the 10 Frame Lose Problem exisitng in Etis Encoder (it just kills the 10 first frames whyever for some sources), and im not quiet sure what for a Resizing Algorithm ETI is useing seems to be LanczosResize if that's the case then the X264 HD Encode would have been alot slower (like 19 fps). You also see that it's entirely optimized for 1 Purpose DVD-> Mobile Device Encoding all other stuff hasn't been efficiently tested. With --partition none for X264 the Speed is identical (see last Beta1 results) tough that would be cheating as ETIs Encoder does at least uses i4x4.

Here is a frame comparision screenshot, takeing this is allways a horrible disaster because of frame seeking problems so the Source Frame has no OSD sorry (ffdshow allways jumped to a i frame :( )


Source (Mpeg-2 P frame Quant 12.39)
http://s2.directupload.net/images/080901/rcximwpw.png

ETI (see OSD)
http://s5.directupload.net/images/080901/hxsr7dsf.png

X264 (see OSD)
http://s3.directupload.net/images/080901/tnncbums.png

Suming it up:

Keep in mind this is a Baseline Comparision ETI says it has working Main Profile ready in the Final Pro Version. From the Visual results you get @ this bitrate here it's really hard to say that one is better then the other also Speedwise i would say it's almost a Draw for this PC Configuration. X264 would Perform better on more recent Cpu Architectures (like Core2 Duo,Quadcore) :)
newer GPU Generations then mine tough could also higher the ETI Speed so it's hard to predict anything (Price wise it's also hard i mean Quadcores get Cheaper and GPUs also).
Energy wise it's a good Question and a CPU approach sounds more economical here currently (despite what Anandtech claims, their speed analysis is pure missinformation currently), tough also GPUs are constantly lowered in Energy requirements so again it needs to be seen how that evolves in the future and also compared with other GPU solutions.
For the first Generation of a GPU Encoder ETI tough did a great Job imho and Cyberlink has to show now what they are capable of :)

[notthatwillsmith]

I'm trying to do apples to apples benchmarks between the Elemental encoder and X264 (using the Handbrake implementation, since that's what I think most end users are actually using.

If I manually specify the command line you used here: --bitrate 2100 --subme 1 --partition i4x4 --keyint 120 --aq-strength 0 --me dia --vbv-maxrate 14000 --no-cabac --vbv-bufsize 2100 --sar 64:45 --no-dct-decimate --threads auto --level 3.1 --no- b-adapt --scenecut -1 --progress -o x264--sd-baseline.264 does that generate a relatively fair, apples-to-apples encode process that I can use to more or less measure results?

[Dark Shikari]

I'm trying to do apples to apples benchmarks between the Elemental encoder and X264 (using the Handbrake implementation, since that's what I think most end users are actually using.

If I manually specify the command line you used here: --bitrate 2100 --subme 1 --partition i4x4 --keyint 120 --aq-strength 0 --me dia --vbv-maxrate 14000 --no-cabac --vbv-bufsize 2100 --sar 64:45 --no-dct-decimate --threads auto --level 3.1 --no- b-adapt --scenecut -1 --progress -o x264--sd-baseline.264 does that generate a relatively fair, apples-to-apples encode process that I can use to more or less measure results?If you're trying to compare speed, sure, but you can do much better quality-wise without significant speed loss. Don't compare quality with such a commandline.

[notthatwillsmith]

The quick and dirty prelim tests (using both apps PS3 presets) showed that they both took about the same length of time to do a full encode of a feature-length DVD ripped to my hard drive (Elemental was 3 minutes faster on a 40 minute encode). However, X264 (Handbrake) was using high profile, while Elemental was using baseline, but scaling the movie up to 720p, for no reason I could tell. It wasn't a fair comparison for a lot of reasons.

What I'd like to do is setup a fair speed comparison, while simultaneously showing the quality differences in a separate run using default settings from Handbrake.

Basically, I want to make sure that my tests don't include the errors that Anandtech's did.

[Sharktooth]

then you shouldnt use default settings but comparable settings between the encoders or settings that will produce the same quality at the same filesize/bitrate (harder).

[notthatwillsmith]

That's true. The problem is that I'm the videocard expert, not the video codec expert. I don't know enough about the different codecs and the vagaries of the implementation of X264 at the command line to know how to setup Handbrake to run to mimic Elemental.

[Dark Shikari]

That's true. The problem is that I'm the videocard expert, not the video codec expert. I don't know enough about the different codecs and the vagaries of the implementation of X264 at the command line to know how to setup Handbrake to run to mimic Elemental.The settings given earlier are similar to that which I suspect Elemental's encoder uses; SAD mode decision, DIA (technically pyramidal, but x264 doesn't support that) motion search, no subpartitions, i4x4 and i16x16 intra modes only.

[notthatwillsmith]

Thanks everyone for your help so far. I dumped the following query into the Advanced H.264 options section of Handbrake (PC) and am seeing what happens now.

subme=1:partitions=i4x4:keyint=120:aq-strength=0:me=dia:vbv-maxrate=14000:no-cabac:vbf-bufsize=2100:no-dct-decimate:level=3.1:no-b-adapt:scenecut=1:progress

[Dark Shikari]

Thanks everyone for your help so far. I dumped the following query into the Advanced H.264 options section of Handbrake (PC) and am seeing what happens now.If possible, update to the latest x264, since there were some rather significant speed improvements for subme1 added recently.

[notthatwillsmith]

I'm using .92 of Handbrake for Windows, which is based on a pretty old version of X264, I think. Unfortunately, I think for the audience that this BadaBoom app is targeting (the DVD archival crowd) that's a more real-world benchmark. The number of people willing to tackle the command line is pretty small I'd think.

That said, after I get results that I'm fairly confident in with Handbrake .92, I'll download the nightly of Handbrake and the most recent version of X264 and try them for both the speed and quality settings. If you were doing a best quality/speed balance for X264, what would you use?

Interestingly, I'm about 10 minutes into the test now, and it doesn't seem that much faster than the default PS3 profile was. I'm doing 42fps average on a stock clocked Q6600, which seems a little slow.

[Dark Shikari]

I'm using .92 of Handbrake for Windows, which is based on a pretty old version of X264, I think. Unfortunately, I think for the audience that this BadaBoom app is targeting (the DVD archival crowd) that's a more real-world benchmark. The number of people willing to tackle the command line is pretty small I'd think. There are loads of other x264 GUIs; I'd say for example AutoMKV is surely more popular than Handbrake.Interestingly, I'm about 10 minutes into the test now, and it doesn't seem that much faster than the default PS3 profile was. I'm doing 42fps average on a stock clocked Q6600, which seems a little slow.It sounds like you might be input-bottlenecked, or maybe not using threads?

[notthatwillsmith]

I'm rerunning now, and it seems much faster. The query that I ran had level=40 in there, somehow, so that would have mucked things up pretty bad. It's averaging about 130fps at 20%, so it's a pretty big difference.

I'm not that familiar with AutoMKV, but I'll look at it again. I used Handbrake for benchmarking because it's self-contained and there aren't any external app dependencies, which could muck up my test. There's something to be said for an idiot-proof utility that lets me queue up a bunch of discs to encode overnight, which will then play on damn near everything.

[audyovydeo]

... I used Handbrake for benchmarking because it's self-contained and there aren't any external app dependencies, which could muck up my test....


Hello Dark Shikari

can't we come up with a cmdline with exactly the needed settings to do the baseline-to-apples comparison notthatwillsmith is doing ?

Would this do ?

[ ratecontrol mode ] -r 1 --me dia --subme 1 -t 0 --direct auto --keyint 120 --aq-strength 0 --vbv-maxrate=14000 --no-cabac--vbf-bufsize=2100 --no-fast-pskip --no-dct-decimate --no-b-adapt --progress --threads auto --no-psnr [ input / output options ]

?

also I assume he means --aq-mode 0 not --aq-strength 0.

My nvidia can't run badaboom, else I'd also tested myself.

cheers
audyovydeo

[Dark Shikari]

[ ratecontrol mode ] -r 1 --me dia --subme 1 -t 0 --direct auto --keyint 120 --aq-strength 0 --vbv-maxrate=14000 --no-cabac--vbf-bufsize=2100 --no-fast-pskip --no-dct-decimate --no-b-adapt --progress --threads auto --no-psnr [ input / output options ]--no-fast-pskip is stupid, that makes it slower. --no-b-adapt is unnecessary, as is -t 0. --no-ssim is missing. --direct auto should be removed. Missing --scenecut -1.

also I assume he means --aq-mode 0 not --aq-strength 0.They're the same thing.

[notthatwillsmith]

I just wanted to thank everyone for their help. The article's live @ http://www.maximumpc.com/article/features/is_era_gpubased_computing_really_upon_us if anyone's interested in my results.

[fields_g]

I just wanted to thank everyone for their help. The article's live @ http://www.maximumpc.com/article/features/is_era_gpubased_computing_really_upon_us if anyone's interested in my results.

Did you really compare it to the x264 version that is in Handbrake 0.9.2? Is there a way to convince you to update the article with a newer version?

Edit: I honestly do appreciate that you were willing to do these tests.

[CruNcher]

It's more true then Anandtechs test though it misses Power Consumption comparision CPU vs GPU you could have added that (according to Anandtechs Measurements http://www.anandtech.com/video/showdoc.aspx?i=3374&p=6) under these speed results the power draw of the entire System useing the GPU and CUDA would have been absolutely uneconomical currently vs the used Quadcore Intel CPU in your test.

[notthatwillsmith]

It's more true then Anandtechs test though it misses Power Consumption comparision CPU vs GPU you could have added that (according to Anandtechs Measurements http://www.anandtech.com/video/showdoc.aspx?i=3374&p=6) under these speed results the power draw of the entire System useing the GPU and CUDA would have been absolutely uneconomical currently vs the used Quadcore Intel CPU in your test.

Do you guys really think power consumption is that important though? I don't think anyone's doing this sort of thing on mobile machines, and certainly not when they're under battery.

Did you really compare it to the x264 version that is in Handbrake 0.9.2? Is there a way to convince you to update the article with a newer version?

Edit: I honestly do appreciate that you were willing to do these tests.

I would definitely add another page with current X264 numbers (although probably not IQ framegrabs), but I ran out of time to test for this story. If someone can help me convert the Handbrake queryies that are posted in the article to X264 command lines, I'll run the tests this weekend and post performance results early next week.

[CruNcher]

Do you guys really think power consumption is that important though? I don't think anyone's doing this sort of thing on mobile machines, and certainly not when they're under battery.



I would definitely add another page with current X264 numbers (although probably not IQ framegrabs), but I ran out of time to test for this story. If someone can help me convert the Handbrake queryies that are posted in the article to X264 command lines, I'll run the tests this weekend and post performance results early next week.

Since im born i belive Power Consumption is important and there are several ways to go Low Power/Low Performance Balanced Power/Balanced Performance and High Power/High Performance and most stuff should be designed in a Balanced way imho (of course the ultimate goal Low Power/High Performance) , the same applies also for Lossy Video in terms of Visual Quality results (Compression Factor Balance).

[jeffy]

I just wanted to thank everyone for their help. The article's live @ http://www.maximumpc.com/article/features/is_era_gpubased_computing_really_upon_us if anyone's interested in my results.

Is this true? 14 times the file size?TEST #4: ENCODING FOR IPHONE
Badaboom Custom iPhone Handbrake iPhone
PeeWeeMark (sec) 728 1548
File Size (gb) 0.074 1.04
(from: http://www.maximumpc.com/article/features/is_era_gpubased_computing_really_upon_us?page=0%2C1)

[Dark Shikari]

Measuring file size is rather silly... if you're encoding with a target bitrate, the file sizes should be almost exactly the same. If they aren't, you're doing it wrong.

[deekey777]

Did anyone try the last Badaboom beta?
(badaboom Media Converter: Beta 4, http://www.nvidia.com/content/forcewithin/us/download.asp)

[CruNcher]

speed increased a little no major changes though still baseline als will be released as baseline there will be no PRO version anymore

[Caroliano]

Badaboom 1.0 has been released

http://techreport.com/discussions.x/15763

[deekey777]

Badaboom 1.1 to come out in mid-December (http://www.techreport.com/discussions.x/16022)

H.264 Main profile output: Provides even higher quality output than version 1.0, especially useful when outputting at resolutions higher than 480p. Baseline profile is still supported.

[Dark Shikari]

Badaboom 1.1 to come out in mid-December (http://www.techreport.com/discussions.x/16022)"Even higher" implies certain things about the output of 1.0... ;)

[deekey777]

"Even higher" implies certain things about the output of 1.0... ;)

But doesn't this mean, they'll support CABAC (on GPU)?

[vucloutr]

But doesn't this mean, they'll support CABAC (on GPU)?

Yes, CABAC is part of H.264 Main Profile (http://en.wikipedia.org/wiki/H.264), which will be supported in version 1.1.

[Caroliano]

They may simply off-load CABAC to CPU. AFAIK CABAC is not paralelizable, so not realy suited to GPU processing.

[LoRd_MuldeR]

Yes, CABAC is part of H.264 Main Profile (http://en.wikipedia.org/wiki/H.264), which will be supported in version 1.1.

Apparently the "Main" profile does allow both, CABAC and CAVLC.

Hence supporting the "Main" profile doesn't necessarily imply using CABAC ;)

[CruNcher]

Though they already support Main since the start in their PRO solutions so i guess they just backporting it now to the Consumer App so Nvidia had something PRO Exclusive for the Quadro CX Series @ the Start, guess the same will happen now for High Profile support when it gets released for the PRO version soon of course delayed again ;).
Also would fit somehow in the PureVideo Encoder appearance, maybe it will support only Baseline though Nvidias Encoder and Badabooms Interface hit 2 different user groups so it wouldn't be needed to crapalize Nvidias Encoder that way :( but who really knows how the guys in the Marketing Departments think ;)

[deekey777]

Apparently the "Main" profile does allow both, CABAC and CAVLC.

Hence supporting the "Main" profile doesn't necessarily imply using CABAC ;)

That's why I've asked.
In TMPGEnc you can choose between CAVLC and CABAC for the Main Profile Encoding.

Thanks. :D

[deekey777]

Badaboom 1.1 Preview (http://www.anandtech.com/video/showdoc.aspx?i=3475p=7)

It comes with CABAC support. :)

[tre31]

Badaboom 1.1 Preview (http://www.anandtech.com/video/showdoc.aspx?i=3475p=7)

It comes with CABAC support. :)
hmm, here's correct link...
http://www.anandtech.com/video/showdoc.aspx?i=3475&p=7

Must say 1.1 preview looks good, output quality seems ok for main profile @ 1080p, looks like they have put some steps forward in the right direction.

[deekey777]

I downloaded the trial and replaced my HD3800 by a 8600 GT. I'm surprised, that this 8600GT with its 32 SPs is so fast. I get 10-12 fps by converting some 1080p24 samples (ts, VC-1 and MPEG2, Main 4.1 and CABAC) to 720p. The strange thing is: TS-files with H.264 are causing a crash, but not this m2ts file (http://forum.doom9.org/showpost.php?p=1224134&postcount=832).

But the worst thing is: I can covert my 50 Hz videos (1080i50 or 720p50), but I can't watch them. :(

[CruNcher]

hmm downloading the trial currently, i wonder if they still use ffmpeg as input decoder for most formats :)

[Atak_Snajpera]

i wonder if they still use ffmpeg as input decoder for most formats
Rhetoric question I assume :)

[deekey777]

http://rapidshare.com/files/176230797/ANIXE_HD_Borussia_Dortmund_-_VfL_Wolfsburg_20081223_204350__1-iPhone.mp4.html
This is my converted video (1080i50 to iPhone). Don't care about the quality, but can you watch it? Because I can't.

[CruNcher]

strange file the bitstream is ok but the container isn't, did Badaboom muxed that output ?
i never had any problems with the preview version and betas with the .mp4 output, tough i never used their iphone profile :D

remuxed .mp4 http://mirror05.x264.nl/CruNcher/force.php?file=./GPU-Encoding/ANIXE2.mp4 does that work on your iphone ?

[deekey777]

I can watch it on MPC and iTunes now. :)

(But not on my iPhone: I had a HDD crash last month and didn't make a back up for the iPhon's libraries. So if I want to upload some multimedia files on my iPhone with iTunes, I have to delete all my files on it, but I don't want to do this, because it's insane)

Yes, it was Badaboom. And it doesn't matter what profile (I've converted the Anixe video to a custom 720p video (main profile, 4.1&CABAC) and the result was the same. Now I tried to de-mux the TS file to .264 and .AC3 with tsMuxer. Then the 264 file has been converted to 720p custom (MP4, video only). Then I took the new video (MP4) and remuxed it with the original AC3 audio stream to a mkv file. And the result was the same again.
MediaInfo says:
Allgemein
Vollständiger Name : C:\...\ANIXE HD Borussia Dortmund - VfL Wolfsburg 20081223_204350 #1-Custom Media Center.mkv
Format : Matroska
Dateigröße : 80.9 MiB
Duration : 4h 26min
Gesamte Bitrate : 42.4 Kbps
Kodierungsdatum : UTC 2008-12-24 00:23:08
Verwendetes Programm : mkvmerge v2.4.1 ('Use Me') built on Dec 5 2008 18:30:05
verwendete Encoder-Bibliothek : libebml v0.7.7 + libmatroska v0.8.1

Video
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L4.1
Format settings, CABAC : Ja
Format settings, ReFrames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4h 26min
Breite : 1280 Pixel
Höhe : 720 Pixel
Bildseitenverhältnis : 16/9
Bildwiederholungsrate : 25.000 FPS
Colorimetry : 4:2:0
Scan type : Progressive

Audio
Format : AC-3
Format/Info : Audio Coding 3
Codec ID : A_AC3
Duration : 4h 26min
Bitraten-Modus : Constant
Bitrate : 448 Kbps
Kanäle : 2 Kanäle
Channel positions : L R
Samplingrate : 48.0 KHz



What muxer did you use?

[CruNcher]

mp4creator

[deekey777]

Version 1.1.1 of Elemental Technologies’ Badaboom® Media Converter is here (http://badaboomit.com/?q=node/4)

Well Badaboom Version 1.1.1 is here, and it addresses many of the issues that you may have seen. Without futher ado, here are the Release Notes, which you can also find in the User Guide:



Fixes:

- SLI disabling is no longer a requirement, but rather a recommendation.

- The 64-bit video file problem that caused certain transcoded videos to fail on a number of devices has been addressed. Error messages that were seen included “Video not supported,” “Unsupported video,” and “Corrupt data.” This affects, but is not limited to, the PSP®, Playstation 3®, and Zune®.

- Audio sync issues have been improved for all file types.

- The Main profile problem causing Badaboom® to hang and crash for certain file types (including AVCHD) has been addressed.

- The Apple TV default resolution has been changed and should now accept all Badaboom® transcoded videos (with default settings).

- The CPU Decode indicator now resets correctly following each transcode.

- The features of Badaboom’s shell extension have been improved.

- Both the video and audio bitrate sliders have been fine-tuned and are more accurate.

- The estimated file size is now more accurate.

- The Advanced menu’s issue of resetting incorrectly has been addressed.

- The video stutter issue of baseline-encoded files on the Xbox 360 has been addressed.

- The overall stability of Badaboom® has been improved.

Features:

- FRAPS support: This allows game enthusiasts to transcode their recorded game play for purposes of uploading to YouTube™, for example.

- 960x540 resolution: This is the ideal resolution for 30 fps videos transcoded to play on Apple TV.

- Main profile selection warning: If a selected device does not officially support Main profile, a warning will be provided if the user selects this profile.

Known Issues:

- Issues with the way the application handles certain errors

- There is scratchy audio output with a very limited number of .avi files.

[Varies]

It is absolutely useless tool...until will not work with avisynth.

lol it's free to use yet :D
wait Hight profile and avisynth support :)

[Kurtnoise]

It is absolutely useless tool...until will not work with avisynth.
you can use it with lossless (Lagarith, etc..) AVI files...

[Varies]

yes, but megui do it faster then i dumux avisynth stream and encode with badaboom :D
also i interested in HD :)

Somebody tried rename avs->avi and encode with this ? :D