Post a Comment
News and New Products
When is a video codec not really a codec?
Analysis: Demanding video-surveillance applications complicate the hardware-versus-software decision.
By Ron Wilson, Executive Editor -- EDN, 9/27/2007
|
In such a situation, a designer should be able to determine which algorithms are necessary, reduce them to C++ or something similar, profile them to determine which loops will require hardware acceleration, and then proceed directly to an SOC architecture based on any of the currently-popular embedded CPU cores. But increasingly, it's not that simple.
The initial problem has been, as mentioned, an overabundance of standards. When reducing algorithms to a hardware-software partitioning, the architect has to be very careful to leave enough flexibility in the hardware to support all of the necessary standards for a particular marketing plan. Unfortunately, while every video encoder does about the same things in about the same ways, there are significant differences in detail between the standards, and these differences often impact several different blocks in the design. So the architect may be forced to leave an algorithm in software and throw computing resources at it, because there are too many slightly different ways the algorithm is used in different encoders. Alternatively, the architect may be forced into the delicate job of making a hardware accelerator configurable enough to handle two rather different versions of an algorithm.
Lately, the problem has become worse. Several high-profile news stories lately have underlined the fact that surveillance monitors often go unwatched for long periods of time. Criminals locate and disable cameras, or are so uncooperative as to perform misdeeds while the camera is pointing elsewhere. Given that the market wants total security but has no intention whatsoever of paying people to provide it, there is strong demand for image-recognition software than can take the place of a human watching a monitor and steering the camera. Such software must be able to recognize an abnormal situation, alert authorities, and optimize image quality for viewing and recording the incident.
This is realistic on a server farm, with longer-than-real-time response. But to achieve it on a system that prospective customers can afford, in close to real time, requires hardware assistance. The most promising area for this assistance is in pre-processing the images to extract object outlines, facial features, suspicious motions, and so forth directly from the pixel stream. Rather than add a whole new subsystem, system architects are tentatively assigning these video analytics task to the video-compression processor.
There's a good reason. As it turns out, many of the basic algorithms required for video analytics are similar to some of the algorithms used in video compression. Several development teams are exploring whether the compression hardware can be extended once again, this time to support the needs of the analytics.
This scenario plays right into the hands of an architect who chose to keep these routines in software all along, and increase the computing bandwidth. Instead of having to once again modify hardware engines, the architect now only has to add headroom to the video-signal-processing kernel. Thus we are seeing an approach to codecs—a cluster of programmable signal processors—that makes no sense at all if you are doing just a few variants of a few specific standards, coming back into vogue because of its ability to cope with additional, related tasks. It is a case in which dedicated hardware has not proved to be the best long-term solution to the problem, at least so far.
