3

私は、おそらく長いビデオ（最低30分）のビデオフレームへの非常に高速なランダムアクセスを必要とするアルゴリズムに取り組んでいます。現在、OpenCVのVideoCaptureを使用してビデオを読んでいますが、シーク機能が壊れているか、非常に遅いです。これまで私が見つけた最高のものは、MKVコンテナ内でMJPEGコーデックを使用することですが、十分な速度ではありません。

任意のビデオ形式を選択することも、新しい形式を作成することもできます。収納スペースは問題ありません（もちろんある程度）。唯一の要件は、ビデオ内の任意の場所への可能な限り最速のシーク時間を取得することです。理想的には、クアッドコアCPUを利用して、複数のフレームに同時にアクセスできるようにしたいと考えています。

リレーショナルデータベースは大量のデータを格納するのに非常に優れており、同時読み取りアクセスが可能であり、インデックスを使用する場合は非常に高速です。

SQLiteは私の特定のニーズに適していますか？各ビデオフレームをJPEGで圧縮して保存し、フレーム番号のインデックスを使用してすばやくアクセスする予定です。

編集：私にとって、フレームは単なる画像であり、ビデオ全体ではありません。30分ビデオ@25fpsには、30 * 60 * 25 = 45000フレームが含まれています。その番号を使用して、そのうちの1つをすばやく取得できるようにしたいと思います。

編集：興味がある人のために、私は最終的に各フレームを固定サイズのブロックに保存するカスタムビデオコンテナを実装しました（したがって、任意のフレームの位置を直接計算できます！）。画像はturbojpegライブラリで圧縮され、ファイルアクセスはマルチスレッド化されます（NCQに対応するため）。ボトルネックはもうHDDではなく、私はついにはるかに優れたパフォーマンスを手に入れました:)

4

2 に答える 2

5

SQLite（または他のdabataseエンジン）を使用することはあなたの問題の良い解決策ではないと思います。データベースはファイルシステムではありません。

必要なのが非常に高速なランダムアクセスである場合は、ファイルシステムに固執します。これは、この種の使用法のために設計されており、これを念頭に置いて最適化されています。あなたのコメントによると、5時間のビデオには450kのファイルが必要だとあなたは言います、まあ、それは私の意見では問題ではありません。確かに、ディレクトリリストは少し長くなりますが、可能な限り最速のランダムアクセスが得られます。そして、あなたは1レベルの抽象化であるため、SQLiteよりも確かに高速です。

また、ディレクトリの一覧表示時間が本当に心配な場合は、フォルダ構造をツリーのように整理する必要があります。それはあなたに長い道のりを与えるでしょう、しかし速いリスト。

于 2012-06-17T16:43:35.553 に答える
1

高レベルの視点を保ちます。問題は、OpenCVがソースビデオを探すのに十分な速さではないことです。これは、

  • コーデックはOpenCVの強みではありません
  • ソースビデオは、効率的なシークのためにエンコードされていません

マシンには活用できる専用のグラフィックハードウェアがたくさんありますが、ファイル、データベース、ファイルのセットなど、17GBのデータセット内をランダムに検索するための特別な機能はありません。ディスクはシークごとに数ミリ秒かかります。SSDには適していますが、それでもそれほど優れていません。次に、メインメモリにロードされるのを待ちます。最初に、すべてのデータを生成する必要があります。

ffmpegを使用します。これは、おそらくGPUを使用しても、デコードを非常に効率的に処理する必要があります。これがチュートリアルです。（免責事項、私はそれを自分で使用していません。）

ビデオを前処理してキーフレームを追加することができます。原則として、少なくともMPEGの場合、これは完全に再エンコードする必要はありませんが、詳細についてはよくわかりません。MJPEGは基本的にすべてのフレームをキーフレームに変換しますが、中間点を見つけることができ、2倍のサイズのコストで1.5倍速くシークすることができます。ただし、ディスクにぶつからないようにしてください。

SQLiteに関しては、これは17GB以内のデータを探すという問題に対する優れた解決策です。データベースがランダムアクセス用に最適化されていないという概念はポピーコックです。もちろんそうです。ファイルシステムは一種のデータベースです。17 GBでのランダムアクセスは、ソフトウェアではなくハードウェアが原因で低速です。

ファイルシステムはマシンの他の部分と同期された共有リソースであるため、このタスクにはファイルシステムを使用しないことをお勧めします。また、50万個のファイルを作成する（そして完了したら削除する）には長い時間がかかります。これは、ファイルシステムが専門としていることではありません。ただし、各ファイルに複数の画像を保存することで、これを回避できます。しかし、目的の画像を見つけるために何らかの形式が必要です。それなら、それらすべてを1つのファイルにまとめてみませんか？

実際、（17 GBのルートを使用する場合）問題全体を無視して、すべてを仮想メモリに入れてみませんか？VMは、SQLiteやファイルシステムと同じようにディスクシークを作成するのに優れています。プロセスがそれだけのメモリを使用しても問題がないことをOSが認識していて、64ビットポインタを使用している限り、これは優れたソリューションであり、最初に試す必要があります。

于 2012-06-18T05:22:11.290 に答える