GPU Transcoding Throwdown: Elemental's Badaboom vs. AMD's Avivo Video Converter
by Anand Lal Shimpi & Derek Wilson on December 15, 2008 3:00 PM EST- Posted in
- GPUs
And now, the rest of the story
To say that the output quality is bad would be entirely too generous. Rather than just take our word for it, here are some screenshots of the video. The actual video is worse as the corruption and anomalies change over time as well, but this is enough to show the problems.
This is the 64-bit version of Avivo encoding WMV files:
Our highest quality output video was S02E01 of MacGyver which lacked any deinterlacing.
Bad Boys delivered the second best output with massive corruption frequently occurring.
The Empire Strikes Back with completely unwatchable video that is nothing but completely corrupted and can even crash a player.
The 32-bit version has fewer problems. Codec choice didn't seem to fix corruption on the 64-bit version, but under the 32-bit version we were able to get cleaner output encoding to WMV (but not iPod (H.264) which remained corrupted).
Here's the Empire shot from the video encoded to WMV under Vista 32. Looks better.
MacGyver is unchanged in quality with the interlacing still a major problem, but at least some of the corruption issues are fixed for those running 32-bit Vista.
Our goal was to test the case where an end user may want to encode DVDs for use on their iPod, as this would allow us to more easily compare the software to Badaboom. Comparing quality comes out well in favor of NVIDIA on either the 64-bit or 32-bit version of Avivo when encoding to iPod video, so this makes any performance comparison much more difficult. We can't honestly directly compare the two software packages because of the major difference in the quality of output they generate.
To further illustrate the point I uploaded a segment to Viddler, but the further conversion to a flash video greatly improved quality. Some of the corruption is still there, but lost is the choppiness and other motion issues as well as the fact that every second or two we get a frame that looks like this thrown in:
It ain't easy being green.
Anyway, here's video clip. Yes, it also encoded with no sound, which is apparently also a feature of the Avivo video converter with some video formats.
We did also try using other sources to transcode from with Avivo, but our attempt to use H.264, DivX, or WMV sources all failed with different results. Some had video with no sound, some had only sound and no video, and some just gave us an error saying the file wasn't a valid movie and it wouldn't even try to transcode it.
And since when is video transcoding not a deterministic process? While working with our Star Wars clip, we noticed that our files weren't all the same size. Our first thought was that maybe when running on different video cards the transcoder operated differently. But after extended testing, we discovered that we don't always get the same output even if nothing changes. Not only do two different cards not output the same data, but one card isn't guaranteed to give you the same result from run to run.
This, on top of all the other issues, makes any performance comparison moot. But we ran the numbers anyway. And here's what we got:
This is a roughly 18 minute section of The Empire Strikes Back that took between 38 and 43 seconds to encode, and we recorded the first run. Subsequent runs came out between 38 and 43 seconds for all the cards. Regardless of which video card we plug in, performance is the same (and this is despite the output not even being the same). This honestly seems to indicate that not much is happening on the GPU. All the variables change with this hardware and nothing is the same width or clock speed from top to bottom.
We used GPU-Z to test utilization and saw that every 4 seconds or so during the encode process, we would see a blip of about 15% utilization on the GPU then it would immediately fall back down to zero. This means that AMD is using the GPU for very very little and most of the performance of the encoder is coming from the Core i7 processor we've got in there. To test our theory, we ran the processor underclocked at 2.6 GHz to see what happened to performance. Performance dropped from between 38 and 43 seconds per run to 56 to 60 seconds per run. This indicates that the performance of Avivo is incredibly CPU bound.
We can see from looking at the task manager during the transcode that there are about three threads that are pretty hard on the CPU. No matter what CPU speed we were running, one core was always pegged. Two other cores sat at over 50% utilization on the 3.2GHz Core i7. Overall utilization hovered between 30 and 40 percent for the most part. When we decreased the clock speed, all three threads ended up pegging their assigned cores at different times, which could indicate the much larger than 25% performance improvement in moving to higher speeds (the change from 2.6GHz to 3.2GHz is just over 23%).
So, we've got a transcoder that doesn't produce watchable output in many cases, doesn't produce consistent output, and doesn't vary in performance with GPU hardware (meaning it doesn't use the GPU very much at all). It doesn't handle incorrect interlacing flags gracefully and there is no option to force deinterlacing. But that's minor compared to the rest of the problems we are seeing here.
Facebook
Twitter
RSS
36 Comments
View All Comments
plonk420 - Tuesday, December 16, 2008 - link
this review is irksome... no mention of x264 version, no mention of resolution or bitrate used on the chart. as a previous comment says, the PQ on the x264 encode looks like the resize was screwed up... the comparison to a software solution was pretty poor.plonk420 - Tuesday, December 16, 2008 - link
http://plonkmedia.org/demo/test.html">http://plonkmedia.org/demo/test.html <-low resolution stream (zoomed 2x)http://www.megaupload.com/?d=ECOIUXQL">http://www.megaupload.com/?d=ECOIUXQL <-low resolution download
http://www.megaupload.com/?d=TPJVM0Y6">http://www.megaupload.com/?d=TPJVM0Y6 <-high resolution
http://www.viddler.com/explore/plonk420/videos/1/">http://www.viddler.com/explore/plonk420/videos/1/ <-what i'm assuming is a transcode (but same site that Anandtech used)
plonk420 - Tuesday, December 16, 2008 - link
quick and dirty tests... (emphesis on dirty; i have Opera with 30+ tabs open, uTorrent, VNC Viewer, handful of other programs open)source: Star Wars 4 VTS_02_4, 18 mins
low res: 320x128 took 310 seconds (±10 sec), processor use was ~30-40%
high res: 640x272 took 325 seconds (±10 sec), processor use was 60-70%
bicubic resizing, no cropping to exactly 2.39:1; couldn't be arsed. just used MeGUI's default iPod encoding settings, but set Quant 19. did SubME 2, 4, 5, and one test with 6 (the high res). it didn't seem to change the time it took to encode.
i'm sure you could up quality, significantly, too with better resizing options (i ususally use Lanczos4), other iPod compatible switches, at minimal speed cost. i don't usually encode for low bitrate/PMPs, but settings to do so are a google away.
but this pq looks decent to me. no issues the hardware encode had. using x264 has a BIT of a learning curve, but can be as fast as these hardware solutions (and possibly excede PQ with the proper options). recent builds have Peryn, i7, and even Phenom optimizations (that weren't utilized in one of the other site's i7 x264 tests).
my tests were encoded on a "mere" Phenom 9550 @ 2.2ghz on Vista x64 SP1, drives fragmented to hell.
options were --qp 19 --level 3 --nf --no-cabac --partitions none --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim (with --level being 1.3 for low or 3 for high, and --subme being 2, 4, 5, 6). build was 1051 (a few builds out of date; 1055 has better CAVLC PQ according to changelog)
mvrx - Monday, December 15, 2008 - link
I've been grumpy about this for years. Most all the commercial video editing packages have treated mananging and encoding 1080p as a pro-only, or "coming next year" feature.. 1080p isn't pro folks. It's consumer level.I have to use StaxRip with x264.exe encoder to do what I really want, as most commericial packages still have issues with 1080p. Everything should be ready for any resolution, including super high def. Don't try to charge customers more just because they are ready for what will be considered common in another year or two.
I'd also like to see the upconverting technolologies that HD dvd/BR players do in real time mature for software converters. I'd like to take my home movies and DVDs and convert them to 1080p, then encode to h.264. I know that doesn't give me true native quality content, I just like the idea of standardizing all my media to 1080p.
MadMan007 - Monday, December 15, 2008 - link
Thanks for keeping up with these articles. GPGPU's killer app for most consumers is video encoding. One thing that's missing from this article as was alluded to by an earlier comment is a reasonable price comparison - I'd like to see how the GPGPU encoders stack up to a dual core CPU since adding a video card is a much easier upgrade and lots of people have dual core CPU systems already.psychobriggsy - Monday, December 15, 2008 - link
It's interesting comparing this review to the Avivo vs Badaboom article I read elsewhere earlier this month (using the leaked pre-release Catalyst) where they achieved significant performance improvements over using a CPU (i.e., it was actually encoding on the GPU in that review, whereas the conclusion here is that it isn't). They didn't use a Core i7 however. Still, when it comes to using a $200 video card with a $200 CPU, or a $1000 CPU to achieve the same thing, the choice is obvious (well, when the quality is sorted out).Regardless AMD really shouldn't have released Avivo in that state, or they could have at least just called it a preview. What's wrong with AMD/ATI's developers? Don't they have any pride in their work?
bobsm1 - Tuesday, December 16, 2008 - link
Looks like Anand is actually reviewing the products instead of taking the marketing crap that is being provided and just posting it. Takes a bit more work but the result is more interestingdaletkine - Tuesday, December 16, 2008 - link
I used my Sapphire Toxic 4870 to convert the MPEG2 recording of Lost in Space VCR tape, to DivX using Avivo Video converter. My size went from 5.10GB to 3.48GB, from 720x480 (12Mbps) to 640x480 (converter doesn't give res options). Speed wasn't drammatic, like around 40min for 2h10min movie, on an Athlon 64 X2 @ 3.23GHz. CPU was utilized 100% and GPU was utilized (can be seen with RivaTuner) around 8-10%. Video quality was great, nothing to complain, no artifacts like anand pointed out, looks fine. So, seems to have worked for me, but not what I expected. The bad: WMV displays artifacting just like anand showed, Catalyst 8.12 drivers have issue with Xvid stuttering playback, so I saw that in WMP when playing my converted file (solved by using VLC player), no compression that I can see taking place (I used max quality setting, but medium only gives savings of 500MB, don't know about low), and it still needs a quad core.The good: it actually works for me, free, simple, good quality (when works).
This on Vista 64, 8GB ram, Athlon 64 X2 5000+ @ 3.23GHz.
Jovec - Monday, December 15, 2008 - link
8.12 Avivio just creates a 0 byte file when trying to transcode my Xvid (AutoGK) videos. Ah well...Etsp - Monday, December 15, 2008 - link
Man, that's some high level of compression. Careful with that, it may just have made an information black-hole on your hard-drive. :)