camera3_device_ops स्ट्रक्चर का रेफ़रंस

डेटा फ़ील्ड
camera3_device_ops स्ट्रक्चर का रेफ़रंस

#include < camera3.h >

डेटा फ़ील्ड

int(*  initialize )(const struct camera3_device *, const camera3_callback_ops_t *callback_ops)
 
int(*  configure_streams )(const struct camera3_device *, camera3_stream_configuration_t *stream_list)
 
int(*  register_stream_buffers )(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set)
 
const camera_metadata_t *(*  construct_default_request_settings )(const struct camera3_device *, int type)
 
int(*  process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request)
 
void(*  get_metadata_vendor_tag_ops )(const struct camera3_device *, vendor_tag_query_ops_t *ops)
 
void(*  dump )(const struct camera3_device *, int fd)
 
int(*  flush )(const struct camera3_device *)
 
void *  reserved [8]
 

पूरी जानकारी

परिभाषा, camera3.h फ़ाइल की लाइन 2509 पर दी गई है.

फ़ील्ड का दस्तावेज़

int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list)

configure_streams:

सिर्फ़ CAMERA_DEVICE_API_VERSION_3_0 के लिए:

एचएएल कैमरा डिवाइस प्रोसेसिंग पाइपलाइन को रीसेट करें और नई इनपुट और आउटपुट स्ट्रीम सेट अप करें. यह कॉल, किसी भी मौजूदा स्ट्रीम कॉन्फ़िगरेशन को stream_list में बताई गई स्ट्रीम से बदल देता है. initialize() के बाद, इस मेथड को कम से कम एक बार कॉल किया जाएगा. ऐसा, process_capture_request() के साथ अनुरोध सबमिट करने से पहले किया जाएगा .

stream_list में कम से कम एक ऐसी स्ट्रीम होनी चाहिए जिसमें आउटपुट दिया जा सके. साथ ही, इसमें एक से ज़्यादा ऐसी स्ट्रीम नहीं होनी चाहिए जिनमें इनपुट दिया जा सके.

stream_list में ऐसी स्ट्रीम शामिल हो सकती हैं जो स्ट्रीम के मौजूदा सेट में भी हैं (configure_stream() के पिछले कॉल से). इन स्ट्रीम में, इस्तेमाल, max_buffers, और निजी पॉइंटर के लिए पहले से मान्य वैल्यू होंगी.

अगर ऐसी स्ट्रीम के बफ़र पहले से रजिस्टर हैं, तो register_stream_buffers() को स्ट्रीम के लिए फिर से नहीं बुलाया जाएगा. साथ ही, स्ट्रीम के बफ़र को इनपुट अनुरोधों में तुरंत शामिल किया जा सकता है.

अगर नए कॉन्फ़िगरेशन की वजह से, एचएएल को किसी मौजूदा स्ट्रीम के लिए स्ट्रीम कॉन्फ़िगरेशन बदलना पड़ता है, तो वह कॉन्फ़िगर कॉल के दौरान, इस्तेमाल और/या max_buffers की वैल्यू को फिर से लिख सकता है.

फ़्रेमवर्क इस तरह के बदलाव का पता लगाएगा. इसके बाद, वह स्ट्रीम बफ़र को फिर से असाइन करेगा. साथ ही, किसी अनुरोध में उस स्ट्रीम के बफ़र का इस्तेमाल करने से पहले, register_stream_buffers() को फिर से कॉल करेगा.

अगर फ़िलहाल चल रही कोई स्ट्रीम, stream_list में शामिल नहीं है, तो एचएएल उस स्ट्रीम के सभी रेफ़रंस को सुरक्षित तरीके से हटा सकता है. फ़्रेमवर्क, बाद में configure() कॉल में इसका फिर से इस्तेमाल नहीं करेगा. साथ ही, configure_streams() कॉल के रिटर्न होने के बाद, इसके लिए सभी gralloc बफ़र खाली कर दिए जाएंगे.

stream_list स्ट्रक्चर का मालिकाना हक फ़्रेमवर्क के पास होता है. हो सकता है कि यह कॉल पूरा होने के बाद, इसे ऐक्सेस न किया जा सके. किसी एक camera3_stream_t स्ट्रक्चर का पता, HAL के ऐक्सेस के लिए तब तक मान्य रहेगा, जब तक पहले configure_stream() कॉल के खत्म होने तक stream_list आर्ग्युमेंट में वह camera3_stream_t शामिल नहीं होता. ऐसा हो सकता है कि एचएएल, निजी पॉइंटर के बाहर स्ट्रीम स्ट्रक्चर में वैल्यू न बदले. हालांकि, configure_streams() कॉल के दौरान, इस्तेमाल और max_buffers सदस्यों को छोड़कर ऐसा हो सकता है.

अगर स्ट्रीम नई है, तो स्ट्रीम स्ट्रक्चर के इस्तेमाल, max_buffer, और प्राइवेट पॉइंटर फ़ील्ड सभी 0 पर सेट हो जाएंगे. configure_streams() कॉल के रिटर्न होने से पहले, एचएएल डिवाइस को ये फ़ील्ड सेट करने होंगे. इसके बाद, फ़्रेमवर्क और प्लैटफ़ॉर्म के gralloc मॉड्यूल, इन फ़ील्ड का इस्तेमाल करके हर स्ट्रीम के लिए gralloc बफ़र को असाइन करते हैं.

