H.264 baseline GPU accelerated encoder

[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