[FFmpeg-devel] [PATCH] Per-frame metadata
michaelni at gmx.at
Sat Apr 23 11:31:15 CEST 2011
On Wed, Apr 13, 2011 at 12:51:17AM +0200, Stefano Sabatini wrote:
> On date Tuesday 2011-04-12 22:02:40 +0200, Stefano Sabatini encoded:
> > On date Tuesday 2011-04-12 20:38:18 +0200, Alexander Strasser encoded:
> > > > > Would it make sense to move metadata to libavutil rather than to
> > > > > libavcodec?
> > > > >
> > > > > For example you may need to display metadata from a lavfi filter.
> > > >
> > > > 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.
> > 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.
> > > 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).
> Elaborating more: for example if you only need libswscale, you may
> strip all which is not used from libavutil (crypto, file, audio utils,
> etc.), thus significantly decreasing the footprint, which is not
> possible with the current monolithic libavutil.
with static libs the linker will strip unused parts
with shared libs ABI/API will prevent disabling of parts
so i dont see what one would gain from compile time disabling of parts
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel