<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-01-23 14:34 GMT+02: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 dir="ltr"><span class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 23, 2015 at 2:20 PM, Anton Shekhovtsov <span dir="ltr"><<a href="mailto:shekh.anton@gmail.com" target="_blank">shekh.anton@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I used swresample only to convert format but it looks simple as brick to
me. <br><br></div></blockquote></div><br></div></span><div class="gmail_extra">Is there somewhere a hidden question "What is the problem in the first place?" :)<br><br></div><div class="gmail_extra">Probably I missed the point somewhere, but some codecs report particular frame_size so one should feed data only with blocks having this particular size. A quote from the sources about <br>AVCodecContext.frame_size<br>...<br> * - encoding: ... Each submitted frame<br> * except the last must contain exactly frame_size samples per channel.<br> * May be 0 when the codec has CODEC_CAP_VARIABLE_FRAME_SIZE set, then the<br> * frame size is not restricted.<br> *)<br><br><br>If incoming data has the same sample_rate as outgoing, no problem, swr_convert will output the same amount of frames as it accepted. But if the sample rate are different (44.1k vs 48 k), you can't avoid tricky arithmetic/logic or caching extra data somewhere unless you have plans to violate the rule. <br></div></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><div class="gmail_extra">Yes, in the code fragment above "buf_data" is assumed to hold data between invocations. Exactly that - caching somewhere<br></div><div class="gmail_extra">But it is plain memory buffer, not tricky :)<br></div></div>