On 27 March 2013 10:26, Carl Eugen Hoyos <[email protected]> wrote: > No, I am not saying that. > (I don't know.)
Heh, I'd be surprised if it does exist. If indeed very few FFmpeg devs have OS X hardware, what would be the reason of existence for such a decoder? :) > It is of course possible that QTKit uses a completely > different format, but one way to find out is to test > your resampling wrapper code with a decoder for which > you know the actual format. Yes. And in parallel, one could dump the captured output, not in some container format as I suggested before, but the raw QTSampleBuffers. It shouldn't be too hard to extract the necessary API (structure definition(s), stub functions, etc) so that one can have platform-independent code for locating the data of interest in those imported QTSampleBuffers and feed it into libav. Provided of course that the encoding part of Brad's code doesn't make use of OS X specific programming language features like ARC. (Which is keeping me from playing with his code because it won't build on my older OS version ...) > Note that an endianess issue is very unlikely because FFmpeg > only supports native endian audio formats (as opposed to So if the QTSampleBuffers contain non-native endian data the FFmpeg-encoded output will inevitably be the "wrong way around" unless it is converted before being encoded. Not? > codecs), a signed / unsigned problem is of course possible > but this should be relatively easy to verify. There must be something relatively simple that underlies Brad's problem. After all, video encoding works fine, so his general approach cannot be completely wrong ... _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
