On Feb 25, 2013, at 9:46 AM, "René J.V. Bertin" <[email protected]> wrote:
> From what I understand the main contributor(s) to this mailing list read(s) > the posts in a way that makes me think back to the tools I used in the very > early nineties. So using html, attachments (etc) are likely to be missed. If attachments would be missed, I'll stick to URLs next time. As of a few minutes ago, everyone should have a direct URL to view the source. > Have you tried running your code in the debugger, stepping into, through and > out of swr_convert? I'm still under 10.6 so don't know Xcode 4.5, but I am > pretty sure that if you add the ffmpeg source tree to your Xcode project the > integrated debugger will pick up the relevant sources. All of my code is running in the debugger, but I'm linking to the FFmpeg libraries built on the command line. In other words, I can step to the library calls themselves, but not inside, and the call is completely crashing the app, with no more information than an EXC_ARITHMETIC (presumably divide by 0) error. I had hoped to avoid debugging through FFmpeg source for a few reasons: - I suspect it is going to be quite a job to pull all of the source into my project without causing the compiler to ball up in the corner and weep...think there may be a time consuming project configuration task there, which is going to be a similar experience of wandering about in the dark for a few days. - After manually reading through the source code path inside the swr-convert call, it seemed likely that even if I found the line which resulted in a divide by zero, I'm still not sure I'd even know what to do with it, or what the expectation of the prior code was (other than, of course, divide by zero). If there's no other alternative, then I suppose I'll have to go that route. But in the meantime, I guess I'd ask a simpler question: - swr_convert is crashing -- not returning an error, mind you, but outright crashing. For those maintainers fluent in the code behind this call, what parameter combination could possibly result in such an unhandled crash? Any inkling? I have a really uneducated, blind stab in the dark at this, which might be completely off, but here goes. Given that allocating the sourceData and destinationData arrays succeeded, and given that the filling of the sourceData array from the QTSampleBuffer data also succeeded, I'm wondering if the issue lies in the difference in sample formats: AV_SAMPLE_FMT_FLT vs. AV_SAMPLE_FMT_S16. I had wondered if the formula being used for the conversion of unsigned to signed values (and I'm not even sure if this floating point format is unsigned or not) but I got to thinking that maybe a divide by zero might arise from that process. Does this scan, or is it not a possibility? Thanks, Brad _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
