Pretty much everyone agrees that digital video has become a killer app for embedded processing engines. But “video” can mean different things to different people; the term encompasses a diverse set of applications with very different requirements. A processor you’d use for video playback in a low-cost cell phone, for example, isn’t going to cut it for an HDTV set and vice versa.
System developers and their chip suppliers must understand exactly what kinds of video they need to handle, and how their choices will affect the demands placed on the processing engine. Key factors include:
- Frame size and frame rate. These span QCIF (about 25,000 pixels) at 15 frames per second to HD (1-2 million pixels) at 30 frames per second, and beyond. The frame size and frame rate have implications not only for processing requirements, but also for memory bandwidth, memory sizes, and other architectural considerations. (And as I’ve written before, don’t try to scale performance data for one frame size/frame rate to another. That way lies heartache.)
- Whether the device requires playback only (e.g., in a personal media player) or also needs to support recording/transmitting. Encoding video tends to require more horsepower than decoding, and simultaneous encode/decode is particularly demanding.
- Whether the video processing algorithms are standards-based (e.g., H.264 decode) or not (e.g., deinterlacing). Can you use off-the-shelf software, or will you need to write custom code? Some video solutions are programmable, some aren’t. Some are programmable only with very high effort. Even a small amount of customization can become a big headache if the development tools are lame.
- Tolerance for latency. Camcorder video capture may be able to tolerate high latencies; video conferencing can’t. If you can't tolerate much latency, you'll need to choose a more powerful processor and/or run at a higher clock rate. As usual, though, there are tradeoffs; for example, cranking up the clock can drive up power consumption and require more expensive memory banks.
Layered on top of these requirements are widely varying design constraints, such as manufacturing budget, power consumption, and time-to-market requirements.
Whether you're designing a video-oriented chip or a full video system, it’s essential to understand where your product (or your customer’s product) fits into each of these categories—or risk coming up short in key resources.
Add new comment