[Opencore-amr-devel] [fdk-aac] negative start time, overlong duration
Audio codecs extracted from Android Open Source Project
Brought to you by:
mstorsjo
|
From: Christian E. <bla...@gm...> - 2014-10-09 07:23:14
|
Hello,
fdk-aac, at least with ffmpeg, always results to a negative
start time timestamp, and a longer duration than the original.
$ ffmpeg -i 03-ThreeJollyHuntsmen.wav -c:a libfdk_aac -b:a 64k test.m4a
ffmpeg version N-66745-g0578623 Copyright (c) 2000-2014 the FFmpeg developers
built on Oct 9 2014 07:29:36 with Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-ffserver --enable-shared --enable-libfdk-aac --enable-libx265 --enable-libx264 --enable-libxvid --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libvidstab --extra-cflags=-I/sw/include --extra-libs=-L/sw/lib
libavutil 54. 10.100 / 54. 10.100
libavcodec 56. 4.101 / 56. 4.101
libavformat 56. 9.100 / 56. 9.100
libavdevice 56. 1.100 / 56. 1.100
libavfilter 5. 1.103 / 5. 1.103
libswscale 3. 1.100 / 3. 1.100
libswresample 1. 1.100 / 1. 1.100
libpostproc 53. 1.100 / 53. 1.100
Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, wav, from '03-ThreeJollyHuntsmen.wav':
Duration: 00:01:25.52, bitrate: 1411 kb/s
Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s
Output #0, ipod, to 'test.m4a':
Metadata:
encoder : Lavf56.9.100
Stream #0:0: Audio: aac (libfdk_aac) (mp4a / 0x6134706D), 44100 Hz, stereo, s16, 64 kb/s
Metadata:
encoder : Lavc56.4.101 libfdk_aac
Stream mapping:
Stream #0:0 -> #0:0 (pcm_s16le (native) -> aac (libfdk_aac))
Press [q] to stop, [?] for help
size= 684kB time=00:01:25.54 bitrate= 65.5kbits/s
video:0kB audio:669kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.259898%
$ ffprobe -v quiet -show_entries stream=start_time,duration 03-ThreeJollyHuntsmen.wav
[STREAM]
start_time=N/A
duration=85.519116
[/STREAM]
$ ffprobe -v quiet -show_entries stream=start_time,duration test.m4a
[STREAM]
start_time=-0.046440
duration=85.565556
[/STREAM]
Similarly from a source where start time is 0.
Is this a bug in the ffmpeg muxer? see here
https://trac.ffmpeg.org/ticket/3859#comment:13
for further comparisons.
For MP4 muxing this does not lead to practical problems, at least
rare user complaints about audio async are hard to prove, as it's
minimal.
But it does have a noticeable consequence for instance when
segmenting for HLS streams: the end of video detection is not
working reliably anymore, playlist transitions do not work
reliably anymore. I am able to circumvent that in ffmpeg by
trimming the negative start time and the overlong remaining
duration - but this is not clean.
Any ideas what's going on here?
Christian
--
Was heißt hier Dogma, ich bin Underdogma!
[ What the hell do you mean dogma, I am underdogma. ]
free movies --->>> http://www.blacktrash.org/underdogma
http://itunes.apple.com/podcast/underdogma-movies/id363423596
|