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



Over recent years, graphics card manufacturers have been highlighting the ability of their GPUs to handle more than just gaming graphics. Although there has been some success in the market for High Performance Computing (financial services sector and so on), the concept of GPGPU (General Purpose computing on GPU) is still struggling to find purchase with the general consumer. Standards like OpenCL and DirectCompute are working to make an impact but so far this is still fairly minor.

Video, naturally!
General consumer GPGPU usage is nevertheless quite common when it comes to video encoding solutions. On paper, the idea seems a very good one. GPU power can already be drawn on for video decoding (Blu-rays for example), via a dedicated circuit integrated into the GPU and it would therefore seem logical to use GPUs for encoding too.

After a fairly limited start with the first version of Badaboom in 2008, transcoding is back on the agenda with Windows 7, which includes the possibility of using your graphics card to transcode files automatically towards a peripheral (portable video player, smartphone, as long as it is compatible and detected by Windows 7). Many free or paid applications have set to getting to grips with file transcoding, whether these files be destined for mobile peripherals, tablets or games consoles.

A common point of all these applications is that they often use libraries designed by GPU manufacturers themselves. Thus NVIDIA supplies an H.264 encoder developed in CUDA (nvcuvenc), AMD has its own which uses Stream technology (AMD Media Codec package at the bottom of the page), and even Intel have put in their penny's worth, as we saw at the beginning of the year on the launch of the Core Sandy Bridge processors with its MediaSDK (which is itself partly based on the IPP library).


But what do all these solutions give in practice? Is all the software that uses them equivalent? What about encoding speed and quality? And how are these encoding solutions to be measured against what is the reference when it comes to H.264 encoding, the open source software x264 (that we regularly use in our CPU tests)? We’ll be getting to grips with all these burning questions in this report!

Before going further, we want to thank Nicolas et fils for the loan of hardware used in the tests, as well as Jason Garrett-Glaser (x264 developer) for replying to our questions on H.264. If you wish to go into more depth on this subject, here are the links to some of the resources used in researching this article:

- The H.264 recommendation
- The book The H.264 Advanced Video Compression Standard by Iain Richardson (the site for which makes available some interesting free content here)
- Jason Garrett-Glaser’s blog


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 >>
Container, codec, transcoding  




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