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:

 

empire strikes=

 

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. 

The Avivo Video Converter Elemental's Badaboom 1.0: The Redemption
POST A COMMENT

34 Comments

View All Comments

  • SkullOne - Tuesday, December 16, 2008 - link

    GPU encoding is not supported by Vista 64-bit at this time. So if Vista 64-bit is being used that would explain why it was CPU based.

    This is straight from the 8.12 release notes: "The ATI Avivo video transcoder does not currently use GPU acceleration under Windows Vista 64-bit edition."

    Now with that said under Vista x64 I do not get nearly the same amount of corruption as seen on the review but I do get it. Hopefully those bugs are worked out in the future.

    I can successfully encode any VCD/SVCD MPEG to iPod size without a single issue. DivX files encode down to iPod size with some video corruption although it appears that the better the DivX encode the less corruption I get the in the iPod file. Xvid files just dump out audio with no video. I can't even try to covert an h.264/x264 based MKV file as Avivo doesn't recognize the container.

    Hopefully ATI addresses these issues quickly.
    Reply
  • DigitalFreak - Tuesday, December 16, 2008 - link

    Wow, good catch. There was some mention of using Vista 32bit on a few encodes, but I have to wonder if they were using Vista 64bit during the timed run. Reply
  • DerekWilson - Tuesday, December 16, 2008 - link

    We used 32-bit for everything but those 64-bit stills. AMD didn't tell us about the issues with 64-bit until we brought them up with them, so we switched half way through.

    All the performance tests were done on 32-bit vista.
    Reply
  • DigitalFreak - Tuesday, December 16, 2008 - link

    Thanks for the clarification, Derek. Reply
  • nissen - Tuesday, December 16, 2008 - link

    Is it Badaboom 1.0 you are using when talking about cpu usage? because here on my duo e6600/gtx280 badaboom eats just between 10-20% of the cpu depending on input ( ~15 for 1080i h264, ~20 for dvd ) , definatly something wrong.
    Reply
  • MojaMonkey - Tuesday, December 16, 2008 - link

    On page 7 you have the 9800 GTX+ outperforming the GTX 260 is this correct or have you got the labels wrong?

    I'd expect the GTX 260 to perform better than a GTX+
    Reply
  • dvinnen - Tuesday, December 16, 2008 - link

    "And since when is video transcoding not a deterministic process?"

    Cool product from AMD and I'm sure it will get better over the coming months, but how do you manage to do that? Weird.
    Reply
  • The Preacher - Saturday, December 20, 2008 - link

    Ever heard of dithering? If you use that and seed the random generator using system time (not really a bright idea) you could get slightly different results each time (I doubt you could actually SEE the difference).
    http://en.wikipedia.org/wiki/Dithering">http://en.wikipedia.org/wiki/Dithering
    Reply
  • 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. Reply
  • 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)
    Reply

Log in

Don't have an account? Sign up now