[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