[FFmpeg-devel] Vid.stab video stabilization ready for libavfilter

[Georg Martius]

Hi,

Thanks for your answer.

On Wednesday 20 February 2013 23:27:56 Clément Bœsch wrote:
> On Wed, Feb 20, 2013 at 11:06:22PM +0100, Georg Martius wrote:
> > Dear ffmpeg developers,
> > 
> > I am the author of the vid.stab [1] video stabilization library that is
> > used in transcode so far.
> > Now I have implemented filters for libavfilter which work great.
> > The code-base was completely restructured and is now independent of
> > transcode and available as a library. The code is on github [2].
> > 
> > How can it become part of ffmpeg?
> > a) the library becomes part of ffmpeg (a subdir in the tree)
> > b) the library stays stand-alone and only the two filter files go into the
> > libavfilter directory.
> > 
> > I would like to keep the implementation of the lib independent of ffmpeg
> > to be able to integrate it into other tools.
> > What is your opinion?
> 
> I've come across your project in the past already, I'm really happy to see
> you interested in contributing to FFmpeg... Especially since our current
> deshake filter isn't perfect in various scenario¹. I'm also curious how it
> compares to the one proposed on Youtube².
The Youtube filter is now very good. Mine does not do rolling shutter 
compensation otherwise it is quite good, much better than the deshake in 
ffmpeg. See [3] for some videos. 
- Sam and Cocoa: is the one from the google page and it has massive rolling 
shutter effects. So here we are not good yet, but better than deshake. 
Vid.stab also has a single pass deshaker (as the deshake plugin in ffmpeg) 
(..._1pass.avi) but it is off course worse than the 2pass standard version. 
- skiing6: there is no rolling shutter and it works great, the dehake plugin 
is much worse here. I didn't try youtube on that yet....

Performance wise on a 720p file (skiing6):
deshake: 15fps
vid.stab: pass1 45fps, pass2 50fps
 
> Now for you question about the integration in FFmpeg:
> 
> I don't think the FFmpeg project will distribute an extra library along
> with the current ones (libavformat, libavcodecs, libswscale, libavfilter,
> etc) given that it has a very specific usage. Also, it's the purpose of
> libavfilter to propose such thing. Of course, your API could be integrated
> to libavfilter somehow, but would likely be exposed to the user only
> through the usage of the filter. Doing this would mean you would have to
> maintain that code in FFmpeg (given that you would be the maintainer of
> that code, you would just ask for regular merges from your github).
> 
> The other solution of just adding the simple filters and link them with
> your library as extra party will require a proper packaging of your
> library in various distributions, otherwise it's likely to be never used
> (while having the whole code maintained in FFmpeg will provide you instant
> users). Also, it will require some discussions with the packagers to get
> FFmpeg linked with it.
> 
I would certainly more like to go for the first choice, it seems much easier. 
The question is how it could be done. Do you except me to use all possible 
avlib functions in my code? Or would it be okay to have a separate directory 
in libavfilter/ where I would have my code with possibly some doubled 
functionality?
The user would anyway only access it via the plugins. 

[3] http://public.hronopik.de/files/vidstab/

-- 
---- Georg Martius,  Tel: +49 177 6413311  -----
--------- http://georg.hronopik.de -------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130222/05c98cd1/attachment.asc>