FFMPEG Fails with an Assert

[ramitb]

Summary of the bug: This is a regression issue of recent, the older versions worked fine.
When trying to audio shift a file created by handbrake using ffmpeg, it fails with an assertion.

This is happening with quite a few files actually, not just one.

How to reproduce:

ffmpeg.exe -i AssetFail.mp4 -ss 5 -i AssetFail.mp4 -ma
p 1:v -map 0:a -acodec copy -vcodec copy AssetFailShift.mp4
ffmpeg version N-62495-g197fe39 Copyright (c) 2000-2014 the FFmpeg developers
  built on Apr 17 2014 11:35:21 with gcc 4.8.0 (GCC)
  configuration: --arch=x86 --target-os=mingw32 --cross-prefix=/Software/ffmpeg/sandbox/mingw-w64-i686/bin/i686-w64-ming
w32- --pkg-config=pkg-config --enable-gpl --enable-libx264 --enable-avisynth --enable-libxvid --enable-libmp3lame --enab
le-version3 --enable-zlib --enable-librtmp --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libopenjpeg
--enable-gnutls --enable-libgsm --enable-libfreetype --enable-libopus --disable-w32threads --enable-frei0r --enable-filt
er=frei0r --enable-libvo-aacenc --enable-bzlib --enable-libxavs --extra-cflags=-DPTW32_STATIC_LIB --enable-libopencore-a
mrnb --enable-libopencore-amrwb --enable-libvo-amrwbenc --enable-libschroedinger --enable-libvpx --enable-libilbc --pref
ix=/Software/ffmpeg/sandbox/mingw-w64-i686/i686-w64-mingw32 --enable-static --disable-shared --enable-libsoxr --enable-f
ontconfig --enable-libass --enable-libutvideo --enable-libbluray --enable-iconv --enable-libtwolame --extra-cflags=-DLIB
TWOLAME_STATIC --enable-libzvbi --enable-libcaca --enable-libmodplug --extra-libs=-lstdc++ --extra-libs=-lpng --enable-l
ibvidstab --extra-cflags= --extra-cflags= --enable-nonfree --enable-libfdk-aac --enable-libfaac --enable-runtime-cpudete
ct
  libavutil      52. 76.100 / 52. 76.100
  libavcodec     55. 58.103 / 55. 58.103
  libavformat    55. 37.100 / 55. 37.100
  libavdevice    55. 13.100 / 55. 13.100
  libavfilter     4.  4.100 /  4.  4.100
  libswscale      2.  6.100 /  2.  6.100
  libswresample   0. 18.100 /  0. 18.100
  libpostproc    52.  3.100 / 52.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'AssetFail.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : HandBrake 6167svn 2014041701
  Duration: 00:31:49.98, start: 0.028000, bitrate: 410 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m), 704x464 [SAR 580:649 DAR 80:59], 1
47 kb/s, 25.93 fps, 59.94 tbr, 90k tbn, 47.95 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Input #1, mov,mp4,m4a,3gp,3g2,mj2, from 'AssetFail.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : HandBrake 6167svn 2014041701
  Duration: 00:31:49.98, start: 0.028000, bitrate: 410 kb/s
    Stream #1:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m), 704x464 [SAR 580:649 DAR 80:59], 1
47 kb/s, 25.93 fps, 59.94 tbr, 90k tbn, 47.95 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #1:1(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Output #0, mp4, to 'AssetFailShift.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf55.37.100
    Stream #0:0(und): Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 704x464 [SAR 580:649 DAR 80:59], q=2-31, 147 kb/s,
25.93 fps, 90k tbn, 90k tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac ([64][0][0][0] / 0x0040), 48000 Hz, stereo, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Stream mapping:
  Stream #1:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
Assertion next_dts >= 0 failed at libavformat/movenc.c:626

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.}}}

[ramitb]

This is the last working build I have

ffmpeg version N-59362-ge079661 Copyright (c) 2000-2013 the FFmpeg developers

built on Dec 25 2013 17:42:26 with gcc 4.8.0 (GCC)

[ramitb]

<SCRATCH THAT - I apparently have trouble figuring out how the merge works>

Apparently the asset code was added in 9d013fe840213407790592ca8ecbab69285030ed commit.

[ramitb]

Correction - it was added on Feb 20th in commit 20fa3fb93d0f3d3eab2b1f63a03168f492fae047

[Michael Niedermayer]

Fixed in dc6a17cf74a90e41d70ea1753cdb70c0a5b2ced8

[Carl Eugen Hoyos]

Did you upload a sample?
Without a sample, I cannot backport the fix.

[ramitb]

Uploaded, its a little big (100MB) so was didn't do it earlier. it's called

#3575 Asset Fail.mp4

[ramitb]

so as I understand the "fix" it prints an error, but does it make the file unusable?
I asked before I just recomplied the same version after commenting out the ASSERTS and the remuxed file playsback fine with WMP

[Cigaes]

Asserts in code are properties that the programmer expects to be always true. When they fail, that means something is wrong. Just removing them is never a correct solution: you may be producing invalid results (and “playsback fine with WMP” is no proof that the result is valid), allowing a more complex crash later or even creating a security issue. To fix an assert failure, you have to understand what went wrong and why, and fix it.

(Of course, sometimes the assert is really completely wrong, and the correct solution is to remove it, but only after understanding why; that is not just removing it.)

[julian]

i'm using v2.2.2 which supposedly has the fix but i'm still hitting this:

Assertion next_dts >= 0 failed at libavformat/movenc.c:621

interested in a file to reproduce it?

[Carl Eugen Hoyos]

No, we obviously don't care about bug reports and we don't want more samples.
=-)

Seriously: Please either post on ffmpeg-user mailing list or open a new ticket here if you have a sample that causes any kind of crash, including an assert failure. Samples are arguably the only thing we expect from users.
To some degree, samples that cause crashes are even an exception to the "please test current FFmpeg git head before reporting problems"-rule.

[julian]

further investigation shows the possibility to hit this assertion was fixed between 2.2.2 and 2.3.2. sorry for the noise.