# Gyroflow: video stabilization that uses the gyro data your camera already recorded > Gyroflow smooths shaky footage by reading motion sensor data recorded alongside the video, and it works across action cameras, drones, cinema bodies and phone apps. The interesting part is the engine split and the plugin route, not just the desktop app. **gyroflow/gyroflow** — Video stabilization using gyroscope data - Repository: https://github.com/gyroflow/gyroflow - Website: https://gyroflow.xyz - Stars: 9,621 · Forks: 535 - Language: Rust - License: GPL-3.0 - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/gyroflow-gyroflow ## Stabilization as a math problem, not a filter Most stabilization in an editor is an optical or a post-hoc filter: the software decides which pixels to keep and discards the rest. Gyroflow does something different in principle. Modern cameras already write gyroscope and sometimes accelerometer data into the video file, recorded on the sensor at the moment each frame was exposed. Gyroflow reads that data, reconstructs the camera's orientation at every timestamp, and warps the frame accordingly. The movement is known rather than guessed. That distinction explains most of the feature list. Because orientation comes from real measurements, the tool can correct rolling shutter, where the top and bottom of a frame were exposed at different moments and therefore have different geometry, and it can work on variable and high frame rate footage, since the README states that all calculations are done on timestamps rather than frame counts. It can also handle underwater distortion, which is a lens profile problem rather than a stabilization problem. The camera list is long enough to show the design is not tied to one vendor. GoPro from HERO 5 onward, a long Sony alpha and FX list, Insta360, DJI, Blackmagic RAW, RED RAW with the R3D SDK, Canon bodies, Freefly Ember, Betaflight blackbox files, ArduPilot logs, XTU, WitMotion and the CAMM standard all appear, along with mobile logger apps such as Sensor Logger and G-Field Recorder. The list also includes already-stabilized GoPro footage captured with Hypersmooth enabled, from Hero 8 upward, which is a useful admission that in-camera stabilization is sometimes the thing you want to undo. ## A dependency-free core with a Qt shell around it The most consequential structural fact is in the feature list, worded as a parenthetical: the core engine is a separate library without external dependencies, specifically no Qt, no ffmpeg and no OpenCV, and it can be used to create OpenFX and Adobe plugins. The OpenFX and Adobe plugin work is on the TODO list, which matters if you are deciding whether to build on it. The Cargo manifest shows how the split is implemented. The `gyroflow-core` dependency is a path dependency pointing at `src/core/`, and it is resolved differently per platform: on Android and iOS it is pulled in with only the `use-opencv` feature, while on desktop it gets `use-opencv` and `use-opencv` alongside `use-opencl`. The feature flags at the top of the manifest expose `opencl` and `opencv` directly and make `opencv` the default. ```toml [features] default = ["opencv"] opencl = ["gyroflow-core/use-opencl"] opencv = ["gyroflow-core/use-opencv"] ``` The desktop shell is Qt and QML, with `qmetaobject`, `qttypes` and `qml-video-rs` listed as dependencies, the last pinned to a specific git revision rather than a crates.io version. Parallel work goes through `rayon`, and the allocator is `mimalloc`, which tells you the project cares about allocation behaviour under a real workload. There is also `rustfft` for the filtering side and `argh` plus `indicatif` for the command line interface. The manifest is on edition 2024 and the version there is 1.6.3, matching the most recent tag. ## The plugin route changes what you should buy Gyroflow maintains separate video editor plugins for Adobe Premiere and After Effects, DaVinci Resolve and Final Cut Pro, hosted in their own gyroflow-plugins repository. The README is specific about why: they allow you to apply stabilization directly in a video editor without transcoding. That is a bigger deal than it first appears. The normal workflow is extract, stabilize, re-encode, re-import, and the re-encode is where quality is lost and time is spent. If the editor plugin applies the correction to the preview and renders from the original file, the only cost is render time at delivery. For anyone working with 10-bit or ProRes footage from a cinema camera, keeping the intermediate out of the pipeline is the whole point. The same section also names the codec and format reach: H.264 and H.265 fully GPU accelerated, ProRes accelerated on Apple Silicon, plus DNxHD, CineForm, PNG and OpenEXR outputs, and support for image sequences in PNG, OpenEXR and CinemaDNG. Version 1.6.2 added support for ProRes RAW. The README also states that 10-bit is supported up to 16-bit 4:4:4:4 for regular codecs and 32-bit float for OpenEXR, working directly on YUV data to preserve quality. One line in that list is worth reading twice: full Sony metadata support, including automatic lens, support for IBIS, OIS and EIS, and the claim that you can have IBIS enabled in the camera and still apply Gyroflow on top. In-camera stabilization warps the frame before Gyroflow sees it, so applying both is normally the wrong order. That combination is possible here because the metadata tells the tool what the camera did, so it can reason about the residual motion rather than fight it. ## Getting it, and the camera list as a gate There is no install command in the README, which is expected for a desktop application distributed as signed builds. The README links a homepage, a download page pointing at GitHub releases, documentation, and a Discord, and the repository holds `Justfile` and `_scripts/` for building it yourself. The `_deployment/` directory is where packaged output lives. The gate for anyone considering this is the supported gyro source list. The README states plainly that for a camera with a built-in gyro which is not on the list, the answer is to contact the project and request support, and points at the documentation for how gyro logging works. For cameras with no gyro at all, the fallback is to use another device's data, which is the Betaflight blackbox path and the phone logger apps. That phrasing sets expectations correctly. This is not a tool where an unknown camera degrades gracefully into approximate stabilization. Either the motion data is parsed correctly, or the project needs to add a parser for it. The telemetry-parser library by the same author handles the source-specific formats, and the README credits it as the basis for out-of-the-box support, which is why a new camera is a matter of parsing rather than mathematics. Lens calibration is also required in practice, and the built-in profile database ships with official profiles for GoPro HERO 6 through 13, Sony, DJI, Insta360 action cameras and RunCam Thumb series and 5 Orange, with the README noting that the profile database updates itself automatically. ## What the release notes fix, and what they reveal Three releases are recorded, and reading them is more informative than the feature list because they name what actually breaks. Version 1.6.3 from 2025-09-04 is a bug fix release: 10-bit rendering on NVIDIA cards, a rendering crash on Intel devices, intermittent decoder failures on macOS, keyframe navigation on Windows, and CLI presets that lacked a version field. Version 1.6.2 from 2025-08-19 mixes improvements and fixes. ProRes RAW and Insta360 Go Ultra support arrived, along with memory optimisation for large Sony files, a frame-offset option replacing the time-offset approach, and Vulkan or D3D12 encoder options for Windows ARM devices. On the fix side: merging multiple files from some DJI cameras, a crash loading old GoPro Hero 5 files, Sony Burano gyro data, and BRAW sync in the CLI. Its SDK update line is the sort of thing worth tracking, since FFmpeg moved to 8.0, BRAW SDK to 5.0.0 and R3D SDK to 8.5.1. Version 1.6.1 from 2025-04-07 added a median filter for motion data, a CLI option to disable GPU decoding, a .tmp file created during rendering so an interrupted export does not look finished, and a metadata check before merging video files so mismatched clips are caught. Its fixes cover long .gcsv files, 10-bit colours on AMD, Sony files without lens metadata, and an iOS crash when exporting gyro data. The pattern across all three is hardware-specific correctness. The last push was on 2026-09-04, the repository is not archived, and the current version line is 1.6.3 under a GPL-3.0 licence. ## Where this is the wrong choice The clearest wrong case is footage with no motion data. Gyroflow's whole approach assumes a rotation record exists. Point it at a clip shot on a camera with no gyro and no external logger and there is nothing to reconstruct orientation from, and the README does not claim otherwise. Long-take tripod or locked-camera material is a poor use of it too, since the correction has nothing to fix. The second wrong case is social video workflows. This is a desktop application with a render queue, a preset system and a motion data chart. If the goal is a stabilizing filter applied to vertical clips for a feed, that is a much smaller job than the tool in front of you. The third is integration risk. The core engine without external dependencies is genuinely attractive if you want to build something on it, but the OpenFX and Adobe plugin work is still on the TODO list, and the plugins that do exist live in a separate repository with their own release cycle. Anyone planning a long-lived integration is betting on a single-maintainer project whose most recent tag is 1.6.3, published in September 2025 while development continued afterwards. One more practical note: GPU decoding can be disabled from the CLI, which the 1.6.1 notes added, and that flag exists because hardware decoders were producing wrong output on specific GPUs. The release history suggests treating decode options as a thing to check when a render looks wrong, rather than assuming the output is clean. ## Conclusion Gyroflow is a good fit when your footage has motion data attached to it and you want the stabilization applied in your own editor rather than baked into a new file, which is exactly what the Premiere, Resolve and Final Cut plugins are for. It is the wrong tool when there is no gyro data at all, since nothing in it invents motion from a single frame sequence, and the wrong tool for someone who wants a one-click button on Windows. What to verify first is whether your exact camera model appears in the supported source list, because the README is explicit that a camera missing from that list means a feature request rather than a settings tweak, and then whether the plugin package matches the editor you actually run. ## FAQ ### Is Gyroflow free to use? Gyroflow is released under the GPL-3.0 licence, and the README links downloads directly to the GitHub releases page rather than to a paid page. There is no feature gate described anywhere in the README, including for the video editor plugins. The licence does carry obligations if you redistribute a modified build, which is a question for your own counsel rather than something the project documents. ### What is Gyroflow used for? Gyroflow stabilizes video using gyroscope and optionally accelerometer data that the camera recorded internally, and it works from external sources such as Betaflight blackbox logs. It corrects rolling shutter distortion, supports underwater footage, offers keyframes and a render queue, and ships plugins for Adobe Premiere, After Effects, DaVinci Resolve and Final Cut Pro so stabilization can be applied without transcoding. ### Which Canon lenses are supported by Gyroflow? The README lists supported Canon bodies rather than lenses by name: the C50, C80, C400, R6 Mark III and R5 Mark II, reading motion data from MP4, MOV and MXF files. For lens detail generally, the README says built-in official lens profiles cover GoPro HERO 6 to 13, Sony, DJI, Insta360 action cameras and RunCam, with automatic lens metadata supported for Sony bodies and a manual calibration process otherwise. ## Sources - [gyroflow/gyroflow on GitHub](https://github.com/gyroflow/gyroflow) - [License: GPL-3.0](https://github.com/gyroflow/gyroflow/blob/master/LICENSE) - [Project website](https://gyroflow.xyz) - [README](https://github.com/gyroflow/gyroflow/blob/master/README.md) - [Releases](https://github.com/gyroflow/gyroflow/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gyroflow-gyroflow