किसी नई स्ट्रीम के बफ़र को कैप्चर करने के अनुरोध में शामिल करने से पहले, फ़्रेमवर्क उस स्ट्रीम के साथ register_stream_buffers() को कॉल करेगा. हालांकि, अनुरोध सबमिट करने से पहले, फ़्रेमवर्क को सभी स्ट्रीम के लिए बफ़र रजिस्टर करने की ज़रूरत नहीं है. इससे, झलक वाली स्ट्रीम को तुरंत शुरू किया जा सकता है. साथ ही, बाद में या एक साथ होने वाली अन्य स्ट्रीम के लिए भी जगह तय की जा सकती है.

सिर्फ़ CAMERA_DEVICE_API_VERSION_3_1 के लिए:

एचएएल कैमरा डिवाइस प्रोसेसिंग पाइपलाइन को रीसेट करें और नई इनपुट और आउटपुट स्ट्रीम सेट अप करें. यह कॉल, किसी भी मौजूदा स्ट्रीम कॉन्फ़िगरेशन को stream_list में बताई गई स्ट्रीम से बदल देता है. initialize() के बाद, इस मेथड को कम से कम एक बार कॉल किया जाएगा. ऐसा, process_capture_request() के साथ अनुरोध सबमिट करने से पहले किया जाएगा .

stream_list में कम से कम एक ऐसी स्ट्रीम होनी चाहिए जिसमें आउटपुट दिया जा सके. साथ ही, इसमें एक से ज़्यादा ऐसी स्ट्रीम नहीं होनी चाहिए जिनमें इनपुट दिया जा सके.

stream_list में ऐसी स्ट्रीम शामिल हो सकती हैं जो स्ट्रीम के मौजूदा सेट में भी हैं (configure_stream() के पिछले कॉल से). इन स्ट्रीम में, इस्तेमाल, max_buffers, और निजी पॉइंटर के लिए पहले से मान्य वैल्यू होंगी.

अगर ऐसी स्ट्रीम के बफ़र पहले से रजिस्टर हैं, तो register_stream_buffers() को स्ट्रीम के लिए फिर से नहीं बुलाया जाएगा. साथ ही, स्ट्रीम के बफ़र को इनपुट अनुरोधों में तुरंत शामिल किया जा सकता है.

अगर नए कॉन्फ़िगरेशन की वजह से, एचएएल को किसी मौजूदा स्ट्रीम के लिए स्ट्रीम कॉन्फ़िगरेशन बदलना पड़ता है, तो वह कॉन्फ़िगर कॉल के दौरान, इस्तेमाल और/या max_buffers की वैल्यू को फिर से लिख सकता है.

फ़्रेमवर्क इस तरह के बदलाव का पता लगाएगा. इसके बाद, वह स्ट्रीम बफ़र को फिर से असाइन करेगा. साथ ही, किसी अनुरोध में उस स्ट्रीम के बफ़र का इस्तेमाल करने से पहले, register_stream_buffers() को फिर से कॉल करेगा.

अगर फ़िलहाल चल रही कोई स्ट्रीम, stream_list में शामिल नहीं है, तो एचएएल उस स्ट्रीम के सभी रेफ़रंस को सुरक्षित तरीके से हटा सकता है. फ़्रेमवर्क, बाद में configure() कॉल में इसका फिर से इस्तेमाल नहीं करेगा. साथ ही, configure_streams() कॉल के रिटर्न होने के बाद, इसके लिए सभी gralloc बफ़र खाली कर दिए जाएंगे.

stream_list स्ट्रक्चर का मालिकाना हक फ़्रेमवर्क के पास होता है. हो सकता है कि यह कॉल पूरा होने के बाद, इसे ऐक्सेस न किया जा सके. किसी एक camera3_stream_t स्ट्रक्चर का पता, HAL के ऐक्सेस के लिए तब तक मान्य रहेगा, जब तक कि पहले configure_stream() कॉल के खत्म होने तक stream_list आर्ग्युमेंट में वह camera3_stream_t शामिल न हो. ऐसा हो सकता है कि एचएएल, निजी पॉइंटर के बाहर स्ट्रीम स्ट्रक्चर में वैल्यू न बदले. हालांकि, configure_streams() कॉल के दौरान, इस्तेमाल और max_buffers सदस्यों को छोड़कर ऐसा हो सकता है.

अगर स्ट्रीम नई है, तो स्ट्रीम स्ट्रक्चर के max_buffer और निजी पॉइंटर फ़ील्ड सभी 0 पर सेट हो जाएंगे. इस्तेमाल को उपभोक्ता के इस्तेमाल के फ़्लैग पर सेट किया जाएगा. configure_streams() कॉल के रिटर्न होने से पहले, एचएएल डिवाइस को ये फ़ील्ड सेट करने होंगे. इसके बाद, फ़्रेमवर्क और प्लैटफ़ॉर्म के gralloc मॉड्यूल, इन फ़ील्ड का इस्तेमाल करके हर स्ट्रीम के लिए gralloc बफ़र को असाइन करते हैं.

किसी नई स्ट्रीम के बफ़र को कैप्चर करने के अनुरोध में शामिल करने से पहले, फ़्रेमवर्क उस स्ट्रीम के साथ register_stream_buffers() को कॉल करेगा. हालांकि, अनुरोध सबमिट करने से पहले, फ़्रेमवर्क को सभी स्ट्रीम के लिए बफ़र रजिस्टर करने की ज़रूरत नहीं है. इससे, झलक वाली स्ट्रीम को तुरंत शुरू किया जा सकता है. साथ ही, बाद में या एक साथ होने वाली अन्य स्ट्रीम के लिए भी जगह तय की जा सकती है.

