ビデオ プレビューが成功しただけでは、意図した動作モードでの RAW イメージのキャプチャが安定しているという証拠としては不十分です。ディスプレイ ソフトウェアは、低解像度、圧縮ストリーム、スキップされたフレーム、または異なるバッファリング ポリシーを使用する場合があります。デバイス、トランスポート、ドライバー、またはアプリケーション キューで問題を特定する前に、動作モードと測定境界を記録し、それらを一定に保ちます。

フレームが失われるレイヤーを定義する

位置 観測可能なフィールド 守るべき区別
デバイスと輸送 デバイスのフレーム識別子、ステータス、転送エラー 未生成、未受信、無効は別のイベントです
ホスト受信 受信数、有効な長さ、形式、エラー 受信したバッファは必ずしも有効な画像であるとは限りません
アダプターとキュー エンキュー、デキュー、待機、占有、破棄の理由 意図的なサンプリングと意図しない損失には別個のカウンターが必要
処理と出力 開始、完了、タイムアウト、および結果の識別子 結果が見つからない場合は、失敗または意図的なスキップが反映されている可能性があります。

連続したデバイス フレーム シーケンス番号が欠落している場合は、再接続、リセット、およびカウンター ラップアラウンド (番号付け範囲の先頭に戻る) も確認してください。ホストが生成したフレーム識別子は、ホストが受信したシーケンスを記述します。デバイスがフレームを失わなかったことを独自に確立することはできません。

生のフレームで最小限の再現を確立する

カメラ、ファームウェア、ケーブル、ホスト、ドライバー、SDK、解像度、フォーマット、フレーム レートを記録します。生のフレームを受信して​​チェックするプログラムから始めます。エラーとリソースを比較しながら、変換、推論、保存、表示を個別に追加します。さまざまなモードを直接比較するのではなく、ベンダーの例をビジネス アプリケーションとは別に記録します。

バッファと所有権を確認する

SDK バッファーがいつ読み取り可能のままであるか、いつ返される必要があるか、およびコールバックが長期所有権を許可するかどうかを定義します。キューの長さと待ち時間を記録します。古いフレームが破棄される可能性がある場合は、破棄の理由と数を保存します。すべてのフレームを保存する必要がある場合は、スループットとバックプレッシャーを考慮して設計してください。キューが大きいだけでは修正は確立されません。

タイミングと回復

クロック ソースを定義し、露出時間、受信時間、エンキュー時間、完了時間を区別します。再接続の場合は、パラメータの再適用、バッファクリア、シーケンス再起動を指定します。デバイスのタイミングや独立した基準がなければ、ホストのタイムスタンプは露光同期を確立せず、エンドツーエンドの応答も完了しません。

合意された条件、同時実行性、期間の下で、通常の操作と回復をテストします。構成、カウンタ定義、生のログ、および再現手順を提供します。関連サービス: イメージキャプチャ開発 そして ビジョンデバイス SDK.