[Libav-user] Audio conversion from planar to non-planar formats

Taha Ansari mtaha.ansari at gmail.com
Thu Jul 4 06:07:46 CEST 2013


You may need to compute the output number of samples, indeed the

> resampler can not guarantee that the number of samples requested will
> be returned due to caching or missing input data (e.g. when
> downsampling). Check the logic in resampling_audio.c, and check the
> swr_convert() return value in order to understand how many samples
> have been converted in your buffer.
>
> A more high-level conversion function may help to simplify the code.
>

Hi Stefano,

You are right, because I was actually downsampling (1152 bytes per frame to
1024), swr was holding back internal buffers, somehow. In
resampling_audio.c example, I can see repeated calls to swr_convert
function... I tried something different: flushing all swr buffers at the
end of conversion process, and it worked just fine.

The only downside is, it adds up to RAM - for smaller files, it is no
problem, but for large files (just for example 05 hours file), it will be
something like:

1152 -1024= 128 bytes per frame
128 * 60 = 7680 bytes per second (approx)
7680 * 60 = 460800 bytes per minute
460800 * 60 = 27648000 bytes per hour
27648000 * 5 = 138240000 bytes for five hour recording
= 131.83 MB added up inside RAM

And that is, assuming I have 60 audio frames per second (I'm sure this
figure is not correct, because I need to evaluate how sampling rate effects
above formula, as well).

So although I got it to work somehow, I am not really sure if this is the
most elegant way of doing it. What do you advice?

p.s. During test process I tried using

av_rescale_rnd(swr_get_delay(swr_ctx, src_rate) +
    src_nb_samples, dst_rate, src_rate, AV_ROUND_UP);

function, but noticed artifacts in destination audio file: plays faster,
data seems to be 'packed' inside each audio frame, giving me audible
artifacts in destination mp4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20130704/d9d34dfa/attachment.html>


More information about the Libav-user mailing list