[Libav-user] av_samples_fill_arrays and memory

Paul B Mahol onemda at gmail.com
Fri Apr 26 21:47:18 CEST 2013


On 4/26/13, Brad O'Hearne <brado at bighillsoftware.com> wrote:
> Last night I delved into the source code looking for the exact handling of
> pointers and population of audio sample arrays. I had a question from the
> av_samples_fill_arrays in samplefmt.c, specifically lines 167-169:
>
>     audio_data[0] = (uint8_t *)buf;
>     for (ch = 1; planar && ch < nb_channels; ch++)
>         audio_data[ch] = audio_data[ch-1] + line_size;
>
> This makes perfect sense for the purpose of this method -- given that it
> takes one buffer as a parameter (buf), all sample data must be contained
> within it, and each channel resides in contiguous memory. So again, this
> code does exactly what I'd expect it to. I got to thinking however about the
> scenario where someone has planar sample data, each plane which is
> completely filled with the proper number of samples and properly structured,
> but whose channels (1, 2, ...n) aren't in contiguous memory.
>
> So for instance, say samples are derived from an outside source (such as
> capture), and channels/planes are delivered and properly structured, and
> code was not to use the av_samples_fill_arrays above, but rather set
> pointers themselves. This would seem right:
>
> audio_data[0] = channel1;
> audio_data[1] = channel2;

and are those aligned?

>
> But what if the above was done, yet this was also true:
>
> audio_data[1] != (audio_data[0] + line_size)
>
> The audio_data array has proper pointers to each channel -- and each channel
> may be properly aligned within. But what if multiple channels aren't in
> contiguous memory? Is that going to be an issue in using the audio_data
> array at any point, perhaps later in encoding?
>
> I think this what may be what Alex was alluding to in a previous post.

Contiguous memory or not AFAIK should not matter.

Instead of setting pointers, you could memcpy data instead, and if
done correctly
your issue should be solved.

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


More information about the Libav-user mailing list