4Kフレームには800万ピクセル以上が含まれています。圧縮せずに毎秒30フレームを送信すると、非常に大きなデータストリームが生成されます。そのため、USBカメラモジュールはMJPEGを使用することがよくあります。JPEG圧縮は、USBリンクを通過する必要のあるデータ量を削減するためです。
USB2.0はUSB3.xよりも実質的な帯域幅がはるかに少なくなっています。USB3.xであっても、非圧縮の高ビットレートモードは他のデバイスやホストコントローラーの制限と競合する可能性があります。MJPEGを使用すると、フレームあたりのバイト数を減らすことで、同じ物理インターフェイスでより高い解像度またはフレームレートを処理できます。
H.264/H.265のようなロングGOPビデオコーデックとは異なり、MJPEGは個々のフレームをJPEG画像として圧縮します。これにより、ランダムなフレームアクセスが比較的簡単になり、フレーム間予測の依存関係が回避されます。一部のビジョンアプリケーションでは、圧縮アーティファクトが残っていても、そのシンプルさが役立ちます。
圧縮はデータを消滅させるのではなく、他の場所に処理を移動させます。カメラまたはブリッジが画像を圧縮し、ホストがそれをデコードします。組み込みプロセッサが弱い場合、USBバスがそれらを処理できる場合でも、複数の4K MJPEGストリームに苦労する可能性があります。
マルチカメラシステムの場合は、USB使用率とCPU/GPUデコード負荷の両方を測定してください。
ホストは依然としてモードをネゴシエートし、ストリームを受信し、フレームをデコードしてメモリに移動する必要があります。ソフトウェアフレームワークはバッファをコピーしたり、カラーフォーマットを変換したりして、遅延を追加する可能性があります。ケーブルの品質とUSBコントローラーの共有も、持続的なパフォーマンスに影響を与える可能性があります。
仕様は、デスクトップPCでのテスト成功から想定するのではなく、最終的なホストで検証する必要があります。
アルゴリズムがJPEGアーティファクトに敏感である場合、一貫したピクセル値を必要とする場合、またはデコーダーの遅延を回避する必要がある場合は、YUY2またはその他の非圧縮/生のパスが好ましい場合があります。その場合、USB3.x、低解像度、低フレームレート、または異なるインターフェイスが必要になる場合があります。
モードテーブル（解像度、フレームレート、フォーマット）を比較します。次に、USBバージョン、ホストデコード負荷、遅延、およびアプリケーションがすべてのフレームを処理するかどうかを確認します。'4K30'を宣伝するモジュールは、そのモードがMJPEG、H.264、または別のフォーマットであるかどうかに応じて、非常に異なる動作をする可能性があります。
単一の4K30 MJPEGカメラはホストで確実にストリーミングできますが、同じカメラ4台はUSBトポロジーまたはデコーダーリソースを圧倒する可能性があります。圧縮により各リンクの帯域幅は削減されましたが、システム全体で4つのストリームを受信してデコードする必要があります。したがって、マルチカメラ設計では、カメラごとの仮定ではなく、集計測定が必要です。
完全なステートメントには、フォーマットとインターフェイスを含める必要があります。たとえば、特定のUSBリンクを介したMJPEGでの30fpsの3840×2160です。フォーマットがないと、数値は主要なエンジニアリング上の制約を隠します。この読み取り習慣は、多くの選択ミスを防ぎます。
可逆圧縮フォーマットではないため、アーティファクトが発生する可能性があります。それらが問題になるかどうかは、圧縮設定とアプリケーションによって異なります。
H.265はより効率的に圧縮できますが、コーデックの複雑さと遅延が増加することがよくあります。MJPEGはシンプルでフレーム独立です。
一部のフォーマットと実装では可能かもしれませんが、正確なデータレート、プロトコルオーバーヘッド、およびホストパイプラインを確認する必要があります。インターフェイス名だけで想定しないでください。
