camera3_device_ops 構造体リファレンス

configure_streams:

CAMERA_DEVICE_API_VERSION_3_0 のみ:

HAL カメラ デバイス処理パイプラインをリセットし、新しい入出力ストリームを設定します。この呼び出しにより、既存のストリーム構成が stream_list で定義されたストリームに置き換えられます。このメソッドは、 initialize() の後に、 process_capture_request() でリクエストが送信される前に、少なくとも 1 回呼び出されます。

stream_list には、出力可能なストリームを 1 つ以上含める必要があります。入力可能なストリームは 1 つだけにする必要があります。

stream_list には、現在アクティブなストリームセット（configure_stream() の前の呼び出しから）にも含まれているストリームが含まれる場合があります。これらのストリームには、使用量、max_buffers、プライベート ポインタの有効な値がすでに設定されています。

このようなストリームのバッファがすでに登録されている場合、 register_stream_buffers() はストリームに対して再度呼び出されず、ストリームのバッファを入力リクエストにすぐに含めることができます。

新しい構成が原因で HAL が既存のストリームのストリーム構成を変更する必要がある場合、configure 呼び出し中に usage や max_buffers の値が書き換えられることがあります。

フレームワークはこのような変更を検出し、ストリーム バッファを再割り当てし、そのストリームのバッファをリクエストで使用する前に register_stream_buffers() を再度呼び出します。

現在アクティブなストリームが stream_list に含まれていない場合、HAL はそのストリームへの参照を安全に削除できます。フレームワークによる後続の configure() 呼び出しでは再利用されず、 configure_streams() 呼び出しが返された後に、その gralloc バッファはすべて解放されます。

stream_list 構造はフレームワークが所有するため、この呼び出しが完了するとアクセスできなくなる可能性があります。個々の camera3_stream_t 構造のアドレスは、stream_list 引数にその camera3_stream_t が含まれなくなった最初の configure_stream() 呼び出しが終了するまで、HAL によるアクセスに対して有効なままになります。HAL は、 configure_streams() 呼び出し自体の使用状況と max_buffers メンバーを除き、プライベート ポインタの外部にあるストリーム構造の値を変更しない場合があります。

ストリームが新しい場合、ストリーム構造の usage、max_buffer、private ポインタ フィールドはすべて 0 に設定されます。HAL デバイスは、 configure_streams() 呼び出しが返される前に、これらのフィールドを設定する必要があります。これらのフィールドは、フレームワークとプラットフォームの gralloc モジュールによって使用され、各ストリームの gralloc バッファが割り振られます。

このような新しいストリームのバッファをキャプチャ リクエストに含めるには、フレームワークがそのストリームで register_stream_buffers() を呼び出す必要があります。ただし、フレームワークは、リクエストを送信する前に すべての ストリームのバッファを登録する必要はありません。これにより、プレビュー ストリームなどの迅速な起動が可能になり、他のストリームの割り当ては後で、または同時に行われます。

---

CAMERA_DEVICE_API_VERSION_3_1 のみ:

HAL カメラ デバイス処理パイプラインをリセットし、新しい入出力ストリームを設定します。この呼び出しにより、既存のストリーム構成が stream_list で定義されたストリームに置き換えられます。このメソッドは、 initialize() の後に、 process_capture_request() でリクエストが送信される前に、少なくとも 1 回呼び出されます。

stream_list には、出力可能なストリームを 1 つ以上含める必要があります。入力可能なストリームは 1 つだけにする必要があります。

stream_list には、現在アクティブなストリームセット（configure_stream() の前の呼び出しから）にも含まれているストリームが含まれる場合があります。これらのストリームには、使用量、max_buffers、プライベート ポインタの有効な値がすでに設定されています。

このようなストリームのバッファがすでに登録されている場合、 register_stream_buffers() はストリームに対して再度呼び出されず、ストリームのバッファを入力リクエストにすぐに含めることができます。

新しい構成が原因で HAL が既存のストリームのストリーム構成を変更する必要がある場合、configure 呼び出し中に usage や max_buffers の値が書き換えられることがあります。

フレームワークはこのような変更を検出し、ストリーム バッファを再割り当てし、そのストリームのバッファをリクエストで使用する前に register_stream_buffers() を再度呼び出します。

