Camera3_device_ops 구조체 참조
#include < camera3.h >
데이터 필드 | |
| 정수(* | 초기화 )(const struct Camera3_device *, const Camera3_callback_ops_t *callback_ops) |
| 정수(* | configure_streams )(const struct Camera3_device *, Camera3_stream_configuration_t *stream_list) |
| 정수(* | Register_stream_buffers )(const struct Camera3_device *, const Camera3_stream_buffer_set_t *buffer_set) |
| const 카메라_메타데이터_t *(* | constructor_default_request_settings )(const struct Camera3_device *, int 유형) |
| 정수(* | process_capture_request )(const struct Camera3_device *, Camera3_capture_request_t *request) |
| 무효의(* | get_metadata_vendor_tag_ops )(const struct Camera3_device *, Vendor_tag_query_ops_t *ops) |
| 무효의(* | 덤프 )(const struct Camera3_device *, int fd) |
| 정수(* | 플러시 )(const struct Camera3_device *) |
| 무효의 * | 예약됨 [8] |
상세 설명
현장 문서
| int(*configure_streams)(const struct Camera3_device *, Camera3_stream_configuration_t *stream_list) |
구성_스트림:
CAMERA_DEVICE_API_VERSION_3_0 전용:
HAL 카메라 장치 처리 파이프라인을 재설정하고 새로운 입력 및 출력 스트림을 설정합니다. 이 호출은 기존 스트림 구성을 stream_list에 정의된 스트림으로 대체합니다. 이 메소드는 요청이 process_capture_request() 로 제출되기 전에 초기화() 후에 적어도 한 번 호출됩니다.
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() 로 제출되기 전에 초기화() 후에 적어도 한 번 호출됩니다.
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() 로 제출되기 전에 초기화() 후에 적어도 한 번 호출됩니다.
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 내에 이 호출에서 반환되어야 하며, 1000ms 내에 이 호출에서 반환되어야 합니다.
반환 값:
0: 성공적인 스트림 구성 시
-EINVAL: 요청한 스트림 구성이 유효하지 않은 경우. 잘못된 스트림 구성의 몇 가지 예는 다음과 같습니다.
- 2개 이상의 입력 가능 스트림(INPUT 또는 BIDIRECTIONAL) 포함
- 출력 가능 스트림(OUTPUT 또는 BIDIRECTIONAL)은 포함되지 않습니다.
- 지원되지 않는 형식 또는 해당 형식에 대해 지원되지 않는 크기의 스트림을 포함합니다.
- 특정 형식의 출력 스트림을 너무 많이 포함합니다.
- 지원되지 않는 회전 구성(버전이 CAMERA_DEVICE_API_VERSION_3_3 이상인 장치에만 적용됨)
- 스트림 크기/형식이 비정상 모드에 대한 Camera3_stream_configuration_t->Operation_mode 요구사항을 충족하지 않거나 요청된 Operation_Mode가 HAL에서 지원되지 않습니다. (버전이 CAMERA_DEVICE_API_VERSION_3_3 이상인 장치에만 적용됨)
잘못된 스트림 구성을 제출하는 프레임워크는 구성하기 전에 스트림 구성을 확인하므로 정상적인 작동이 아닙니다. 잘못된 구성은 프레임워크 코드에 버그가 있거나 HAL의 정적 메타데이터와 스트림 요구 사항이 일치하지 않음을 의미합니다.
-ENODEV: 치명적인 오류가 발생하여 장치가 더 이상 작동하지 않는 경우. 이 오류가 반환된 후에는 close()만 프레임워크에서 성공적으로 호출할 수 있습니다.
| const Camera_metadata_t *(* constructor_default_request_settings)(const struct Camera3_device *, int 유형) |
구성_기본_요청_설정:
표준 카메라 사용 사례에 대한 캡처 설정을 만듭니다.
장치는 요청된 사용 사례를 충족하도록 구성된 설정 버퍼를 반환해야 하며, 이는 CAMERA3_TEMPLATE_* 열거형 중 하나여야 합니다. 모든 요청 제어 필드가 포함되어야 합니다.
HAL은 이 구조의 소유권을 유지하지만 구조에 대한 포인터는 기기가 닫힐 때까지 유효해야 합니다. 프레임워크와 HAL은 이 호출에 의해 반환된 버퍼를 수정할 수 없습니다. 동일한 템플릿에 대한 후속 호출이나 다른 템플릿에 대해 동일한 버퍼가 반환될 수 있습니다.
성능 요건:
이는 비차단 호출이어야 합니다. HAL은 1ms 내에 이 호출에서 반환되어야 하며, 5ms 내에 이 호출에서 반환되어야 합니다.
반환 값:
유효한 메타데이터: 기본 설정 버퍼가 성공적으로 생성된 경우.
NULL: 치명적인 오류가 발생한 경우. 이것이 반환된 후에는 프레임워크에서 close() 메서드만 성공적으로 호출할 수 있습니다.
| void(* 덤프)(const struct Camera3_device *, int fd) |
덤프:
카메라 장치의 디버깅 상태를 인쇄합니다. 이는 dumpsys 도구를 사용하거나 버그 보고서를 캡처할 때 발생하는 디버그 덤프를 카메라 서비스에 요청할 때 프레임워크에 의해 호출됩니다.
전달된 파일 설명자는 dprintf() 또는 write()를 사용하여 디버깅 텍스트를 작성하는 데 사용할 수 있습니다. 텍스트는 ASCII 인코딩으로만 이루어져야 합니다.
성능 요건:
이는 비차단 호출이어야 합니다. HAL은 1ms 내에 이 호출에서 반환되어야 하며, 10ms 내에 이 호출에서 반환되어야 합니다. 이 호출은 카메라 작동 중 언제든지 호출될 수 있으므로 교착 상태를 피해야 합니다. 사용되는 모든 동기화 기본 요소(예: 뮤텍스 잠금 또는 세마포어)는 시간 초과를 통해 획득해야 합니다.
| int(* 플러시)(const struct Camera3_device *) |
플러시:
현재 처리 중인 모든 캡처와 지정된 장치의 파이프라인에 있는 모든 버퍼를 플러시합니다. 프레임워크는 이를 사용하여 configure_streams() 호출을 준비하기 위해 가능한 한 빨리 모든 상태를 덤프합니다.
성공적으로 반환되기 위해 버퍼가 필요하지 않으므로 플러시() 시점에 보유된 모든 버퍼(성공적으로 채워졌는지 여부에 관계없이)가 CAMERA3_BUFFER_STATUS_ERROR와 함께 반환될 수 있습니다. 성공적으로 채워진 경우 HAL은 이 호출 중에 유효한(CAMERA3_BUFFER_STATUS_OK) 버퍼를 반환할 수 있습니다.
현재 HAL에 있는 모든 요청은 가능한 한 빨리 반환될 것으로 예상됩니다. 처리 중이 아닌 요청은 즉시 오류를 반환해야 합니다. 인터럽트 가능한 하드웨어 블록은 모두 중지되어야 하며, 인터럽트 불가능한 블록은 대기해야 합니다.
플러시()는 process_capture_request() 와 동시에 호출될 수 있으며, process_capture_request가 빠르게 반환되고 해당 process_capture_request 호출에 제출된 요청이 다른 모든 진행 중인 요청처럼 처리될 것으로 예상됩니다. 동시성 문제로 인해 HAL의 관점에서 보면 플러시가 호출되었지만 아직 반환되지 않은 후에 process_capture_request() 호출이 시작될 수 있습니다. 이러한 호출이 플러시() 가 반환되기 전에 발생하는 경우 HAL은 새 캡처 요청을 다른 진행 중인 보류 요청처럼 처리해야 합니다(아래 #4 참조).
보다 구체적으로 HAL은 다양한 경우에 대해 아래 요구사항을 따라야 합니다.
- HAL이 취소/중지하기에는 너무 늦어 HAL에 의해 정상적으로 완료되는 캡처의 경우 즉, HAL은 셔터/알림, process_capture_result 및 버퍼를 정상적으로 보낼 수 있습니다.
- 처리를 수행하지 않은 대기 중인 요청의 경우 HAL은 CAMERA3_MSG_ERROR_REQUEST 알림을 호출하고 오류 상태(CAMERA3_BUFFER_STATUS_ERROR)에서 process_capture_result가 포함된 모든 출력 버퍼를 반환해야 합니다. HAL은 릴리스 펜스를 오류 상태로 설정해서는 안 됩니다. 대신 릴리스 펜스는 프레임워크에 의해 전달된 획득 펜스로 설정되거나 HAL에서 이미 대기한 경우 -1로 설정되어야 합니다. 이는 HAL이 이미 CAMERA3_MSG_SHUTTER를 사용하여 inform()을 호출했지만 메타데이터/유효한 버퍼를 생성하지 않는 모든 캡처에 대해 따라야 할 경로이기도 합니다. CAMERA3_MSG_ERROR_REQUEST 이후에는 특정 프레임에 대해 CAMERA3_BUFFER_STATUS_ERROR의 버퍼가 있는 process_capture_results만 허용됩니다. null이 아닌 메타데이터를 사용한 추가 알림 또는 process_capture_result는 허용되지 않습니다.
일부 출력 버퍼가 없거나 메타데이터가 누락되어 부분적으로 완료된 대기 중인 요청의 경우 HAL은 다음을 따라야 합니다.
3.1. 예상 결과 메타데이터 중 일부(예: 하나 이상의 부분 메타데이터)를 캡처에 사용할 수 없는 경우 CAMERA3_MSG_ERROR_RESULT로 알림을 호출하세요.
3.2. 캡처를 위해 생성되지 않을 모든 버퍼에 대해 CAMERA3_MSG_ERROR_BUFFER로 알림을 호출하세요.
3.3 process_capture_result와 함께 버퍼/메타데이터가 반환되기 전에 캡처 타임스탬프가 있는 CAMERA3_MSG_SHUTTER로 알림을 호출합니다.
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( ) 호출이 활성화된 동안 플러시( )가 호출되면 해당 프로세스 호출은 가능한 한 빨리 반환되어야 합니다. 또한, push()가 호출된 후 플러시 ( )가 반환되기 전에 process_capture_request() 호출이 이루어진 경우 늦은 process_capture_request 호출에 의해 제공되는 캡처 요청은 위의 사례 #2에서 보류 중인 요청처럼 처리되어야 합니다.
Flush()는 HAL에 더 이상 미해결 버퍼나 요청이 남아 있지 않은 경우에만 반환해야 합니다. 프레임워크는 (HAL 상태가 이제 중지되었으므로)configure_streams를 호출하거나 새 요청을 발행할 수 있습니다.
완전히 성공한 결과와 완전히 실패한 결과 사례만 지원하면 충분합니다. 그러나 부분 실패 사례도 지원하는 것이 플러시 호출 전체 성능을 향상시키는 데 도움이 될 수 있으므로 매우 바람직합니다.
성능 요건:
HAL은 100ms 내에 이 호출에서 반환되어야 하며, 1000ms 내에 이 호출에서 반환되어야 합니다. 그리고 이 호출은 파이프라인 대기 시간보다 오랫동안 차단되어서는 안 됩니다(정의는 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(* 초기화)(const struct Camera3_device *, const Camera3_callback_ops_t *callback_ops) |
초기화:
프레임워크 콜백 함수 포인터를 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에서 이전에 본 적이 없는).
성능 고려 사항:
새 버퍼를 처리하는 작업은 매우 가벼워야 하며 프레임 속도 저하나 프레임 지터가 발생하지 않아야 합니다.
이 호출은 특히 스트리밍 사례(후처리 품질 설정이 FAST로 설정됨)의 경우 요청된 프레임 속도가 유지될 수 있을 만큼 충분히 빠르게 반환되어야 합니다. 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) |
레지스터_스트림_버퍼:
>= 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()만 프레임워크에서 성공적으로 호출할 수 있습니다.
이 구조체에 대한 문서는 다음 파일에서 생성되었습니다.