[FFmpeg-devel] [PATCH] examples: add resampling_audio.c file
Stefano Sabatini
stefasab at gmail.com
Tue Dec 4 10:58:48 CET 2012
On date Tuesday 2012-12-04 01:54:21 +0100, Michael Niedermayer encoded:
> On Tue, Dec 04, 2012 at 12:12:53AM +0100, Stefano Sabatini wrote:
[...]
> > > * av_opt_set_int(swr, "in_sample_rate", 48000, 0);
> > > * av_opt_set_int(swr, "out_sample_rate", 44100, 0);
> > > [....]
> > > * int out_samples = av_rescale_rnd(swr_get_delay(swr, 48000) +
> > > * in_samples, 44100, 48000, AV_ROUND_UP);
> >
> > dst_rate = 44100
> > src_rate = 48000
>
> this would make:
>
> > > > > > + dst_nb_samples = av_rescale_rnd(swr_get_delay(swr_ctx, dst_rate) + src_nb_samples,
> > > > > > + dst_rate, src_rate, AV_ROUND_UP);
>
> to this:
>
> > > > > > + dst_nb_samples = av_rescale_rnd(swr_get_delay(swr_ctx, 44100) + src_nb_samples,
> > > > > > + 44100, 48000, AV_ROUND_UP);
>
> which is not what the example says
>
>
> >
> > And I'm not sure why swr_get_delay() is useful/required.
>
> If you ever feed "more" in than take out then these samples get
> buffered. Such samples would be stuck in there until flushing
> at the end without the swr_get_delay().
I realized that the swr_get_delay() in the example is useless, since it
is called before the first conversion is performed (so it is always
0). On the other hand the destination size is computed so that it
should contain *all* the converted samples, so I assume that if the
output buffer is big enough then no buffering will occurr at all. Is
this correct?
--
FFmpeg = Funny Fabulous Mega Philosofic Earthshaking Gadget
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lswr-swresample-use-AV_OPT_TYPE_SAMPLE_FMT-for-sampl.patch
Type: text/x-diff
Size: 5709 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121204/af583144/attachment.bin>
More information about the ffmpeg-devel
mailing list