現在アクティブなストリームが stream_list に含まれていない場合、HAL はそのストリームへの参照を安全に削除できます。フレームワークによる後続の configure() 呼び出しでは再利用されず、 configure_streams() 呼び出しが返された後に、その gralloc バッファはすべて解放されます。

stream_list 構造はフレームワークが所有するため、この呼び出しが完了するとアクセスできなくなる可能性があります。個々の camera3_stream_t 構造のアドレスは、stream_list 引数にその camera3_stream_t が含まれなくなった最初の configure_stream() 呼び出しが終了するまで、HAL によるアクセスに対して有効なままになります。HAL は、 configure_streams() 呼び出し自体の使用状況と max_buffers メンバーを除き、プライベート ポインタの外部にあるストリーム構造の値を変更しない場合があります。

ストリームが新規の場合、ストリーム構造の max_buffer フィールドとプライベート ポインタ フィールドはすべて 0 に設定されます。使用量はコンシューマの使用フラグに設定されます。HAL デバイスは、 configure_streams() 呼び出しが返される前に、これらのフィールドを設定する必要があります。これらのフィールドは、フレームワークとプラットフォームの gralloc モジュールによって使用され、各ストリームの gralloc バッファが割り振られます。

このような新しいストリームのバッファをキャプチャ リクエストに含めるには、フレームワークがそのストリームで register_stream_buffers() を呼び出す必要があります。ただし、フレームワークは、リクエストを送信する前に すべての ストリームのバッファを登録する必要はありません。これにより、プレビュー ストリームなどの迅速な起動が可能になり、他のストリームの割り当ては後で、または同時に行われます。

---

>= CAMERA_DEVICE_API_VERSION_3_2:

HAL カメラ デバイス処理パイプラインをリセットし、新しい入出力ストリームを設定します。この呼び出しにより、既存のストリーム構成が stream_list で定義されたストリームに置き換えられます。このメソッドは、 initialize() の後に、 process_capture_request() でリクエストが送信される前に、少なくとも 1 回呼び出されます。

stream_list には、出力可能なストリームを 1 つ以上含める必要があります。入力可能なストリームは 1 つだけにする必要があります。

stream_list には、現在アクティブなストリームセット（configure_stream() の前の呼び出しから）にも含まれているストリームが含まれる場合があります。これらのストリームには、使用量、max_buffers、プライベート ポインタの有効な値がすでに設定されています。

新しい構成が原因で HAL が既存のストリームのストリーム構成を変更する必要がある場合、configure 呼び出し中に usage や max_buffers の値が書き換えられることがあります。

フレームワークはこのような変更を検出し、そのストリームのバッファを再割り当てしてから、そのストリームのバッファをリクエストで使用します。

現在アクティブなストリームが stream_list に含まれていない場合、HAL はそのストリームへの参照を安全に削除できます。フレームワークによる後続の configure() 呼び出しでは再利用されず、 configure_streams() 呼び出しが返された後に、その gralloc バッファはすべて解放されます。

stream_list 構造はフレームワークが所有するため、この呼び出しが完了するとアクセスできなくなる可能性があります。個々の camera3_stream_t 構造のアドレスは、stream_list 引数にその camera3_stream_t が含まれなくなった最初の configure_stream() 呼び出しが終了するまで、HAL によるアクセスに対して有効なままになります。HAL は、 configure_streams() 呼び出し自体の使用状況と max_buffers メンバーを除き、プライベート ポインタの外部にあるストリーム構造の値を変更しない場合があります。

ストリームが新規の場合、ストリーム構造の max_buffer フィールドとプライベート ポインタ フィールドはすべて 0 に設定されます。使用量はコンシューマの使用フラグに設定されます。HAL デバイスは、 configure_streams() 呼び出しが返される前に、これらのフィールドを設定する必要があります。これらのフィールドは、フレームワークとプラットフォームの gralloc モジュールによって使用され、各ストリームの gralloc バッファが割り振られます。

フレームワークによって、新しく割り振られたバッファがキャプチャ リクエストにいつでも含まれる可能性があります。gralloc バッファが process_capture_result とともにフレームワークに返されると（および、対応する release_fence がシグナル送信されると）、フレームワークはいつでもバッファを解放または再利用できます。

---

前提条件:

