Weird h264 Audio behaviour

A few years ago we ran into this issue with our audio department seeing our MP4s out-of-sync.
We found the Apple Dev article and a little more from what I remember.

I believe now, MP4s have a value set for audio priming in the MP4’s header. But Apple didn’t write QTKit/QuickTime 7 to read this value, and always assumes 2112 samples for audio priming. I think Apple’s development of QTKit pre-dated the MP4 spec addressing this issue.

So here is the fun part, most AAC encoders use 1024 samples, which is why we see the wrong offset in some apps. QTKit has been deprecated since Mac OSX Lion. And developers were told to transition to AVFoundation, which handles all of this MP4/AAC mess correctly. But, apps like Media Composer and Pro Tools were using QTKit Apple stopped shipping it with MacOS.

But I’m guessing because that took so long and because of complaints, some apps like AME did some janky offset to compensate. However by doing this offset to make it “right” in QTKit. You then makes it out-of-sync in anything using AVFoundation/anything modern.

So you get into the pickle and angry meeting on why the client’s iPhone, Pro Tools, and QT7 can’t all be in sync at the same time.

It seems to be getting better now that clients aren’t trying to play files back in QT7 and developers have been forced to re-write using AVFoundation. But we try to discourage importing the MP4 files internally to avoid this headache.

I always imagine a high fidelity future where we start using FLAC audio with MP4s. It is supported and whenever I try it, it always seems to work. But yet to see it take off.

2 Likes