It's tempting. You've got to figure how much processing power you'll need to implement a particular video-compression algorithm, and there on the Web is the data you need — but for a slightly different scenario. Perhaps the data is for a smaller frame than you envisioned.

You think, "I don't have the exact data I need, so I'll just multiply what I do have by a scaling factor that will account for the differences in the workloads." But that's where things can go wrong.

Let's say your data is for a small frame. Your frame is, say, four times as big, so you are sorely tempted to multiply the processor loading data by a factor of four. But look out. It's possible the smaller frame fits in on-chip memory and the bigger one doesn't. If so, then as soon as you exceed the capacity of on-chip memory, you may take a huge performance hit. At that point, the relationship between the processing power required for each of those scenarios can go nonlinear, and your scaling won't mean much. In fact, because video algorithms tend to be very data-intensive, the size of the on-chip memory and bandwidth of the off-chip memory often limit performance.

Other factors complicate matters. In typical video-compression algorithms (like H.264), for example, most blocks operate on pixels, but a very important one doesn't: the entropy coding block operates on coefficients, not pixels. So its processing load is a function of the compressed bit rate, not the pixel rate.

You could just ignore this block, but that would be a mistake. The entropy coding portion of a video-compression algorithm can consume as much as a third of the processing power needed for the entire algorithm. So if you double the bit rate — even while keeping the pixels/second constant — you'll need more horsepower. And even when you think the performance data you've found is an exact match for your scenario, you're probably wrong. Many subtle factors can affect the processing load of a video algorithm, and you often won't have enough information on those factors to assess the relevance of the data.

For example, say you plan to incorporate H.264 Baseline Profile encoding, with a VGA frame size at 30 frames/second. And say your processor vendor has performance data for that very scenario. That's good, but until you nail down a number of other variables, the data you're looking at may mislead more than inform. These variables include things like the quality of the video, the type of video content being encoded and the off-chip memory bandwidth. Without a detailed understanding of the circumstances under which the data was generated, you won't be able to truly predict performance.

Engineers naturally want to extrapolate data. But in video processing, do so carefully, or not at all.

-Jeff Bier, general manager of Berkeley Design Technology Inc. (www.BDTI.com), a consulting firm providing analysis and advice on DSP technology. Jennifer Eyre of BDTI contributed to this column.