[Libav-user] Converting audio sample buffer format
Brad O'Hearne
brado at bighillsoftware.com
Tue Feb 26 20:44:12 CET 2013
On Feb 25, 2013, at 12:11 PM, Brad O'Hearne <brado at bighillsoftware.com> wrote:
> However, the little nugget of info this dished out on next run might be enough to give a foothold to find the problem. It appears that the offending line that is crashing is a call to
>
> swri_realloc_audio
>
> inside of
>
> swr_convert.
>
> I've attached a small image that shows this part of the stack trace in Xcode. Does that spark any theories by the FFmpeg gurus out there?
I have what may be a stupid question here, but I've been looking curiously at another line of code upstream from my swr_convert line of code which is failing, specifically the call to this method:
int av_samples_fill_arrays(uint8_t **audio_data,
int *linesize,
const uint8_t *buf,
int nb_channels,
int nb_samples,
enum AVSampleFormat sample_fmt,
int align);
This is being called to fill my sourceData array (allocated with av_samples_alloc) with the captured data in QTSampleBuffer. In noticing that most of these libswresample functions declare buffers as:
const uint8_t *buf
what does this mean for sample data that is signed? is the fill function above performing a conversion of signed sample data to its unsigned value, or am I completely missing something about the data storage for signed/unsigned data in these buffers? If not, then what is the recommended way to perform this conversion? (I'm guessing this is swr_convert -- but this regards further upstream behavior of just filling a sample array with expected data.)
So one last follow on...if I was to resample a 32-bit buffer to 16-bit, what's the typical approach to losing precision -- is this a proportional rescale? Surely it isn't just truncating...
Thanks for your assistance,
Brad
More information about the Libav-user
mailing list