Home  |  News  |  Reviews  | About Search :  HardWare.fr 

MiscellaneousStorageGraphics CardsMotherboardsProcessors
Advertise on BeHardware.com
Review index:
Intel Core i7 and Core i5 LGA 1155 Sandy Bridge
by Damien Triolet, Franck Delattre, Guillaume Louel et Marc Prieur
Published on March 21, 2011

Video playback
Like the other solutions on the market, the Intel IGPs obviously provide hardware decoding of videos. The idea isn’t necessarily to help the CPUs – even entry-level dual core models can decode the AVC HD flow of a Blu-ray – but rather to reduce the chip’s energy consumption (and therefore improve the battery life of laptops).

The previous generation already supported hardware decoding for MPEG2, VC1 and AVC (H.264). Here, however, Intel has extended the number of fixed units. Where previously Motion Compensation and Deblocking were processed by execution units, the Sandy Bridges now use fixed units for these decoding stages.

The hardware modifications implemented by Intel to its Sandy Bridge architecture are not transparent and require alterations in playback software. For example, the public version of Media Player Classic HomeCinema which allows H.264 decoding by the IGP for previous generations, here detects our Sandy Bridge correctly, but the result is a mass of artefacts.

Intel however supplied us with two Sandy Bridge compatible applications, PowerDVD 10 and Total Media Theater 5 in adapted beta versions. We were able to verify that hardware acceleration was running correctly on the first in various formats, including H.264 on MKV 720p and 1080p files. Note that Intel seems to have corrected one of the faults that we noted previously, namely the temporary accumulation of flickering in some dark areas. Either the bug has been corrected or the denoising – activated in the Intel drivers – is much more efficient. Its default setting is a bit aggressive, with very slight blurring of noisy scenes as you can see in HD HQV.

The majority of options linked to video decoding depend on correct handling of interlacing, which isn’t a problem with Blu-rays as here images are displayed through progressive scanning. On very high quality sources, the differences are almost imperceptible and depend more on the denoising setting chosen than anything else. Note that Intel provides automatic correction of skin tones in its drivers. Deactivated by default, the option seems quite ineffective to us. We can’t see much point in it, once again, as with good quality sources the necessity of carrying out corrections is limited. We put dynamic contrast correction in the same category, very much like you see with some LCD televisions.

Among the bugs previously noted, there’s image deterioration during accelerated playback of a Blu-ray at lower than native resolution (downscaling). This seems to have been corrected in Total Media Theater 5. However, as
Home Media
has noted, video playback is still imperfect from sources at 23.976 img/s as these are read at 24 Hz and not 23 Hz, which makes for small jumps in the flow of images every forty seconds (not necessarily visible if you don’t know about them).
Video encoding: Intel Quick Sync
Behind the marketing name Quick Sync, Intel is drawing developers’ attention to the option of using their IGP to carry out video encoding tasks. As with CUDA on an NVIDIA GPU or Stream on an AMD GPU, you can use some of the hardware units to carry out video encoding. The Intel equivalent to Stream/CUDA in the case of video decoding and encoding works via MediaSDK. This is an API that allows developers to fall back on software when hardware acceleration isn’t available. It’s up to developers to use the bits that serve them.

From a technical point of view, when the IGP acceleration is used, the Sandy Bridge decoding of the source image (in the case of transcoding) is very fast as it’s carried out by the new fixed units. From the point of view of encoding, while there are some fixed blocks, most of the work (Motion Estimation and so on) is carried out on the IGP’s execution units.

Intel supplied us with two applications that are compatible with the latest version of MediaSDK, at least when it comes to hardware acceleration. These were the beta version of Cyberlink’s MediaEspresso and Arcsoft’s Media Converter, both transcoding applications which serve mainly to convert voluminous files (Blu-ray and so on) into a format adapted to a peripheral (mobile phone, tablet and so on). The encoding isn’t very high quality in either case.

We used MediaEspresso so as to compare encoding times at the same time noting any quality variation there may be. The software doesn’t give you much room for manoeuvre when configuring the advanced encoding options. It’s impossible to choose between one or several render passes or the H.264 profile used. The options are limited to a simple choice of bitrate. For our test we re-encoded a 720p (1280x720) video as a 640x480 (while keeping a 16/9 aspect ratio) at a bitrate of 3 Mbps.

In MediaEspresso it’s possible to choose the level of acceleration you’re looking for. None, accelerated decoding, accelerated encoding, and accelerated decoding + encoding. We tested these four scenarios, deactivating the image quality improvement options in MediaEspresso so as not to disadvantage one or another of the solutions.

Before introducing the results, we must insist on the fact that we have obtained four files of more or less comparable but not identical size. The same goes for quality, something we’ll describe below. The encoding times should therefore be considered with circumspection.

Looking at the graph, we can say that using hardware acceleration in Sandy Bridge allows you to cut encoding time in three on the Core i7-2600K. Note also that with accelerated encoding, the CPU is still put to work. For information, the processor utilisations in the three accelerated modes were 83%, 38% and 23%.

Qualitatively speaking, the results are not exactly the same. We carried out a crop on an encoded frame, from top to bottom you can see the source image, the image encoded in CPU mode, with IGP decoding, IGP encoding and IGP decoding + encoding.

Given that the original video had a bitrate that was hardly higher than that chosen, you can’t say that the final image is the sort of quality you’d expect (we went from 1.1 GB on the source video at 720p to 990 MB at 480p!). Next, it seems pretty clear that MediaEspresso uses a completely different software path when you use a purely processor version and when you use an accelerated one (completely or partially). Chromatic tendencies towards red appear on the right side of the image (first example going from the middle) in the three accelerated versions. We suppose that the Intel MediaSDK is only used when there’s hardware acceleration (partial or complete) and that another path is used for the processor version.

But even if you only look at the MediaSDK images, the three images aren’t strictly identical. The purely processor versions clearly look as of they’re at another level to us. Even if it does look a little blurry, the difference is clear during playback and you get a lot fewer artefacts.

So then, although Intel is apparently giving us hardware acceleration for video encoding with Sandy Bridge, in practice the library on which it’s based doesn’t necessarily seem to be on a par with the best available software options, including those, which are nevertheless modest, integrated in MediaEspresso.

<< Previous page
Intel HD Graphics, CPU vs IGP

Page index
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23
Next page >>
Energy consumption  

Copyright © 1997- Hardware.fr SARL. All rights reserved.
Read our privacy guidelines.