FCP X not parsing .MOV containing AAC audio with AAC Priming less than 2112 samples

Originator:me
Number:rdar://16522632 Date Originated:2014-04-04
Status:Closed Resolved:2014-12-16
Product: Product Version:
Classification: Reproducible:
 
Summary:
I am following the instructions in https://developer.apple.com/library/mac/documentation/quicktime/qtff/QTFFAppenG/QTFFAppenG.html to produce a .MOV file with explicit AAC delay information (the AAC encoder I'm using has a priming delay of 2014 samples)

The instructions on that page note "An incomplete implementation will result in unspecified interpretation by Apple software and tools. In the absence of the sample group structures, the classic solution of expecting an implicit encoding delay of 2112 samples and the edit list to start at the beginning of encoder delay will be assumed as described in the previous section." - however the tools seem to be ignoring this information

Steps to Reproduce:
1. Generate .MOV file (see attachment - checked in Atom Inspector for validity, generated by our custom version of libavformat)
2. Import into FCP X

Expected Results:
For audio and video to sync up perfectly, since the MOV includes explicit delay information indicating that we are using AAC priming of 1024 rather than 2112

Actual Results:
Audio is 1088 samples early compared to video (which also means the first 1088 samples in the file are lost). This means that the media loses AV sync when edited(!)

Version:
Running on OS X 10.9.2 build 13C64
FCP X 10.1.1 build 240682
Quicktime Player Version 10.3 (727.3)
Quicktime for Windows

Notes:


Configuration:
If using PCM instead of AAC, the resulting file is parsed perfectly and AV sync is maintained

Attachments:
'aac.mov' was successfully uploaded.

Comments

Apple Developer Relations16-Dec-2014 09:47 PM

There are no plans to address this based on the following:

The file does have correct 'roll' sample group entries. However, according to the edit there is not enough audio samples indicated by the 'roll' sample group before the start of the media. Also the last packet (or media sample) has the duration smaller than the sample per packet, and would not decode properly.

We are now closing this report.

If you have questions about the resolution, or if this is still a critical issue for you, then please update your bug report with that information.

Please be sure to regularly check new Apple releases for any updates that might affect this issue.

By me at Dec. 16, 2014, 11:22 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!