ATi/AMD AVIVO Video Converter - GPU "hardware-accelerated" encoder: June 2011 update

It is July, but I typed June, because I tested the June drivers and the July drivers were not out yet.

AVIVO... ATi claimed it was their version of hardware-accelerated encoding using the GPU. The first versions were exposed to be CPU-only after they were hacked for use with other brands of GPUs, including Intel's integrated graphics. Sure it was fast, but it was CPU-only, and the quality sucked.

After some time, ATi/AMD released an update to the AVIVO Video Converter which is locked for use with HD4600-series and better cards, again promising GPU acceleration. Restricting access to it for users with older, slower cards could mean either a genuine hardware update, or another attempt to smokescreen people into thinking that way, and preventing owner of slower cards from discovering the obvious truth when their HD2000-series cards accelerated as much as a spanking new and fast (at that time) HD4850.

Due to the lack of available hardware (more than one card capable of the acceleration), I will not aim to prove if this hardware-acceleration is true or yet another bullsh*t this time. (Underclocking the GPU does not help, because GPU usage is never full and the GPU rarely increases speed from the idling state when encoding. Though that should tell you about the truthfulness of the claim.)

Instead, I shall look at, again, if this program really works or is just a piece of crap repackaged to smoke the shareholders.


Here we have the AVIVO Video Converter completing an encode as per normal. Phenom II with 3 cores at 2.8GHz, and HD5670.

Note the GPU load. Pretty much minimal. And look at the CPU usage history. Just strange.

Now we have the AVIVO Video Converter complete the same encode but with the CPU locked at 800MHz:


The much longer time indicates it is CPU-limited in this case. So does the super-low GPU load graph.

But...

1) 800MHz resulted in a time taken that is 2.55 times that of 2.8GHz. 2.8/0.8, however, gives 3.5.
2) Not one of the CPU cores was at or near 100% in either scenario.

I suspect there is GPU hardware acceleration, but latency resulted in both the CPU and GPU waiting and doing nothing. It is also possible that the GPU accelerates only specific parts of the whole transcoding process, like resizing and decoding, so for the other parts it remain CPU-limited. The GPU did increase to max speed in the first encode with the CPU at 2.8GHz and possibly be GPU-limited, but with the CPU at 800MHz, the GPU didn't even care.

So what exactly is happening in the GPU? I don't know, and I said I am not going to find out.

But lets look at if the program really works. As in, it produces something good enough to justify its existence.

40 seconds, or double real-time speed for a 720p H.264 encode with resizing involved is still too good to be true even today. Well the first versions of AVIVO did show us that it is possible, but video encoding is always a trade-off between speed and image quality (or compression ratio), and AVIVO is the best example of that.

Because, have you ever seen massive macroblocking occuring in a 720p 4mbps H.264-encoded video? (Those 300MB for 24 minutes episodes you download from the internet, those are 1.667mbps inclusive of audio. 4mbps would give 720MB.)

Well now you have.


No, I know this is not massive macroblocking. Because this is massive blocking:



And I didn't even talk about the serious problem when dealing with interlaced sources. This source is interlaced, but I picked out the problem-free frames. This is a problematic frame:


It happens once every few frames as long as there is action. Just as all interlace-related problems do. This problem has been found and talked about by others since a few years ago, so I won't talk about it in detail.

In a previous look at AVIVO Video Converter (not posted on this blog), I commented that the AVIVO's disgusting image quality is justified if you need a lot of transcoding done in a hurry. Because the speed of encode is unmatched (Any other encoder would take multiple minutes, except for CUDA-accelerated programs - CUDA is a tried-and-tested beast that works, I've tried it myself). But so is the bad quality unmatched.

So I thought, since the compression is so bad, can I use an older, less demanding codec to achieve higher encoding speeds at the cost of lower compression?

And so I did the encode again, this time in MPEG1 using TMPGEnc 4.0 XPress.

