How about this for a partial solution - ffmpeg supports the audiotoolbox aac encoder on macOS. For the sake of being able to create .mov which are compatible with the Quicktime format, there is a single change which I think could work well, albeit the ‘fix' would be limited to macOS system encoders.
Currently a .mov created by ffmpeg when using the aac_at audiotoolbox encoder creates a sound track edit list with a media time of 2112. This will not work with Quicktime decoders, the file with decode out of sync. If this value was 0 however, then the file will decode properly in sync. For now, would it be possible to change this value to 0 when using the aac_at encoder in ffmpeg? Doing the same for the ffmpeg native aac encoder does help quite a bit, about 1/2 frame out of sync as opposed to a full frame. > On 29 Jun 2017, at 18:52, Sasi Inguva <[email protected]> wrote: > 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". _______________________________________________ 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".
