Struktura camera3_capture_result
#include <
camera3.h
>
Pola danych |
|
uint32_t | frame_number |
const camera_metadata_t * | wynik |
uint32_t | num_output_buffers |
const camera3_stream_buffer_t * | output_buffers |
const camera3_stream_buffer_t * | input_buffer |
uint32_t | partial_result |
Szczegółowy opis
camera3_capture_result_t:
Wynik pojedynczego przechwycenia/przetworzenia przez urządzenie HAL aparatu. Jest on przesyłany do frameworku asynchronicznie za pomocą funkcji process_capture_result() w odpowiedzi na pojedyncze żądanie przechwycenia wysłane do HAL za pomocą funkcji process_capture_request(). HAL może wykonać wiele wywołań funkcji process_capture_result() dla każdego żądania.
Każde wywołanie o tym samym numerze ramki może zawierać podzbiór buforów wyjściowych lub metadane wyników. Metadane mogą być podawane tylko raz dla danego numeru klatki. W przypadku wszystkich innych wywołań metadanych wyniku należy ustawić wartość NULL.
Struktura wyniku zawiera metadane wyjściowe z tego ujęcia oraz zestaw buforów wyjściowych, które zostały lub zostaną wypełnione w ramach tego ujęcia. Każdy bufor wyjściowy może zawierać element synchronizacji, który framework będzie oczekiwał przed odczytaniem, jeśli bufor nie został jeszcze wypełniony przez HAL.
>= CAMERA_DEVICE_API_VERSION_3_2:
Metadane mogą być podawane wielokrotnie dla jednego numeru klatki. Framework będzie gromadzić końcowy zbiór wyników, łącząc poszczególne wyniki w jeden zbiór wyników.
Jeśli w żądaniu podano bufor wejściowy, HAL musi zwrócić go w jednym z wywołań process_capture_result. Wywołanie może zwracać tylko bufor wejściowy, bez metadanych i buforów wyjściowych. Bariery synchronizacji muszą być obsługiwane tak samo jak w przypadku buforów wyjściowych.
Uwagi dotyczące wydajności:
Aplikacje otrzymają te częściowe wyniki natychmiast, dlatego wysyłanie częściowych wyników jest bardzo zalecaną optymalizacją wydajności, która pozwala uniknąć całkowitego opóźnienia w przetwarzaniu danych przed wysłaniem wyników dotyczących informacji znanych już na bardzo wczesnym etapie przetwarzania.
Typowym przypadkiem użycia może być obliczanie stanu AF w połowie procesu. Dzięki natychmiastowemu wysyłaniu stanu z powrotem do frameworku uzyskujemy 50% wzrost wydajności i większą responsywność autofokusu.
Dokumentacja pola
uint32_t frame_number |
Numer kadru to rosnąca liczba całkowita ustawiona przez framework w przesłanym żądaniu, aby jednoznacznie zidentyfikować to przechwycenie. Służy ona też do identyfikowania żądania w powiadomieniach asynchronicznych wysyłanych do camera3_callback_ops_t.notify() .
const camera3_stream_buffer_t * input_buffer |
>= CAMERA_DEVICE_API_VERSION_3_2:
Uchwyt do bufora strumienia wejściowego dla tego przechwycenia. Może on nie zostać jeszcze wykorzystany w momencie wywołania przez HAL metody process_capture_result(). Zanim framework ponownie użyje bufora, będzie czekać na zwolnienie zabezpieczeń synchronizacji udostępnionych przez HAL.
HAL powinien obsługiwać płoty synchronizacji w taki sam sposób jak w przypadku buforów wyjściowych.
Na żądanie można wysłać tylko 1 bufor danych wejściowych. Podobnie jak w przypadku buforów wyjściowych, kolejność zwracanych buforów wejściowych musi być zachowana przez HAL.
Uwagi dotyczące wydajności:
Bufor danych wejściowych powinien zostać zwrócony jak najszybciej. Jeśli interfejs HAL obsługuje bariery synchronizacji, może wywołać funkcję process_capture_result, aby zwrócić ją z odpowiednio ustawionymi barierami synchronizacji. Jeśli ogrodzenia synchronizacji nie są obsługiwane, bufor może zostać zwrócony dopiero po jego wykorzystaniu, co może zająć dużo czasu. HAL może skopiować ten bufor wejściowy, aby szybciej zwrócić bufor.
uint32_t num_output_buffers |
Liczba buforów wyjściowych zwróconych w tej strukturze wyników. Musi być mniejsza lub równa liczbie pasujących żądań rejestrowania. Jeśli jest ona mniejsza niż liczba buforów w żądaniu rejestrowania, należy wykonać co najmniej 1 dodatkowe wywołanie process_capture_result z tym samym parametrem frame_number, aby zwrócić pozostałe bufory wyjściowe do frameworku. Wartość ta może być równa 0 tylko wtedy, gdy struktura zawiera prawidłowe metadane wyników lub zwracany jest bufor danych wejściowych.
const camera3_stream_buffer_t * output_buffers |
Uchwyty buforów strumienia wyjściowego dla tego przechwycenia. W momencie wywołania przez HAL metody process_capture_result() mogą one jeszcze nie być wypełnione. Zanim framework odczyta bufory, będzie czekać na zwolnienie zabezpieczeń synchronizacji udostępnionych przez HAL.
HAL musi ustawić synchronizację zwolnienia bufora strumienia na prawidłową wartość synchronizacji fd lub na -1, jeśli bufor jest już wypełniony.
Jeśli podczas przetwarzania bufora HAL napotka błąd, a bufor nie jest wypełniony, pole stanu bufora musi być ustawione na CAMERA3_BUFFER_STATUS_ERROR. Jeśli HAL nie czekał na zablokowanie nabywania przed napotkaniem błędu, zablokowanie nabywania powinno zostać skopiowane do zablokowania zwalniania, aby umożliwić frameworkowi oczekiwanie na zablokowanie przed ponownym użyciem bufora.
W przypadku wszystkich buforów wyjściowych wartość acquire fence musi być ustawiona na -1. Jeśli parametr num_output_buffers ma wartość 0, może on zawierać wartość NULL. W takim przypadku HAL musi wykonać co najmniej 1 kolejną metodę process_capture_result, aby udostępnić bufory wyjściowe.
Gdy process_capture_result jest wywoływany z nowym buforem klatki, wszystkie bufory poprzednich klatek dla danego strumienia muszą być już dostarczone (nie muszą być jeszcze sygnalizowane).
>= CAMERA_DEVICE_API_VERSION_3_2:
Bufory Gralloc dla ramki mogą zostać wysłane do frameworku przed odpowiednim wywołaniem SHUTTER-notify.
Uwagi dotyczące wydajności:
Bufory dostarczone do frameworku nie zostaną wysłane do warstwy aplikacji, dopóki nie zostanie odebrany sygnał czasu rozpoczęcia ekspozycji za pomocą wywołania SHUTTER notify(). Zdecydowanie zalecamy jak najszybsze przeprowadzenie tej rozmowy.
uint32_t partial_result |
>= CAMERA_DEVICE_API_VERSION_3_2:
Aby korzystać z częściowych wyników, HAL musi ustawić statyczne metadane android.request.partialResultCount na liczbę częściowych wyników, które zostaną wysłane dla każdego obrazu.
Każdy nowy wynik przechwycenia z częściowym wynikiem musi mieć to pole (partial_result) ustawione na niepowtarzalną wartość w zakresie od 1 do android.request.partialResultCount.
Jeśli nie chcesz korzystać z tej funkcji, nie ustawiaj parametrów android.request.partialResultCount ani partial_result na wartość inną niż 1.
Ta wartość musi być ustawiona na 0, gdy wynik przechwytywania zawiera tylko bufory i nie zawiera metadanych.
const camera_metadata_t * result |
Metadane wyniku dotyczące tego zapisu. Zawiera on informacje o ostatecznych parametrach rejestrowania, stanie sprzętu do rejestrowania i postprocessingu, stanie algorytmów 3A (jeśli są włączone) oraz dane wyjściowe z wszelkich włączonych jednostek statystycznych.
Metadane wyniku może zawierać tylko jedno wywołanie funkcji process_capture_result() z danym parametrem frame_number. W przypadku wszystkich innych wywołań o tym samym argumencie frame_number wartość NULL jest dozwolona.
Jeśli podczas generowania metadanych wyniku wystąpił błąd, result musi być pustym buforem metadanych, a funkcja notify() musi być wywołana z argumentem ERROR_RESULT.
>= CAMERA_DEVICE_API_VERSION_3_2:
Wielokrotne wywołania funkcji process_capture_result() z danym parametrem frame_number mogą zawierać metadane wyniku.
Przesłane metadane częściowe nie powinny zawierać żadnego klucza metadanych zwróconego w poprzednim częściowym wyniku dla danej ramki. Każdy nowy częściowy wynik w danym ujęciu musi mieć też odrębną wartość partial_result.
Jeśli wywołanie notify zostało wywołane z argumentem ERROR_RESULT, wszystkie dalsze częściowe wyniki dla tego ramki zostaną zignorowane przez framework.
Dokumentacja tego typu danych została wygenerowana z tego pliku:
- hardware/libhardware/include/hardware/ camera3.h