camera3_callback_ops Struct Reference
#include < camera3.h >
Champs de données | |
annuler(* | process_capture_result ) (const struct camera3_callback_ops *, const camera3_capture_result_t * résultat) |
annuler(* | notifier ) (const struct camera3_callback_ops *, const camera3_notify_msg_t * msg) |
Description détaillée
Documentation sur le terrain
void (* notify) (const struct camera3_callback_ops *, const camera3_notify_msg_t * msg) |
notifier:
Rappel de notification asynchrone à partir du HAL, déclenché pour diverses raisons. Uniquement pour les informations indépendantes de la capture d'image ou qui nécessitent une synchronisation spécifique. La propriété de la structure du message reste avec la HAL, et le msg ne doit être valide que pour la durée de cet appel.
Plusieurs threads peuvent appeler simultanément notify () .
<= CAMERA_DEVICE_API_VERSION_3_1:
La notification de début d'exposition pour une requête donnée doit être envoyée par la HAL avant que le premier appel à process_capture_result () pour cette requête ne soit effectué.
> = CAMERA_DEVICE_API_VERSION_3_2:
Les tampons livrés au framework ne seront pas envoyés à la couche application tant qu'un horodatage de début d'exposition (ou un horodatage de début d'exposition de l'image d'entrée pour une demande de retraitement) n'aura pas été reçu via un appel SHUTTER notify () . Il est fortement recommandé d'envoyer cet appel le plus tôt possible.
Exigences de performance:
Ceci est un appel non bloquant. Le framework retournera cet appel dans 5 ms.
void (* process_capture_result) (const struct camera3_callback_ops *, const camera3_capture_result_t * résultat) |
process_capture_result:
Envoyez les résultats d'une capture terminée au framework. process_capture_result () peut être invoqué plusieurs fois par la HAL en réponse à une seule demande de capture. Cela permet, par exemple, de renvoyer les métadonnées et les tampons basse résolution en un seul appel et les tampons JPEG post-traités lors d'un appel ultérieur, une fois qu'ils sont disponibles. Chaque appel doit inclure le numéro de trame de la demande pour laquelle il renvoie des métadonnées ou des tampons.
Un composant (tampon ou métadonnées) du résultat complet ne peut être inclus que dans un seul appel process_capture_result. Un tampon pour chaque flux et les métadonnées de résultat doivent être retournés par la HAL pour chaque requête dans l'un des appels process_capture_result, même en cas d'erreurs produisant une partie de la sortie. Un appel à process_capture_result () sans tampon de sortie ni métadonnées de résultat n'est pas autorisé.
L'ordre de renvoi des métadonnées et des tampons pour un seul résultat n'a pas d'importance, mais les tampons pour un flux donné doivent être retournés dans l'ordre FIFO. Ainsi, le tampon de la requête 5 pour le flux A doit toujours être renvoyé avant le tampon de la requête 6 pour le flux A. Cela s'applique également aux métadonnées de résultat; les métadonnées de la requête 5 doivent être renvoyées avant les métadonnées de la requête 6.
Cependant, différents flux sont indépendants les uns des autres, il est donc acceptable et attendu que le tampon pour la demande 5 pour le flux A puisse être retourné après le tampon pour la demande 6 pour le flux B. Et il est acceptable que les métadonnées de résultat pour la demande 6 pour le flux B soient renvoyées avant que le tampon pour la demande 5 pour le flux A ne le soit.
Le HAL conserve la propriété de la structure des résultats, qui doit uniquement être valide pour accéder pendant cet appel. Le framework copiera tout ce dont il a besoin avant le retour de cet appel.
Les tampons de sortie n'ont pas encore besoin d'être remplis; le framework attendra sur la clôture de synchronisation de libération du tampon de flux avant de lire les données du tampon. Par conséquent, cette méthode doit être appelée par le HAL dès que possible, même si certains ou tous les tampons de sortie sont toujours en cours de remplissage. Le HAL doit inclure des clôtures de synchronisation de libération valides dans chaque entrée de tampon de flux output_buffers, ou -1 si ce tampon de flux est déjà rempli.
Si le tampon de résultat ne peut pas être construit pour une demande, le HAL doit renvoyer un tampon de métadonnées vide, mais toujours fournir les tampons de sortie et leurs clôtures de synchronisation. De plus, notify () doit être appelé avec un message ERROR_RESULT.
Si un tampon de sortie ne peut pas être rempli, son champ d'état doit être défini sur STATUS_ERROR. De plus, notify () doit être appelé avec un message ERROR_BUFFER.
Si la capture entière a échoué, cette méthode doit encore être appelée pour renvoyer les tampons de sortie au framework. Tous les états de tampon doivent être STATUS_ERROR et les métadonnées de résultat doivent être un tampon vide. De plus, notify () doit être appelé avec un message ERROR_REQUEST. Dans ce cas, les messages ERROR_RESULT / ERROR_BUFFER individuels ne doivent pas être envoyés.
Exigences de performance:
Ceci est un appel non bloquant. Le framework retournera cet appel dans 5 ms.
La latence du pipeline (voir S7 pour la définition) doit être inférieure ou égale à 4 intervalles de trame, et doit être inférieure ou égale à 8 intervalles de trame.
La documentation de cette structure a été générée à partir du fichier suivant:
- matériel / libhardware / include / hardware / camera3.h