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

[Paul B Mahol]

On 5/18/13, Brad O'Hearne <brado at bighillsoftware.com> wrote:
> 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?

Is it so hard to send exact number of samples that encoder wants?

>
> Thanks for your help.
>
> Brad
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>