opencvのオプティカルフローで見たすべての実装は、ビデオをフレームの配列として使用し、各画像にオプティカルフローを実装します。これは、画像をN×Nブロックにスライスし、速度ベクトルを探索することを含む。オプティカルフローのビデオの動きベクトルデータを使用しないのはなぜですか？
ビデオコーデックの動きベクトルは誤解を招きますが、必ずしも動き情報が含まれているとは限りませんが、どのブロックに動きがあるかをチェックし、それらのブロックでオプティカルフローを実行するのはなぜですか？プロセスを固定するべきではありませんか？
OpenCVは汎用画像処理フレームワークです。アルゴリズムの圧縮ビデオではなく、フレームのが必要です。
コーデックからopenCVへの置き換えに関する情報を引き渡すビデオデコーダを作成することはできますが、それは非常にコーデック固有であり、したがってopenCVの範囲には含まれません。
私は、オプティカルフロー/ビジョンモーション解析のためのh.264などのコーデックに埋め込まれた "モーション"ベクトルの使用について学んだことをはっきりと覚えています。これを行う最も簡単なアプローチは、反復推定（Horn and Schunkなど）です。デコーダからのベクトルを用いて反復アルゴリズムを簡単にブートストラップすることができる。
これで推定の精度は向上しません。収束の速度を上げることができ、早期に停止することができます。
すべてのh.264エンコードが同じ品質であるわけではありません。特に、限られたハードウェアを持つリアルタイムシステムから。動きベクトルがひどくひどい場合があり、実際には助けに代えて流れの見積もりに損害を与える可能性があります。私は、ほとんど静的なシーンのために設計された、ローエンドのIPカメラを考えています。照明などを変えて動いています。
ありがとう。非常に高い理論的意味では、動きベクトルデータはオプティカルフローのプロセスをスピードアップし、コーデックとopencv関連の実装を破棄するべきですか？つまり、ビデオコーデックの動きベクトルはオプティカルフローの速度ベクトルですが、高度に最適化されていますが、より良い圧縮を達成するために異なるアルゴリズムを使用しています。おそらく – cowboysaif
？特定のコーデックを見ずに、モーションデータをデコーダから取り出すためにどれだけのオーバーヘッドがあるかを把握することなく、言うことは不可能です。おそらく単に我々が話していることを単に実装するだけです。 VLCのソースコードを見てください。 IIRCでは、VLCは少なくとも動きベクトルを小さな矢印として表示できます。チャンスは、あなたはそのメカニズムを採用することができます。 –