Videos produced with -shortest are longer than the audio

[Igal Tabachnik]

Summary of the bug:

I tried following the guide for converting an audio file to video for YouTube, and I noticed that when using the -shortest switch, the videos produced were about 10 seconds longer than the audio track, and it was impossible to skip.

After some searching, I found an old thread that suggests this was a bug introduced sometime in 2012, and suggested using an older version.

I was able to find that last good build, after which the bug happens!
Last good build was: ffmpeg-20120720-git-85761ef found here: ​https://ffmpeg.zeranoe.com/builds/win64/static/

All subsequent versions after it, including the very latest, have this incorrect behavior.

How to reproduce:
Attached is an 8 second .flac file (and an image for still frame) Run the following:

ffmpeg -loop 1 -framerate 1 -i bg.jpg -i recit24bit.flac -shortest output.mp4

When done with the "good" build 85761ef, the resulting mp4 is 10 seconds long

When done with any other newer version, the resulting mp4 is 1 minute 08 seconds on my machine.

See attached logs for additional info.

[Igal Tabachnik]

Log files (-report) the "good" encode and "bad"

[Igal Tabachnik]

Still image for the video

[Igal Tabachnik]

The source flac sample used is: ​http://download.linnrecords.com/test/flac/recit24bit.aspx

[AyrA]

I am affected by the same issue. It looks like somewhere the calculation is off. If you don't use the input argument -framerate you get approximately the same video and audio stream length (2 seconds off for a 3m50s audio track). It looks like ffmpeg defaults to 25 FPS in that case. If you manually specify higher framerates (for example 60) you get closer to the audio duration.

This is still an issue in the current version:

ffmpeg version N-86537-gae6f6d4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.1.0 (GCC)
configuration: --disable-static --enable-shared --enable-gpl --enable-version3
    --enable-cuda --enable-cuvid --enable-d3d11va --enable-dxva2
    --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib
    --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv
    --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca
    --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc
    --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb
    --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg
    --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr
    --enable-libspeex --enable-libtheora --enable-libtwolame
    --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis
    --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264
    --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg
    --enable-lzma --enable-zlib
libavutil      55. 66.100 / 55. 66.100
libavcodec     57. 99.100 / 57. 99.100
libavformat    57. 73.100 / 57. 73.100
libavdevice    57.  7.100 / 57.  7.100
libavfilter     6. 94.100 /  6. 94.100
libswscale      4.  7.101 /  4.  7.101
libswresample   2.  8.100 /  2.  8.100
libpostproc    54.  6.100 / 54.  6.100

[Roland]

Issue still appears to be present - using FFmpeg 4.2.2 (win64 build) and running into exact same problem. Increasing framerate decreases extra time added to video (1 FPS = ~1 minute extra, 25 FPS = ~3 seconds extra). I was able to kind of mitigate it by adding

-fflags +shortest -max_interleave_delta 500M

to the end of my command, which significantly reduced the amount of extra time added to the output.