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

Mark Burton mwjburton at gmail.com
Sat Apr 15 00:44:52 EEST 2017

> On 14 Apr 2017, at 22:22, Christian Ebert <blacktrash at gmx.net> wrote:
>>> Also, when you run with -v verbose, you'll see a delay (depends
>>> on audio codec), for you case it's probably 1024. Maybe try:
>>> -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
>>> Especially the latter could be exactly the wrong thing for your
>>> purpose, but it doesn't hurt trying.
>> 1024 looks correct. This method successfully changes the start, and the encoded audio plays, almost, 100% in sync. Its slightly cut off at the head, but only very slightly. However the downside of this method is that the audio now overruns the end of the picture further and is not trimmed from remaining samples I’m guessing. This results in a blank video frame being added to the tail of clip. ffprobe for ffmpeg_v3 attached.
>> I tried using -shortest, but that didn’t help address the above issue.
> Inserting
> -t `ffprobe -v quiet -of default=nw=1:nk=1 -select_streams V -show_entries stream=duration SyncTest24p.mov`
> into your commandline should do the trick.

Adding '-t 2.000000’ to the command does help a little, but ultimately the final audio packet is still too large - 6ms in this case - and the black frame still occurs.


> imho this is a muxing bug in dealing with aac priming in many
> situations, but making my case fell on deaf ears.

It feels a bit odd having to chase the output file in this way doesn’t it. I’ve read a number of the reports around this issue (perhaps some from you?) and there does appear to be a real difference of opinion on both sides.

How do you work round this in your products? I find it hard having to accept an encode will always play out of sync on certain players.

Thank so much for your help,


More information about the ffmpeg-user mailing list