[FFmpeg-devel] [RFC] lavu/lavc/lavfi dependencies

Michael Niedermayer michaelni at gmx.at
Sat Apr 23 20:09:29 CEST 2011


On Sat, Apr 23, 2011 at 04:48:19PM +0200, Stefano Sabatini wrote:
> On date Saturday 2011-04-23 11:46:09 +0200, Michael Niedermayer encoded:
> > On Wed, Apr 13, 2011 at 01:07:44PM +0200, Nicolas George wrote:
> > > Le tridi 23 germinal, an CCXIX, Stefano Sabatini a écrit :
> > [...]
> > > > My argument is that metadata is not codec-specific, so I consider
> > > > libavutil a better place (and at least per-frame metadata filtering
> > > > looks senseful, even if I can't imagine other uses outside libavcodec
> > > > at the moment).
> > > 
> > > I perfectly understand the argument, and in fact I agree with it. I will
> > > wait a bit more to see if there are other remarks, especially from Michael.
> > 
> > I favor libavcodec over libavutil ATM for the API, if avcore still
> > existed it would be an option
> 
> OK, so let's consider which would be at this point the possible parts
> of libavcodec which may be moved to libavutil:
> 
> * metadata: use case is lavfi per-frame metadata rendering



> 
> * DSP/FFT: use case is again lavfi, DSP/FFT can be used for filtering
>   operations (e.g. frequency-domain filtering), and for improving
>   performances

FFT is quite generic and could be moved to lavu


[....]


> 
> * misc stuff (e.g. see the pict_type patch)

enums are a non issue as they dont increase binary size and thus
dont bloat libavutil


[...]
> j-b from the VideoLAN project told me that having lavfi depend on lavc
> was making hard/impossible to use it in VLC. I would like to have a
> more in-depth explanation of this constraint, and in general some
> feedback from library users regarding these dependency issues.

Iam interrested in j-bs oppinion as well

[...]

> For users which need a stripped down libavutil dynamic library, we may
> enable a *non-binary compatible* configurable libavutil-lite, for use
> in custom projects.

the plan of a libavutil-lite is probably a good idea if we cant keep
all the stuff out that non MM application domt want

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad
-------------- 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/f8c2c39c/attachment.asc>


More information about the ffmpeg-devel mailing list