[FFmpeg-devel] [RFC] libavfilter audio - af_resample

Måns Rullgård mans
Sun Jul 11 00:37:54 CEST 2010


Michael Niedermayer <michaelni at gmx.at> writes:

> On Sat, Jul 10, 2010 at 12:05:43PM +0100, M?ns Rullg?rd wrote:
>> "S.N. Hemanth Meenakshisundaram" <smeenaks at ucsd.edu> writes:
>> 
>> > 2. Earlier, the channel conversion functions only worked for short
>> > (SAMPLE_FMT_S16) pointers but writing a different version for each
>> > will increase the number of functions required by 5x. To get around
>> > this, I have chosen to always convert incoming audio data to
>> > SAMPLE_FMT_S16. Most of the times, this conversion is not necessary
>> > since most codecs output S16 data. Once we ensure data is in S16
>> > format, channel downmix/upmix is done and finally this data is
>> > converted to required output sample format (in case it is not
>> > SAMPLE_FMT_S16).
>> 
>> Entirely unacceptable.
>
> rude comment and entirely unproductive
> Hemanth is actually doing quite good work having 
> nb_sample_fmts^2 * nb_channel_layouts^2 pieces of code is not practical.
> having just s16 is also not ideal
> i would suggest we support s16->s16 and float->float mixers and than a
> full set of X->Y sample format converters to connect to them
> sample formats different from s16 and float are rater rare so this should
> be ok

The interface still has to accept any format for input and output.
Converting everything to s16 or float internally, to favour speed or
accuracy, is probably acceptable.  It should nevertheless be designed
such that specific conversions can be easily added later.

>> > 4. There is now a 1. existing stereo to mono, 2. existing mono to
>> > stereo, 3. generic mono downmix that uses only 2 of the incoming
>> > channels, 4. generic stereo downmix that uses only 2 of the incoming
>> > channels and 5. the existing stereo to ac3 (5.1) converters.
>> >
>> > Please review and comment. The A52 library seems to have the required
>> > formula for a lot of downmix/upmix fuunctions and it also uses
>> > separate routines for different channel conversions. I also plan to
>> > add additional channel conversion routines using mixing formulae from
>> > this and other sources.
>> > All downmix/upmix routines will have the same return type and argument
>> > list and a function pointer in the context gets initialized to the
>> > required routine whenever input channels change.
>> 
>> I dislike the idea of having basic mixing functionality only available
>> as a full-blown filter.
>
> i do like having just a single api through which any mix+sample convertion
> can be requested and then the best and fastest implementation for this
> is automatically selected
>
> The reason why i like this, is that a single simple API is easy to document
> remember and use. Also its very easy to export the subparts individually
> at a later point if there is anyone wanting that.

That is exactly what I said.  Being able to do a simple conversion
without invoking all the might of libavfilter is desirable.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list