[Libav-user] How to handle of aac encoder delay using ffmpeg libs
krueger at lesspain.de
Sun Sep 13 17:46:28 CEST 2015
I am struggeling a bit to find out how to handle encoder delay (e.g. for
aac) correctly using libavformat/libavcodec.
Let's take an example (using current ffmpeg from git master):
If I create an aac file using ffmpeg on the command line, say 1second sine
wave like so:
ffmpeg -f lavfi -i "sine=frequency=1000:sample_rate=48000:duration=1"
-strict -2 -c:a aac -y ~/tmp/audiodelay/ffmpeg_sine_1s.m4a
and then decode the file, it has a start time of approx -22ms (which is
equivalent to 1024 samples, which I presume to be the encoder delay that is
detected or assumed).
So, is my reading correct, that to really obtain the samples of the signal
without the padding samples, I would have to discard the first 1024
samples. But how do I decide that e.g. in a player or (more critical)
analysis application? I then assumed that maybe AVCodecContext::delay would
let me make that decision but that is 0 for these files that ffmpeg
generates and all others I checked.
How can an ffmpeg api user know when to cut off how many samples or do I
have to use heuristics for that?
I found https://trac.ffmpeg.org/ticket/2325, which seems related and never
Another observation I made was that the ffmpeg-generated pcm file converted
to aac (in m4a) using Apple Compressor did not have this timestamp offset
and decoding the signal naively using ffmpeg did not yield any sync issues.
Maybe they do something in the mov container to account for the padding but
I have not checked that.
What needs to be done to find out if this is an ffmpeg bug?
If someone wants this visually (signals compared as they come out of ffmpeg
libs when decoding pcm vs. aac file), here are signal comparison graphs
scaled to 8000Hz.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user