editor's blog
Subscribe Now

Stable Video, Easier Development

There are times when a shaky video can be just the thing. Imagine: where would the Blair Witch Project have been without it? What would an entire generation of hipsters do without the ability to shake (ironically) their video? How are happening new producers supposed to attract new audiences without being able to make their video look shoddy and unprofessional?

But, aside from those times, shaky video is not so good. In fact, for a lot of us, even these examples aren’t great (some of them representing videos that only their producers could love). We all have a hard enough time holding our cameras still without having to add shaking as part of some obscure production value.

We already take care of this for still pictures using optical image stabilization (OIS); why not simply apply that technology to videos? Well, for the same reason you don’t use a still photo camera to shoot video. Oops! Wait… I guess these days you can. OK, then simply because video isn’t the same as a still picture, so what works for one doesn’t necessarily work for the other.

First of all, still photos are just that: still. Any movement is wrong (except for things like sports, I suppose). So, in theory, you can just neutralize any motion, period. But, as you can imagine, that’s not going to work with video – unless you want to turn your video into a still shot. No, video means motion by definition. So when stabilizing a video image, you have to figure out what motion is intended and what motion is due to unwanted shaking.

Unlike OIS, which is typically implemented as hardware embedded into the camera module, CEVA is proposing handling digital video stabilization (DVS) in software for things like smartphones, wearable electronics, and cameras mounted inside moving vehicles, all of which involve inherent shaking. And all of which benefit from low power – wearable cameras in particular.

So CEVA has put together a set of DVS functions optimized to work on the CEVA-MM3101, their imaging-oriented DSP platform. These functions come with a number of options and parameters, since one solution doesn’t necessarily solve all the problems optimally. And with no standards out there, they see this as an opportunity for their customers to differentiate their camera solutions.

Other reasons for using a programmable solution instead of a hardware version are the fact that the DSP hardware can be reused for other functions – or can combine DVS with other functions like Super-Resolution.

Their solution provides correction along four axes: the x/y/z directions and then one angular direction: roll (which they call rotation about the Z axis, so I guess the convention is that forward is along the Z axis). They also provide correction for the “Jello effect”: this is distortion that occurs due to a shutter that’s rolling while the image or camera is moving, causing something of a relativistic leaning effect. And they can scale to handle 4K Ultra HD on a single core and adapt to various lighting conditions.

But power is also critical: they say that existing solutions use around 1 W of power; they’re touting less than 35 mW for 1080p30 video when implemented on a 28-nm process.

This new set of libraries could be integrated into an application using their new Application Development Kit (ADK), which they announced at the same time. The ADK is a framework for easing application development and optimization.

One noted feature is called SmartFrame. This allows a developer to operate on an entire video frame while the underlying framework takes care of logistical details. In particular, it can tile up the frame and apply “tunneling” to multiple algorithms, which they refer to as “kernels.”

This tunneling combines a pipeline architecture with the ability to chain multiple kernels together for back-to-back execution. Without tunneling, each kernel would be called by a program, and execution would return to the calling function after the kernel completed so that the program could then call the next kernel.

Instead, the framework allows the first kernel to work on one tile and then hand that tile directly off to the next kernel in the chain while the first kernel starts work on the second tile. And so forth for additional tiles and kernels. This minimizes the amount of data copying needed, and control doesn’t return to the calling program until the entire frame has been processed by all of the kernels.

The ADK also makes it possible to call DSP offloads from CPU programs, something we saw with CEVA’s AMF announcement.

You can find out more about CEVA’s DVS capabilities in their DVS announcement, and there’s more about their ADK in their ADK announcement.

Leave a Reply

featured blogs
Apr 7, 2020
Have you seen the video that describes how the coronavirus has hit hardest where 5G was first deployed?...
Apr 7, 2020
In March 2020, the web team focused heavily on some larger features that we are working on for release in the spring. You’ll be reading about these in a few upcoming posts. Here are a few smaller updates we were able to roll out in March 2020. New Online Features for Ma...
Apr 6, 2020
My latest video blog is now available. This time I am looking at the use of dynamic memory in real-time embedded applications. You can see the video here or here: Future video blogs will continue to look at topics of interest to embedded software developers. Suggestions for t...
Apr 3, 2020
[From the last episode: We saw some of the mistakes that can cause programs to fail and to breach security and/or privacy.] We'€™ve seen how having more than one program or user resident as a '€œtenant'€ in a server in the cloud can create some challenges '€“ at leas...

Featured Video

Industry’s First USB 3.2 Gen 2x2 Interoperability Demo -- Synopsys & ASMedia

Sponsored by Synopsys

Blazingly fast USB 3.2 Gen 2x2 are ready for your SoC. In this video, you’ll see Synopsys and ASMedia demonstrate the throughput available with Synopsys DesignWare USB 3.2 IP.

Learn more about Synopsys USB 3.2