Camera3_callback_ops Odniesienie do struktury

notyfikować:

Asynchroniczne wywołanie zwrotne powiadomienia z warstwy HAL uruchamiane z różnych powodów. Tylko w przypadku informacji niezależnych od przechwytywania klatek lub wymagających określonego czasu. Własność struktury wiadomości pozostaje w HAL, a msg musi być ważne tylko przez czas trwania tego wywołania.

Wiele wątków może jednocześnie wywoływać funkcję notify() .

<= CAMERA_DEVICE_API_VERSION_3_1:

Powiadomienie o rozpoczęciu ekspozycji dla danego żądania musi zostać wysłane przez warstwę HAL przed wykonaniem pierwszego wywołania metody Process_capture_result() dla tego żądania.

>= CAMERA_DEVICE_API_VERSION_3_2:

Bufory dostarczone do platformy nie zostaną wysłane do warstwy aplikacji, dopóki znacznik czasu rozpoczęcia naświetlania (lub znacznik czasu rozpoczęcia naświetlania obrazu wejściowego w przypadku żądania ponownego przetworzenia) nie zostanie odebrany za pośrednictwem wywołania SHUTTER notify() . Zdecydowanie zaleca się wysłanie tego połączenia tak wcześnie, jak to możliwe.

Wymagania dotyczące wydajności:

To jest połączenie nieblokujące. Struktura zwróci to wywołanie w ciągu 5 ms.

Definicja w linii 2499 pliku kamera3.h .

wynik_przechwytywania_procesu:

Wyślij wyniki ukończonego przechwytywania do platformy. Process_capture_result() może być wywoływana wielokrotnie przez warstwę HAL w odpowiedzi na pojedyncze żądanie przechwytywania. Umożliwia to na przykład zwrócenie metadanych i buforów o niskiej rozdzielczości w jednym wywołaniu oraz przetworzenie buforów JPEG w późniejszym wywołaniu, gdy będą one dostępne. Każde wywołanie musi zawierać numer ramki żądania, dla którego zwraca metadane lub bufory.

Składnik (bufor lub metadane) pełnego wyniku może zostać uwzględniony tylko w jednym wywołaniu Process_capture_result. Bufor dla każdego strumienia i metadane wyników muszą zostać zwrócone przez warstwę HAL dla każdego żądania w jednym z wywołań Process_capture_result, nawet w przypadku błędów podczas generowania części danych wyjściowych. Wywołanie metody Process_capture_result() bez buforów wyjściowych ani metadanych wyników jest niedozwolone.

Kolejność zwracanych metadanych i buforów dla pojedynczego wyniku nie ma znaczenia, ale bufory dla danego strumienia muszą być zwracane w kolejności FIFO. Zatem bufor żądania 5 dla strumienia A musi być zawsze zwrócony przed buforem żądania 6 dla strumienia A. Dotyczy to również metadanych wynikowych; metadane dla żądania 5 muszą zostać zwrócone przed metadanymi dla żądania 6.

Jednakże różne strumienie są od siebie niezależne, zatem dopuszczalne i oczekiwane jest, że bufor żądania 5 dla strumienia A może zostać zwrócony po zwróceniu bufora żądania 6 dla strumienia B. Dopuszczalne jest, że metadane wynikowe dla żądania 6 dla strumienia B są zwracane przed zwróceniem bufora dla żądania 5 dla strumienia A.

HAL zachowuje własność struktury wyników, która musi być ważna tylko w celu uzyskania dostępu podczas tego wywołania. Struktura skopiuje wszystko, czego potrzebuje, zanim to wywołanie powróci.

Bufory wyjściowe nie muszą być jeszcze zapełnione; struktura będzie czekać na ogrodzeniu synchronizacji zwolnienia bufora strumienia przed odczytaniem danych z bufora. Dlatego metoda ta powinna zostać wywołana przez warstwę HAL tak szybko, jak to możliwe, nawet jeśli niektóre lub wszystkie bufory wyjściowe są nadal zapełniane. HAL musi zawierać prawidłowe ograniczenia synchronizacji wersji w każdym wpisie bufora strumienia Output_buffers lub -1, jeśli ten bufor strumienia jest już wypełniony.

Jeśli dla żądania nie można skonstruować bufora wyników, warstwa HAL powinna zwrócić pusty bufor metadanych, ale nadal udostępniać bufory wyjściowe i ich zabezpieczenia synchronizacji. Ponadto należy wywołać funkcję notify() z komunikatem ERROR_RESULT.

Jeżeli nie można zapełnić bufora wyjściowego, jego pole statusu musi być ustawione na STATUS_ERROR. Ponadto należy wywołać funkcję notify() z komunikatem ERROR_BUFFER.

Jeśli całe przechwytywanie nie powiodło się, należy wywołać tę metodę, aby zwrócić bufory wyjściowe do platformy. Wszystkie statusy buforów powinny mieć wartość STATUS_ERROR, a metadane wyników powinny być pustym buforem. Ponadto należy wywołać funkcję notify() z komunikatem ERROR_REQUEST. W takim przypadku nie należy wysyłać pojedynczych komunikatów ERROR_RESULT/ERROR_BUFFER.

Wymagania dotyczące wydajności:

To jest połączenie nieblokujące. Struktura zwróci to wywołanie w ciągu 5 ms.

Opóźnienie potoku (definicja w S7) powinno być mniejsze lub równe 4 interwałom ramek i musi być mniejsze lub równe 8 interwałom ramek.

Definicja w linii 2466 pliku kamera3.h .