camera3_callback_ops-Strukturreferenz

Benachrichtigen:

Asynchroner Benachrichtigungs-Callback vom HAL, der aus verschiedenen Gründen ausgelöst wird. Nur für Informationen, die unabhängig von der Frame-Erfassung sind oder ein bestimmtes Timing erfordern. Die Eigentümerschaft der Nachrichtenstruktur verbleibt beim HAL und die Nachricht muss nur für die Dauer dieses Aufrufs gültig sein.

Mehrere Threads können notify() gleichzeitig aufrufen.

<= CAMERA_DEVICE_API_VERSION_3_1:

Die Benachrichtigung über den Beginn der Belichtung für eine bestimmte Anfrage muss vom HAL gesendet werden, bevor der erste Aufruf von process_capture_result() für diese Anfrage erfolgt.

>= CAMERA_DEVICE_API_VERSION_3_2:

An das Framework übergebene Puffer werden erst an die Anwendungsebene gesendet, wenn über einen SHUTTER-Aufruf notify() ein Zeitstempel für den Beginn der Belichtung (oder der Zeitstempel für den Beginn der Belichtung des Eingabebilds für eine Anfrage zur erneuten Verarbeitung) empfangen wurde. Wir empfehlen dringend, diesen Aufruf so früh wie möglich zu senden.

Anforderungen für die Leistung:

Dies ist ein nicht blockierender Aufruf. Das Framework gibt diesen Aufruf nach 5 ms zurück.

Definition in Zeile 2499 der Datei camera3.h .

process_capture_result:

Ergebnisse einer abgeschlossenen Erfassung an das Framework senden. process_capture_result() kann vom HAL als Reaktion auf eine einzelne Erfassungsanfrage mehrmals aufgerufen werden. So können beispielsweise die Metadaten und Puffer mit niedriger Auflösung in einem Aufruf zurückgegeben werden und die nachbearbeiteten JPEG-Puffer in einem späteren Aufruf, sobald sie verfügbar sind. Jeder Aufruf muss die Framenummer der Anfrage enthalten, für die Metadaten oder Puffer zurückgegeben werden.

Eine Komponente (Puffer oder Metadaten) des vollständigen Ergebnisses darf nur in einem process_capture_result-Aufruf enthalten sein. Für jede Anfrage muss von der HAL in einem der process_capture_result-Aufrufe ein Puffer für jeden Stream und die Ergebnismetadaten zurückgegeben werden, auch wenn Fehler auftreten, die einen Teil der Ausgabe verursachen. Ein Aufruf von process_capture_result() ohne Ausgabepuffer oder Ergebnismetadaten ist nicht zulässig.

Die Reihenfolge, in der Metadaten und Puffer für ein einzelnes Ergebnis zurückgegeben werden, spielt keine Rolle. Puffer für einen bestimmten Stream müssen jedoch in FIFO-Reihenfolge zurückgegeben werden. Der Puffer für Anfrage 5 für Stream A muss also immer vor dem Puffer für Anfrage 6 für Stream A zurückgegeben werden. Das gilt auch für die Ergebnismetadaten: Die Metadaten für Anfrage 5 müssen vor den Metadaten für Anfrage 6 zurückgegeben werden.

Die verschiedenen Streams sind jedoch unabhängig voneinander. Daher ist es akzeptabel und zu erwarten, dass der Puffer für Anfrage 5 für Stream A nach dem Puffer für Anfrage 6 für Stream B zurückgegeben wird. Außerdem ist es akzeptabel, dass die Ergebnismetadaten für Anfrage 6 für Stream B vor dem Puffer für Anfrage 5 für Stream A zurückgegeben werden.

Das HAL behält die Inhaberschaft der Ergebnisstruktur bei, die nur für den Zugriff während dieses Aufrufs gültig sein muss. Das Framework kopiert alles, was es benötigt, bevor dieser Aufruf zurückgegeben wird.

Die Ausgabepuffer müssen noch nicht gefüllt werden. Das Framework wartet auf den Synchronisations-Fence für die Freigabe des Stream-Puffers, bevor die Pufferdaten gelesen werden. Daher sollte diese Methode so schnell wie möglich vom HAL aufgerufen werden, auch wenn einige oder alle Ausgabepuffer noch gefüllt werden. Das HAL muss in jedem „output_buffers“-Stream-Puffereintrag gültige Release-Synchronisations-Fences einfügen oder -1, wenn dieser Stream-Puffer bereits gefüllt ist.

Wenn der Ergebnisbuffer für eine Anfrage nicht erstellt werden kann, sollte das HAL einen leeren Metadatenbuffer zurückgeben, aber trotzdem die Ausgabebuffer und ihre Synchronisations-Fences bereitstellen. Außerdem muss notify() mit einer ERROR_RESULT-Nachricht aufgerufen werden.

Wenn ein Ausgabepuffer nicht gefüllt werden kann, muss sein Statusfeld auf STATUS_ERROR gesetzt werden. Außerdem muss notify() mit einer ERROR_BUFFER-Nachricht aufgerufen werden.

Wenn die gesamte Aufnahme fehlgeschlagen ist, muss diese Methode trotzdem aufgerufen werden, um die Ausgabepuffer an das Framework zurückzugeben. Alle Pufferstatus sollten STATUS_ERROR sein und die Ergebnismetadaten sollten ein leerer Puffer sein. Außerdem muss notify() mit einer ERROR_REQUEST-Nachricht aufgerufen werden. In diesem Fall sollten keine einzelnen ERROR_RESULT-/ERROR_BUFFER-Nachrichten gesendet werden.

Anforderungen für die Leistung:

Dies ist ein nicht blockierender Aufruf. Das Framework gibt diesen Aufruf nach 5 ms zurück.

Die Pipeline-Latenz (siehe S7 für die Definition) sollte kleiner oder gleich 4 Frame-Intervallen sein und muss kleiner oder gleich 8 Frame-Intervallen sein.

Definition in Zeile 2466 der Datei camera3.h .