[FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?

Mark Burton mwjburton at gmail.com
Wed May 24 15:20:34 EEST 2017

On 23 May 2017, at 11:20, Christian Ebert <blacktrash at gmx.net> wrote:
>> So I looked back at your above -af and realised that the 1024 should actually be 2112 which is Apple’s chosen fixed encoding delay.
>> https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html <https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html>
>> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+2112
> Strange, probably all depends on the demuxing application.
My take on it is that Quicktime will always assume 2112 padding, so I believe a .mov should be setup with this priming duration.

> ffprobe -show_entries stream=codec_type,start_time,start_pts,duration result
> for me gives 0 for all start values.
Which is then being pulled back -2112 samples on playback, which is why it goes out of sync I believe. Unless you have 2112 samples of empty audio before the source audio data starts, there will be a sync issue.

> Did you look at the atrim filter? It offers end, end_sample, and
> end_pts parameters. You may have to to some calculations.
> Re-reading the article you referenced, it may even a better idea
> to use atrim instead of asetpts for the start as well.
> Maybe:
> -filter:a aresample=async=1:first_pts=0,atrim=start_pts=2112:end={-t value}
Thanks for the idea. I’m  not having much luck with this for the tail and unless I keep asetpts as before, the head is pulled out of sync.

I think the problem is that these trailing samples should just be trimmed on playback automatically. Thats works when we don’t add 2112 samples of padding, but with the required padding there are either too many trailing samples or it breaks the trailing detection process. I’ve tried to learn how this is signalled to the decoder, but I’m not really understanding it and its above my intellect grade.

It would be very useful to hear from the devs why (again with the greatest respect, I completely accept I’m not going to have a full picture here) ffmpeg does not follow the Quicktime file format spec for their .mov muxer in the way that Apple has advised, and ideally if there was a way to offer an extra option for this muxer to create aac files with Quicktime decoder compatibility.


More information about the ffmpeg-user mailing list