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

[Stefano Sabatini]

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

* colorspace definitions and utilities: use cases are both libswscale
  (colorspace support), and libavfilter (colorspace manipulation
  filtering)

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

Audio sample format utils, pixel format/image utils have been already
moved to libavutil.

DSP and metadata are possibly the most demanding in terms of memory
requirements, would be interesting to measure in practice which is
their memory footprint.

lavc in lavfi can be possibly required per-filter, as for metadata
this would require a non-conditional dependency, since we would need
to use the metadata definition in the AVFilterBufferRef struct.

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.

lavfi/lavc dependency status is: no running-time dependency, there is
only one compile-time dependency on AVFrame in
libavfilter/vsrc_buffer.h, which I plan to remove.

We'll re-add a running-time dependency on libavcodec when introducing
audio filtering, which depends on the libavcodec conversion/resampling
API, but this will be removed as we'll redesign it (maybe creating a
separate libavresample), so for practical reasons we can ignore this
dependency for now.

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.
-- 
FFmpeg = F**king and Fiendish Multimedia Perennial Excellent Gymnast