[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
tel:+421-908-363-848
mailto:martin at zdila.sk
http://www.zdila.sk/
More information about the ffmpeg-user
mailing list