>= CAMERA_DEVICE_API_VERSION_3_2:

एचएएल कैमरा डिवाइस प्रोसेसिंग पाइपलाइन को रीसेट करें और नई इनपुट और आउटपुट स्ट्रीम सेट अप करें. यह कॉल, किसी भी मौजूदा स्ट्रीम कॉन्फ़िगरेशन को stream_list में बताई गई स्ट्रीम से बदल देता है. initialize() के बाद, इस मेथड को कम से कम एक बार कॉल किया जाएगा. ऐसा, process_capture_request() के साथ अनुरोध सबमिट करने से पहले किया जाएगा .

stream_list में कम से कम एक ऐसी स्ट्रीम होनी चाहिए जिसमें आउटपुट दिया जा सके. साथ ही, इसमें एक से ज़्यादा ऐसी स्ट्रीम नहीं होनी चाहिए जिनमें इनपुट दिया जा सके.

stream_list में ऐसी स्ट्रीम शामिल हो सकती हैं जो स्ट्रीम के मौजूदा सेट में भी हैं (configure_stream() के पिछले कॉल से). इन स्ट्रीम में, इस्तेमाल, max_buffers, और निजी पॉइंटर के लिए पहले से ही मान्य वैल्यू होंगी.

अगर नए कॉन्फ़िगरेशन की वजह से, एचएएल को किसी मौजूदा स्ट्रीम के लिए स्ट्रीम कॉन्फ़िगरेशन बदलना पड़ता है, तो वह कॉन्फ़िगर कॉल के दौरान, इस्तेमाल और/या max_buffers की वैल्यू को फिर से लिख सकता है.

फ़्रेमवर्क इस तरह के बदलाव का पता लगाएगा. इसके बाद, किसी अनुरोध में उस स्ट्रीम के बफ़र का इस्तेमाल करने से पहले, स्ट्रीम बफ़र को फिर से असाइन कर सकता है.

अगर फ़िलहाल चल रही कोई स्ट्रीम, stream_list में शामिल नहीं है, तो एचएएल उस स्ट्रीम के सभी रेफ़रंस को सुरक्षित तरीके से हटा सकता है. फ़्रेमवर्क, बाद में configure() कॉल में इसका फिर से इस्तेमाल नहीं करेगा. साथ ही, configure_streams() कॉल के रिटर्न होने के बाद, इसके लिए सभी gralloc बफ़र खाली कर दिए जाएंगे.

stream_list स्ट्रक्चर का मालिकाना हक फ़्रेमवर्क के पास होता है. हो सकता है कि यह कॉल पूरा होने के बाद, इसे ऐक्सेस न किया जा सके. किसी एक camera3_stream_t स्ट्रक्चर का पता, HAL के ऐक्सेस के लिए तब तक मान्य रहेगा, जब तक कि पहले configure_stream() कॉल के खत्म होने तक stream_list आर्ग्युमेंट में वह camera3_stream_t शामिल न हो. ऐसा हो सकता है कि एचएएल, निजी पॉइंटर के बाहर स्ट्रीम स्ट्रक्चर में वैल्यू न बदले. हालांकि, configure_streams() कॉल के दौरान, इस्तेमाल और max_buffers सदस्यों को छोड़कर ऐसा हो सकता है.

अगर स्ट्रीम नई है, तो स्ट्रीम स्ट्रक्चर के max_buffer और निजी पॉइंटर फ़ील्ड सभी 0 पर सेट हो जाएंगे. इस्तेमाल को उपभोक्ता के इस्तेमाल के फ़्लैग पर सेट किया जाएगा. configure_streams() कॉल के रिटर्न होने से पहले, एचएएल डिवाइस को ये फ़ील्ड सेट करने होंगे. इसके बाद, फ़्रेमवर्क और प्लैटफ़ॉर्म के gralloc मॉड्यूल, इन फ़ील्ड का इस्तेमाल करके हर स्ट्रीम के लिए gralloc बफ़र को असाइन करते हैं.

फ़्रेमवर्क, किसी भी समय कैप्चर के अनुरोध में नए बफ़र शामिल कर सकता है. जब कोई gralloc बफ़र, process_capture_result के साथ फ़्रेमवर्क में वापस आ जाता है (और उसके release_fence को सिग्नल मिल जाता है), तो फ़्रेमवर्क उसे किसी भी समय खाली कर सकता है या फिर से इस्तेमाल कर सकता है.

ज़रूरी शर्तें:

फ़्रेमवर्क इस तरीके को सिर्फ़ तब कॉल करेगा, जब कोई कैप्चर प्रोसेस नहीं किया जा रहा हो. इसका मतलब है कि सभी नतीजे फ़्रेमवर्क को दिखा दिए गए हैं. साथ ही, सभी इन-फ़्लाइट इनपुट और आउटपुट बफ़र दिखा दिए गए हैं और एचएएल ने उनकी रिलीज़ सिंक फ़ेंस के लिए सिग्नल भेज दिया है. configure_streams() कॉल चलने के दौरान, फ़्रेमवर्क कैप्चर के लिए नए अनुरोध सबमिट नहीं करेगा.

पोस्टकंडीशन:

एचएएल डिवाइस को अपने-आप कॉन्फ़िगर करना चाहिए, ताकि आउटपुट स्ट्रीम के साइज़ और फ़ॉर्मैट के हिसाब से ज़्यादा से ज़्यादा आउटपुट फ़्रेम रेट दिया जा सके. इस बारे में कैमरा डिवाइस के स्टैटिक मेटाडेटा में जानकारी दी गई है.

परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तें:

यह कॉल ज़्यादा समय ले सकता है और इसे पूरा होने में कई सौ मिलीसेकंड लग सकते हैं. ऐसा इसलिए, क्योंकि इसके लिए इमेज सेंसर और कैमरे की प्रोसेसिंग पाइपलाइन को रीसेट और फिर से कॉन्फ़िगर करना पड़ सकता है. इसके बावजूद, एचएएल डिवाइस को रीकॉन्फ़िगरेशन में लगने वाले समय को कम करने की कोशिश करनी चाहिए, ताकि ऐप्लिकेशन के ऑपरेशनल मोड में बदलाव (जैसे, स्टिल कैप्चर से वीडियो रिकॉर्डिंग पर स्विच करना) के दौरान, उपयोगकर्ता को दिखने वाले रुकावटों को कम किया जा सके.

HAL को इस कॉल से 500 मिलीसेकंड में और इस कॉल से 1000 मिलीसेकंड में वापस आ जाना चाहिए.

रिटर्न वैल्यू:

0: स्ट्रीम कॉन्फ़िगर होने पर

-EINVAL: अगर अनुरोध की गई स्ट्रीम का कॉन्फ़िगरेशन अमान्य है. अमान्य स्ट्रीम कॉन्फ़िगरेशन के कुछ उदाहरणों में ये शामिल हैं:

  • इनपुट की सुविधा वाली एक से ज़्यादा स्ट्रीम (INPUT या BIDIRECTIONAL) शामिल करना
  • आउटपुट की सुविधा वाली कोई स्ट्रीम (OUTPUT या BIDIRECTIONAL) शामिल न करना
  • ऐसी स्ट्रीम शामिल करना जिनका फ़ॉर्मैट काम नहीं करता या जिनका साइज़, फ़ॉर्मैट के हिसाब से सही नहीं है.
  • किसी फ़ॉर्मैट की बहुत ज़्यादा आउटपुट स्ट्रीम शामिल करना.
  • रोटेशन का ऐसा कॉन्फ़िगरेशन जो काम नहीं करता (सिर्फ़ उन डिवाइसों पर लागू होता है जिनका वर्शन CAMERA_DEVICE_API_VERSION_3_3 या उसके बाद का है)
  • स्ट्रीम के साइज़/फ़ॉर्मैट, नॉन-नॉर्मल मोड के लिए camera3_stream_configuration_t->operation_mode की ज़रूरी शर्तों को पूरा नहीं करते हैं या अनुरोध किया गया operation_mode, एचएएल के साथ काम नहीं करता. (सिर्फ़ उन डिवाइसों पर लागू होता है जिनका वर्शन CAMERA_DEVICE_API_VERSION_3_3 या इसके बाद का है)

ध्यान दें कि अमान्य स्ट्रीम कॉन्फ़िगरेशन सबमिट करने वाला फ़्रेमवर्क सामान्य नहीं है, क्योंकि कॉन्फ़िगर करने से पहले स्ट्रीम कॉन्फ़िगरेशन की जांच की जाती है. अमान्य कॉन्फ़िगरेशन का मतलब है कि फ़्रेमवर्क कोड में कोई गड़बड़ी है या HAL के स्टैटिक मेटाडेटा और स्ट्रीम की ज़रूरी शर्तों में कोई अंतर है.

-ENODEV: अगर कोई गंभीर गड़बड़ी हुई है और डिवाइस अब काम नहीं कर रहा है. गड़बड़ी का यह मैसेज मिलने के बाद, फ़्रेमवर्क सिर्फ़ close() को कॉल कर सकता है.

परिभाषा, फ़ाइल camera3.h की लाइन 2769 पर दी गई है.

const camera_metadata_t *(* construct_default_request_settings)(const struct camera3_device *, int type)

construct_default_request_settings:

कैमरे के इस्तेमाल के स्टैंडर्ड उदाहरणों के लिए, कैप्चर सेटिंग बनाएं.

डिवाइस को सेटिंग बफ़र दिखाना चाहिए, जो अनुरोध किए गए इस्तेमाल के उदाहरण को पूरा करने के लिए कॉन्फ़िगर किया गया हो. यह CAMERA3_TEMPLATE_* एनम में से किसी एक होना चाहिए. अनुरोध कंट्रोल के सभी फ़ील्ड शामिल होने चाहिए.

HAL के पास इस स्ट्रक्चर का मालिकाना हक बना रहता है. हालांकि, डिवाइस बंद होने तक स्ट्रक्चर का पॉइंटर मान्य होना चाहिए. इस कॉल से बफ़र वापस आने के बाद, हो सकता है कि फ़्रेमवर्क और एचएएल उसमें बदलाव न कर पाएं. एक ही टेंप्लेट या अन्य टेंप्लेट के लिए, बाद के कॉल के लिए वही बफ़र दिखाया जा सकता है.

परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तें:

यह कॉल ब्लॉक नहीं होना चाहिए. HAL को इस कॉल से 1 मिलीसेकंड में और इस कॉल से 5 मिलीसेकंड में वापस आना चाहिए.

रिटर्न वैल्यू:

मान्य मेटाडेटा: डिफ़ॉल्ट सेटिंग बफ़र बनाने के बाद.

NULL: गंभीर गड़बड़ी होने पर. यह वैल्यू मिलने के बाद, फ़्रेमवर्क सिर्फ़ close() मेथड को कॉल कर सकता है.

