libavcodec: negative dts problems due to 32bit counter in deprecated audio encoder API

[pegro]

We are using the the libavformat consumer of melt (​http://www.mltframework.org) for RTMP livestream encoding.
After several hours a warning occurs in the libavformat muxer and the encoding crashes:

[aac @ 0x26f76c0] Que input is backward in time
[flv @ 0x26d9580] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 48695751 >= -48695774

The dts counter seems to count milliseconds, since the problem occurs reproducible after 13h32m.

While debugging the issue we noticed melt uses the old avcodec_encode_audio API, which is deprecated for over a year now. The commit [1] introducing the compatibility API adds a 32 bit integer "sample_count" to AVCodecInternal (libavcodec/internal.h) used for computing the pts (64bit).

We think that causes the problem, since changing the counter type to int64_t fixes the problem for us. See patch attached.

For debugging purposes a 15h silent audio track was generated using ffmpeg with /dev/zero as input.

[1] ​http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b2c75b6e6320b1a399d76913f9d98c56f386f98b

[Carl Eugen Hoyos]

Please send patches to ffmpeg-devel, they receive much more attention there.

If you could suggest how we can make people aware that sending patches to this bug tracker usually does not help, you would also do us a favor.

[pegro]

Maybe trying add such information to the web page describing how to report bugs: ​http://ffmpeg.org/bugreports.html ?

[Carl Eugen Hoyos]

We tried it on the new tickets page:
https://ffmpeg.org/trac/ffmpeg/newticket

[Michael Niedermayer]

Patch has been applied (c6c2231227c1d9031de43496dacdbcb309829b4d)