[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