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
signature.asc
Description: Digital signature
_______________________________________________ FFmpeg-soc mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
