[FFmpeg-devel] [PATCH] lavfi audio framework

[Stefano Sabatini]

On date Saturday 2010-07-31 10:43:53 -0700, S.N. Hemanth Meenakshisundaram encoded:
> On 07/30/2010 01:29 AM, Stefano Sabatini wrote:
> > On date Thursday 2010-07-22 01:18:36 -0700, S.N. Hemanth Meenakshisundaram encoded:
> >   
> >> [...]
> >>  #define MAX_REGISTERED_AVFILTERS_NB 64
> >>  
> >>  static AVFilter *registered_avfilters[MAX_REGISTERED_AVFILTERS_NB + 1];
> >> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> >> index a9bec02..faeb3b6 100644
> >> --- a/libavfilter/avfilter.h
> >> +++ b/libavfilter/avfilter.h
> >> @@ -38,6 +38,7 @@
> >>  
> >>  #include <stddef.h>
> >>  #include "libavcodec/avcodec.h"
> >> +#include "libavcodec/audioconvert.h"
> >>  
> >>  /**
> >>   * Return the LIBAVFILTER_VERSION_INT constant.
> >> @@ -66,7 +67,7 @@ typedef struct AVFilterPad     AVFilterPad;
> >>   */
> >>  typedef struct AVFilterBuffer
> >>  {
> >> -    uint8_t *data[8];           ///< buffer data for each plane
> >> +    uint8_t *data[8];           ///< buffer data for each plane/channel
> >>      int linesize[8];            ///< number of bytes per line
> >>      int format;                 ///< media format
> >>  
> >> @@ -130,6 +131,32 @@ static inline void avfilter_copy_picref_props(AVFilterPicRef *dst, AVFilterPicRe
> >>  }
> >>  
> >>  /**
> >> + * A reference to an AVFilterBuffer for audio. Since filters can manipulate the
> >> + * origin of an audio buffer to, for example, reduce precision without any memcpy,
> >> + * sample format and channel_layout are per-reference properties. Sample step is
> >> + * also useful when reducing the number of channels, etc, and so is also per-reference.
> >> + */
> >> +typedef struct AVFilterSamplesRef
> >> +{
> >> +    AVFilterBuffer *samples;      ///< the audio buffer that this is a reference to
> >> +    uint8_t *data[8];             ///< audio data for each channel
> >> +    int linesize[8];              ///< number of bytes to next sample
> >> +    int64_t pts;                  ///< presentation timestamp in units of 1/AV_TIME_BASE
> >> +
> >> +    int64_t channel_layout;       ///< channel layout of current buffer
> >> +    int64_t sample_rate;          ///< samples per second
> >> +    enum SampleFormat sample_fmt; ///< sample format
> >> +
> >> +    int samples_nb;               ///< number of samples in this buffer
> >> +    /* Should this go here or in the AVFilterBuffer struct? */
> >> +    int size;                     ///< size of buffer
> >> +
> >> +    int perms;                    ///< permissions
> >> +
> >> +    int planar;                   ///< is buffer planar or packed
> >> +} AVFilterSamplesRef;
> >>     
> > The alternative here if we don't want to duplicate the generic fields:
> > AVFilterBuffer -> actually contains the data
> >
> > AVFilterBufferRef[erence] in place of AVFilterSamplesRef and
> > AVFilterSamplesPic.
> >
> > Then we may share the common fields (perms, size, pts, buffer, data,
> > linesize), use a media type field and put the media specific stuff in
> > an union.
> >
> > This requires more work to re-adapt the patch, but will avoid evil
> > code duplication.
> >
> > Michael?
> >
> > Same technique may be used for AVFilterLink.
> >
> > [...]
> >
> > Regards.
> >   
> 
> I noticed that sample_rate is only an int or uint32_t in other places,
> will change it in lavfi too to uint32_t. Also 'int format' can be moved
> from AVFilterBuffer to AVFilterPicRef since SamplesRef already has it
> and only two filters (vsrc_buffer and vf_overlay) need to be changed to
> use format field in PicRef instead of AVFilterBuffer.
> 
> Also I need to add pos to AVFilterSamplesRef.
> 
> With those two changes, things should fit nicely into unions and making
> AVFilterBufferRef will be simpler.
> 
> pic/samples, data, linesize, format, pts, pos and perms common,
> AVRational pixel_aspect(2 integers) in PicRef and channel layout (int64)
> in SamplesRef forming a union,
> 
> 4 other ints in PicRef (w, h, interlaced, top_field_first) and 4 ints in
> SamplesRef (samples_nb, size, planar and sample_rate).
> 
> Can I go ahead with this?

Perfect. And as usual split the changes in separate patches/threads,
one for each atomic logical change.

Regards.
-- 
FFmpeg = Foolish and Fucking Marvellous Picky Entertaining Gigant