परिभाषा, camera3.h फ़ाइल की लाइन 2859 पर दी गई है.

void(* dump)(const struct camera3_device *, int fd)

डंप:

कैमरा डिवाइस के लिए, डीबग करने की स्थिति को प्रिंट करें. जब कैमरा सेवा से डीबग डंप के लिए कहा जाएगा, तब फ़्रेमवर्क इसे कॉल करेगा. ऐसा, dumpsys टूल का इस्तेमाल करने या बग रिपोर्ट कैप्चर करने पर होता है.

पास किए गए फ़ाइल डिस्क्रिप्टर का इस्तेमाल, dprintf() या write() का इस्तेमाल करके डीबगिंग टेक्स्ट लिखने के लिए किया जा सकता है. टेक्स्ट सिर्फ़ ASCII एन्कोडिंग में होना चाहिए.

परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तें:

यह कॉल, ब्लॉकिंग कॉल नहीं होना चाहिए. एचएएल को इस कॉल से 10 मिलीसेकंड में वापस आना चाहिए. इस कॉल में डेडलॉक से बचना ज़रूरी है, क्योंकि इसे कैमरे के ऑपरेशन के दौरान किसी भी समय कॉल किया जा सकता है. इस्तेमाल किए गए सिंक्रोनाइज़ेशन प्राइमिटिव (जैसे, म्यूटेक्स लॉक या सिग्नल) को टाइम आउट के साथ हासिल किया जाना चाहिए.

परिभाषा, camera3.h फ़ाइल की लाइन 2971 पर दी गई है .

int(* flush)(const struct camera3_device *)

flush:

दिए गए डिवाइस पर, फ़िलहाल प्रोसेस में चल रहे सभी कैप्चर और पाइपलाइन में मौजूद सभी बफ़र को फ़्लश करें. फ़्रेमवर्क, इसकी मदद से सभी स्टेटस को जल्द से जल्द डंप कर देगा, ताकि वह configure_streams() कॉल के लिए तैयार हो सके.

कोई भी बफ़र सही तरीके से वापस नहीं किया जाना चाहिए. इसलिए, flush() के समय सेव किया गया हर बफ़र (चाहे वह सही तरीके से भरा गया हो या नहीं) CAMERA3_BUFFER_STATUS_ERROR के साथ वापस किया जा सकता है. ध्यान दें कि इस कॉल के दौरान, एचएएल के पास मान्य (CAMERA3_BUFFER_STATUS_OK) बफ़र दिखाने की अनुमति अब भी है. हालांकि, इसके लिए ज़रूरी है कि बफ़र भर चुके हों.

फ़िलहाल, एचएएल में मौजूद सभी अनुरोधों को जल्द से जल्द वापस कर दिया जाएगा. जिन अनुरोधों को प्रोसेस नहीं किया जा रहा है उन्हें तुरंत गड़बड़ियों की जानकारी देनी चाहिए. जिन हार्डवेयर ब्लॉक को रोका जा सकता है उन्हें रोक दिया जाना चाहिए. साथ ही, जिन ब्लॉक को रोका नहीं जा सकता उनके लिए इंतज़ार करना चाहिए.

