Wrong duration for G.729 in wav

[Carl Eugen Hoyos]

Forum user muchuan uploaded a wav file containing G.729, the duration shown by FFmpeg is wrong, additionally many Non-monotonous DTS in output stream warnings are shown while decoding.

$ ffmpeg -i 222.vd8
ffmpeg version N-72351-g1b23654 Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      54. 24.100 / 54. 24.100
  libavcodec     56. 41.100 / 56. 41.100
  libavformat    56. 33.101 / 56. 33.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 16.101 /  5. 16.101
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Guessed Channel Layout for  Input Stream #0.0 : mono
Input #0, wav, from '222.vd8':
  Duration: 00:00:16.90, bitrate: 64 kb/s
    Stream #0:0: Audio: g729 ([154]r[0][0] / 0x729A), 8000 Hz, 1 channels, s16, 8 kb/s
At least one output file must be specified

The actual duration of the attached file is 2:15.

[Ganesh Ajjanagadde]

Attached file does not conform to the WAV specification.
See ​http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/WAVE/Docs/RIFFNEW.pdf (under Fact Chunk),
and source code libavformat/wavdec.c.
The Fact Chunk is supposed to contain number of samples (since codec is compressed), and is set to 135200 here.
However, it should be 135200 * 8.
Note that the fact chunk is currently redundant, since the number of samples can alternatively
be derived from the data size and bits per sample,
and so most programs (except ffmpeg) use this to derive number of samples.
ffmpeg also does this, but only in some other situations.
If ffmpeg did this for G.729 as well, correct duration can be reported.

I thus see two possible solutions:

1. Continue to bend over backwards so as to support an even larger set of non spec compliant files,

and thus make behavior match that of other media libraries/players.

2. Not fix this, as file is not spec compliant.

BTW, I have not looked into the non-monotone DTS aspect,
but suspect it would follow from correctly setting duration and related timestamp stuff.

[Ganesh Ajjanagadde]

Fixed duration estimation in c1bfb99ff2445c7f3ba319ea342dd8004345d67a and 13d605e090bd408a1040624f7173bcc142f81410.

I do not know about the DTS warnings, hopefully someone with more knowledge of timestamps stuff can check whether this is due to a bad input file or whether this is a genuine bug.

[Carl Eugen Hoyos]

Thank you for fixing the original issue, I opened ticket #4753 for the warnings shown.