GPU Transcoding Throwdown: Elemental's Badaboom vs. AMD's Avivo Video Converter

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.