flush() को process_capture_request() के साथ एक साथ कॉल किया जा सकता है. ऐसा इसलिए किया जाता है, ताकि process_capture_request जल्दी रिटर्न हो और उस process_capture_request कॉल में सबमिट किए गए अनुरोध को, इन-फ़्लाइट के सभी अन्य अनुरोधों की तरह ही माना जाए. एक साथ कई काम करने से जुड़ी समस्याओं की वजह से, ऐसा हो सकता है कि HAL के हिसाब से, flush के शुरू होने के बाद, process_capture_request() कॉल शुरू हो जाए, लेकिन वह अभी तक रिटर्न न हुआ हो. अगर ऐसा कॉल, flush() के रिटर्न होने से पहले होता है, तो HAL को नए कैप्चर अनुरोध को, इन-फ़्लाइट के तौर पर मौजूद अन्य अनुरोधों की तरह ही माना जाना चाहिए (नीचे #4 देखें).

खास तौर पर, एचएएल को अलग-अलग मामलों में इन ज़रूरी शर्तों का पालन करना होगा:

  1. ऐसे कैप्चर के लिए जिन्हें एचएएल रद्द/बंद नहीं कर सकता और जो एचएएल के ज़रिए सामान्य रूप से पूरे हो जाएंगे. इसका मतलब है कि एचएएल, शटर/सूचना और process_capture_result और बफ़र को सामान्य रूप से भेज सकता है.
  2. जिन अनुरोधों को प्रोसेस नहीं किया गया है उनके लिए, एचएएल को CAMERA3_MSG_ERROR_REQUEST को सूचना देनी होगी. साथ ही, process_capture_result के साथ सभी आउटपुट बफ़र को गड़बड़ी की स्थिति (CAMERA3_BUFFER_STATUS_ERROR) में दिखाना होगा. एचएएल को रिलीज़ फ़ेंस को गड़बड़ी की स्थिति में नहीं रखना चाहिए. इसके बजाय, रिलीज़ फ़ेंस को फ़्रेमवर्क से पास किए गए हासिल करने वाले फ़ेंस पर सेट किया जाना चाहिए या अगर एचएएल ने पहले ही उनका इंतज़ार किया है, तो -1 पर सेट किया जाना चाहिए. यह उन सभी कैप्चर के लिए भी सही पाथ है जिनके लिए एचएएल ने पहले ही CAMERA3_MSG_SHUTTER के साथ notify() को कॉल किया है, लेकिन जिनके लिए कोई मेटाडेटा/मान्य बफ़र नहीं जनरेट किया जाएगा. CAMERA3_MSG_ERROR_REQUEST के बाद, किसी फ़्रेम के लिए सिर्फ़ CAMERA3_BUFFER_STATUS_ERROR में बफ़र के साथ process_capture_results की अनुमति है. नॉन-शून्य मेटाडेटा के साथ, notifys या process_capture_result का कोई और इस्तेमाल करने की अनुमति नहीं है.

  3. जिन अनुरोधों को पूरा नहीं किया गया है और जिनमें सभी आउटपुट बफ़र या मेटाडेटा मौजूद नहीं है उनके लिए, एचएएल को यह तरीका अपनाना चाहिए:

    3.1. अगर कैप्चर के लिए, उम्मीद के मुताबिक कुछ मेटाडेटा (जैसे, एक या उससे ज़्यादा मेटाडेटा का कुछ हिस्सा) उपलब्ध नहीं होगा, तो CAMERA3_MSG_ERROR_RESULT के साथ notify को कॉल करें.

    3.2. कैप्चर के लिए जनरेट नहीं किए जाने वाले हर बफ़र के लिए, CAMERA3_MSG_ERROR_BUFFER के साथ notify को कॉल करें.

    3.3 process_capture_result के साथ कोई भी बफ़र/मेटाडेटा लौटाए जाने से पहले, CAMERA3_MSG_SHUTTER के साथ शटर के खुलने के समय की जानकारी दें.

    3.4 कुछ नतीजे देने वाले कैप्चर के लिए, एचएएल को CAMERA3_MSG_ERROR_REQUEST को कॉल नहीं करना चाहिए, क्योंकि इससे पूरी तरह से फ़ाइल न बनने का पता चलता है.

    3.5. मान्य बफ़र/मेटाडेटा को फ़्रेमवर्क में सामान्य तरीके से पास किया जाना चाहिए.

    3.6. दूसरे मामले में बताए गए तरीके से, काम न करने वाले बफ़र को फ़्रेमवर्क में वापस लाया जाना चाहिए. हालांकि, अमान्य बफ़र को मान्य बफ़र की तरह क्रम में नहीं रखा जाता. साथ ही, ये मान्य बफ़र के मुकाबले क्रम से बाहर हो सकते हैं. उदाहरण के लिए, अगर बफ़र A, B, C, D, E भेजे जाते हैं और D और E काम नहीं करते, तो A, E, B, D, C का क्रम, बफ़र वापस करने का सही क्रम है.

    3.7. अगर मेटाडेटा पूरी तरह से मौजूद नहीं है, तो CAMERA3_MSG_ERROR_RESULT को कॉल करना ही काफ़ी है. इसके लिए, NULL मेटाडेटा या मिलते-जुलते मेटाडेटा के साथ process_capture_result को कॉल करने की ज़रूरत नहीं है.

  4. अगर process_capture_request() का आह्वान चालू होने के दौरान, flush() का आह्वान किया जाता है, तो प्रोसेस कॉल को जल्द से जल्द वापस आना चाहिए. इसके अलावा, अगर flush() को कॉल करने के बाद, process_capture_request() को कॉल किया जाता है, लेकिन flush() के रिटर्न होने से पहले, तो देर से किए गए process_capture_request कॉल से मिले कैप्चर अनुरोध को ऊपर दिए गए केस #2 में, लंबित अनुरोध की तरह माना जाना चाहिए.

flush() सिर्फ़ तब रिटर्न होना चाहिए, जब HAL में कोई बफ़र या अनुरोध न बचा हो. फ़्रेमवर्क, configure_streams को कॉल कर सकता है (क्योंकि HAL की स्थिति अब शांत है) या नए अनुरोध जारी कर सकता है.

ध्यान दें कि सिर्फ़ पूरी तरह से काम करने वाले और पूरी तरह से काम न करने वाले नतीजों के मामलों के लिए, यह सुविधा काफ़ी है. हालांकि, कुछ मामलों में फ़्लश कॉल पूरा न होने पर भी, फ़्लश कॉल को पूरा करने में मदद मिल सकती है. इससे फ़्लश कॉल की परफ़ॉर्मेंस बेहतर हो सकती है.

परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तें:

HAL को इस कॉल से 100 मिलीसेकंड में और इस कॉल से 1, 000 मिलीसेकंड में वापस आ जाना चाहिए. साथ ही, यह कॉल, पाइपलाइन में लगने वाले समय से ज़्यादा समय तक ब्लॉक नहीं किया जाना चाहिए. इसकी परिभाषा के लिए S7 देखें.

वर्शन की जानकारी:

यह सिर्फ़ तब उपलब्ध है, जब डिवाइस का वर्शन CAMERA_DEVICE_API_VERSION_3_1 या इससे ज़्यादा हो.

रिटर्न वैल्यू:

0: कैमरा एचएएल फ़्लश होने पर.

-EINVAL: अगर इनपुट गलत है (डिवाइस मान्य नहीं है).

-ENODEV: अगर कैमरा डिवाइस में कोई गंभीर गड़बड़ी हुई है. यह गड़बड़ी दिखने के बाद, फ़्रेमवर्क सिर्फ़ close() तरीके को कॉल कर सकता है.

परिभाषा, camera3.h फ़ाइल की लाइन 3077 पर दी गई है.

void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, vendor_tag_query_ops_t *ops)

get_metadata_vendor_tag_ops:

