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

[Mark Burton]

On 15 Apr 2017, 09:18 +0100, Mark Burton <mwjburton at gmail.com>, wrote:

> On 14 Apr 2017, 23:45 +0100, Carl Eugen Hoyos <ceffmpeg at gmail.com>, wrote:
> > 2017-04-14 23:44 GMT+02:00 Mark Burton <mwjburton at gmail.com>:
> > > I find it hard having to accept an encode will always play out of
> > > sync on certain players.
> >
> > Could you elaborate a little?
> > So far, for every ticket, it either turned out that out-of-sync was
> > not reproducible with MPlayer / vlc (and FFmpeg) or it was off-
> > by-one-frame which I consider hard to reproduce…
>
> Hi Carl,
>
> Thanks for taking the time to look at this again, it really is appreciated. My environment is post production based. We work in DNxHD with PCM audio which is in sync with the picture inside the Avid editing system. We export using same as source to make a 24fps (not 23.976) Avid DNx115 video, 48khz 24bit PCM audio Quicktime .mov file. This file plays back in any decoder in sync, exactly the same as it did inside the Avid software.
>
> Take this file, encode with ffmpeg using native aac and playback in Quicktime Player 7 or X or Switch or any other player which uses a Quicktime decoder and it is now out of sync by 1 frame (audio is early). The same encode played back in VLC shows about 1/2 frame of sync slip.
>
> I have yet to produce a .mov or .mp4 with any ffmpeg build with an AAC stream which plays back in sync (the same sync as the source file) in Quicktime based decoders.
>
> A good test file is to have a visual and audible 1 frame pip on the first frame, then the same on the last frame. Create it with PCM audio and using a video codes such as DNx or MJPEG. Encode this with a standard command:
>
> ffmpeg -i SyncTest24p.mov -c:v copy -c:a aac -b:a 128k ffmpeg_aac.mov
>
> The first frame where there used to be an audible pip, is now mute. The end pip now plays approx. 1 frame early. I think in the past you’ve asked how can we know that AV-sync is off by 0.04 seconds. I can’t tell you the ‘exact' amount it is off by, but I do know that the first pip is gone completely and end pip is approx. 1 frame early, but overall the sync in the encoded file does not match the original and is therefore out of sync.
>
> Perhaps there is somewhere I could upload and share my test file for you to test?
>
> I’m really mindful that my explanation may not be technically the best and hopefully others who have been reporting this may chime in to offer data which is more quantifiable. However, I will do anything I can to help resolve this if at all possible.


Hi Carl,

Did you have any thoughts on this?

Christians fix helps with the sync issue, although not 100%, but the downside is that it creates an even longer audio track, which causes Quicktime decoders to create a bogus black end frame.

Do you not see the same behaviour?

Kind regards
Mark