Camera3_capture_result Odniesienie do struktury
#include < camera3.h >
Pola danych | |
| uint32_t | numer_ramki |
| stała kamera_metadane_t * | wynik |
| uint32_t | num_output_buffers |
| stała kamera3_stream_buffer_t * | bufory_wyjściowe |
| stała kamera3_stream_buffer_t * | bufor_wejściowy |
| uint32_t | częściowy_wynik |
szczegółowy opis
kamera3_capture_result_t:
Wynik pojedynczego przechwycenia/ponownego przetworzenia przez urządzenie HAL kamery. Jest to wysyłane do struktury asynchronicznie za pomocą metody Process_capture_result() w odpowiedzi na pojedyncze żądanie przechwytywania wysłane do warstwy HAL za pomocą metody Process_capture_request(). Dla każdego żądania warstwa HAL może wykonać wiele wywołań Process_capture_result().
Każde wywołanie, wszystkie z tym samym numerem ramki, może zawierać pewien podzbiór buforów wyjściowych i/lub metadane wynikowe. Metadane można podać tylko raz dla danego numeru ramki; wszystkie inne wywołania muszą ustawić metadane wyników na NULL.
Struktura wyników zawiera metadane wyjściowe z tego przechwytywania oraz zestaw buforów wyjściowych, które zostały/zostaną wypełnione w ramach tego przechwytywania. Każdy bufor wyjściowy może być wyposażony w barierę synchronizacji wydania, na którą framework będzie czekać przed odczytaniem, w przypadku gdy bufor nie został jeszcze wypełniony przez warstwę HAL.
>= CAMERA_DEVICE_API_VERSION_3_2:
Metadane mogą być dostarczane wielokrotnie dla pojedynczego numeru ramki. Struktura zgromadzi razem ostateczny zestaw wyników, łącząc każdy wynik częściowy w całkowity zestaw wyników.
Jeśli w żądaniu podany jest bufor wejściowy, warstwa HAL musi go zwrócić w jednym z wywołań Process_capture_result, a wywołanie może polegać po prostu na zwróceniu bufora wejściowego, bez metadanych i buforów wyjściowych; z ograniczeniami synchronizacji należy postępować w taki sam sposób, jak w przypadku buforów wyjściowych.
Uwagi dotyczące wydajności:
Aplikacje również natychmiast otrzymają te częściowe wyniki, więc wysyłanie częściowych wyników jest zdecydowanie zalecaną optymalizacją wydajności, aby uniknąć całkowitego opóźnienia potoku przed wysłaniem wyników dla tego, co jest znane na bardzo wczesnym etapie potoku.
Typowym przypadkiem użycia może być obliczenie stanu AF w połowie potoku; wysyłając natychmiast stan z powrotem do frameworka, uzyskujemy 50% wzrost wydajności i postrzeganą responsywność autofokusa.
Dokumentacja terenowa
| uint32_t numer_ramki |
Numer ramki to rosnąca liczba całkowita ustawiana przez platformę w przesłanym żądaniu w celu jednoznacznej identyfikacji tego przechwytywania. Służy także do identyfikacji żądania w asynchronicznych powiadomieniach wysyłanych do kamery3_callback_ops_t.notify() .
| const kamera3_stream_buffer_t * bufor_wejściowy |
>= CAMERA_DEVICE_API_VERSION_3_2:
Uchwyt bufora strumienia wejściowego dla tego przechwytywania. Może nie zostać jeszcze wykorzystany w momencie wywołania metody HAL Process_capture_result(); struktura będzie czekać na zabezpieczenia synchronizacji wydania dostarczone przez warstwę HAL przed ponownym użyciem bufora.
HAL powinna obsługiwać ogrodzenia synchronizacji w taki sam sposób, jak w przypadku buforów wyjściowych.
Na jedno żądanie można wysłać tylko jeden bufor wejściowy. Podobnie jak w przypadku buforów wyjściowych, kolejność zwracanych buforów wejściowych musi być utrzymywana przez warstwę HAL.
Uwagi dotyczące wydajności:
Bufor wejściowy powinien zostać zwrócony możliwie najwcześniej. Jeśli warstwa HAL obsługuje bariery synchronizacji, może wywołać Process_capture_result, aby zwrócić ją z odpowiednio ustawionymi barierami synchronizacji. Jeśli zabezpieczenia synchronizacji nie są obsługiwane, bufor można zwrócić dopiero po jego zużyciu, co może zająć dużo czasu; warstwa HAL może zdecydować się na skopiowanie tego bufora wejściowego, aby bufor powrócił wcześniej.
| 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ń przechwytywania. Jeśli jest to mniej niż liczba buforów w żądaniu przechwytywania, należy wykonać co najmniej jeszcze jedno wywołanie metody Process_capture_result z tym samym numerem_klatki, aby zwrócić pozostałe bufory wyjściowe do struktury. Może to być zero, jeśli struktura zawiera prawidłowe metadane wyniku lub w wyniku zwrócony jest bufor wejściowy.
| const kamera3_stream_buffer_t * bufory_wyjściowe |
Uchwyty buforów strumienia wyjściowego dla tego przechwytywania. Mogą one nie być jeszcze wypełnione w momencie wywołania metody HAL Process_capture_result(); struktura będzie czekać na zabezpieczeniach synchronizacji wydania dostarczonych przez warstwę HAL przed odczytaniem buforów.
HAL musi ustawić granicę synchronizacji zwolnienia bufora strumienia na prawidłową synchronizację fd lub na -1, jeśli bufor został już wypełniony.
Jeśli warstwa HAL napotka błąd podczas przetwarzania bufora, a bufor nie zostanie wypełniony, pole stanu bufora musi być ustawione na CAMERA3_BUFFER_STATUS_ERROR. Jeśli warstwa HAL nie zaczekała na ogrodzenie nabywania przed napotkaniem błędu, ogrodzenie nabywania powinno zostać skopiowane do ogrodzenia zwolnienia, aby struktura mogła poczekać na ogrodzeniu przed ponownym użyciem bufora.
Ograniczenie nabycia musi być ustawione na -1 dla wszystkich buforów wyjściowych. Jeśli num_output_buffers wynosi zero, może to być NULL. W takim przypadku warstwa HAL musi wykonać co najmniej jeszcze jedno wywołanie Process_capture_result, aby zapewnić bufory wyjściowe.
Kiedy proces_capture_result jest wywoływany z nowym buforem dla ramki, bufory wszystkich poprzednich ramek dla tego odpowiedniego strumienia muszą już zostać dostarczone (ogrodzenia nie muszą jeszcze zostać zasygnalizowane).
>= CAMERA_DEVICE_API_VERSION_3_2:
Bufory Gralloc dla ramki mogą zostać wysłane do frameworka przed odpowiednim powiadomieniem SHUTTER.
Uwagi dotyczące wydajności:
Bufory dostarczone do frameworka nie zostaną wysłane do warstwy aplikacji, dopóki nie zostanie odebrany znacznik czasu rozpoczęcia ekspozycji poprzez wywołanie SHUTTER notify(). Zdecydowanie zaleca się wysłanie tego połączenia tak wcześnie, jak to możliwe.
| uint32_t częściowy_wynik |
>= CAMERA_DEVICE_API_VERSION_3_2:
Aby skorzystać z częściowych wyników, warstwa HAL musi ustawić statyczne metadane android.request.partialResultCount na liczbę częściowych wyników, które wyśle dla każdej ramki.
Każdy nowy wynik przechwytywania z wynikiem częściowym musi ustawić to pole (partial_result) na odrębną wartość obejmującą od 1 do android.request.partialResultCount.
Warstwy HAL, które nie chcą korzystać z tej funkcji, nie mogą ustawiać parametrów android.request.partialResultCount lub Partial_result na wartość inną niż 1.
Ta wartość musi być ustawiona na 0, jeśli wynik przechwytywania zawiera tylko bufory i nie zawiera metadanych.
| const kamera_metadata_t * wynik |
Metadane wyniku dla tego przechwytywania. Zawiera informacje o końcowych parametrach przechwytywania, stanie sprzętu do przechwytywania i przetwarzania końcowego, stanie algorytmów 3A, jeśli są włączone, oraz danych wyjściowych wszelkich włączonych jednostek statystycznych.
Tylko jedno wywołanie metody Process_capture_result() z podanym numerem_klatki może zawierać metadane wyniku. Wszystkie inne wywołania tego samego numeru_klatki muszą mieć ustawioną wartość NULL.
Jeśli podczas tworzenia metadanych wynikowych wystąpił błąd, wynik musi być pustym buforem metadanych, a funkcja notify() musi zostać wywołana z komunikatem ERROR_RESULT.
>= CAMERA_DEVICE_API_VERSION_3_2:
Wiele wywołań metody Process_capture_result() z podanym numerem_klatki może zawierać metadane wyniku.
Częściowo przesłane metadane nie powinny zawierać żadnego klucza metadanych zwróconego w poprzednim częściowym wyniku dla danej ramki. Każdy nowy wynik częściowy dla tej ramki musi także ustawić odrębną wartość częściowego wyniku.
Jeśli wywołano notify z ERROR_RESULT, wszystkie dalsze częściowe wyniki dla tej ramki są ignorowane przez platformę.
Dokumentacja tej struktury została wygenerowana z następującego pliku:
- hardware/libhardware/include/hardware/ camera3.h