[Opencore-amr-devel] [fdk-aac] negative start time, overlong duration

[Christian E. <bla...@gm...>]

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