AAC encoder delay

Referencing this document:

https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html


Hi,


I'm looking to determine of there are any existing Apple or third party encoders which use the method 'Track Structures to Represent Encoder Delay Explicitly' for audio priming / handling encoder delay in AAC in a .mov.


Looking at Quicktime 7 (very old I know), Quicktime X and Compressor 4.3.2, they all use the historical solution of encoding a file for the decoder to assume a delay of 2112 samples. So far this is the only method I can see Apple uses in any of their tools despite the description of the track structure (modern) method in their document above.


Does anyone know if there are any Apple or 3rd party encoders which can produce a .mov that strictly follows the modern' method outlined in the above link, known as 'Using Track Structures to Represent Encoder Delay Explicitly'?


Alternativly, can anyone confirm that Quicktime / AVFoundation based decoders will *always* assume 2112 samples of encoder delay no matter the track structure?


Many thanks

Mark

When using AVFoundation's AVAssetWriter, it will add an edit list for your AAC track (provided your CMSampleBuffers have the correct data attached so AVF knows the delay).

The keys for this are kCMSampleBufferAttachmentKey_TrimDurationAtStart and kCMSampleBufferAttachmentKey_TrimDurationAtEnd.


Otherwise, as far as I know, QuickTime/AVF assume 2112 samples of delay.

Many thanks Valerian. Thats very useful. Are you aware of any encoding software on macOS that actaully uses this explicit encoder delay method? That seems to be the way that many other encoders and decoders have gone with regards to creating or expecting explicit encoder delay, but I cant find any QT/AVF based encoders which actually produce a file that does this.


Many thanks

Mark

Accepted Answer

The next version of HandBrake will use an explicit encoder delay (you can already download a nightly build or compile the source code yourself).

Thanks galad87. Thats actually very interesting.


The reason for my initial post is because I've been using ffmpeg and found it is not currently producing a .mov with aac which decodes in sync in Quicktime players.


Looking at the latest Handbrake nightly, it does have the Sample to Group atom in the output file, but it actually suffers the exact same issue as ffmpeg. Audio is out of sync (by about 1 frame) when decoded in Quicktime players.


It just seems that Quicktime always falls back on the historical 2112 method, no matter what the file tries to tell it.


I'm finding it hard to pass on a fix for ffmpeg because despite following the recomended sample group atom method, no one seems to actually be able to get it to work.


Have you any further insight into why this might be happening?


Many thanks

Mark

HandBrake right now doesn't apply an inplicit delay to file with no explicit encoder delay (because for example every AAC encoder uses a different delay), so it will add a delay if you reencode a file with no explicit encoder delay. Did you try to encode for example some pcm audio?

By the way I already reported an issue in Final Cut Pro X, but QuickTime seemed to work in my limited testing.

Thanks. Actually, for me I've only been inputting files with uncompressed PCM audio and encoding to AAC. So its happening on the first conversion from PCM. The file when played in a Quicktime decoder (such as QT7, QTX, Avid or Switch Player) has incorrect sync. The same file plays fine in VLC.


Does that make sense?

Can you share the test file you are using?

Anyway, there's enough info to open a new radar 😐 either the documentation is wrong or no one actually tested this feature in AVFoundation.

Final Cut Pro, Compressor, Adobe Premiere ... though all will probably create a file with a delay of 2112.

what flavor of aac? ffmpeg has an internal aac encoder and you can build fdk-aac

Here are two files which should be pretty useful to test with. I've been using these to check the sync after encoding using the ffmpeg internal AAC encoder and then playing back in Quicktime. They have an audio pip on the first frame (00fr) and an audio pip on the last frame (23fr). They are Avid DNx115 files.


2 second clip (30mb)

https://www.dropbox.com/s/k9dpuwmgnzc6zl6/SyncTest_2sec_24p.mov?dl=0

1 minute clip (890mb)

https://www.dropbox.com/s/bht8b8hnuwryycc/SyncTest_1min_24p.mov?dl=0


If you see and hear what I do, then you won't hear the pip on first frame and you will hear the last audio pip one frame early. If you convert the AAC file back to PCM with a Quicktime app, you will see the same result on the conversion. Play the AAC file in VLC and it is in sync.

Hi, this is with the internal ffmpeg aac encoder, but have also tested with the audiotoolbox aac encoder in ffmpeg (aac_at) with same results.

build the libfdk-acc, i think latest version of ffmpeg removed this lib but an older version around 2.3 should still build


the source code states that it has delay but only supports 2 formatss


git.libav.org/?p=libav.git;a=blob;f=libavcodec/libfdk-aacenc.c


416 AVCodec ff_libfdk_aac_encoder = {

417 .name = "libfdk_aac",

418 .long_name = NULL_IF_CONFIG_SMALL("Fraunhofer FDK AAC"),

419 .type = AVMEDIA_TYPE_AUDIO,

420 .id = AV_CODEC_ID_AAC,

421 .priv_data_size = sizeof(AACContext),

422 .init = aac_encode_init,

423 .encode2 = aac_encode_frame,

424 .close = aac_encode_close,

425 .capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY,

426 .sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16,

427 AV_SAMPLE_FMT_NONE },

428 .priv_class = &aac_enc_class,

429 .defaults = aac_encode_defaults,

430 .profiles = profiles,

431 .supported_samplerates = aac_sample_rates,

432 .channel_layouts = aac_channel_layout,

433 };

Hi galad,


I've posted a longer response with some test files, but its still being moderated, I guess because it contains links to the test files. Anyway, hopefully that is posted soon.


Thanks

Mark

Hi iPad_dev, thanks for your message. There are a number of features which mean I need to stay on the latest ffmpeg, but also I'm not sure this will help since I think its the muxer that is having the issue creating a file which Quicktime will respond too. Having said that, have you tested this AAC codec and found it does something different in this regard? Many thanks, Mark

Hi Valerian, I dont have FCP or Premiere, but in my tests Compressor did not create a sample group atom.

AAC encoder delay
 
 
Q