camera3_device_ops 구조체 참조
#include <
camera3.h
>
데이터 필드 |
|
| int(* | initialize )(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
| int(* | configure_streams )(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
| int(* | register_stream_buffers )(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
| const camera_metadata_t *(* | construct_default_request_settings )(const struct camera3_device *, int type) |
| int(* | process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request) |
| void(* | get_metadata_vendor_tag_ops )(const struct camera3_device *, vendor_tag_query_ops_t *ops) |
| void(* | dump )(const struct camera3_device *, int fd) |
| int(* | flush )(const struct camera3_device *) |
| void * | reserved [8] |
상세 설명
필드 문서
| int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
configure_streams:
CAMERA_DEVICE_API_VERSION_3_0만 해당:
HAL 카메라 기기 처리 파이프라인을 재설정하고 새 입력 및 출력 스트림을 설정합니다. 이 호출은 기존 스트림 구성을 stream_list에 정의된 스트림으로 대체합니다. 이 메서드는 process_capture_request() 와 함께 요청이 제출되기 전에 initialize() 다음에 한 번 이상 호출됩니다.
stream_list에는 출력 기능이 있는 스트림이 하나 이상 포함되어야 하며 입력 기능이 있는 스트림은 두 개 이상 포함할 수 없습니다.
stream_list에는 이전에 configure_stream()을 호출할 때 현재 활성 상태인 스트림 세트에도 있는 스트림이 포함될 수 있습니다. 이러한 스트림에는 이미 사용량, max_buffers, 비공개 포인터에 유효한 값이 있습니다.
이러한 스트림의 버퍼가 이미 등록된 경우 register_stream_buffers() 가 스트림에 대해 다시 호출되지 않으며 스트림의 버퍼가 입력 요청에 즉시 포함될 수 있습니다.
HAL이 새 구성으로 인해 기존 스트림의 스트림 구성을 변경해야 하는 경우 구성 호출 중에 사용량 또는 max_buffers 값을 재작성할 수 있습니다.
프레임워크는 이러한 변경사항을 감지한 후 스트림 버퍼를 재할당하고 요청에서 해당 스트림의 버퍼를 사용하기 전에 register_stream_buffers() 를 다시 호출합니다.
현재 활성 상태인 스트림이 stream_list에 포함되지 않은 경우 HAL은 해당 스트림에 대한 참조를 안전하게 삭제할 수 있습니다. 프레임워크의 후속 configure() 호출에서 재사용되지 않으며, 이에 관한 모든 gralloc 버퍼는 configure_streams() 호출이 반환된 후에 해제됩니다.
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_1만 해당:
HAL 카메라 기기 처리 파이프라인을 재설정하고 새 입력 및 출력 스트림을 설정합니다. 이 호출은 기존 스트림 구성을 stream_list에 정의된 스트림으로 대체합니다. 이 메서드는 process_capture_request() 와 함께 요청이 제출되기 전에 initialize() 다음에 한 번 이상 호출됩니다.
stream_list에는 출력 기능이 있는 스트림이 하나 이상 포함되어야 하며 입력 기능이 있는 스트림은 두 개 이상 포함할 수 없습니다.
stream_list에는 이전에 configure_stream()을 호출할 때 현재 활성 상태인 스트림 세트에도 있는 스트림이 포함될 수 있습니다. 이러한 스트림에는 이미 사용량, max_buffers, 비공개 포인터에 유효한 값이 있습니다.
이러한 스트림의 버퍼가 이미 등록된 경우 register_stream_buffers() 가 스트림에 대해 다시 호출되지 않으며 스트림의 버퍼가 입력 요청에 즉시 포함될 수 있습니다.
HAL이 새 구성으로 인해 기존 스트림의 스트림 구성을 변경해야 하는 경우 구성 호출 중에 사용량 또는 max_buffers 값을 재작성할 수 있습니다.
프레임워크는 이러한 변경사항을 감지한 후 스트림 버퍼를 재할당하고 요청에서 해당 스트림의 버퍼를 사용하기 전에 register_stream_buffers() 를 다시 호출합니다.
현재 활성 상태인 스트림이 stream_list에 포함되지 않은 경우 HAL은 해당 스트림에 대한 참조를 안전하게 삭제할 수 있습니다. 프레임워크의 후속 configure() 호출에서 재사용되지 않으며 이에 관한 모든 gralloc 버퍼는 configure_streams() 호출이 반환된 후에 해제됩니다.
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에 정의된 스트림으로 대체합니다. 이 메서드는 process_capture_request() 와 함께 요청이 제출되기 전에 initialize() 다음에 한 번 이상 호출됩니다.
stream_list에는 출력 기능이 있는 스트림이 하나 이상 포함되어야 하며 입력 기능이 있는 스트림은 두 개 이상 포함할 수 없습니다.
stream_list에는 이전에 configure_stream()을 호출할 때 현재 활성 상태인 스트림 세트에도 있는 스트림이 포함될 수 있습니다. 이러한 스트림에는 이미 사용량, max_buffers, 비공개 포인터에 유효한 값이 있습니다.
HAL이 새 구성으로 인해 기존 스트림의 스트림 구성을 변경해야 하는 경우 구성 호출 중에 사용량 또는 max_buffers 값을 재작성할 수 있습니다.
프레임워크는 이러한 변경사항을 감지하고 요청에서 해당 스트림의 버퍼를 사용하기 전에 스트림 버퍼를 재할당할 수 있습니다.
현재 활성 상태인 스트림이 stream_list에 포함되지 않은 경우 HAL은 해당 스트림에 대한 참조를 안전하게 삭제할 수 있습니다. 프레임워크의 후속 configure() 호출에서 재사용되지 않으며 이에 관한 모든 gralloc 버퍼는 configure_streams() 호출이 반환된 후에 해제됩니다.
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은 이 호출에서 500ms 후에 반환되어야 하며 1, 000ms 후에 반환되어야 합니다.
반환 값:
0: 스트림 구성 성공
-EINVAL: 요청된 스트림 구성이 잘못된 경우. 잘못된 스트림 구성의 예는 다음과 같습니다.
- 입력 가능한 스트림 (INPUT 또는 BIDIRECTIONAL)이 2개 이상 포함됨
- 출력 가능한 스트림 (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()만 프레임워크에서 성공적으로 호출할 수 있습니다.
| const camera_metadata_t *(* construct_default_request_settings)(const struct camera3_device *, int type) |
construct_default_request_settings:
표준 카메라 사용 사례의 캡처 설정을 만듭니다.
기기는 요청된 사용 사례를 충족하도록 구성된 설정 버퍼를 반환해야 하며, 이 버퍼는 CAMERA3_TEMPLATE_* enum 중 하나여야 합니다. 모든 요청 제어 필드를 포함해야 합니다.
HAL은 이 구조체의 소유권을 유지하지만 구조체 포인터는 기기가 닫힐 때까지 유효해야 합니다. 프레임워크와 HAL은 이 호출에서 버퍼가 반환되면 버퍼를 수정하지 않을 수 있습니다. 동일한 템플릿 또는 다른 템플릿의 후속 호출에 동일한 버퍼가 반환될 수 있습니다.
성능 요구사항:
비차단 호출이어야 합니다. HAL은 이 호출에서 1ms 내에 반환되어야 하며 5ms 내에 반환되어야 합니다.
반환 값:
유효한 메타데이터: 기본 설정 버퍼가 생성된 경우
NULL: 심각한 오류가 발생한 경우 이 값이 반환된 후에는 프레임워크에서 close() 메서드만 성공적으로 호출할 수 있습니다.
| void(* dump)(const struct camera3_device *, int fd) |
dump:
카메라 기기의 디버깅 상태를 출력합니다. 이 메서드는 카메라 서비스에 디버그 덤프가 요청될 때 프레임워크에서 호출됩니다. 이는 dumpsys 도구를 사용하거나 버그 신고를 캡처할 때 발생합니다.
전달된 파일 설명자는 dprintf() 또는 write()를 사용하여 디버깅 텍스트를 작성하는 데 사용할 수 있습니다. 텍스트는 ASCII 인코딩으로만 작성해야 합니다.
성능 요구사항:
비차단 호출이어야 합니다. HAL은 이 호출에서 1ms 내에 반환되어야 하며 10ms 내에 반환되어야 합니다. 이 호출은 카메라 작동 중 언제든지 호출될 수 있으므로 교착 상태를 방지해야 합니다. 사용되는 모든 동기화 원시 유형 (예: 뮤텍스 잠금 또는 세마포)은 시간 제한으로 획득해야 합니다.
| int(* flush)(const struct camera3_device *) |
플러시:
지정된 기기에서 현재 처리 중인 모든 캡처와 파이프라인의 모든 버퍼를 플러시합니다. 프레임워크는 이를 사용하여 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은 다양한 사례에 대해 다음 요구사항을 따라야 합니다.
- HAL이 취소/중지하기에는 너무 늦었고 HAL에서 정상적으로 완료할 캡처의 경우입니다. 즉, HAL은 셔터/알림 및 process_capture_result와 버퍼를 평소와 같이 전송할 수 있습니다.
- 처리되지 않은 대기 중인 요청의 경우 HAL은 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이 아닌 메타데이터가 있는 notifys 또는 process_capture_result는 더 이상 허용되지 않습니다.
-
일부 출력 버퍼가 없거나 메타데이터가 누락된 부분적으로 완료된 대기 중인 요청의 경우 HAL은 다음을 따라야 합니다.
3.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를 호출할 필요가 없습니다.
- process_capture_request() invocation이 활성 상태인 동안 flush() 가 호출되면 해당 프로세스 호출은 최대한 빨리 반환되어야 합니다. 또한 flush() 이 호출된 후 flush() 가 반환되기 전에 process_capture_request() 호출이 이루어지는 경우, 지연된 process_capture_request 호출에서 제공된 캡처 요청은 위의 케이스 2에서 대기 중인 요청처럼 처리되어야 합니다.
flush() 는 HAL에 더 이상 대기 중인 버퍼나 요청이 없을 때만 반환해야 합니다. 프레임워크는 HAL 상태가 이제 정지 상태이므로 configure_streams를 호출하거나 새 요청을 실행할 수 있습니다.
완전히 성공한 결과 케이스와 완전히 실패한 결과 케이스만 지원해도 충분합니다. 그러나 전체 플러시 호출 성능을 개선하는 데 도움이 될 수 있으므로 부분 실패 사례도 지원하는 것이 좋습니다.
성능 요구사항:
HAL은 100ms 이내에 이 호출에서 반환되어야 하며 1, 000ms 이내에 이 호출에서 반환되어야 합니다. 또한 이 호출은 파이프라인 지연 시간보다 오래 차단되어서는 안 됩니다 (정의는 S7 참고).
버전 정보:
기기 버전이 CAMERA_DEVICE_API_VERSION_3_1 이상인 경우에만 사용할 수 있습니다.
반환 값:
0: 카메라 HAL을 플러시하는 데 성공한 경우
-EINVAL: 입력 형식이 잘못되었습니다 (기기가 유효하지 않음).
-ENODEV: 카메라 기기에 심각한 오류가 발생한 경우입니다. 이 오류가 반환된 후에는 프레임워크에서 close() 메서드만 성공적으로 호출할 수 있습니다.
| void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, vendor_tag_query_ops_t *ops) |
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를 구현하세요.
| int(* initialize)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
initialize:
프레임워크 콜백 함수 포인터를 HAL에 전달하는 일회성 초기화입니다. open() 호출에 성공한 후 camera3_device_ops 구조에서 다른 함수가 호출되기 전에 한 번 호출됩니다.
성능 요구사항:
비차단 호출이어야 합니다. HAL은 이 호출에서 5ms 후에 반환되어야 하며 10ms 후에 반환되어야 합니다.
반환 값:
0: 초기화 성공 시
-ENODEV: 초기화에 실패한 경우 이후에는 프레임워크에서 close()만 성공적으로 호출할 수 있습니다.
| int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request) |
process_capture_request:
HAL에 새 캡처 요청을 전송합니다. HAL은 처리할 다음 요청을 수락할 준비가 될 때까지 이 호출에서 반환해서는 안 됩니다. 프레임워크는 한 번에 process_capture_request() 를 한 번만 호출하며, 모든 호출은 동일한 스레드에서 이루어집니다. 새 요청과 연결된 버퍼를 사용할 수 있게 되는 즉시 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에서 이전에 본 적이 없는 완전히 새로운 버퍼일 수 있습니다.
성능 고려사항:
새 버퍼를 처리하는 작업은 매우 가벼워야 하며 프레임 속도 저하나 프레임 지터가 발생해서는 안 됩니다.
이 호출은 특히 스트리밍 케이스 (사후 처리 품질 설정이 빠름으로 설정됨)에서 요청된 프레임 속도를 유지할 수 있을 만큼 충분히 빠르게 반환되어야 합니다. HAL은 1프레임 간격으로 이 호출을 반환해야 하며 4프레임 간격으로 이 호출에서 반환해야 합니다.
반환 값:
0: 캡처 요청 처리가 성공적으로 시작된 경우
-EINVAL: 입력 형식이 잘못되어 (허용되지 않는 경우 설정이 NULL이고 출력 버퍼가 0개 등) 캡처 처리를 시작할 수 없는 경우입니다. 요청 처리 중 실패는 camera3_callback_ops_t.notify() 를 호출하여 처리해야 합니다. 이 오류가 발생하면 프레임워크가 스트림 버퍼의 펜스와 버퍼 핸들에 대한 책임을 유지합니다. HAL은 펜스를 닫거나 process_capture_result와 함께 이러한 버퍼를 반환해서는 안 됩니다.
-ENODEV: 카메라 기기에 심각한 오류가 발생한 경우입니다. 이 오류가 반환된 후에는 프레임워크에서 close() 메서드만 성공적으로 호출할 수 있습니다.
| int(* register_stream_buffers)(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set) |
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은 이 호출에서 1ms 내에 반환되어야 하며 5ms 내에 반환되어야 합니다.
반환 값:
0: 새 스트림 버퍼 등록 완료 시
-EINVAL: stream_buffer_set이 유효한 활성 스트림을 참조하지 않거나 버퍼 배열이 유효하지 않은 경우.
-ENOMEM: 버퍼 등록에 실패한 경우입니다. 프레임워크는 모든 스트림 버퍼가 등록 취소되었다고 간주해야 하며 나중에 다시 등록을 시도할 수 있습니다.
-ENODEV: 심각한 오류가 발생하여 기기가 더 이상 작동하지 않는 경우 이 오류가 반환된 후에는 close()만 프레임워크에서 성공적으로 호출할 수 있습니다.
이 구조체에 관한 문서는 다음 파일에서 생성되었습니다.
- hardware/libhardware/include/hardware/ camera3.h