[Libav-user] Resample frame to specified number of samples

[Andy Shaules]

On Jul 19, 2017 10:59 AM, "Kerry Loux" <louxkr at gmail.com> wrote:

Hello all,

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.

The rendered audio is very slow.

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?

I'm not entirely sure what's going on.  My thoughts include:
- Try buffering 3x number of input frames prior to resampling so the
resulting frame will be ~1024 samples
- 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...)

Any recommendations?  Can I just stick multiple frames together in a larger
buffer prior to resampling (i.e. calling swr_convert())?

Thanks,

Kerry

_______________________________________________
Libav-user mailing list
Libav-user at ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user



2 things perhaps. what sample rate does your sdp advertize? what scale are
your audio rtp timstamps?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20170721/2208e166/attachment.html>