[FFmpeg-devel] [PATCH] Per-frame metadata

[Stefano Sabatini]

On date Thursday 2011-04-14 01:16:58 +0200, Alexander Strasser encoded:
> Hi,
> 
> Stefano Sabatini wrote:
> > On date Tuesday 2011-04-12 20:38:18 +0200, Alexander Strasser encoded:
> > > Nicolas George wrote:
> [...]
> > > > 
> > > > libavutil was my first choice, as it has absorbed libavcore; but Michael
> > > > seemed to prefer libavcodec.
> > > > 
> > > > If you think this is better in libavutil I will make the change.
> > > 
> > >   Just for the record:
> > > 
> > >   I still dislike the merge of libavcore into libavutil and I dislike
> > > adding more stuff on top of that, too.
> > > 
> > 

> > >   There should be better solutions like making lavfi purposefully
> > > depend on lavc or something I didn't yet think of.

This can be already achieved, some filters may be compiled in only if
libavcodec is enabled. But the problem we're addressing here is making
lavfi as a library not depend on libavcodec.

Note that I have been explicitely asked to make lavfi independent from
libavcodec, for easing/making possible lavfi integration in projects
not depending on lavc.

> > Of course this is possible, but I also want to keep the dependencies
> > of lavfi as low as possible, also logically metadata doesn't seem
> > related to (only) codecs. 

>   But for our purposes it is related IMHO and other users would depend
> on lavc. Additionally I have the feeling there is more stuff in lavc
> of which lavfi or its filters could make use of.

DSP comes to mind.

> > > I know this has its drawbacks as well, but maybe something can be
> > > done about it.
> > 
> > If you want to keep lavu small, there is still the possibility to make
> > it modular, and strip whatever is not needed through some configure
> > magic, possibly unsafe (from the ABI/API compatibility standpoint) but
> > should work fine for self-contained projects with very strict
> > footprint requirements (e.g. micro-devices).
> 

>   I don't think adding this kind of complexity is needed. If you have
> such low footprint projects, static linking should be fine and only
> pull in the objects used.

I suppose it is possible to link only the used symbols in an
application, but what if you need to deliver a low-fooprint .a/.so?
-- 
FFmpeg = Freak & F**k**g Mysterious Purposeless Earthshaking Geisha