フレームワークは、キャプチャが処理されていない場合にのみ、このメソッドを呼び出します。つまり、すべての結果がフレームワークに返され、処理中のすべての入出力バッファが返され、そのリリース同期フェンスが HAL によって通知されています。 configure_streams() の呼び出し中は、フレームワークはキャプチャの新しいリクエストを送信しません。

後置条件:

HAL デバイスは、カメラデバイスの静的メタデータに記載されているように、出力ストリームのサイズと形式を考慮して、可能な限り最大の出力フレームレートを提供するように構成する必要があります。

パフォーマンス要件:

この呼び出しは負荷が高く、画像センサーとカメラ処理パイプラインのリセットと再構成が必要になる可能性があるため、完了までに数百ミリ秒かかることがあります。それでも、HAL デバイスは、アプリケーションの動作モードの変更（静止画像キャプチャから動画録画への切り替えなど）中にユーザーが認識できる一時停止を最小限に抑えるために、再構成の遅延を最小限に抑える必要があります。

HAL は 500 ミリ秒以内にこの呼び出しから戻り、1, 000 ミリ秒以内にこの呼び出しから戻る必要があります。

戻り値は次のとおりです。

0: ストリーム構成が成功した場合

-EINVAL: リクエストされたストリーム構成が無効な場合。無効なストリーム構成の例を次に示します。

• 入力可能なストリームが複数含まれている（INPUT または BIDIRECTIONAL）
• 出力可能なストリーム（OUTPUT または BIDIRECTIONAL）は含めない
• サポートされていない形式のストリームや、その形式でサポートされていないサイズのストリームなど。
• 特定の形式の出力ストリームが多すぎる。
• サポートされていない回転設定（バージョンが CAMERA_DEVICE_API_VERSION_3_3 以上のデバイスにのみ適用）
• ストリームのサイズ/形式が、NORMAL モード以外の camera3_stream_configuration_t->operation_mode の要件を満たしていないか、リクエストされた operation_mode が HAL でサポートされていません。（バージョンが CAMERA_DEVICE_API_VERSION_3_3 以上のデバイスにのみ適用）

ストリーム構成は構成前にチェックされるため、無効なストリーム構成を送信するフレームワークは正常な動作ではありません。無効な構成とは、フレームワーク コードにバグが存在するか、HAL の静的メタデータとストリームの要件に不一致があることを意味します。

-ENODEV: 致命的なエラーが発生し、デバイスが動作しなくなった場合。このエラーが返された後、フレームワークで正常に呼び出せるのは close() のみです。

ファイル camera3.h の 2769 行の定義。

construct_default_request_settings:

標準のカメラのユースケース用の回収設定を作成します。

デバイスは、リクエストされたユースケースを満たすように構成された設定バッファを返す必要があります。これは、CAMERA3_TEMPLATE_* 列挙型のいずれかである必要があります。リクエスト制御フィールドはすべて含める必要があります。

HAL はこの構造の所有権を保持しますが、デバイスが閉じられるまで、構造体へのポインタは有効である必要があります。この呼び出しによって返されたバッファは、フレームワークと HAL によって変更されない場合があります。同じテンプレートの後続の呼び出しや、他のテンプレートの呼び出しで、同じバッファが返されることがあります。

パフォーマンス要件:

これはノンブロッキング呼び出しである必要があります。HAL は、この呼び出しから 1 ミリ秒以内に、また 5 ミリ秒以内に返す必要があります。

戻り値は次のとおりです。

有効なメタデータ: デフォルト設定バッファの作成が正常に完了した場合。

NULL: 致命的なエラーの場合。これが返された後、フレームワークで正常に呼び出せるのは close() メソッドのみです。

ファイル camera3.h の 2859 行の定義。

dump:

カメラデバイスのデバッグ状態を出力します。このメソッドは、カメラ サービスにデバッグ ダンプが要求されたときにフレームワークによって呼び出されます。これは、dumpsys ツールを使用しているときや、バグレポートをキャプチャしているときに発生します。

渡されたファイル記述子を使用して、dprintf() または write() でデバッグ テキストを書き込むことができます。テキストは ASCII エンコードのみにする必要があります。

パフォーマンス要件:

