Not All Codecs Are Created Equal
By Marco Jacobs
Codecs heavily compress real-world speech, audio, and video data. This compression greatly saves on transmission bandwidth and storage space. Without codecs, we’d only be able to receive a handful of channels on TV instead of the hundreds we’re used to now. We wouldn’t be able to make penny-a-minute global phone calls, and our DVDs would only store a few minutes of video instead of a whole movie.
By far the majority of codecs have been standardized. This ensures that data that has been captured on one device can be played back on another device, resulting in devices that are interoperable. The standardization effort involves many researchers working for several years, inventing clever compression algorithms to remove as much of the redundant and irrelevant information as possible. After years of discussion and evaluation of the best algorithms, the codec standard is frozen, gets published, and is ready for licensing to implementers.
It’s important to realize, however, that while a great deal of effort goes into this standardization process, not all codecs that implement a given standard are equivalent. Only the bitstream data—that information which the encoder and decoder exchange—is standardized, not the encoder or decoder itself. There’s actually a lot of freedom when implementing the codecs, and a lot of hard work and bright engineering ideas are required to develop a high-quality one. When licensing a codec, you would be wise to carefully evaluate the quality, performance and ease of use. Here are some things to consider:
Quality refers to both the audio or video quality of the compressed and consecutively decompressed data, as well as to the quality of the implementation. Is the codec robust to bit errors? Will it continue operating when it receives invalid data or data containing transmission errors, or will it hang? Will errors pop and crackle in the user’s ear, or will he hardly notice they’re there? Has the codec been certified? Does the codec work as advertised? Unfortunately, many codecs on the market are often incomplete or of low quality.
Performance can be measured using different metrics and under a wide variety of circumstances. What are the processor load, memory footprint and I/O requirements? What’s the performance in a real-world system where memory access latencies are often high, and bandwidth is constrained. Also, be aware of the bitstreams that were used to measure the above parameters. Were the streams carefully crafted to show good performance or are they real-world and difficult streams that really stress the system? A codec’s performance typically varies greatly based on the complexity of the bitstream.
Ease of use is the final important aspect. How easy will it be to integrate the code into your existing systems? How flexible and modular is the design? Will you have access to the source code, or is the codec provided as a binary only? Source code can be compiled for size or speed, and gives you the capability to extend and adapt the codec to meet specific (future) needs. Furthermore, looking through the source code is like opening the hood of a car. You can really get a good look at what’s inside. Also, if the codec isn’t working, is hardware or software to blame? You don’t want to get caught in a finger-pointing game between the codec vendor and the hardware vendor.
So when your next SOC needs to support a new coding standard, remember that not all codecs are created equal. Choose your codecs wisely, and make sure you learn everything you can about the supplier.
–Marco Jacobs is the product line manager for ARC processors at Virage Logic.
Tags: ARC, Virage Logic