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



ProcessorsMotherboardsGraphics CardsMiscellaneousHard DisksSSD
Advertise on BeHardware.com
Review index:
H.264 encoding - CPU vs GPU: Nvidia CUDA, AMD Stream, Intel MediaSDK and x264
by Guillaume Louel
Published on August 18, 2011

H.264
Sometimes known as AVC (often when talking about Blu-rays) or MPEG4 Part 10 (ISO terminology), H.264 (ITU terminology) is a video compression standard often considered to be the most technically advanced compression format. In ISO terminology it follows MPEG-1 (CD video), MPEG 2 (used on DVDs) and MPEG 4 Part 2 (XviD).

It's a standard with an open specification (downloadable here), the use of which is subject to a certain number of patents belonging to various big names in computing, electronics, telecommunications and various universities (Apple, Cisco, France Telecom, Fraunhofer, Microsoft, Mitsubishi, Panasonic, Philips, Sony and Toshiba to name but a few; the full list of patents is available here). All these companies have come together to create a pool of patents managed by MPEG LA. In the framework we’re looking at (personal use, non-commercial), no license is required.

H.264 is now widely used, whether this be for Blu-rays (where it coexists with a Microsoft format, VC-1, which also comes under the supervision of patents handled by MPEG LA) or because of the fact that H.264 decoding can be accelerated by most current general consumer devices (smartphones, tablets, games consoles and so on). It is also widely used on online video sites, something that we noted in our test of the AMD Brazos platform when the Flash software posed a problem in terms of video acceleration.

Video compression in practice
Without going into too much detail, we’re going to give you a general overview of how H.264 works, which will allow us to put into context any issues we have with the various encoders tested further on in the article.

A video is a stream of frames, compressed one after the next. H.264, like many formats before it, subdivides frames into blocks of pixels (squares of between 4x4 and 16x16 pixels, known as macroblocks). To achieve the final result, an encoder must determine the data required for the recreation of a frame (this is what’s known as prediction; there are two types) then compress this data as efficiently as possible (here again, there are two distinct types of compression).

Temporal prediction
Behind this term lies a very simple concept: a succession of frames in a video are very likely to be linked, to have a relationship to each other. Whether the sequence is made up of a static shot or moving characters, or a camera pan taking in a landscape, the successive frames will very often have numerous links between them. Starting from this principle, the encoder will attempt to identify blocks in the destination frame taken from one or several previous frames. Differences may be minuscule, down to a quarter of a pixel. This is what’s known as motion estimation and is a type of processing for which GPUs are likely to be very efficient. Henceforth we will refer to temporal prediction as inter prediction.


Avatar, Fox Pathé Europa


On this frame taken from a scene in Avatar (using Elecard StreamEye) where the camera moves left to right, while advancing, you can see that the elements of the frame which are at different depths (the creeper on the left, the ferns at the bottom, the lighter coloured ferns at the top and the creepers at the top) all move differently within the frame.

Spatial prediction
Again this term is more complicated than it sounds. Spatial prediction consists in compressing data from the current frame. Rather than looking for similarities between current and previous frames, spatial prediction looks for similarities within the current frame. This concept is equivalent to the compression of static frames (JPEG and so on) and we will refer to this as intra prediction in the rest of this article.

Of course, an encoder can use both types of prediction within the same frame. If we take the same frame as before (still using Elecard StreamEye):


The inter predicted blocks (temporal prediction, using a previous frame) are in blue/yellow and the intra predicted blocks (spatial prediction, within the current frame) in red/orange. Avatar, Fox Pathé Europa


Note that even when an encoder does its best to be as precise as possible in its predictions, they aren’t necessarily perfect. In every case of prediction where an attempt is made to find similarities between one block and another (whether within the same frame, intra prediction, or in another, inter prediction), the destination doesn't always exactly resemble the source. This isn’t a problem as the difference can simply be made up. By definition, it will be small as, after all, the blocks resemble each other.

Compress what and how?
Our predictions generate two types of quite distinct data. On the one hand precise data such as motion vectors used in predictions. If the encoder has put in the effort to obtain precision down to a quarter of a pixel, obviously you don’t want to compress this data and lose accuracy. For such essential data, H.264 uses lossless coding (entropy coding). There are two distinct types, CAVLC and CABAC. The difference between the two is that the second requires considerably more processing, whether to encode or decode. You may remember that some time back, the GeForce 8800s offered decoding of accelerated H.264 streams, though this was partial. There was no GPU support for CABAC decoding at the time (this was added to the following generations). CAVLC is less resource hungry but also less efficient (lower compression ratio).

For data which can be subjected to a (slight) loss, such as, for example, the residual image that corresponds to the difference between the source and destination blocks during a prediction (see above), a destructive compression, known as quantization, is applied.

The combination of this compressed data (lossless and lossy) makes up your H.264 video file.

Now that we’ve set down a general overview of H.264, we’re going to look in detail at a few of the points that came to the fore during our tests.

<< Previous page
Container, codec, transcoding

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 | 24 | 25 | 26 | 27
Next page >>
H.264 (2/2)  




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