これは非ブロッキング呼び出しである必要があります。HAL は、この呼び出しから 10 ミリ秒以内に返す必要があります。この呼び出しはカメラの動作中にいつでも呼び出されるため、デッドロックを回避する必要があります。使用される同期プリミティブ（ミューテックス ロックやセマフォなど）は、タイムアウトで取得する必要があります。

ファイル camera3.h の 2971 行の定義。

flush:

指定したデバイスで、現在処理中のすべてのキャプチャとパイプライン内のすべてのバッファをフラッシュします。フレームワークは、 configure_streams() 呼び出しの準備のために、このフラグを使用してすべての状態をできるだけ早くダンプします。

正常に返されるバッファは必要ないため、 flush() の時点で保持されているすべてのバッファ（正常に入力されたかどうかにかかわらず）が CAMERA3_BUFFER_STATUS_ERROR とともに返される場合があります。この呼び出し中に、バッファが正常に入力された場合、HAL は有効な（CAMERA3_BUFFER_STATUS_OK）バッファを返すことができます。

現在 HAL にあるすべてのリクエストは、できるだけ早く返却される予定です。処理中でないリクエストは、すぐにエラーを返す必要があります。中断可能なハードウェア ブロックは停止し、中断不可能なブロックは待機する必要があります。

flush() は process_capture_request() とともに呼び出すことができます。この場合、process_capture_request はすぐに戻り、その process_capture_request 呼び出しで送信されたリクエストは、他のすべての処理中のリクエストと同様に処理されます。同時実行の問題により、HAL の観点から、フラッシュが呼び出されたがまだ返されていない後に process_capture_request() 呼び出しが開始される可能性があります。このような呼び出しが flush() の返却前に行われる場合、HAL は新しいキャプチャ リクエストを他の処理中の保留中リクエストと同様に処理する必要があります（下記の 4 を参照）。

具体的には、HAL はさまざまなケースで次の要件を満たす必要があります。

1. HAL がキャンセル/停止するには遅すぎるキャプチャで、HAL によって正常に完了されるキャプチャ。つまり、HAL はシャッター/通知を送信し、process_capture_result とバッファを通常どおり送信できます。
2. 処理が完了していない保留中のリクエストの場合、HAL は notify CAMERA3_MSG_ERROR_REQUEST を呼び出し、process_capture_result がエラー状態（CAMERA3_BUFFER_STATUS_ERROR）のすべての出力バッファを返す必要があります。HAL は、リリース フェンスをエラー状態にすることはできません。代わりに、リリース フェンスをフレームワークから渡された取得フェンスに設定するか、HAL によってすでに待機されている場合は -1 に設定する必要があります。また、HAL が CAMERA3_MSG_SHUTTER で notify() をすでに呼び出しているものの、メタデータや有効なバッファを生成する予定がないキャプチャにも、このパスが適用されます。CAMERA3_MSG_ERROR_REQUEST の後、特定のフレームでは、CAMERA3_BUFFER_STATUS_ERROR のバッファを含む process_capture_results のみが許可されます。メタデータが null 以外の notify や process_capture_result は許可されません。

3. 出力バッファがすべて存在しなかったり、メタデータが欠落しているなど、部分的に完了した保留中のリクエストの場合、HAL は次のように対応する必要があります。

   3.1. 想定される結果メタデータの一部（1 つ以上の部分メタデータ）がキャプチャに使用できない場合は、CAMERA3_MSG_ERROR_RESULT で notify を呼び出します。

   3.2. キャプチャに生成されないバッファごとに、CAMERA3_MSG_ERROR_BUFFER を使用して notify を呼び出します。

   3.3 バッファまたはメタデータが process_capture_result で返される前に、キャプチャ タイムスタンプを使用して CAMERA3_MSG_SHUTTER で notify を呼び出します。

   3.4 一部の結果が得られるキャプチャの場合、HAL は CAMERA3_MSG_ERROR_REQUEST を呼び出してはなりません。これは完全な失敗を示します。

   3.5. 有効なバッファ/メタデータは、通常どおりフレームワークに渡す必要があります。

   3.6. 失敗したバッファは、ケース 2 で説明されているようにフレームワークに返す必要があります。ただし、失敗したバッファは、有効なバッファの厳密な順序に従う必要はなく、有効なバッファに対して順序が乱れている可能性があります。たとえば、バッファ A、B、C、D、E が送信され、D と E が不合格だった場合、A、E、B、D、C は許容される返品順序です。

   3.7. メタデータが完全に欠落している場合は、CAMERA3_MSG_ERROR_RESULT を呼び出すだけで十分です。NULL メタデータまたは同等のメタデータを使用して process_capture_result を呼び出す必要はありません。

