On 15 Apr 2017, 09:18 +0100, Mark Burton <[email protected]>, wrote:
> On 14 Apr 2017, 23:45 +0100, Carl Eugen Hoyos <[email protected]>, wrote: > > 2017-04-14 23:44 GMT+02:00 Mark Burton <[email protected]>: > > > 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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
