I am not knowledgeable enough about audio codec implementations, but I don't think we can control an audio codec implementation to follow a certain delay. For AAC codec for example, I believe libfhg-aac sets 1600 samples of dealy, while libfdk-aac would set 1024 etc. Some one with more knowledge can tag in here.
On Thu, Jun 29, 2017 at 10:46 AM, Mark Burton <[email protected]> wrote: > > > On 28 Jun 2017, at 01:12, Sasi Inguva <[email protected]> > wrote: > > I have been helping Mark test Marton's patch. I looked at the test file > Mark > > was using to test the sync. There are multiple reasons for audio being > > off-sync. > > > > i) That file doesn't contain a non-zero edit list or 'sgpd' atom, as > > https://developer.apple.com/library/content/documentation/ > QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html > > suggests to put. For this kind of file the spec says that, use the > > historical solution of assuming the delay as 2112 samples. And this is > what > > the QuickTime player and iMovie on my MAC seem to be doing. However in > > Ffmpeg we don't assume the delay as 2112 samples. If there is no edit > list, > > we assume it as zero. > > Hence, when we transcode the video using ffmpeg, we are adding 2112 > samples > > of silence in the transcoded file ( as actual audio data). > > ii) On top of that ffmpeg AAC encoder itself introduces 1024 samples of > > silence, and ffmpeg then uses edit list to denote that as the encoder > delay. > > However the spec says that along with the edit list, we should also set > the > > "sgpd" atom, ( which is what Marton's patch does). > > > > So to fix this, I hacked ffmpeg MOV demuxer to assume 2112 delay for AAC, > > and combined it with Marton's patch. I hoped that the file transcoded > from > > ffmpeg built from these two patches, will correctly match the original > test > > file when decoded with Apple tools (iMovie) . > > > > However it was not to be. It seems like even Apple tools don't respect > the > > new way of setting the encoder delay. When I decode the file using > iMovie, I > > observe that 2112 samples from the beginning are gone, indicating that > Apple > > is still assuming 2112 samples of delay for AAC. > > > > I am attaching the original test file, and the file I generated. > > SyncTest_2sec_24p_Compressor_enc.mp4 > > <http://www.ffmpeg-archive.org/file/n4680414/SyncTest_ > 2sec_24p_Compressor_enc.mp4> > > SyncTestFfmpegAdEdit2112.mp4 > > <http://www.ffmpeg-archive.org/file/n4680414/ > SyncTestFfmpegAdEdit2112.mp4> > > Thanks Sasi. So the short of this is that its unclear whether it is in > fact possible to create a mov file which Apple tools will decode using the > ‘new’ method. > > If Apple tools will always reliably use the 2112 decode method, would it > not make more sense to include a new option in ffmpeg to encode in this way > (same as Quicktime encoders) and therefore ensure accurate decode of the > file in the actual formats decoder? If the current methods are either not > fully meeting the spec or are simply being ignored by Quicktime, it would > seem that in order to maintain compatibility with the format itself, having > a way to encode with 2112 delay would be the most reliable way to go. > > Thanks > 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". > _______________________________________________ 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".
