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

[Michael Niedermayer]

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
of libavutil

[...]
-- 
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
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110423/badfa2b2/attachment.asc>