[Libav-user] QTKit -> Libav: has it ever been done?

[René J.V. Bertin]

On 27 March 2013 10:26, Carl Eugen Hoyos <cehoyos at ag.or.at> 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 ...