वेंडर एक्सटेंशन मेटाडेटा टैग की जानकारी के लिए क्वेरी करने के तरीके जानें. एचएएल को वेंडर टैग के सभी ऑपरेशन के तरीके भरने चाहिए. अगर कोई वेंडर टैग तय नहीं किया गया है, तो ऑपरेशन में कोई बदलाव नहीं किया जाना चाहिए.

vendor_tag_query_ops_t की परिभाषा, system/media/camera/include/system/camera_metadata.h में देखी जा सकती है.

>= CAMERA_DEVICE_API_VERSION_3_2: अब काम नहीं करता. इस फ़ंक्शन का इस्तेमाल बंद कर दिया गया है. इसे HAL की मदद से NULL पर सेट किया जाना चाहिए. इसके बजाय, कृपया camera_common.h में get_vendor_tag_ops को लागू करें.

परिभाषा, फ़ाइल के camera3.h की लाइन 2950 पर दी गई है.

int(* initialize)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops)

initialize:

एचएएल को फ़्रेमवर्क कॉलबैक फ़ंक्शन के पॉइंटर पास करने के लिए, एक बार शुरू किया जाने वाला प्रोसेस. open() फ़ंक्शन के सही तरीके से काम करने के बाद, इसे एक बार कॉल किया जाएगा. इसके बाद ही, camera3_device_ops स्ट्रक्चर पर किसी दूसरे फ़ंक्शन को कॉल किया जाएगा.

परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तें:

यह कॉल ब्लॉक नहीं होना चाहिए. HAL को इस कॉल से 5 मिलीसेकंड में और इस कॉल से 10 मिलीसेकंड में वापस आना चाहिए.

रिटर्न वैल्यू:

0: इंटिग्रेशन पूरा होने पर

-ENODEV: अगर प्रोसेस शुरू नहीं हो पाती. इसके बाद, फ़्रेमवर्क सिर्फ़ close() को कॉल कर सकता है.

परिभाषा, camera3.h फ़ाइल की लाइन 2530 पर दी गई है .

int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *request)

process_capture_request:

एचएएल को कैप्चर करने का नया अनुरोध भेजें. HAL को इस कॉल से तब तक नहीं लौटना चाहिए, जब तक वह प्रोसेस करने के लिए अगला अनुरोध स्वीकार करने के लिए तैयार न हो. फ़्रेमवर्क एक बार में, process_capture_request() पर सिर्फ़ एक कॉल करेगा. साथ ही, सभी कॉल एक ही थ्रेड से किए जाएंगे. नया अनुरोध और उससे जुड़े बफ़र उपलब्ध होते ही, process_capture_request() के लिए अगला कॉल किया जाएगा. आम तौर पर, झलक देखने के दौरान, फ़्रेमवर्क फ़ंक्शन को तुरंत फिर से कॉल करेगा.

अनुरोध को प्रोसेस करने की असल प्रोसेस असाइनक्रोनस होती है. इसमें, HAL, process_capture_result() कॉल के ज़रिए कैप्चर के नतीजे दिखाता है. इस कॉल के लिए, नतीजे का मेटाडेटा उपलब्ध होना ज़रूरी है. हालांकि, आउटपुट बफ़र में, सिंक करने के लिए फ़ेंस की सुविधा मिल सकती है. आउटपुट फ़्रेम रेट को बनाए रखने के लिए, एक साथ कई अनुरोध किए जा सकते हैं.

अनुरोध के स्ट्रक्चर का मालिकाना हक, फ़्रेमवर्क के पास ही रहता है. यह सिर्फ़ इस कॉल के दौरान मान्य होगा. HAL डिवाइस को उस जानकारी की कॉपी बनानी होगी जिसे कैप्चर करने की प्रोसेस के लिए सेव रखना है. बफ़र के फ़ेंस के बंद होने का इंतज़ार करने और उन्हें बंद करने के साथ-साथ, फ़्रेमवर्क को बफ़र हैंडल वापस करने की ज़िम्मेदारी एचएएल की होती है.

अगर input_buffer NULL नहीं है, तो HAL को input_buffer->release_fence में, इनपुट बफ़र के रिलीज़ सिंक फ़ेंस के लिए फ़ाइल डिस्क्रिप्टर लिखना होगा. अगर एचएएल, इनपुट बफ़र रिलीज़ सिंक फ़ेंस के लिए -1 दिखाता है, तो फ़्रेमवर्क इनपुट बफ़र का तुरंत फिर से इस्तेमाल कर सकता है. ऐसा न करने पर, फ़्रेमवर्क इनपुट बफ़र को फिर से भरने और उसका फिर से इस्तेमाल करने से पहले, सिंक फ़ेंस पर इंतज़ार करेगा.

>= CAMERA_DEVICE_API_VERSION_3_2:

हर अनुरोध में फ़्रेमवर्क से दिए गए इनपुट/आउटपुट बफ़र, बिलकुल नए हो सकते हैं. इन बफ़र को HAL ने पहले कभी नहीं देखा होगा.

परफ़ॉर्मेंस से जुड़ी बातें:

नए बफ़र को मैनेज करना बहुत आसान होना चाहिए. साथ ही, फ़्रेम रेट में कोई गिरावट नहीं आनी चाहिए या फ़्रेम में कोई झटका नहीं आना चाहिए.

