[FFmpeg-user] Video processing stopped prematurely on resolution change

Martin Ždila m.zdila at gmail.com
Thu Oct 20 15:46:56 EEST 2016

Even simpler example to reproduce the problem using just one file from the
referenced tarball:

ffmpeg -y -i b.webm -filter_complex "
  color=color=black:size=320x240 [bg];
  [0:v] setpts=PTS-STARTPTS,
scale=320x240:force_original_aspect_ratio=decrease [main];
  [bg][main] overlay=x=160-overlay_w/2:shortest=1" \
-c:v libx264 -preset slow output.mp4

It seems that ffmpeg has pretty much a problem with videos changing its
dimension. For example this will only show single frame:

ffmpeg -y -i b.webm -i logo.png -filter_complex "
  color=color=black:size=320x240 [bg];
  [0:v] setpts=PTS-STARTPTS,
scale=320x240:force_original_aspect_ratio=decrease [main];
  [bg][main] overlay=x=160-overlay_w/2:shortest=1 [tmp];
  [tmp][1:v] overlay=shortest=1" \
-c:v libx264 -preset slow output.mp4

This even uses the video not changing its dimenstions, but the result is
like 1 FPS and there are many messages in the logs "[Parsed_overlay_8 @
0x1cf2500] [framesync @ 0x1cf25e8] Buffer queue overflow, dropping.". Also
the same video used on both sides is not even synced:

ffmpeg -y -i a.webm -i logo.png -filter_complex "
  color=color=black:size=640x240 [base];
  [1:v] setpts=PTS-STARTPTS [logo];
  [0:v] setpts=PTS-STARTPTS,
scale=320x240:force_original_aspect_ratio=decrease [left];
  [0:v] setpts=PTS-STARTPTS,
scale=320x240:force_original_aspect_ratio=decrease [right];
  [base][left] overlay [tmp1];
  [tmp1][right] overlay=x=320+160-overlay_w/2 [tmp2];
  [tmp2][logo] overlay" \
-c:v libx264 -preset slow -c:a aac -t 30 output.mp4

Replacing a.webm with b.webm makes encoding so slow that i doubt it will
ever end (CPU is at 0%).

Do you think I should report is as a bug?

PS: version info (is in the debug log in the tarball as well):

ffmpeg version 3.1.4-1 Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 6.2.0 (Debian 6.2.0-6) 20161010
  configuration: --prefix=/usr --extra-version=1 --toolchain=hardened
--libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu
--enable-gpl --enable-shared --disable-libtesseract --disable-stripping
--disable-decoder=libschroedinger --enable-avresample --enable-avisynth
--enable-gnutls --enable-ladspa --enable-libass --enable-libbluray
--enable-libbs2b --enable-libcaca --enable-libcdio --enable-libebur128
--enable-libflite --enable-libfontconfig --enable-libfreetype
--enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug
--enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse
--enable-librubberband --enable-libschroedinger --enable-libshine
--enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh
--enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx
--enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid
--enable-libzmq --enable-libzvbi --enable-openal --enable-opengl
--enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-frei0r
--enable-chromaprint --enable-libopencv --enable-libx264
  libavutil      55. 28.100 / 55. 28.100
  libavcodec     57. 48.101 / 57. 48.101
  libavformat    57. 41.100 / 57. 41.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter     6. 47.100 /  6. 47.100
  libavresample   3.  0.  0 /  3.  0.  0
  libswscale      4.  1.100 /  4.  1.100
  libswresample   2.  1.100 /  2.  1.100
  libpostproc    54.  0.100 / 54.  0.100

On Thu, Oct 20, 2016 at 12:32 PM, Martin Ždila <m.zdila at gmail.com> wrote:

> Hello
> I have two videos where one of them changes it resolution (rotation)
> twice. I would like to join them side by side. I've used following command:
> ffmpeg -y -i a.webm -i b.webm -filter_complex "
>   color=color=black:size=640x240 [base];
>   [0:v] setpts=PTS-STARTPTS, scale=320x240:force_original_aspect_ratio=decrease
> [left];
>   [1:v] setpts=PTS-STARTPTS, scale=320x240:force_original_aspect_ratio=decrease
> [right];
>   [base][left] overlay [tmp1];
>   [tmp1][right] overlay=x=320" \
> -c:v libx264 -preset fast -c:a copy -t 30 output.mkv
> The problem is that the result video (output.mkv) ends at second
> resolution change and doesn't continue beyond that. It looks like a bug of
> ffmpeg. Could somebody please confirm it or suggest a workaround? Attached
> attach including debug output can be found at http://filebin.ca/
> 2z6yMpuLdtyP/videotest.tgz.
> Thank you
> --
> Martin Ždila

Ing. Martin Ždila
mailto:martin at zdila.sk

More information about the ffmpeg-user mailing list