4. process_capture_request() 呼び出しがアクティブなときに flush() が呼び出された場合は、そのプロセス呼び出しをできるだけ早く返す必要があります。また、 flush() が呼び出された後、 flush() が返される前に process_capture_request() が呼び出された場合は、遅延した process_capture_request 呼び出しによって提供されたキャプチャ リクエストは、上記のケース 2 の保留中のリクエストと同様に扱われます。

flush() は、HAL に未処理のバッファやリクエストが残っていない場合にのみ返す必要があります。フレームワークは、（HAL の状態が休止状態になったため）configure_streams を呼び出すか、新しいリクエストを発行する場合があります。

完全に成功した結果と完全に失敗した結果のケースのみをサポートすれば十分です。ただし、部分的な障害の場合もサポートすることを強くおすすめします。これにより、フラッシュ呼び出しの全体的なパフォーマンスが向上する可能性があります。

パフォーマンス要件:

HAL は 100 ミリ秒以内にこの呼び出しから戻り、1, 000 ミリ秒以内にこの呼び出しから戻る必要があります。また、この呼び出しはパイプラインのレイテンシよりも長くブロックされてはなりません（定義については S7 をご覧ください）。

バージョン情報:

デバイスのバージョンが CAMERA_DEVICE_API_VERSION_3_1 以上の場合のみ使用できます。

戻り値は次のとおりです。

0: カメラ HAL のフラッシュが正常に完了した場合。

-EINVAL: 入力が不正な形式の場合（デバイスが無効な場合）。

-ENODEV: カメラデバイスで重大なエラーが発生した場合。このエラーが返された後、フレームワークで正常に呼び出せるのは close() メソッドのみです。

ファイル camera3.h の 3077 行の定義。

get_metadata_vendor_tag_ops:

ベンダー拡張機能のメタデータタグ情報をクエリするメソッドを取得します。HAL は、すべてのベンダータグ オペレーション メソッドを入力するか、ベンダータグが定義されていない場合はオペレーションを変更しないでください。

vendor_tag_query_ops_t の定義は、system/media/camera/include/system/camera_metadata.h にあります。

CAMERA_DEVICE_API_VERSION_3_2 以上: 非推奨。この関数は非推奨となり、HAL によって NULL に設定する必要があります。代わりに、 camera_common.h に get_vendor_tag_ops を実装してください。

ファイル camera3.h の 2950 行の定義。

initialize:

フレームワークのコールバック関数ポインタを HAL に渡す 1 回限りの初期化。open() の呼び出しが成功した後、 camera3_device_ops 構造体で他の関数が呼び出される前に 1 回呼び出されます。

パフォーマンス要件:

これはノンブロッキング呼び出しである必要があります。HAL は 5 ミリ秒以内にこの呼び出しから戻り、10 ミリ秒以内にこの呼び出しから戻る必要があります。

戻り値は次のとおりです。

0: 初期化が正常に完了した場合

-ENODEV: 初期化に失敗した場合。その後、フレームワークで正常に呼び出せるのは close() のみです。

ファイル camera3.h の 2530 行の定義。

process_capture_request:

新しいキャプチャ リクエストを HAL に送信します。HAL は、処理する次のリクエストを受け入れる準備が整うまで、この呼び出しから戻ってはなりません。フレームワークによって一度に呼び出される process_capture_request() は 1 回のみで、呼び出しはすべて同じスレッドから行われます。新しいリクエストとそれに関連付けられたバッファが利用可能になるとすぐに、 process_capture_request() が次に呼び出されます。通常のプレビュー シナリオでは、この関数はフレームワークによってほぼ即座に再呼び出されます。

実際のリクエスト処理は非同期で、キャプチャの結果は process_capture_result() 呼び出しを介して HAL から返されます。この呼び出しでは、結果メタデータが使用可能である必要がありますが、出力バッファは待機する同期フェンスを提供するだけです。完全な出力フレームレートを維持するために、複数のリクエストが同時に送信されることが想定されます。

