[Libav-user] Audio sample rate conversion and fixed frame size

Max Vlasov max.vlasov at gmail.com
Wed Jan 21 20:51:16 CET 2015


Thanks for the suggestion, I noticed somebody mentioned fifo in a forum,
but I could not find working examples. At first swr_convert looked like the
easier approach comparing to manual resampling, but with all those
complications I'm not longer sure

On Wed, Jan 21, 2015 at 4:15 PM, Gonzalo Garramuno <ggarra13 at gmail.com>
wrote:

> You should take a look at the fifo functions that would cache the audio
> for you and you would feed the encoder the number of samples you see fit.
>
> 2015-01-21 8:31 GMT-03:00 Max Vlasov <max.vlasov at gmail.com>:
>
>> Hi,
>>
>> When sample rate conversion is needed, one can face another problem. Some
>> codecs reports they don't have CODEC_CAP_VARIABLE_FRAME_SIZE capability so
>> accept only some fixed frame size buffers with an exception for the last
>> block. I tried to find a working example, but it seems they often lack full
>> support for such cases. Obviously one may cache converter results and
>> output by necessary blocks, but this involves supporting several buffers
>> for planar data and knowing exact format.
>>
>> With own experiment I tried to do the following:
>> 1) For the required dest_frames use infamous formula
>>   av_rescale_rnd(swr_get_delay(...) + inp_frames,...
>> trying to detect the number of input frames (inp_frames here) necessary
>> for at least dest_frames (src_frames). Either with binary search or just by
>> using an incrementer
>> 2) call swr_convert with src_frames as the number of input frames, but
>> pass exactly dest_frames as output. So the converter have to cache some
>> input frames since I limited the output buffer.
>>
>> The approach worked at least for some cases, but there are problems I
>> faced:
>> - I have to use much larger dest_frames (currently it is twice as large).
>> Otherwise sometimes swr_convert reports making several bytes less than I
>> requested (1535 instead of 1536). I suspect this is because swr_get_delay
>> is approximate in most cases. The question is whether should I fix this
>> multiplier (x2) or use some other approach for this detection.
>> - I can not figure out how correctly get the last cached frames from the
>> converter and not violate the rule for frame_size (it should have the same
>> size with every step except the last one). When I fed the last input bytes,
>> I probably already get non-standard output so another call with Null and 0
>> as input will produce extra non-standard block.
>>
>> Any help will be appreciated
>>
>> Thanks,
>>
>> Max
>>
>> _______________________________________________
>> Libav-user mailing list
>> Libav-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/libav-user
>>
>>
>
>
> --
> Gonzalo Garramuño
> ggarra13 at gmail.com
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20150121/7c140a73/attachment.html>


More information about the Libav-user mailing list