<div dir="ltr">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<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 4:15 PM, Gonzalo Garramuno <span dir="ltr"><<a href="mailto:ggarra13@gmail.com" target="_blank">ggarra13@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-21 8:31 GMT-03:00 Max Vlasov <span dir="ltr"><<a href="mailto:max.vlasov@gmail.com" target="_blank">max.vlasov@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div>Hi,<br><br></div><div>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. <br><br>With own experiment I tried to do the following:<br>1) For the required dest_frames use infamous formula <br>  av_rescale_rnd(swr_get_delay(...) + inp_frames,... <br>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 <br>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. <br><br>The approach worked at least for some cases, but there are problems I faced:<br>- 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.<br>- 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. <br><br></div>Any help will be appreciated <br><br></div>Thanks,<br><div><div><br>Max<br></div></div></div>
<br></div></div>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div>Gonzalo Garramuño<br><a href="mailto:ggarra13@gmail.com" target="_blank">ggarra13@gmail.com</a></div>
</font></span></div>
<br>_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a><br>
<a href="http://ffmpeg.org/mailman/listinfo/libav-user" target="_blank">http://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br></blockquote></div><br></div>