フレームワークはリクエスト構造の所有権を保持します。この呼び出し中のみ有効であることが保証されます。HAL デバイスは、キャプチャ処理のために保持する必要がある情報のコピーを作成する必要があります。HAL は、バッファのフェンスを待機して閉じ、バッファ ハンドルをフレームワークに返す責任があります。

HAL は、input_buffer が NULL でない場合、入力バッファのリリース同期フェンスのファイル記述子を input_buffer->release_fence に書き込む必要があります。HAL が入力バッファのリリース同期フェンスに対して -1 を返した場合、フレームワークは入力バッファをすぐに再利用できます。そうしないと、フレームワークは同期フェンスを待ってから入力バッファを再充填して再利用します。

>= CAMERA_DEVICE_API_VERSION_3_2:

各リクエストでフレームワークによって提供される入出力バッファは、まったく新しいもの（HAL でこれまでに使用されたことがないもの）である可能性があります。

---

パフォーマンスに関する考慮事項:

新しいバッファの処理は非常に軽量で、フレームレートの低下やフレームジッターが発生しないようにする必要があります。

この呼び出しは、特にストリーミング ケース（ポストプロセッシング品質設定が FAST に設定されている場合）で、リクエストされたフレームレートを維持できるほど速く戻す必要があります。HAL は、この呼び出しを 1 フレーム間隔で返す必要があります。また、この呼び出しから 4 フレーム間隔で返す必要があります。

戻り値は次のとおりです。

0: キャプチャ リクエストの処理が正常に開始された場合

-EINVAL: 入力が不正な形式の場合（許可されていない場合に設定が NULL の場合、出力バッファが 0 個の場合など）、キャプチャ処理を開始できません。リクエスト処理中にエラーが発生した場合は、 camera3_callback_ops_t.notify() を呼び出して処理する必要があります。このエラーの場合、フレームワークはストリーム バッファのフェンスとバッファ ハンドルの責任を保持します。HAL はフェンスを閉じたり、process_capture_result でこれらのバッファを返したりしないでください。

-ENODEV: カメラデバイスで重大なエラーが発生した場合。このエラーが返された後、フレームワークで正常に呼び出せるのは close() メソッドのみです。

ファイル camera3.h の 2928 行の定義。

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

非推奨。これは呼び出されないため、NULL に設定する必要があります。

<= CAMERA_DEVICE_API_VERSION_3_1:

特定のストリームのバッファを HAL デバイスに登録します。このメソッドは、configure_streams によって新しいストリームが定義された後、そのストリームのバファがキャプチャ リクエストに含まれる前に、フレームワークによって呼び出されます。後続の configure_streams() 呼び出しで同じストリームがリストに含まれている場合、そのストリームに対して register_stream_buffers が再度呼び出されることはありません。

フレームワークは、最初のキャプチャ リクエストを送信する前に、構成されたすべてのストリームのバッファを登録する必要はありません。これにより、他のストリームが割り当てられている間でも、プレビュー（または同様のユースケース）をすばやく起動できます。

このメソッドは、HAL デバイスがバッファをマッピングまたは準備して後で使用できるようにすることを目的としています。渡されたバッファは、すでに使用のためにロックされています。呼び出しの終了時に、すべてのバッファがストリームに返される準備ができている必要があります。buffer_set 引数は、この呼び出し中のみ有効です。

ストリーム形式が HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED に設定されている場合、カメラ HAL はここで渡されたバッファを検査して、プラットフォーム固有のピクセル形式情報を特定する必要があります。

パフォーマンス要件:

これはノンブロッキング呼び出しである必要があります。HAL は、この呼び出しから 1 ミリ秒以内に、また 5 ミリ秒以内に返す必要があります。

戻り値は次のとおりです。

0: 新しいストリーム バッファの登録が成功した場合

-EINVAL: stream_buffer_set が有効なアクティブ ストリームを参照していない場合、またはバッファ配列が無効な場合。

-ENOMEM: バッファの登録に失敗した場合。フレームワークは、すべてのストリーム バッファを未登録と見なす必要があります。後で再登録を試行できます。

-ENODEV: 致命的なエラーが発生し、デバイスが動作しなくなった場合。このエラーが返された後、フレームワークで正常に呼び出せるのは close() のみです。

ファイル camera3.h の 2823 行目の定義。

ファイル camera3.h の 3080 行の定義。