If you're clever, you can do this kind of postprocessing without a big CPU hit on mobile phones. Phones compress video in hardware, and as part of that process the hardware looks for blocks of video that are roughly the same across frames. When it finds one, it attaches a pointer indicating where it should go in the next frame.
Taken in aggregate, all of these pointers in the compressed data stream effectively show you which way the image "shook" relative to the previous image (and how far it shook) saving you CPU cycles to determine this yourself. You can even detect rotation. So all you need to do now is compensate for the shake by rewriting the compressed stream, "panning" (and perhaps rotating) in the opposite direction of the shake. In order to have room to pan, you need to emit a smaller rectangle than the original video.
This isn't sufficient for advanced stabilization, but it's a quick first pass.
I took a stab at writing this for the iPhone in 2010, but by that time the writing was clearly on the wall: Apple was soon going to offer this functionality in hardware (and they do, on the iPhone 4S and 5), and they would only do a better job with every phone refresh. The only way one can hope to compete is to perform global optimizations across the entire video clip that the hardware encoder can't do (e.g. dynamic programming), or else apply fancier transforms which are so CPU intense they kill the mobile experience. Good job on the part of the developers; the video looks great. As iPhone GPUs get more powerful stabilization algorithms will only get better.
One business angle here is to give the app. away for free and charge a dollar per video to deshake clips as a web service in the cloud.
It seems to take the approach of a post-processing frame shift rather than real-time stabilisation. In other words it lets the phone capture and compress using hardware, but keeps the sensor data separately and shifts the x,y of the video to stabilise. Unlike Final Cut etc. that has to analyse each frame, Luma has the raw data as the video was being shot. So the battery hit would come on export when the video has to be re-rendered I'm guessing.
I think this is the method because the Luma video appears more zoomed in than the original, i.e. they leave some space around so the video is always visible. This means that the Luma output will be lower res than the original hardware captured video I'm guessing.
Still, if it avoids walking around with your phone in a steadicam rig then it's a huge win. I have a steadicam smoothee but the ridicule from friends and family mean I don't use it, the slightly lower res output with Luma is the price my family will pay for their insensitive mockery!
Luma applies stabilization on playback. We keep all the pixels we get from the camera, even when you upload to our cloud service. As we improve our algorithms your existing videos will continue to improve with time. There's much more that we can do to help you create stunning videos. We're just getting started :)
It sounds like you're applying post-decode linear transformation to the data, but, if so, the video would only appear stabilized in your own custom player. Does MPEG-4 allow one to specify per-frame linear transformations beyond simple ROI? I didn't think so, but if so, that's pretty cool. Or perhaps you keep the original data around server-side, but always stream a corrected version to anyone who asks to play the video.
Either way, your videos look great. I love the fact that you also compensate for rotation, which is expensive even when you have macroblock vectors. I hope you can stay ahead of Apple (both iPhone, iMovie, and FCP) and Android in this space. Best of luck. May you become the Instagram of online video!
Comments
If you're clever, you can do this kind of postprocessing without a big CPU hit on mobile phones. Phones compress video in hardware, and as part of that process the hardware looks for blocks of video that are roughly the same across frames. When it finds one, it attaches a pointer indicating where it should go in the next frame.
Taken in aggregate, all of these pointers in the compressed data stream effectively show you which way the image "shook" relative to the previous image (and how far it shook) saving you CPU cycles to determine this yourself. You can even detect rotation. So all you need to do now is compensate for the shake by rewriting the compressed stream, "panning" (and perhaps rotating) in the opposite direction of the shake. In order to have room to pan, you need to emit a smaller rectangle than the original video.
This isn't sufficient for advanced stabilization, but it's a quick first pass.
I took a stab at writing this for the iPhone in 2010, but by that time the writing was clearly on the wall: Apple was soon going to offer this functionality in hardware (and they do, on the iPhone 4S and 5), and they would only do a better job with every phone refresh. The only way one can hope to compete is to perform global optimizations across the entire video clip that the hardware encoder can't do (e.g. dynamic programming), or else apply fancier transforms which are so CPU intense they kill the mobile experience. Good job on the part of the developers; the video looks great. As iPhone GPUs get more powerful stabilization algorithms will only get better.
One business angle here is to give the app. away for free and charge a dollar per video to deshake clips as a web service in the cloud.
The app is great.
It seems to take the approach of a post-processing frame shift rather than real-time stabilisation. In other words it lets the phone capture and compress using hardware, but keeps the sensor data separately and shifts the x,y of the video to stabilise. Unlike Final Cut etc. that has to analyse each frame, Luma has the raw data as the video was being shot. So the battery hit would come on export when the video has to be re-rendered I'm guessing.
I think this is the method because the Luma video appears more zoomed in than the original, i.e. they leave some space around so the video is always visible. This means that the Luma output will be lower res than the original hardware captured video I'm guessing.
Still, if it avoids walking around with your phone in a steadicam rig then it's a huge win. I have a steadicam smoothee but the ridicule from friends and family mean I don't use it, the slightly lower res output with Luma is the price my family will pay for their insensitive mockery!
Luma applies stabilization on playback. We keep all the pixels we get from the camera, even when you upload to our cloud service. As we improve our algorithms your existing videos will continue to improve with time. There's much more that we can do to help you create stunning videos. We're just getting started :)
It sounds like you're applying post-decode linear transformation to the data, but, if so, the video would only appear stabilized in your own custom player. Does MPEG-4 allow one to specify per-frame linear transformations beyond simple ROI? I didn't think so, but if so, that's pretty cool. Or perhaps you keep the original data around server-side, but always stream a corrected version to anyone who asks to play the video.
Either way, your videos look great. I love the fact that you also compensate for rotation, which is expensive even when you have macroblock vectors. I hope you can stay ahead of Apple (both iPhone, iMovie, and FCP) and Android in this space. Best of luck. May you become the Instagram of online video!