9月4日，有用户在pygyroflow项目上执行了python -m pygyroflow.cli.main GoPro_Hero_6.MP4命令，得到的输出视频与原始素材一样抖动，反馈只有四个字——没有防抖效果。据该项目维护者介绍，pyGyroflow是用Python对Gyroflow进行重构后自行维护的移植项目，此前测试只使用了DJI拍摄的视频，缺少GoPro素材，因此一直未能验证GoPro设备上的处理表现。目前手上有了可用的测试资源，维护者利用接连几个周末持续排查，把问题定位到两个环节。
Hero5/6不写STMP标签，陀螺数据被压缩到995毫秒
拿到反馈视频后，维护者先从遥测数据入手：时长34秒的片段，解析出来的陀螺数据竟然只剩995毫秒，这说明要么视频里附带的陀螺信息有问题，要么解析代码存在缺陷。GoPro把陀螺仪和加速度计数据封装在MP4文件的GPMF轨道内，按设计每个gpmd包应当携带一个STMP标签，即绝对时间戳。旧版解析实现把STMP当作时间基准来用，一旦某个包内缺失该标签，就统一赋值为0。然而Hero5与Hero6设备本身并不写出这个字段，偏差便由此产生。维护者比对了Rust编写的参考实现，在telemetry-parser的util.rs里找到normalized_imu相关处理，又在gopro模块的get_avg_sample_duration中确认了原因，随后把对应思路移植进自己的代码，修正了这一时间基准计算逻辑。
镜头档案匹配仅靠宽高比加字母序，输出迟迟不达标
解决了时间戳问题再跑一次，结果依然没有达到预期。维护者继续往下查，发现镜头参数的配对同样存在漏洞：原有自动匹配只依赖两项规则，第一是宽高比一致，第二是按字幕顺序排列。更换更准确的匹配方式、重新比对GoPro对应的镜头参数后，流程才算初步跑通。9月4日的那条命令重新执行后，autosync保持默认开启状态，镜头档案三项全部命中，输出数值为0.55/2.84，已经很接近Gyroflow官方版本的处理水平。维护者也坦言，距离完全对齐Rust版本的表现仍有明显差距，后续还会继续调优。文末他还向读者征集素材：若手头上有其他品牌设备的遥测数据和类似抖动视频，可以在评论区提供文件，他会尝试进一步优化。
小镇：这是一次典型的「跨机型兼容性不足」案例。GoPro Hero5/6省略STMP标签、旧解析逻辑按0兜底，再加上镜头档案选配太粗，两个问题叠加导致防抖彻底失效。修复路径已经明确，pyGyroflow在非DJI设备上的可用性正在逼近主流实现，但完全追平仍有距离。