オプティカルフロー:フレーム間の動きを読み取る

オプティカルフローによるモーショントラッキングは、AutoScript Sync のすべてのスクリプトの土台となる唯一の信号です。サンプリングしたフレームの各ペアの間で、DIS 密オプティカルフローが、動いている領域のピクセルがどれだけずれたかを測定します。これで速度が得られ、エンジンはそれを積算して位置の軌跡にし、アンカーに結び付けてずれを抑えます。フローはすべてのマシンで CPU 上で動作します。

2026 年 9 月 21 日にアプリのコードと照合済み。

動いている領域に対する DIS オプティカルフロー

既定の適応型 AI エンジンは、OpenCV の DIS(Dense Inverse Search)オプティカルフローを FAST プリセットで使います。エンジンが動いていると判断した領域、または Set Motion Region… や Live Track で描いた枠に対して、幅 320 px に縮小したフレームの中で実行されます。それと並行して、ultrafast プリセットによる半分の解像度の 2 回目の DIS 処理が動き、フローが信頼できるかを確認します。

Fast
4 フレームごとにフローを計算:30 fps の動画で毎秒 7.5 サンプル。
Balanced
3 フレームごと:30 fps の動画で毎秒 10 サンプル。既定値です。
High
2 フレームごと:30 fps の動画で毎秒 15 サンプル。幅 640 px 以上の平面(VR でない)映像では、追跡領域のフローを 640 px でも測定します。開発者の記録では、これによる改善はわずか(2 本の動画でストローク F1 が +0.007 と +0.003)で、解析時間は約 1.4 倍です。

間隔は固定のフレーム数なので、60 fps の動画ではどのレートも倍になります。

AutoScript Sync は Farneback オプティカルフローを使っている、という記述をほかで見かけるかもしれません。メインのエンジンは使っていません。Farneback が登場するのは、メインの Generate ボタンで Use adaptive AI engine のチェックを外したときの基本エンジンと、AI Bulk Learn の裏で動くサンプラーだけです。

速度から位置へ

フローからわかるのは何かがどれだけ速く動いたかで、それがどこにあるかではありません。速度を積算すれば位置になりますが、小さな誤差もすべて一緒に積み重なり、軌跡がさまよってしまいます。そこでエンジンは、積算したフローをアンカーに結び付けます。アンカーとは、動いている領域の中心、姿勢のキーポイント相対的な深度から動画ごとに選定する、より遅い絶対的な位置の尺度です。既定では、読み取れるすべてのチャンネルをサンプルごとにブレンドしたものが、単独の勝者と同等以上のスコアであればアンカーになります。

RTS スムーザー付きの Kalman フィルター(動画全体に対して順方向の処理のあと逆方向の処理を行う)が、この 2 つを 1 本の位置の軌跡に統合します。Depth priority 設定(30〜90、既定値 85)は、その軌跡のどれだけを速度から得るかを決めます。値が高いほどアンカーの重みは小さくなります。設定のツールチップ自体がこのトレードオフを説明しています:速度はストロークの大きさを担い、アンカーはずれを止めますが深さを平らにし、速いストロークには追従できません。変更するには、再送だけでなく再生成が必要です。

トラッキングが途切れた部分は、前後のストロークから続くリズミカルな動きで補完され、こうして補完したタイムラインの割合はスクリプトのメタデータに記録されます。

リズムの整理

既定では、完成した軌跡に 2 つの整理処理が行われます。ハーモニック・フォールディングは、実際のストロークの倍の周期で現れるジグザグを取り除きます。リズム正規化は、信頼度の低いピークを周囲のビートの方へ寄せます。そのあと、AI ファンスクリプト生成のしくみで説明したとおり、反転するたびに点が置かれます。

コーデックの動きベクトルと音声のエンベロープ

メインの処理が動いている間、バックグラウンドのスレッドが PyAV でさらに 2 つの信号を読み取ります。どちらもオプションです。PyAV や音声トラックがなければ、映像のみの経路がそのまま動作します。

  • コーデックの動きベクトル。圧縮された動画には、フレームごとに画面のブロックがどう動いたかがすでに保存されています。アプリは、サンプリングしたフレームだけでなくすべてのフレームのベクトルを、動画の長さに応じて 25〜150 秒の時間枠の中で読み取ります。その速度が信号として使われるのは、動画の 90% 以上をカバーできた場合だけです。
  • 50 Hz の音量エンベロープ。時間枠は 20〜120 秒です。音声は、補完した動きをサウンドトラックのビートと位相が合った状態に保ちます。

