[FFmpeg-user] Create an AAC stream matching the Core Media Audio packet format / priming etc?
mwjburton at gmail.com
Sat Jul 1 17:13:37 EEST 2017
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 <isasi-at-google.com at ffmpeg.org> 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 <mwjburton at gmail.com> wrote:
>>> On 28 Jun 2017, at 01:12, Sasi Inguva <isasi-at-google.com at ffmpeg.org>
>>> I have been helping Mark test Marton's patch. I looked at the test file
>>> was using to test the sync. There are multiple reasons for audio being
>>> i) That file doesn't contain a non-zero edit list or 'sgpd' atom, as
>>> 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
>>> 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
>>> we assume it as zero.
>>> Hence, when we transcode the video using ffmpeg, we are adding 2112
>>> 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
>>> However the spec says that along with the edit list, we should also set
>>> "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
>>> ffmpeg built from these two patches, will correctly match the original
>>> file when decoded with Apple tools (iMovie) .
>>> However it was not to be. It seems like even Apple tools don't respect
>>> 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
>>> is still assuming 2112 samples of delay for AAC.
>>> I am attaching the original test file, and the file I generated.
>> 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.
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".
More information about the ffmpeg-user