<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 21, 2017 at 11:38 PM, Andy Shaules <span dir="ltr"><<a href="mailto:bowljoman@gmail.com" target="_blank">bowljoman@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="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Jul 19, 2017 10:59 AM, "Kerry Loux" <<a href="mailto:louxkr@gmail.com" target="_blank">louxkr@gmail.com</a>> wrote:<br type="attribution"></div></div><blockquote class="m_-5682883991200687215quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hello all,<div><br></div><div>I have an application where I am opening an audio file that was sampled at 44100 Hz, decoding it, resampling to 16000 Hz, encoding it again (AAC) then broadcasting it on an RTSP stream.  On the receiving end, I decode the incoming AAC packets and render them.</div><div><br></div><div>The rendered audio is very slow.</div><div><br></div><div>It appears to me that the problem is related to the AVFrame.nb_samples field.  When I read a packet from file (using av_read_frame()), the packet size is 1024 samples (at 44100 Hz).  After I resample to 16000 Hz, I have ~1/3 the samples that I had in the original frame (as expected).  Then, the frame gets encoded, streamed and decoded.  After decoding, the AVFrame.nb_samples is 1024 when I expect it to be 372 or so.  The AVCodecContext passed to avcodec_receive_frame() has frame_size = 1024, so I assume that the decoder is setting the number of samples of the decoded frame to 1024 regardless of the number of samples actually contained in the input packet?  Or maybe it's my job to ensure that the input packets always contain 1024 samples?</div><div><br></div><div>I'm not entirely sure what's going on.  My thoughts include:</div><div>- Try buffering 3x number of input frames prior to resampling so the resulting frame will be ~1024 samples</div><div>- Calculate the number of samples manually (how to do this is unclear) and override the number of samples assigned by the decoder (this seems wrong...)</div><div><br></div><div>Any recommendations?  Can I just stick multiple frames together in a larger buffer prior to resampling (i.e. calling swr_convert())?</div><div><br></div><div>Thanks,</div><div><br></div><div>Kerry</div></div>
<br></div></div><span class="">______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://ffmpeg.org/mailman/list<wbr>info/libav-user</a><br>
<br></span></blockquote></div><br></div></div><div class="gmail_extra" dir="auto"><br></div><div class="gmail_extra" dir="auto">2 things perhaps. what sample rate does your sdp advertize? what scale are your audio rtp timstamps? </div></div>
<br>______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">http://ffmpeg.org/mailman/<wbr>listinfo/libav-user</a><br>
<br></blockquote></div>SDP correctly advertises 16000 Hz and my timestamps are scaled to microseconds.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Kerry</div></div>