カメラのフレームレートを高くすると短時間の動きをより確実に捉えられますが、NVRのデコード、推論、メモリ、ストレージにかかる負荷は増加します。
車道を映すカメラが30 FPSで録画しながら、検出器は毎秒5フレームだけを解析する場合があります。カメラのフレームレートを上げるとパイプラインが扱える時間的な情報量は増えますが、有用なフレームがモデルに届き、ハードウェアが処理を滞らせずに済む場合にのみ精度が向上します。この関係は、対象の速度、露出の品質、推論時のサンプリング、コーデックの負荷、録画と解析に別々のストリームを使うかどうかによって変わります。
フレームレートが変えるのは時間的な捕捉範囲であり、モデルの能力ではない
フレームレートは、カメラが動いているシーンをサンプリングする頻度を決めます。5 FPSでは連続する画像の間隔が200ミリ秒、30 FPSでは約33ミリ秒です。そのため、動きの速い対象は低いフレームレートのサンプル間でより大きく移動し、検出範囲から外れるまでに利用可能な位置として映る回数が少なくなる可能性があります。
高いFPSは速い動きについて、より連続的な視覚情報を提供します。一方、低いフレームレートでは、短時間の接触や方向転換を見逃すことがあります。ただし、この利点は時間的なものであり、ブレ、暗さ、対象が小さいこと、シーンに適していない学習が行われた検出器を改善するものではありません。
イベントがすでに十分な数の鮮明な解析フレームにわたっている場合、精度は頭打ちになることがあります。広いポーチを横切るゆっくりした人物は控えめなFPSでも検出し続けられる一方、狭い視野の端付近を通過する車両には、より密なサンプリングが必要になる場合があります。意味のある比較を行うには、解像度、露出、モデル、シーンを一定に保ち、解析フレームレートだけを変更します。
解析FPSは録画FPSと異なる場合がある
NVRは入力されたすべてのフレームを保存しながら、選択したフレームだけを検出器に送信できます。録画FPSは再生の滑らかさと証拠の密度を維持し、検出FPSは推論を実行する頻度を決めます。両者を同じ設定として扱うと、高品質なメインストリームを保持しながら、低いフレームレートまたは低い解像度のサブストリームを解析するという、よくある最適化が見えなくなります。
この違いは、カメラストリームの処理能力を見積もる際に重要です。1台の物理カメラが、取り込み、デコード、録画、動体検知、AIという別々の負荷を生み出すため、「8台のカメラ」という数字だけでは、毎秒何フレームがデコードまたは推論されるかは分かりません。
30 FPSのカメラを5 FPSで解析すると、時間的な補間を使わない限り、モデルに届くのは6フレームに1フレームだけです。カメラのFPSだけを上げても、録画ストリームのサイズが増えるだけで、検出範囲は変わらない可能性があります。運用上の指標となるのは、実際にデコードされ推論に提示されるフレーム数と、選ばれたフレームの品質です。
解析するフレームが増えるたびにパイプラインの処理量も増加する
解析する各フレームでは、パケット処理、動画デコード、色変換、リサイズ、モデル推論、後処理、追跡、イベント処理が必要になる場合があります。一部の処理はバッチ化または高速化できますが、それでもフレーム数に応じて増加します。複数のカメラでは、独立したストリームとメモリバッファごとに負荷が積み重なります。
スパースなキーフレームに関する研究は、動画システムがすべてのフレームで最も重いネットワークを独立して実行するのを避ける理由を示しています。時間的特徴を再利用すれば重複した計算を減らせますが、フレームの処理が無償になるわけではなく、精度と速度の別の設計が必要になります。
NVRが飽和すると、要求FPSと実効FPSに差が生じます。フレームがキューに滞留したり、ドロップしたり、アラートの価値が失われるほど遅れて届いたりする可能性があります。その時点では、名目上のフレームレートを高くしても、適時に連続したサンプルを解析するのではなく、古い、または不均一なサンプルを解析することになるため、運用上の精度が低下する場合があります。
有用なFPSはイベントの継続時間とハードウェアの余裕で決まる
解析FPSは、観測する必要がある最短のイベントと、検出器またはトラッカーが必要とする鮮明なフレームの最小数から決めます。ゆっくりした滞在状況の検知なら疎なサンプリングでも対応できる場合がありますが、速いゲート通過、投げられた物体、狭い領域に入るナンバープレートなどでは不十分な可能性があります。カメラの設置位置によっても、その要件はFPSと同程度に変わります。
空フレームのフィルタリングに関する研究は、関連する動きがないフレームで高コストな検出を避けることの価値を示しています。シーンによるゲーティング、動体領域、サブストリームを活用すれば、時間的な密度が実際の判定を改善する区間に計算資源を振り向けられます。
したがって、最適なフレームレートはカメラが公称する最大値ではありません。対象イベントを十分な時間的範囲で捉えながら、稼働中のすべてのストリームに対してデコードと推論の余裕を確保できるレートです。滑らかな再生だけで判断するのではなく、複数カメラを同時に使ったテスト、ドロップフレーム数、推論レイテンシ、イベントの見逃し状況を確認して検証してください。
テック&AIハブ
もっと読む

サービスを追加するにつれて変わるJellyfinホームサーバーのアーキテクチャ
Jellyfinボックスはアプリを追加するほどサービススタックへと発展するため、CPU、ストレージ、ネットワーク、シークレット、バックアップ、復旧の境界について、誰が管理するのかを明確にする必要があります。

キャッシュを容量と取り違えずにJellyfinのパフォーマンスを測定する方法
信頼性の高いJellyfinベンチマークでは、キャッシュされたメタデータやファイルシステムのページを恒久的なハードウェア性能と取り違えないよう、コールド状態とウォーム状態を分けてラベル付けします。

マルチユーザーのJellyfinには、iGPUのどれくらいの余力が必要?
JellyfinのiGPUの余力はワークロードによって異なります。任意の使用率を基準にするのではなく、再現性のある同時トランスコード構成の中で最も負荷が高いものを上回る余裕を確保してください。

