AAC encoder delay

My bad. Sorry, they all use the edit list atom (unless it changed recently) !

I don't remember encountering any file with the sgpd atom ...

Seems that support for this in FFmpeg is quite recent as well (4 months) so this might explain to lack of files having that.

You can encode with FFmpeg (or whatever other library) and mux with AVAssetWriter. That way you're sure QuickTime will read in sync.

i personally don't like to use the AAC codec, performance and quality wise, they're very lacking. opus or vorbis iss what i use with lossy but i regularly build my own custom version ffmpeg with a lot of fixes.

i agree with others, whatever you're using to mux is the issue

converted a flac to default aac encoder, quicktime had no issues playing or a delay.

ffmpeg started on 2017-07-10 at 13:05:35
Report written to logs/log_ffmpeg170710.log
Input #0, flac, from /Volumes/Apps_Media/Music/Genesis/Genesis_Land_Of_Confusion.flac:
  Duration: 00:04:46.23, start: 0.000000, bitrate: 975 kb/s
    Stream #0:0: Audio: flac, 44100 Hz, stereo, s16
Stream mapping:
  Stream #0:0 -> #0:0 (flac (native) -> aac (native))
Press [q] to stop, [?] for help
Output #0, adts, to 'test.aac':
  Metadata:
    encoder         : Lavf57.75.100
    Stream #0:0: Audio: aac (LC), 44100 Hz, stereo, fltp (16 bit), 128 kb/s
    Metadata:
      encoder         : Lavc57.100.103 aac
size=    4625kB time=00:04:46.23 bitrate= 132.4kbits/s speed=49.8x 
video:0kB audio:4541kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.855953%
[aac @ 0x7fedde836c00] Qavg: 952.935

Hi iPad_dev, would you be able to test with one of the two files I posted above. This issue is regarding video / audio sync, so you are certainky not going to notice it unless you have picture. Many thanks, Mark

The thing I noticed with the edit list is that its not counteracting the Quicktime 2112 assumption. In the case of the latest ffmpeg, when encoding using the Audiotoolbox aac codec, the edit list atom has a value set at 2112, but the Quicktime decoder is applying that and also applying an additonal assumed 2112, so the combined delay removal means a loss of 2112 samples overall. At least thats my reading of it. Very crudely, if this edit list is edited with Atom Inspector to change the 2112 to 0, then the file plays in sync (there are issues with the remaining samples not being properly trimmed, but thats a whole other problem!).

Aon on its own the edit list atom does not appear to be enough to force Quicktime to ony read its value. This is where the sample group atoms come in I think, but as said before, Quicktime appears to not be responding to these correctly either.

In QuickTime X it plays the first beep, but if I seek back to the begin and play again it cuts it a bit. Weird. If I export the file in QuickTime it removes the edit list and sample group atom, but it plays the same as before (first time in sync, second time out of sync), so it seems a bug unrelated to the sample group atom.

You should send a bug report to Apple. I'll try to send one too if I have time.

Thats an intersting route. How would I employ the AVAssetWriter step? I'm OK with the ffmpeg steps to produce the streams, but I'm not a developer unfortunatly so wouldn't be able to write my own mux application.

Thats odd, I've never had the first beep play in any Quicktime player, 7 or X or 3rd party. So you encoded the test file I sent with ffmpeg using built in aac codec (or Audiotoolbox aac) and you heard the first beep in QT X? Thats so weird.

I don't think there is a sample group atom at all is there? Latest snapshot build of ffmpeg does not produce a mov with a sample group atom for me. What build are you using? Do you def see a sample group atom for the sound track?

I'd love to post a bug report to Apple, but I'm still a little unsure how to describe the issue beyond saying the file is not being played back in sync. You've been very kind with your time, but could I ask one more favour and ask how you would describe this to Apple so I can make a report which goes to the right place.

Many thanks

Mark

I encoded with the latest HandBrake master branch code, that adds both the edit list and the sample group atom.

There is no way a FFmpeg encoded file is going to work correctly if it doesn't include the sample group atom.

Thanks galad, when I tried it a week or so ago, I could not get a file with the sample group atom, but as you say its working now.

Altghough the file does decode in sync in QTX (although trimming end is not working, so clips run overlong and produce black frame at end), it still sufferes the same issue as before in QT7, so it does seem that that player won't support the 'modern' Apple delay method no matter what. Shame as its a much more useful player than QTX in my opinion.

It seems many thrid party QT players are based on that same underlying tech too - Switch player also does not read the sample group atoms.

Is this all to do with the move from QTKit to AV Foundation? QTKit can't understand sample group delay signaling, whereas AV Foundation can?

Ultimatly, we need ffmpeg dev's to add the sample group code anyway.

Right, it doesn't work in QTKit and QuickTime 7. But these are deprecated and 32bit, I guess it's time to switch to AVFoundation now that it's almost feature complete.

Thanks to all those you helped and offered their time to look into this. I feel I've probably hit a bit of a brick wall. The ffmpeg developers don't seem overly concerned with the lack of 'compatibility' with AVFoundation or QTKit based decoders. I'm sure its a complex situation which I don't fully understand, so to be fair to them, they no doubt have their reasons.

I'm not a developer, so I can't be a huge amount of help in offering up a solution. I still think there are some issues which AV Foundation / QT X need to address on their side, but with the right atom structure from ffmpeg I do think it could be much closer to a correct decode.

Thanks
Mark

UPDATE

A very helpful developer has submitted a patch which means ffmpeg (as of 10th Aug 2017) now produces files with the sample group atoms. This is as per Apple's own document.

The good news is that this now means the files play perfectly in sync in AV Foundation based decoders (QT 10.x). The sad news is that QT7 / QT Kit based decoders do not honour this atom and still default to 2112 despite its presence.

I think that makes it clear that the older QT framework never had the ability to work with the sample group atom and obviously now its EOL'ed it will never be fixed. Its a great shame as almost all post production software is still based on the older QT framework, so this issue will hang around for sometime I would imagine.

Anyway, its still a big step forward and I'm enoumously greatful to the developer in question for sorting and submitting the fix.