時間枠があるため、長い動画は一部しかカバーされないことがあります。これらの主な役割は周波数の証拠となることで、どの区間をフルフレームレートで読み直す 2 回目の処理にかけるかの判断を助けます。この処理は、サンプリングレートに対して動きが速すぎるように見えるウィンドウや、トラッキングの品質が低いウィンドウを対象にします。対象は最大 4 区間、動画の最大 35% までです。開発者の測定では、区間が時間順に選ばれるため、実際にカバーしたのは各テスト動画の 0.2〜0.6% で、すべて最初の 40 秒以内でした。動画全体をフルフレームレートで処理するものではありません。選んだ区間については、タイムラインエディターの Re-analyze でそれをいつでも実行できます。

シーンカットの検出

カットをまたいでフローを積算すると、カメラの切り替えを巨大な動きとして扱ってしまいます。そこでエンジンは、サンプリングしたフレームのペアごとに確認します:ピクセルの平均差が 28 を超えるとカットの候補とし、2 枚のグレースケールフレームの輝度ヒストグラムの相関も 0.80 を下回った場合にだけカットとみなします。ヒストグラムの確認によって、本物のカットと速い動きを区別します。速い動きは多くのピクセルを変えますが、同じ画面を動かしているだけで、置き換えているわけではないからです。カットはこの方法で検出しており、コーデックの動きベクトルからではありません。

フローの処理コスト

フローは重い処理ではありません。開発者のフロー検証では、CPU でのフロー処理にかかった時間の中央値は、Balanced 設定でサンプルあたり 4.8〜5.1 ms、High の倍の領域解像度で 7.6〜9.1 ms でした。これらの数値は 3 本の動画それぞれの 200〜400 サンプルから得たもので、生成全体ではなくフロー処理だけを測ったものです。ベンチマークではなく、規模の目安として受け取ってください。深度推定が GPU に移ってからは、開発者の測定では姿勢推定が最も大きな段階になっています。

制限

  • 速いストロークとサンプリングレート。30 fps の動画を Balanced で処理すると、エンジンが見るのは毎秒 10 フレームです。開発者が手作業でスクリプトを作ったテストクリップと比べると、最も速い 2 本の動画でストロークが人間のものよりかなり小さくなりました。現時点での説明は、このレートでは速い動きがならされて消えてしまう、というものです。High はより密にサンプリングし、Re-analyze は選択した区間をフルフレームレートで読み取ります。
  • フローが測るのは動きで、意味ではない。追跡領域の中の動きは、それが目的のストロークかどうかに関係なく、すべて記録されます。人間がアクションなしと指定した区間でも、エンジンは毎分約 85 回の方向転換を出力しました。
  • CPU のみ。フローはすべての PC で OpenCV の CPU 実装で動作します。速い GPU で高速化されるのは姿勢と深度で、フローではありません。

よくある質問

なぜアプリは Farneback ではなく DIS を使うのですか?

既定の適応型 AI エンジンは、FAST プリセットの DIS に、半分の解像度での信頼性チェックを組み合わせて使います。Farneback が残っているのは基本エンジンと AI Bulk Learn のサンプラーだけです。この 2 つは OpenCV の異なる密オプティカルフローの手法です。このページはコードが実際に何を実行しているかを説明するもので、私たちが公表した直接比較ではありません。

動画に音声は必要ですか?

いいえ。サウンドトラックがある場合、音声のエンベロープは補完した部分をビートに合わせるのに役立ちます。ない場合は、映像のみの経路がそのまま動作します。

フレームの特定の部分をフローに追わせることはできますか?

はい。Set Motion Region… は動画全体に 1 つの枠を指定し、Live Track では動画の再生中に枠を動かせます。その軌跡は .roitrack.json ファイルとして動画の隣に保存されます。

次に読む

自分の動画で試す

体験版は 1 日間、あなた自身の PC で動作します。動画はローカルで解析され、アップロードされることはありません。