[FFmpeg-trac] #2325(undetermined:new): MP4 AAC Audio is delayed by 2ms when converted to PCM
FFmpeg
trac at avcodec.org
Wed Mar 6 02:56:42 CET 2013
#2325: MP4 AAC Audio is delayed by 2ms when converted to PCM
-------------------------------------+-------------------------------------
Reporter: brchapman | Owner:
Type: defect | Status: new
Priority: important | Component:
Version: git-master | undetermined
Keywords: aac mov | Resolution:
regression | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by brchapman):
Replying to [comment:9 cehoyos]:
> Replying to [comment:8 brchapman]:
> > Just tried pulling 0332324, and everything lines up great! there's no
2ms delay,
>
> > and the other ticket about a duplicate first frame I posted #2324 is
also fixed!
>
> No, the output file is not valid.
> (You can easily change the FFmpeg source to allow writing VFR mov files,
but they are not conforming to any specification.)
>
> > > > > Could you explain how you know that the delay is a bug?
> > > > When converting through After Effects, I don't get this delay.
Everything lines up exactly in the output wave file.
> > >
> > > How does it "line up"? (I don't understand how the numbers should
relate to the sound. I am certainly not claiming there is no issue - I
don't know - but since we know already of three - very different -
applications that decode the sample differently from After Effects, I
wonder how you can be sure that it is correct.)
> >
> > I'm defining correct as placing the source mp4 and output wave file in
a timeline together and checking if the waveforms match between them.
This is shown in the attached screenshot. Since I'm not doing anything
other than just reading a file in and encoding it to a different, I would
expect the input and output sound to line up exactly. Is this how you
would expect it work?
>
> Your reasoning basically assumes that After Effects is right and FFmpeg,
nero and QuickTime are wrong. While I am not saying this isn't the case,
it is no proof imo.
> (There is a mov sample from a camera somewhere on this tracker that
shows a "visible" noise (knocking on a table iirc), it would be
interesting to test that sample with all applications, I unfortunately
fail to find it atm.)
>
> > > > > Do you see the same problem if you extract the audio stream from
the mov file with "ffmpeg -i test100.mp4 -acodec copy out.aac" ? Ie, is
the problem in any way related to the container or only to aac?
> > > > No, I don't get the delay. It lines up perfectly.
> > >
> > > You mean you get the same delay if you use FFmpeg but no delay with
After Effects if you try with the aac file - or do I misunderstand?
> > When I run the command "ffmpeg -i test100.mp4 -acodec copy out.aac",
the out.aac file audio matches the source mp4's audio exactly, without any
delay.
>
> And if you transcode the out.aac file with FFmpeg and compare it in
AfterEffects, you see the same delay as when transcoding the original mp4
file, or am I wrong?
yes, if i first transcode the orignal
{{{
% ffmpeg -i test100.mp4 -c:a copy test100.aac
}}}
then:
{{{
% ffmpeg -i test100.aac -c:a pcm_s16le test100_audio.wav
}}}
test100_audio.wav is delayed.
Also, if I encode test100.mp4 without the aac audio stream (ie with no
audio) and then convert it:
{{{
% ffmpeg -i test100_no_aac.mp4 -c:v prores test100_ffmpeg.mov
}}}
I don't get the duplicate first frame bug in #2324
Based on this I would guess that this would work:
{{{
ffmpeg -i test100.mp4 -c:v prores -an test100_ffmpeg.mov
}}}
However, it doesn't. The first frame is still duplicated.
--
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2325#comment:10>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list