camera3_callback_ops Strukturreferenz

benachrichtigen:

Asynchroner Benachrichtigungsrückruf von der HAL, ausgelöst aus verschiedenen Gründen. Nur für Informationen, die unabhängig von der Bilderfassung sind oder ein bestimmtes Timing erfordern. Das Eigentum an 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 von der 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 gelieferte Puffer werden erst dann an die Anwendungsschicht gesendet, wenn ein Zeitstempel für den Beginn der Belichtung (oder der Zeitstempel für den Beginn der Belichtung des Eingabebilds für eine Neuverarbeitungsanforderung) über einen SHUTTER notify()- Aufruf empfangen wurde. Es wird dringend empfohlen, diesen Anruf so früh wie möglich abzusenden.

Leistungsanforderungen:

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

Definition in Zeile 2499 der Datei camera3.h .

Process_Capture_Result:

Senden Sie Ergebnisse einer abgeschlossenen Erfassung an das Framework. Process_capture_result() kann von der HAL als Reaktion auf eine einzelne Erfassungsanforderung mehrmals aufgerufen werden. Dadurch können beispielsweise die Metadaten und Puffer mit niedriger Auflösung in einem Aufruf zurückgegeben werden und die JPEG-Puffer in einem späteren Aufruf nachverarbeitet werden, sobald sie verfügbar sind. Jeder Aufruf muss die Frame-Nummer der Anforderung enthalten, für die er Metadaten oder Puffer zurückgibt.

Eine Komponente (Puffer oder Metadaten) des Gesamtergebnisses darf nur in einem Aufruf von „process_capture_result“ enthalten sein. Ein Puffer für jeden Stream und die Ergebnismetadaten müssen von der HAL für jede Anforderung in einem der Aufrufe von „process_capture_result“ zurückgegeben werden, auch im Falle von Fehlern, die einen Teil der Ausgabe erzeugen. Ein Aufruf von „process_capture_result()“ ohne Ausgabepuffer oder Ergebnismetadaten ist nicht zulässig.

Die Reihenfolge der Rückgabe von Metadaten und Puffern für ein einzelnes Ergebnis spielt keine Rolle, Puffer für einen bestimmten Stream müssen jedoch in FIFO-Reihenfolge zurückgegeben werden. Daher muss der Puffer für Anfrage 5 für Stream A immer vor dem Puffer für Anfrage 6 für Stream A zurückgegeben werden. Dies gilt auch für die Ergebnismetadaten; Die Metadaten für Anfrage 5 müssen vor den Metadaten für Anfrage 6 zurückgegeben werden.

Allerdings sind unterschiedliche Streams unabhängig voneinander, daher ist es akzeptabel und zu erwarten, dass der Puffer für Anfrage 5 für Stream A möglicherweise zurückgegeben wird, nachdem der Puffer für Anfrage 6 für Stream B zurückgegeben wird. Und es ist akzeptabel, dass die Ergebnismetadaten für Anfrage 6 für Stream B zurückgegeben werden, bevor der Puffer für Anfrage 5 für Stream A zurückgegeben wird.

Die HAL behält den Besitz der Ergebnisstruktur, 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ückkehrt.

Die Ausgabepuffer müssen noch nicht gefüllt werden; Das Framework wartet auf den Stream-Puffer-Release-Synchronisierungszaun, bevor es die Pufferdaten liest. Daher sollte diese Methode so schnell wie möglich von der HAL aufgerufen werden, auch wenn einige oder alle Ausgabepuffer noch gefüllt sind. Die HAL muss gültige Release-Sync-Fences in jeden Stream-Puffer-Eintrag „output_buffers“ einschließen, oder -1, wenn dieser Stream-Puffer bereits gefüllt ist.

Wenn der Ergebnispuffer für eine Anfrage nicht erstellt werden kann, sollte die HAL einen leeren Metadatenpuffer zurückgeben, aber dennoch die Ausgabepuffer und ihre Synchronisierungsgrenzen bereitstellen. Darüber hinaus muss notify() mit einer ERROR_RESULT-Meldung aufgerufen werden.

Wenn ein Ausgabepuffer nicht gefüllt werden kann, muss sein Statusfeld auf STATUS_ERROR gesetzt werden. Darüber hinaus muss notify() mit einer ERROR_BUFFER-Meldung aufgerufen werden.

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

Leistungsanforderungen:

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

Die Pipeline-Latenz (Definition siehe S7) 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 .