[Libav-user] av_samples_fill_arrays and memory

[Brad O'Hearne]

On Apr 28, 2013, at 12:22 PM, Bruce Wheaton <bruce at spearmorgan.com> wrote:

> Why don't you just check the addresses of the data planes and know it? It's 2 minutes to check a few times.

Bruce...thanks for the advice. The data in both channel 1 and channel 2 (and as a whole), planar or not, and both in the captured sample buffer and in the source data buffer is 32-byte aligned (has been all along). I tested both. Beyond that, just for good measure, I went through the exercise of moving sample values anyway from the capture buffer to the FFmpeg-allocated source data buffer created with av_samples_alloc_array_and_samples -- so by definition it should have been aligned (checked it still though)....same result, data aligned just as before,  but same distortion. 

It appears however I've found the problem. First, after reading that aac is apparently a dead codec, I dumped it and went to libmp3lame. Ran it, same problem. Did some further debugging...revisited this. In avcodec.h, there is this doc above the frame_rate variable: 

     * Number of samples per channel in an audio frame.
     *
     * - encoding: set by libavcodec in avcodec_open2(). Each submitted frame
     *   except the last must contain exactly frame_size samples per channel.
     *   May be 0 when the codec has CODEC_CAP_VARIABLE_FRAME_SIZE set, then the
     *   frame size is not restricted.

In creating the destination data buffer for resampling and the eventual frame to be streamed, I'd been using the frame_size value computed by libavcodec in avcodec_open2 as my destination number of samples (which the doc would suggest is what should be done -- and in my journeys through code snippets and blogs encountered in the series of tubes, it was suggested this was a proper approach). I otherwise would not have thought anything of it had I not been checking this computed value and noticed that libmp3lame results in a value of 1152, which was different than what I'd seen coming off other codecs. So I ditched using the frame_size, went back to using the number of samples as received by capture. Don't know what to make of the doc above. My frames contain 512 samples, while the frame_size of the codec context is 1152. 

Result, clear audio, both alone and combined with video, both written to a local file and streamed. More tests are needed to verify consistently problem-free function, but seems to work as desired. 

Brad