[FFmpeg-devel] [PATCH] lavfi: add audio eval signal source

[Michael Niedermayer]

On Sat, Oct 15, 2011 at 12:47:00PM +0200, Stefano Sabatini wrote:
> On date Thursday 2011-10-13 10:04:34 +0200, Nicolas George encoded:
> > Le duodi 22 vendémiaire, an CCXX, Stefano Sabatini a écrit :
> > > + at section aevalsrc
> > 
> > Cool idea, thanks.
> > 
> > > +Generate an audio signal generated by an expression.
> > 
> > The Department of Redundancy Department wants to thank you for having
> > generated such an awesome introduction line.
> > 
> > > +This source accepts in input an expression, which is evaluated and
> > > +used for generating a mono audio signal.
> > 
> > "to generate", I believe.
> > 
> > > + at table @option
> > > + at item E, PI, PHI
> > > +the corresponding mathematical approximated values for e
> > > +(euler number), pi (greek PI), PHI (golden ratio)
> > 
> > Shouldn't it be made part of the eval system once and for all?
> > 
> > > + at item n
> > > +the number of sample, starting from 0
> > > +
> > > + at item t
> > > +time of the sample expressed in second, starting from 0
> > 
> > The place of "the" is moving. I fond the second one easier to understand.
> > 
> 
> > > +Generate a sin signal with frequence 4400 Hz:
> > > + at example
> > > +aevalsrc="sin(4400*t)"
> > 
> > sin(4400*t*2*PI), or it will be 700 Hz.
> 
> Ouch!
> 
> > 
> > > +    int64_t chlayouts[] = { AV_CH_LAYOUT_MONO, -1 };
> > 
> > As Michael said, the possibility to generate several channels would be cool.
> > OTOH, it could be left to a separate amerge filter: (n channels, p channels)
> > -> n+p channels.
> 
> Extended. I opted for the syntax:
> expr1|expr2|...|exprN:opts
> 
> Assumptions: ":" and "|" must not appear in the expressions.
> 
> Right now the source generates planar audio, it shouldn't be hard to
> add support for packed if people want that.
>  
> > > +    eval->var_values[VAR_N] = eval->n;
> > > +
> > > +    /* evaluate expression for each single sample */
> > > +    for (i = 0; i < eval->nb_samples; i++) {
> > > +        eval->var_values[VAR_T] = eval->var_values[VAR_N] * (double)1/eval->sample_rate;
> > > +        *((double *) samplesref->data[0] + i) =
> > > +            av_expr_eval(eval->expr, eval->var_values, NULL);
> > > +        eval->var_values[VAR_N] = eval->n++;
> > > +    }
> 
> > 
> > The computation for VAR_N is wrong by one except on the first round because
> > n++ is postincrementation, not preincrementation. I believe it could be more
> > clearly written as:
> > 
> >     for (i = 0; i < eval->nb_samples; i++) {
> >         eval->var_values[VAR_N] = eval->n;
> >         eval->var_values[VAR_T] = eval->var_values[VAR_N] * (double)1/eval->sample_rate;
> >         *((double *) samplesref->data[0] + i) =
> >             av_expr_eval(eval->expr, eval->var_values, NULL);
> >         eval->n++;
> >     }
> > 
> > with possibly the eval->n++ part of the third for clause.
> 
> Fixed.
> 
> ...
> 
> Complete example command:
> $ ffplay -f lavfi "aevalsrc=abs(sin(1/10*2*PI*t))*sin(440*2*PI*t)|(1-abs(sin(1/10*t*2*PI)))*sin(450*2*PI*t + PI*sin(2*PI*t)), aconvert=s16:stereo:packed"
> 
> note that the aconvert=s16:stereo:packed is (unfortunately) required
> or there will be a conversion to mono, as the auto-inserted aconvert
> merges all the formats supported by aconvert with the output filter
> formats, and this is done *before* to merge the formats supported by
> aevalsrc and aconvert (but I'm thinking to add a new aconvert mode for
> forcing aconvert to use the same input formats whenever it's
> possible).

Theres no way this can happen unless theres a bug

(input supporting 2ch/dbl/planar)
(output supporting various 16bit packed formats)

at this point a mismatch exists and a convert filter is inserted
a convert filter supports everything as input and everything as output
and this gives us a solution and no further format messing

also when there are problems with aconvert i suggest to switch
to swresample, which is the only converter used by ffplay.c and
ffmpeg.c since a while and which supports all layouts and sample
formats without mistakely switching to mono

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20111015/2d909285/attachment.asc>