On 26 May 2017, at 12:53, Christian Ebert <blacktr...@gmx.net> wrote: > Yeah, filtering does not add an edit list (apparently the > 'modern' solution): > https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25592 > and therefore QuickTime fails over to a hardcoded 'historical' > default. That explains it. > > There are some options referring to edit lists, but I haven't > tried whether, nevermind how, they could be used for this > purpose.
https://ffmpeg.org/pipermail/ffmpeg-cvslog/2012-October/055289.html <https://ffmpeg.org/pipermail/ffmpeg-cvslog/2012-October/055289.html> http://ffmpeg.org/pipermail/ffmpeg-cvslog/2014-November/082944.html <http://ffmpeg.org/pipermail/ffmpeg-cvslog/2014-November/082944.html> I’ve looked into these two notes before, when I experimented a little it in the past, I found it caused the tracks to not playback at a consistent rate and so sync was shifting by a frame throughout. Its a hard one to narrow down, as it seems to affect mostly the sync when I move to a new clip location and restart playback. Since my test clip has visual running timecode and timecode in a data track, I can see that the sync between these two is not being maintained when pausing or jumping to a new play point. I’ve been using the video_track_timescale option for a while anyway, but I think this option is even more important when adding the command option "-use_editlist 0”. Testing with the native aac encoder (with the option "-use_editlist 0” and without any of the -af options) produces a file which plays approx. 1/2 frame out sync in Quicktime decoders and the file ends when it should, but with the jump around sync issue mentioned above. Doing the same test but with the AutoToolbox aac encoder (aac_at) produces a file which is plays in sync, but still has the jump around data sync issue and produces a 1 frame overlong duration. Although playback audio / video sync is either very close or right on when started from head of the clip, neither show reliable sync to the timecode track, this doesn't seem viable as is. Its odd though as it seems to have been developed for this reason, so perhaps its the closest option to a solution and needs some final changes to make it fully reliable. Apologies for my technical descriptions, I appreciate some of it is a little basic on my behalf. Thanks Mark _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