यह कॉल इतनी तेज़ी से रिटर्न होना चाहिए कि यह पक्का किया जा सके कि अनुरोध किया गया फ़्रेम रेट बरकरार रखा जा सकता है. ऐसा खास तौर पर स्ट्रीमिंग के मामलों में होता है, जब पोस्ट-प्रोसेसिंग क्वालिटी की सेटिंग 'फ़ास्ट' पर सेट होती है. एचएएल को इस कॉल को एक फ़्रेम इंटरवल में रिटर्न करना चाहिए और इस कॉल से चार फ़्रेम इंटरवल में वापस आना चाहिए.

रिटर्न वैल्यू:

0: कैप्चर करने के अनुरोध को प्रोसेस करने की प्रोसेस शुरू होने पर

-EINVAL: अगर इनपुट गलत है (अनुमति न होने पर सेटिंग NULL हैं, 0 आउटपुट बफ़र हैं वगैरह) और कैप्चर प्रोसेसिंग शुरू नहीं हो पा रही है. अनुरोध प्रोसेस करने के दौरान होने वाली गड़बड़ियों को ठीक करने के लिए, camera3_callback_ops_t.notify() को कॉल करें . इस गड़बड़ी के मामले में, फ़्रेमवर्क, स्ट्रीम बफ़र के फ़ेंस और बफ़र हैंडल की ज़िम्मेदारी बनाए रखेगा. एचएएल को फ़ेंस बंद नहीं करने चाहिए या process_capture_result के साथ इन बफ़र को नहीं दिखाना चाहिए.

-ENODEV: अगर कैमरा डिवाइस में कोई गंभीर गड़बड़ी हुई है. यह गड़बड़ी दिखने के बाद, फ़्रेमवर्क सिर्फ़ close() तरीके को कॉल कर सकता है.

परिभाषा, फ़ाइल camera3.h की लाइन 2928 पर दी गई है.

int(* register_stream_buffers)(const struct camera3_device *, const camera3_stream_buffer_set_t *buffer_set)

register_stream_buffers:

>= CAMERA_DEVICE_API_VERSION_3_2:

अब काम नहीं करता. इसे कॉल नहीं किया जाएगा और इसे NULL पर सेट करना होगा.

<= CAMERA_DEVICE_API_VERSION_3_1:

HAL डिवाइस के साथ किसी स्ट्रीम के लिए बफ़र रजिस्टर करना. इस तरीके को फ़्रेमवर्क तब कॉल करता है, जब configure_streams से कोई नई स्ट्रीम तय की जाती है और उस स्ट्रीम के बफ़र को कैप्चर करने के अनुरोध में शामिल करने से पहले. अगर उसी स्ट्रीम को बाद में configure_streams() कॉल में शामिल किया जाता है, तो उस स्ट्रीम के लिए register_stream_buffers को फिर से नहीं बुलाया जाएगा जाएगा.

फ़्रेमवर्क को कैप्चर करने का पहला अनुरोध सबमिट करने से पहले, कॉन्फ़िगर की गई सभी स्ट्रीम के लिए बफ़र रजिस्टर करने की ज़रूरत नहीं होती. इससे, झलक देखने या मिलते-जुलते इस्तेमाल के उदाहरणों के लिए, तुरंत स्टार्टअप की सुविधा मिलती है. ऐसा तब होता है, जब अन्य स्ट्रीम को अभी तक ऐलोकेट नहीं किया गया है.

इस तरीके का मकसद, एचएएल डिवाइस को बाद में इस्तेमाल करने के लिए, बफ़र को मैप करने या अन्य तरीके से तैयार करने की अनुमति देना है. इस्तेमाल के लिए, पहले से ही बफ़र लॉक कर दिए जाएंगे. कॉल खत्म होने पर, सभी बफ़र स्ट्रीम में वापस आ जाने चाहिए. buffer_set आर्ग्युमेंट सिर्फ़ इस कॉल के दौरान मान्य होता है.

अगर स्ट्रीम फ़ॉर्मैट को HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED पर सेट किया गया था, तो कैमरा एचएएल को यहां पास किए गए बफ़र की जांच करनी चाहिए, ताकि प्लैटफ़ॉर्म के निजी पिक्सल फ़ॉर्मैट की जानकारी का पता लगाया जा सके.

परफ़ॉर्मेंस से जुड़ी ज़रूरी शर्तें:

यह कॉल ब्लॉक नहीं होना चाहिए. HAL को इस कॉल से 1 मिलीसेकंड में और इस कॉल से 5 मिलीसेकंड में वापस आना चाहिए.

रिटर्न वैल्यू:

0: नई स्ट्रीम बफ़र के रजिस्ट्रेशन के पूरा होने पर

-EINVAL: अगर stream_buffer_set किसी मान्य चालू स्ट्रीम का रेफ़रंस नहीं देता है या बफ़र कलेक्शन अमान्य है.

-ENOMEM: अगर बफ़र रजिस्टर करने में कोई गड़बड़ी हुई. फ़्रेमवर्क को सभी स्ट्रीम बफ़र को अनरजिस्टर माना जाना चाहिए और बाद में फिर से रजिस्टर करने की कोशिश की जा सकती है.

-ENODEV: अगर कोई गंभीर गड़बड़ी होती है और डिवाइस काम नहीं कर रहा है. गड़बड़ी का यह मैसेज मिलने के बाद, फ़्रेमवर्क सिर्फ़ close() को कॉल कर सकता है.

परिभाषा, camera3.h फ़ाइल की लाइन 2823 पर दी गई है.

void* reserved[8]

परिभाषा, फ़ाइल के camera3.h की लाइन 3080 पर दी गई है .

इस स्ट्रक्चर का दस्तावेज़, इस फ़ाइल से जनरेट किया गया था: