Referencia de la estructura camera3_callback_ops

notify:

Devolución de llamada de notificación asíncrona del HAL, que se activa por varios motivos. Solo para información independiente de la captura de fotogramas o que requiere una sincronización específica. La propiedad de la estructura del mensaje permanece en la HAL, y el mensaje solo debe ser válido durante la duración de esta llamada.

Varios subprocesos pueden llamar a notify() de forma simultánea.

<= CAMERA_DEVICE_API_VERSION_3_1:

El HAL debe enviar la notificación del inicio de la exposición para una solicitud determinada antes de que se realice la primera llamada a process_capture_result() para esa solicitud.

>= CAMERA_DEVICE_API_VERSION_3_2:

Los búferes entregados al framework no se enviarán a la capa de la aplicación hasta que se reciba una marca de tiempo de inicio de exposición (o la marca de tiempo de inicio de exposición de la imagen de entrada para una solicitud de reprocesamiento) a través de una llamada a notify() de SHUTTER. Se recomienda enviar esta llamada lo antes posible.

Requisitos de rendimiento:

Esta es una llamada sin bloqueo. El framework devolverá esta llamada en 5 ms.

Definición en la línea 2499 del archivo camera3.h .

process_capture_result:

Envía los resultados de una captura completada al framework. process_capture_result() puede invocarse varias veces por el HAL en respuesta a una sola solicitud de captura. Esto permite, por ejemplo, que los metadatos y los búferes de baja resolución se devuelvan en una llamada, y los búferes JPEG posprocesados en una llamada posterior, una vez que estén disponibles. Cada llamada debe incluir el número de fotograma de la solicitud para la que se devuelven metadatos o búferes.

Un componente (búfer o metadatos) del resultado completo solo se puede incluir en una llamada a process_capture_result. El HAL debe devolver un búfer para cada transmisión y los metadatos del resultado para cada solicitud en una de las llamadas a process_capture_result, incluso en caso de errores que produzcan parte del resultado. No se permite una llamada a process_capture_result() sin búferes de salida ni metadatos de resultado.

El orden en que se devuelven los metadatos y los búferes para un solo resultado no importa, pero los búferes para un flujo determinado se deben devolver en orden FIFO. Por lo tanto, el búfer de la solicitud 5 del flujo A siempre debe devolverse antes del búfer de la solicitud 6 del flujo A. Esto también se aplica a los metadatos de los resultados: los metadatos de la solicitud 5 se deben devolver antes que los de la solicitud 6.

Sin embargo, los diferentes flujos son independientes entre sí, por lo que es aceptable y esperado que el búfer de la solicitud 5 del flujo A se muestre después del búfer de la solicitud 6 del flujo B, y que los metadatos del resultado de la solicitud 6 del flujo B se muestren antes del búfer de la solicitud 5 del flujo A.

El HAL conserva la propiedad de la estructura de resultados, que solo debe ser válida para acceder durante esta llamada. El framework copiará lo que necesite antes de que se muestre esta llamada.

Aún no es necesario llenar los búferes de salida; el framework esperará la barrera de sincronización de liberación del búfer de transmisión antes de leer los datos del búfer. Por lo tanto, el HAL debe llamar a este método lo antes posible, incluso si algunos o todos los búferes de salida aún se están llenando. El HAL debe incluir barreras de sincronización de versión válidas en cada entrada de búfer de transmisión output_buffers o -1 si ese búfer de transmisión ya está lleno.

Si no se puede construir el búfer de resultados para una solicitud, el HAL debe devolver un búfer de metadatos vacío, pero seguir proporcionando los búferes de salida y sus barreras de sincronización. Además, se debe llamar a notify() con un mensaje ERROR_RESULT.

Si no se puede llenar un búfer de salida, su campo de estado debe establecerse en STATUS_ERROR. Además, se debe llamar a notify() con un mensaje ERROR_BUFFER.

Si falló toda la captura, se debe llamar a este método para devolver los búferes de salida al framework. Todos los estados del búfer deben ser STATUS_ERROR, y los metadatos del resultado deben ser un búfer vacío. Además, se debe llamar a notify() con un mensaje ERROR_REQUEST. En este caso, no se deben enviar mensajes ERROR_RESULT/ERROR_BUFFER individuales.

Requisitos de rendimiento:

Esta es una llamada sin bloqueo. El framework devolverá esta llamada en 5 ms.

La latencia de la canalización (consulta S7 para obtener la definición) debe ser menor o igual que 4 intervalos de fotogramas y debe ser menor o igual que 8 intervalos de fotogramas.

Definición en la línea 2466 del archivo camera3.h .