As the settings in AVIVO Video Converter are limited or non-existent and inaccurate, I trial-and-errored a few times to get TMPGEnc to encode a file with a similar file size with similar settings - resizing to 1280x720 pixels, 29.97 fps, 1 pass, quality-based, 44.1kHz audio (even though the original file is 48kHz, yes the AVIVO program is that stupid), obviously I could not select the same video and audio codec settings since different codecs were used.

The resulting time taken is in the region of 50+ to 60+ seconds. So it takes roughly 1.3 to 1.5 times the time taken by AVIVO. TMPGEnc has a slight disadvantage here due to a slow built-in resizer, speaking of which, I was forced to resize to 1280x720 because AVIVO Video Converter does not even allow H.264 to be encoded in resolutions other than 720 and 1080 vertical pixels. And it does not check for aspect ratio either, so expect your non-16:9 videos to end up looking like crap.

This is the picture when encoded in MPEG1 at a similar file size by TMPGEnc -




Seriously, this is what 4mbps MPEG1 should look like. Ok, not really, the lines are blur because the source is blur (720x480 @ 7668kbps DVD source) and there is some blocking because it is a high-action scene with regions of low contrast. And seriously, AVIVO's conversion quality sucks. How can a H.264 video look worse than an MPEG1 with similar bitrate? I know the H.264 encoded faster, but it does not mean it is going to decode faster, if any difference it would be slower and take more hardware than MPEG1. And just look at the difference in quality. Would you use 50% more time to get that better quality? I would.

I'll say it clear, the few pictures taken are relatively hard to compress, and the source itself is blur (but relatively noise-free - it is direct from DVD, and there is a limit to what 8000kbps MPEG2 can do), so it is hard work for encoders. But even with other sources and other scenes the AVIVO Video Converter does not give acceptable performance. Yes this is at the lowest setting of 3mbps, but 3mbps is like more than enough already. Yet somehow with AVIVO it is not enough.



I rest my case. The TMPGEnc MPEG1 encode has more prominent mosquito noise but I'd take that over the blurred out edges any day. At any rate it is strange to compare H.264 against MPEG1 anyway. And yes this picture is in the wrong aspect ratio. Because the aspect ratio cannot be chosen in AVIVO.

Lets ask the question of why we encode. To save space, and more often to convert it into a format which can be played by a less-capable device. (It makes no sense to re-encode for a more-capable device if the more-capable device can play the original, because encoding only reduces quality, never increase or keep the same.) And the less-capable device tends to also have limited resolution, maximum bitrate allowed and disk space, or rather, disk space has always been a problem when you are encoding entire seasons of shows, even since the VCD and DVD days. Hence there is always the push for newer more efficient codecs and competition between codecs using the same technology.

And here we have a H.264 encoder that has a worse compression efficiency than MPEG1. The default setting for 1080p is 14mbps, which for H.264 results in (or should result in, as long as you are not using AVIVO) a quality as good as, if not better than digital HDTV broadcasts, and even nearing Blu-ray. If your source is as good, why do you even bother, and if your source is not as good, why do you even bother. And if your device can already play HD H.264, why do you even bother.

And since the program does not allow you to encode standard-definition and custom-resolution H.264 videos, and H.264 videos with less than 3mbps bitrate, this limits the usefulness of the program to "people with super-high-quality sources and/or has a lot of disk space to spend on a device that accepts H.264 but somehow not the source". Which is, basically nearly none, and any one that exists would have a better time with another encoder, like x264.

To conclude, the purpose of this program is probably to show the world that the creators have something that their rival also has, and hope that nobody uses it by making it a separate download, and if somebody does use it, hide the bad compression under high bitrates.

Me doing side-by-side playback subjective comparison

Disclaimer: This review has been heavily dramatized, the encoding quality is so bad only because of issues with interlaced source; with a progressive source (sleeping people) the quality is more comparable with the MPEG1 encode, with blur but noise-free of the H.264 vs sharp but noisy of the MPEG1. In fact, if without the source to compare against, the H.264 is subjectively less offensive. But still, comparing a H.264 encode to an MPEG1 is...