Opened 8 years ago

Last modified 4 weeks ago

#5456 new defect

Videos produced with -shortest are longer than the audio

Reported by: Igal Tabachnik Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: human.peng@gmail.com Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Attachments (2)

shortest-logs.7z (5.5 KB ) - added by Igal Tabachnik 8 years ago.
Log files (-report) the "good" encode and "bad"
bg.jpg (8.2 KB ) - added by Igal Tabachnik 8 years ago.
Still image for the video

Download all attachments as: .zip

Change History (7)

by Igal Tabachnik, 8 years ago

Attachment: shortest-logs.7z added

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

by Igal Tabachnik, 8 years ago

Attachment: bg.jpg added

Still image for the video

comment:1 by Igal Tabachnik, 8 years ago

comment:2 by AyrA, 7 years ago

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
Last edited 7 years ago by AyrA (previous) (diff)

comment:3 by Roland, 4 years ago

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.

comment:4 by fireattack, 4 years ago

Cc: human.peng@gmail.com added

comment:5 by areweAV1yet, 4 weeks ago

I am still having issues creating 8k/4k videos with this. The interleave trick helped but was still leading to 50% longer videos (than the audio length)

I found that converting to aac before and then doing a copy seemed to fix it

for i in *.mp3; do (ffmpeg -i "$i" -b:a 256k "${i%.*}.aac"; ffmpeg -r 0.01 -i image.jpg -i "${i%.*}.aac" -c:a copy -shortest -max_interleave_delta 500M -c:v libx265 -x265-params lossless=1 -pix_fmt yuvj420p -vf "loop=-1:1" -movflags faststart "${i%.*}.mp4"); done

Last edited 4 weeks ago by areweAV1yet (previous) (diff)
Note: See TracTickets for help on using tickets.