[FFmpeg-soc] [soc]: r4390 - in afilters: Makefile.dummy af_null.c avfilter.c avfilter.h dummy.c

[Michael Niedermayer]

On Mon, Jun 08, 2009 at 10:17:51PM +0200, Vitor Sessak wrote:
> kdub wrote:
[...]
>> Modified: afilters/avfilter.h
>> ==============================================================================
>> --- afilters/avfilter.h	Sun Jun  7 20:19:38 2009	(r4389)
>> +++ afilters/avfilter.h	Mon Jun  8 06:02:12 2009	(r4390)
>> @@ -101,6 +101,20 @@ typedef struct AVFilterPicRef
>>  #define AV_PERM_REUSE2   0x10   ///< can output the buffer multiple 
>> times, modified each time
>>  } AVFilterPicRef;
>>  +
>> +typedef struct AVFilterSamples
>> +{
>> +    /* data */
>> +    void *data;
>
> I think it is better to declare it uint8_t, so you can write code like:
>
> /* advance data N samples */
> data += N << bits_per_sample;
>
>> +    int *n_samples;
>> +
>> +    void *priv;
>> +    void (*free)(struct AVFilterSamples *samples)
>> +
>> +}AVFilterSamples;
>> +
>> +
>> +
>>  /**
>>   * Adds a new reference to a picture.
>>   * @param ref   an existing reference to the picture
>> @@ -345,6 +359,17 @@ struct AVFilterPad
>>       * and another value on error.
>>       */
>>      int (*config_props)(AVFilterLink *link);
>> +
>> +
>> +    /**
>> +     * Process an audio buffer. This function is where the audio filter 
>> should
>> +     * recieve and process data
>
> recEIve
>
>> +     */
>> +    int (*start_buffer)(AVFilterLink *link);
>> +
>> +    int (*end_buffer)(AVFilterLink *link);
>> +
>> +
>>  };
>
> @Michael: If you are going to complain of having start_buffer() for audio 
> and start_frame() for video, this it the best time for it.

well, iam not sure if its the best time ...
best time would be if theres a description of the planed design on the table
or if theres enough code to infer from it the planned design.

As is its hard to comment, because i simply dont yet see where this is
heading toward

in video we have single frames at a time or single slices at a time that are
passed around, the functions are designed to handle these
frame start slice0 slice1 ... sliceN frame end

in audio we have samples, handling a single sample at a time is not
practical. And samples are not truly bundled in clear frames ...

request_frame() possibly should be extended by a int sample_count argument
draw_slice() seems useful with y & height representing
start sample and count

one big question is about the buffer layout and the awnser would
likely affect the API that makes sense to it.

there have been old discussions on mplayer-dev with rich and
possibly ivan about audio filters and buffering ...

Goals would certainly be
* filters should be simple
* core should be simple
* no or few memcpy/memmove

Things to keep in mind 
* many filters do need multiple input samples for an output sample
-> thus the filter core must be able to do some buffering magic
   giving a filter a little future and past context if needed, the
   amount of that would be requested by the filter
* audio data can be stored packed and planar, both must be supported
  there also where some disscussions on how to fit this in
  data & linesize

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20090609/58a55b07/attachment.pgp>