On Apr 25, 2013, at 2:29 AM, Paul B Mahol <[email protected]> wrote: > This is last time I repeat this: Aligment set by align is 32 BYTES and > not 4 BYTES > or 32 BITS.
If you could post a reference or where in the FFmpeg doc (which I've looked for and haven't found) which explains exactly what this 32 bytes relates to with respect to sample / planar structure, that would help me greatly. I've mentioned in a few other posts that I'm having to bridge two different definitions of alignment -- one from FFmpeg and another from QuickTime. Perhaps clarification on this point would lead to the solution. > Because this does not happen with any of ffmpeg libraries or tools I can > conclude with 1000% confidence that bug is in your code. Thank you for looking at my code, which I greatly appreciate. I take it from your comment that no specific problem with the code was apparent (doesn't mean it isn't there, just nothing jumped out). > If both source and destination are planar you need to check that align > argument > for both of them is correct, and also that you give correct number of > samples (per each channel) > to every swr_convert() call. The correct number of samples are coming in per call. As for the alignment, I've experimented with both 0 and 1 values for that parameter, with no difference -- also the current alignment settings worked just fine for the incoming source data when resampled to a different output sample format. I would have expected a problem in source alignment handling to manifest itself regardless of the destination sample format, but perhaps that's where the problem lies. I think once I understand more clearly exactly how that alignment relates to plane structure and byte storage, I'll be able to eliminate it as an issue. Thank you for taking the time to look at this code. If anything else arises that might uncover the problem, let me know. Thx, Brad _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
