On Feb 25, 2013, at 12:11 PM, Brad O'Hearne <br...@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
_______________________________________________
Libav-user mailing list
Libav-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/libav-user
