Closed MiniGod closed 3 years ago
Good idea. The main thing which requires user interaction at the moment is selecting points for syncing, but analyzing more parts of the video might solve that. Will look into it.
That shouldn't be a problem for Hero 8 since it shouldn't need syncing (see #51).
I understand that it would be more complicated for other camera setups.
I'm also interested. I record with AirUnit, so all videos have more or less same points of sync. Would be great to be able to say like: --sync1 5 --sync2 -15 --sync-diff 0.3 Which means: first sync point is at 5 second. second sync point is 15 sec from end, allowed difference between two sync points is 0.3 secods. If that works, continue rendering. These settings works 90% of time for me, I've already gone though around 40 videos 1-5 minutes long
It would also be really nice to be able to export the stab_transform
matrices instead of a video, then later use that as input into gyroflow together with the original video. Similar to how reelsteady saves the sync points so it doesn't have to do it again.
That way you could run the sync and stabilization calculations once, and for instance parallelize the rendering afterwards, or render various sections of the video without having to re-sync or calculate smoothing every time.
@MiniGod You can already do that. In the UI export tab, export a gyroflow data file (defaults to videofilename.mp4.gyroflow
) which contains stab_transform, camera intrinsics etc. Which is automatically read next time that file is loaded though the UI
I threw together a cli and tried running two exports. One for 10-15 seconds and one for 15-20 seconds, and then concatenate them afterwards. The result was not very smooth when using adaptive zooming. There was a clear cut from the first to the second clip.
I believe it's caused by the adaptive zooming (smoothingFocus
) because it's only being computed for the frames chosen for export. Is that right?
The concatenated file was perfectly fine with no "cut" with smoothingFocus=-2
, so I assume it's the adaptive zooming that causes it.
Glancing over the code for adaptive zoom, I'm not sure how to fix that without changing it to computing adaptive zooming for whole file. Any advice?
+1 for this feature request - support for batch processing would be a great addition. Like most others I suspect, I've settled on a static set of settings (+ auto sync) that work for my style - so the ability to script GyroFlow to iterate over the days flights would take a lot of tedium out of the workflow.
Awesome project 👍
A CLI was added in #104 which has been merged and is available on the dev
branch.
There are examples in pr: #104
It would be great to be able to automate the process of stabilizing by running gyroflow without a GUI, and passing all options in the cli. Supporting all options via cli could be hard, so using config files will probably be needed for more advanced options.
I almost always use the same settings (on first run), so it would speed up the process a lot.
Then one could also stabilize multiple files at once (in series), so I could stabilize 20 videos over night for instance.
How I imagine it'd work from the cli: