ArcSoft Media Converter, Avatar 720p (1/4)Developed by ArcSoft (authors of the Blu-ray Total Media Theater playback software), Media Converter 7 (version 184.108.40.206, abbreviated as AMC in our graphs) proposes to transcode sources either in the form of video files or DVDs. The software has profiles for consoles (Xbox, PS3, Wii, PSP), tablets (iPad), smartphones and other peripherals designed for TV playback (Apple TV, WD TV, etc).
We created two profiles manually for the 720p and 1080p resolutions, maximizing quality options. The H.264 high profile is not supported and Arcsoft seems to have custom encoders for the CUDA and Stream versions. Quality is almost constant whichever GeForce is used, with a very slight advantage with the GeForce GTX 460. In practice, this advantage makes no difference. Note also that the GeForce GTX 570 (too recent?) wasn't detected by our version of Media Converter. Quality was strictly identical across the various Radeons.
Let’s start with the results at 720p for Avatar. To recap, our files encoded at 720p were carried out with a requested video throughput of 4 Mbit/s.
The first surprise was that using a Radeon drastically changes the encoding options. It uses the Baseline profile and there are no B-frames or CABAC. You do however get virtually dynamic GOP here in as much as it uses an I-frame on scene changes. The others are more radical: one I-frame ever 80 frames, then between them a repeated group of 1 P-frame followed by 2 B-frames. If you compare the scores of the Arcsoft encoders between themselves, the CPU version is quite some way ahead for SSIM. The Intel MediaSDK seems to be optimised for PSNR (and therefore optimised for benchmarks rather than visual quality). The CUDA version gives an extremely low score, which requires some explanation.
In terms of processing time, the pure CPU version is devilishly fast, while the Radeon version, in spite of the baseline profile, is twice as slow. The Radeon HD 5750 is faster than the bigger Radeon models, though without any obvious reason.
The average SSIM values (or PSNR) do not however mean a great deal. As with any relationship, it’s how the difficult times are managed that provides us with the parameters for judging encoder quality. To highlight these difficult situations more clearly, we isolated two series of 500 distinct frames, taken from our extract.
Click here to see the PSNR graph of this scene.
Note that for this graph and for those that follow, we had to go for a dynamic scale in accordance with the content. So as to help you to visualise the differences between the various graphs, an orange line shows an SSIM of 0.9. You can also increase the size of the graph by clicking on the icon at top right.
Our first extract of 500 frames (scene 1) can be broken down into three parts. From around frame 0 to around 157, we have a relatively static scene. The main character is filmed in the pod and only the head moves. This is very easy to compress and all the encoders do a good job here. The scene ends with a fade to black (which gives us a score of 1 as all encoders know how to encode an entirely black image!). Up to frame 362 a new scene is introduced, more complex than the previous one as the camera moves in a slow tracking shot from left to right while advancing slowly. At frame 363, a new scene appears, again a relatively slow moving scene.
The Radeons use the least advanced encoding technique (baseline profile), but use dynamic GOP. The result of this is that while the quality of the encoding is systematically down on the others, the use of dynamic GOP means the Radeon gives better quality than the HD 3000 when there’s a change in scene. The GeForces are however completely lost when there’s a change in scene and there's a notable loss in quality. Much more serious than this however, when the image changes a little too much (and remember this is a slow-moving scene…), the Arcsoft Cuda encoder loses its footing between two I-frames (the peaks you can see every 80 frames) with a significant loss in quality. These jumps in quality are very visible. So as to show you what this gives in practice, we have isolated an identical frame from each encoded sequence, around half a second after the change in scene. The frames used for our comparison below are stored in PNG format so as to prevent any deformation. They may take a few seconds to load depending on the speed of your connection:Click here to display the frame comparison in a new tab.
While, as we said, the GTX 460 CUDA encoding has a very slight advantage when it comes to conservation of textures over the GTX 450 version, in practice neither are useable because of the excessive artefacts. The Arcsoft CUDA encoder is quite simply not up to the task. Our other encoders show differences in sharpness. The HD 3000 encoder lags behind from a visual point of view, while the AMD versions and CPU encoder are comparable, with the AMD encoder even seeming slightly better when you look closely at the texture of the skin. In practice these two frames are both a long way off the source frame unfortunately, with a significant loss of detail.
Our second scene includes several quite rapid movements and uses motion blur heavily, which facilitates the task of the encoders. What does this give in practice?
Click here to see the PSNR graph for this scene.
The Arcsoft encoders function well with motion blur. The CUDA version is too poor to speak of, but our three other encoders are neck and neck. The minute SSIM nuances are however visible. Look at the second frame that we have extracted from a motion blur sequence:Click here to display the frame comparison in a new tab.
If we only take faces into account, the AMD encoder does pretty well and conserves a maximum of sharpness on the faces. There are however artefacts in the shaded areas between the dark and light areas on the faces on the CPU and HD 3000 encoder versions (left part of Jake’s forehead, on the right of the screen). Let’s see if this level of quality is confirmed in the slightly more complex scenes!