Open ScissorHill opened 4 years ago
Yes, it seems there are some bugs with the tripod mode. What happens if you do not use the tripod mode, but use a large smoothing (e.g. 200 or so)
WIth smoothing=200, no tripod mode There's still a bit of 'drift', which is undesirable. The video has about 540 frames, so I tried with smoothing=500. This is close to what I was hoping for, thanks!
Probably related to #27, but seems more severe in my case and the suggested resolution doesn't work. Hence submitting a new issue, let me know if this is ok.
Example:
ffmpeg -i ghl_orig.mp4 -vf vidstabdetect=tripod=1:show=2 tmpout.mp4
ffmpeg -i ghl_orig.mp4 -vf vidstabtransform=input="transforms.txt":tripod=1:maxangle=0 -c:a copy ghl_stab.mp4
Original Video (ghl_orig.mp4) Stabilized Video (ghl_stab.mp4) Intermediate Video(tmpout.mp4) Transforms (transforms.txt)
The stabilized video shows two rapid bursts of shaking, but is otherwise acceptable, like it was placed on a tripod. The intermediate video shows that the detection itself seems to fail at those points. I've tried various other settings of
shakiness, accuracy, stepsize, mincontrast
with no success. Changing thetripod=
value to some other frame changes where the shake happens in the video, but it happens, and sometimes in several places.Typically, output contains a
[vidstabdetect @ 0x7ffd4f05c5c8] too low contrast. (no translations are detected in frame 211)
line close to where the crazy shake occurs.Additional info:
ffmpeg version 3.4.7 Copyright (c) 2000-2019 the FFmpeg developers built with gcc 6.5.0 (Ubuntu 6.5.0-2ubuntu1~18.04) 20181026 configuration: --pkg-config-flags=--static --extra-libs='-lpthread -lm' --enable-gpl --enable-libvidstab --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-cuda-sdk --enable-cuvid --enable-nvenc --enable-libnpp --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64 --enable-nonfree