Fix?/Workaround for the 2026 DJI 04 stabilization issue
After encountering this problem myself with a really solid commercial BNF drone - the GepRC Vapor X4 - I like so many others began looking for a firmware update or setting that would correct the problem. The closest I found was Justin Bainbridges workflow to remove the gyro data and use visual tracking instead (described here https://www.youtube.com/watch?v=w8imPl0sZ_o).
This convinced me that the issue is indeed corruption in portions of the gyro data. Instead of throwing it all away, I decided to look for a way to simply clean up the bad data.
An afternoon with Claude proved to be shockingly productive. I started by getting it to extract the gyro data to a csv file just to take a look at the data. Sure enough - I could see impossible spikes in rotation rates in areas where the footage was "bad". I then got claude to re-inject massaged csv files back into the MP4 - easy enough. Finally I prompted it to analyze the data, pointing out timestamp areas of corruption, and design filtering approaches. A few iterations of that produced surprisingly good results - I was then able to load the patched video into Gyroflow and, using just default settings, out came very much improved video. Not perfect, but much much better.
I've sent the code over to the Gyroflow team - not sure if they'll do anything with it (they may have legit licensing reasons for not), but who knows.
Of course the "proper" fix should come from DJI, but in the mean time I'll be using this.
If you're comfortable running Python and would like to try this out, here is the repo: https://github.com/gmatocha/DJI_04_Air_Unit_Gyro_Patcher
Side note - I've been a software engineer for decades. I've "vibe coded" a few times and haven't been impressed. But this was different. I know nothing about how gyro data is stored in MP4 files. In two hours this was solved. No hallucinations - each iteration worked. No agents running in VMs - all through the browser. I swear this isn't an ad.