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

[Clément Bœsch]

On Fri, Feb 22, 2013 at 12:53:10AM +0100, Georg Martius wrote:
[...]
> > 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. 

Both solutions have their advantages and drawbacks. Here is my opinion
about the (complete) integration in FFmpeg:

 pro:
  - get your code reviewed by several other developers, so potential
    improvements
  - all the advantages of being part of a big project (more users, more
    contribs, ...)
  - your code can get simplified and optimized by using the internals
  - your code can survive after you abandon it (if in a good shape, well
    integrated and covered by our test suite)

 con:
  - you have to stick with the "FFmpeg style" and its constraints. This is
    a big con, because it means you will likely have to rework a large
    part of your code to be integrated. And it also means you will not be
    able to break the API and ABI as freely as you would do with another
    project. It also means you won't be able to expose various part of
    your API and will have to integrate the code transparently in the
    project.

So no, integration within FFmpeg is not much easier, and in the short term
it's mostly beneficial only for the FFmpeg project, not yours. On the long
term, it's potentially interesting for you and your project thought.

OTOH, if you think you can maintain your project and its distribution on
your own (or with the help of others developers of course), it is much
more interesting to be split from the FFmpeg project (and only have a
filter-wrapper in FFmpeg), and thus define your own rules and constraints
in your project.

[...]

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130222/6d2ad87f/attachment.asc>