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

Alexander Strasser eclipse7 at gmx.net
Fri Apr 22 00:54:13 CEST 2011


Stefano Sabatini wrote:
> 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:
> > > >   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.

  I did not know that.

> > > 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?

  I built lavc without any codecs but did not yet come to analyze
what takes up the most space. I suspect if it is too big than there
is something that can be done to reduce the size.

  But, as I know now, the question remains if the people that asked
you to not depend on lavc would accept to depend on a mostly empty
version of lavc. If we get this done correctly it would not be a
matter of size, because with the alternative solution roughly the
same size would be added to lavu.

  That said, if you need the metadata API now and not having it
in lavu holds up your work on lavfi, I won't be in the way.


More information about the ffmpeg-devel mailing list