[Libav-user] # of audio samples, calculated vs. codec context

Brad O'Hearne brado at bighillsoftware.com
Sat May 18 22:11:09 CEST 2013

I have the following audio use-case: 

audio capture -> resample captured audio to destination format for encoding -> encode audio -> stream audio

I have developed an app which has worked decently well for fairly common sample rates (44100, 48000). However, I came across a sample rate of 16000 which is breaking the app. The problem stems from the calculation of the number of audio samples in the destination data exceeding the codec context's frame size. 

In the resampling_audio.c example, there it shows the following means to calculate the destination number of samples: 

 dst_nb_samples = av_rescale_rnd(swr_get_delay(swr_ctx, src_rate) +
                                        src_nb_samples, dst_rate, src_rate, AV_ROUND_UP);

Here are the values for these variables: 

src_rate = 16000
src_nb_samples = 512
dst_rate = 44100

and the calculated value: 

dst_nb_samples = 1412

However, the codec context's frame size is set (by the encoder, as per the documentation) at 1152, smaller than the calculated value. If I continue with the resampling and followed by encoding with these values, I see this in the console: 

[libmp3lame @ 0x10380a200] more samples than frame size (avcodec_encode_audio2)

followed by receiving a -22 return code from avcodec_encode_audio2. I tracked this into the FFmpeg source, and the console output is coming from libavcodec's utils.c line 1208 as the result of this check in the preceding line failing: 

            if (frame->nb_samples > avctx->frame_size) {

Fair enough, it doesn't want more samples than the codec specifies for its expected frame size. Just to see what would happen, I assigned dst_nb_samples the codec context's frame size value, and the audio seems mostly fine, but the associated video timing is out of sync and askew (which probably makes sense, as the timings should be wrong given using a wrong number of samples). 

So my question is how should I handle this scenario? What should the app do to accommodate the calculation for the number of samples which exceeds the frame size specified by the codec context, so that the timing isn't thrown out of whack? 

Thanks for your help. 


More information about the Libav-user mailing list