कैमरा3_डिवाइस_ऑप्स संरचना संदर्भ

कैमरा3_डिवाइस_ऑप्स संरचना संदर्भ

#include < camera3.h >

डेटा फ़ील्ड

पूर्णांक(* प्रारंभ करें )(स्थिरांक स्ट्रक्चर कैमरा3_डिवाइस *, स्थिरांक कैमरा3_कॉलबैक_ऑप्स_टी *कॉलबैक_ऑप्स)
पूर्णांक(* कॉन्फ़िगर_स्ट्रीम )(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *, कैमरा3_स्ट्रीम_कॉन्फ़िगरेशन_टी *स्ट्रीम_लिस्ट)
पूर्णांक(* रजिस्टर_स्ट्रीम_बफ़र्स )(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *, कास्ट कैमरा3_स्ट्रीम_बफ़र_सेट_टी *बफ़र_सेट)
स्थिरांक कैमरा_मेटाडेटा_t *(* कन्स्ट्रक्ट_डिफॉल्ट_रेक्वेस्ट_सेटिंग्स )(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *, इंट टाइप)
पूर्णांक(* प्रोसेस_कैप्चर_रिक्वेस्ट )(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *, कैमरा3_कैप्चर_रिक्वेस्ट_टी *रिक्वेस्ट)
खालीपन(* get_metadata_vendor_tag_ops )(const struct कैमरा3_डिवाइस *, वेंडर_टैग_क्वेरी_ops_t *ops)
खालीपन(* डंप )(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *, इंट एफडी)
पूर्णांक(* फ्लश )(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *)
खालीपन * आरक्षित [8]

विस्तृत विवरण

कैमरा3.एच फ़ाइल की पंक्ति 2509 पर परिभाषा।

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

int(* config_streams)(स्थिरांक संरचना कैमरा3_डिवाइस *, कैमरा3_स्ट्रीम_कॉन्फिगरेशन_टी *स्ट्रीम_लिस्ट)

कॉन्फ़िगर_स्ट्रीम:

केवल CAMERA_DEVICE_API_VERSION_3_0:

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

स्ट्रीम_लिस्ट में कम से कम एक आउटपुट-सक्षम स्ट्रीम होनी चाहिए, और एक से अधिक इनपुट-सक्षम स्ट्रीम नहीं हो सकती है।

स्ट्रीम_लिस्ट में ऐसी स्ट्रीम शामिल हो सकती हैं जो स्ट्रीम के वर्तमान-सक्रिय सेट में भी हैं (पिछली कॉल से config_stream() तक)। इन स्ट्रीम में उपयोग, max_buffers और प्राइवेट पॉइंटर के लिए पहले से ही मान्य मान होंगे।

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

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

फ्रेमवर्क इस तरह के बदलाव का पता लगाएगा, और फिर स्ट्रीम बफ़र्स को फिर से आवंटित करेगा, और अनुरोध में उस स्ट्रीम से बफ़र्स का उपयोग करने से पहले रजिस्टर_स्ट्रीम_बफ़र्स() को फिर से कॉल करेगा।

यदि वर्तमान में सक्रिय स्ट्रीम स्ट्रीम_लिस्ट में शामिल नहीं है, तो एचएएल उस स्ट्रीम के किसी भी संदर्भ को सुरक्षित रूप से हटा सकता है। इसे फ्रेमवर्क द्वारा बाद में कॉन्फ़िगर() कॉल में पुन: उपयोग नहीं किया जाएगा, और इसके लिए सभी ग्रैलोक बफ़र्स config_streams() कॉल रिटर्न के बाद मुक्त कर दिए जाएंगे।

स्ट्रीम_लिस्ट संरचना फ्रेमवर्क के स्वामित्व में है, और इस कॉल के पूरा होने के बाद इसे एक्सेस नहीं किया जा सकता है। एक व्यक्तिगत कैमरा3_स्ट्रीम_टी संरचना का पता पहले कॉन्फ़िगर_स्ट्रीम() कॉल के अंत तक एचएएल द्वारा पहुंच के लिए मान्य रहेगा, जिसमें अब स्ट्रीम_लिस्ट तर्क में कैमरा3_स्ट्रीम_टी शामिल नहीं है। config_streams() कॉल के दौरान उपयोग और max_buffers सदस्यों को छोड़कर, HAL निजी पॉइंटर के बाहर स्ट्रीम संरचना में मान नहीं बदल सकता है।

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

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


केवल CAMERA_DEVICE_API_VERSION_3_1:

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

स्ट्रीम_लिस्ट में कम से कम एक आउटपुट-सक्षम स्ट्रीम होनी चाहिए, और एक से अधिक इनपुट-सक्षम स्ट्रीम नहीं हो सकती है।

स्ट्रीम_लिस्ट में ऐसी स्ट्रीम शामिल हो सकती हैं जो स्ट्रीम के वर्तमान-सक्रिय सेट में भी हैं (पिछली कॉल से config_stream() तक)। इन स्ट्रीम में उपयोग, max_buffers और प्राइवेट पॉइंटर के लिए पहले से ही मान्य मान होंगे।

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

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

फ्रेमवर्क इस तरह के बदलाव का पता लगाएगा, और फिर स्ट्रीम बफ़र्स को फिर से आवंटित करेगा, और अनुरोध में उस स्ट्रीम से बफ़र्स का उपयोग करने से पहले रजिस्टर_स्ट्रीम_बफ़र्स() को फिर से कॉल करेगा।

यदि वर्तमान में सक्रिय स्ट्रीम स्ट्रीम_लिस्ट में शामिल नहीं है, तो एचएएल उस स्ट्रीम के किसी भी संदर्भ को सुरक्षित रूप से हटा सकता है। इसे फ्रेमवर्क द्वारा बाद में कॉन्फ़िगर() कॉल में पुन: उपयोग नहीं किया जाएगा, और इसके लिए सभी ग्रैलोक बफ़र्स config_streams() कॉल रिटर्न के बाद मुक्त कर दिए जाएंगे।

स्ट्रीम_लिस्ट संरचना फ्रेमवर्क के स्वामित्व में है, और इस कॉल के पूरा होने के बाद इसे एक्सेस नहीं किया जा सकता है। एक व्यक्तिगत कैमरा3_स्ट्रीम_टी संरचना का पता पहले कॉन्फ़िगर_स्ट्रीम() कॉल के अंत तक एचएएल द्वारा पहुंच के लिए मान्य रहेगा, जिसमें अब स्ट्रीम_लिस्ट तर्क में कैमरा3_स्ट्रीम_टी शामिल नहीं है। config_streams() कॉल के दौरान उपयोग और max_buffers सदस्यों को छोड़कर, HAL निजी पॉइंटर के बाहर स्ट्रीम संरचना में मान नहीं बदल सकता है।

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

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


>= CAMERA_DEVICE_API_VERSION_3_2:

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

स्ट्रीम_लिस्ट में कम से कम एक आउटपुट-सक्षम स्ट्रीम होनी चाहिए, और एक से अधिक इनपुट-सक्षम स्ट्रीम नहीं हो सकती है।

स्ट्रीम_लिस्ट में ऐसी स्ट्रीम शामिल हो सकती हैं जो स्ट्रीम के वर्तमान-सक्रिय सेट में भी हैं (पिछली कॉल से config_stream() तक)। इन स्ट्रीम में उपयोग, max_buffers और प्राइवेट पॉइंटर के लिए पहले से ही मान्य मान होंगे।

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

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

यदि वर्तमान में सक्रिय स्ट्रीम स्ट्रीम_लिस्ट में शामिल नहीं है, तो एचएएल उस स्ट्रीम के किसी भी संदर्भ को सुरक्षित रूप से हटा सकता है। इसे फ्रेमवर्क द्वारा बाद में कॉन्फ़िगर() कॉल में पुन: उपयोग नहीं किया जाएगा, और इसके लिए सभी ग्रैलोक बफ़र्स config_streams() कॉल रिटर्न के बाद मुक्त कर दिए जाएंगे।

स्ट्रीम_लिस्ट संरचना फ्रेमवर्क के स्वामित्व में है, और इस कॉल के पूरा होने के बाद इसे एक्सेस नहीं किया जा सकता है। एक व्यक्तिगत कैमरा3_स्ट्रीम_टी संरचना का पता पहले कॉन्फ़िगर_स्ट्रीम() कॉल के अंत तक एचएएल द्वारा पहुंच के लिए मान्य रहेगा, जिसमें अब स्ट्रीम_लिस्ट तर्क में कैमरा3_स्ट्रीम_टी शामिल नहीं है। config_streams() कॉल के दौरान उपयोग और max_buffers सदस्यों को छोड़कर, HAL निजी पॉइंटर के बाहर स्ट्रीम संरचना में मान नहीं बदल सकता है।

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

नए आवंटित बफ़र्स को फ्रेमवर्क द्वारा किसी भी समय कैप्चर अनुरोध में शामिल किया जा सकता है। एक बार जब ग्रैलोक बफर को प्रोसेस_कैप्चर_रिजल्ट (और इसके संबंधित रिलीज_फेंस को संकेत दिया गया है) के साथ फ्रेमवर्क में वापस कर दिया जाता है, तो फ्रेमवर्क इसे किसी भी समय मुक्त या पुन: उपयोग कर सकता है।


पूर्व शर्ते:

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

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

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

प्रदर्शन संबंधी जरूरतें:

यह कॉल भारी होने की उम्मीद है और संभवतः इसे पूरा होने में कई सौ मिलीसेकंड लगेंगे, क्योंकि इसमें छवि सेंसर और कैमरा प्रोसेसिंग पाइपलाइन को रीसेट और पुन: कॉन्फ़िगर करने की आवश्यकता हो सकती है। फिर भी, एचएएल डिवाइस को एप्लिकेशन परिचालन मोड में बदलाव (जैसे स्टिल कैप्चर से वीडियो रिकॉर्डिंग पर स्विच करना) के दौरान उपयोगकर्ता-दृश्यमान रुकावटों को कम करने के लिए पुन: कॉन्फ़िगरेशन विलंब को कम करने का प्रयास करना चाहिए।

एचएएल को इस कॉल से 500 एमएस में वापस आना चाहिए, और इस कॉल से 1000 एमएस में वापस आना चाहिए।

वापसी मान:

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

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

  • 1 से अधिक इनपुट-सक्षम स्ट्रीम (इनपुट या द्विदिशात्मक) शामिल है
  • कोई भी आउटपुट-सक्षम स्ट्रीम (आउटपुट या द्विदिशात्मक) शामिल नहीं है
  • असमर्थित प्रारूप वाली स्ट्रीम, या उस प्रारूप के लिए असमर्थित आकार शामिल करना।
  • एक निश्चित प्रारूप की बहुत सारी आउटपुट स्ट्रीम शामिल करना।
  • असमर्थित रोटेशन कॉन्फ़िगरेशन (केवल संस्करण >= CAMERA_DEVICE_API_VERSION_3_3 वाले उपकरणों पर लागू होता है)
  • स्ट्रीम आकार/प्रारूप गैर-सामान्य मोड के लिए कैमरा3_स्ट्रीम_कॉन्फिगरेशन_टी->ऑपरेशन_मोड आवश्यकताओं को पूरा नहीं करते हैं, या अनुरोधित ऑपरेशन_मोड एचएएल द्वारा समर्थित नहीं है। (केवल संस्करण >= CAMERA_DEVICE_API_VERSION_3_3 वाले उपकरणों पर लागू होता है)

ध्यान दें कि अमान्य स्ट्रीम कॉन्फ़िगरेशन सबमिट करने वाला फ़्रेमवर्क सामान्य ऑपरेशन नहीं है, क्योंकि कॉन्फ़िगर करने से पहले स्ट्रीम कॉन्फ़िगरेशन की जाँच की जाती है। अमान्य कॉन्फ़िगरेशन का मतलब है कि फ़्रेमवर्क कोड में एक बग मौजूद है, या एचएएल के स्थिर मेटाडेटा और स्ट्रीम पर आवश्यकताओं के बीच एक बेमेल है।

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

कैमरा3.एच फ़ाइल की पंक्ति 2769 पर परिभाषा।

कॉन्स्ट कैमरा_मेटाडेटा_टी *(* कन्स्ट्रक्ट_डिफॉल्ट_रेक्वेस्ट_सेटिंग्स)(कास्ट स्ट्रक्चर कैमरा3_डिवाइस *, इंट टाइप)

निर्माण_डिफ़ॉल्ट_अनुरोध_सेटिंग्स:

मानक कैमरा उपयोग के मामलों के लिए कैप्चर सेटिंग्स बनाएं।

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

एचएएल इस संरचना का स्वामित्व बरकरार रखता है, लेकिन डिवाइस बंद होने तक संरचना का सूचक वैध होना चाहिए। इस कॉल द्वारा लौटाए जाने के बाद फ्रेमवर्क और एचएएल बफर को संशोधित नहीं कर सकते हैं। उसी टेम्पलेट के लिए या अन्य टेम्पलेट्स के लिए बाद की कॉल के लिए वही बफर लौटाया जा सकता है।

प्रदर्शन संबंधी जरूरतें:

यह एक नॉन-ब्लॉकिंग कॉल होनी चाहिए. एचएएल को इस कॉल से 1ms में वापस आना चाहिए, और इस कॉल से 5ms में वापस आना चाहिए।

वापसी मान:

वैध मेटाडेटा: डिफ़ॉल्ट सेटिंग्स बफ़र के सफल निर्माण पर।

शून्य: किसी घातक त्रुटि के मामले में. इसके वापस आने के बाद, फ्रेमवर्क द्वारा केवल क्लोज़() विधि को सफलतापूर्वक कॉल किया जा सकता है।

कैमरा3.एच फ़ाइल की पंक्ति 2859 पर परिभाषा।

शून्य(* डंप)(स्थिरांक struct कैमरा3_डिवाइस *, इंट एफडी)

गंदी जगह:

कैमरा डिवाइस के लिए डिबगिंग स्थिति का प्रिंट आउट लें। इसे फ़्रेमवर्क द्वारा तब कॉल किया जाएगा जब कैमरा सेवा से डिबग डंप के लिए कहा जाएगा, जो डंपसिस टूल का उपयोग करते समय, या बग्रेपोर्ट कैप्चर करते समय होता है।

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

प्रदर्शन संबंधी जरूरतें:

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

कैमरा3.एच फ़ाइल की पंक्ति 2971 पर परिभाषा।

int(* फ्लश)(कास्ट स्ट्रक्चर कैमरा3_डिवाइस *)

फ्लश:

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

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

एचएएल में वर्तमान में सभी अनुरोधों को यथाशीघ्र लौटाए जाने की उम्मीद है। प्रक्रिया में नहीं होने वाले अनुरोधों में त्रुटियां तुरंत वापस आनी चाहिए। किसी भी व्यवधानकारी हार्डवेयर ब्लॉक को रोका जाना चाहिए, और किसी भी निर्बाध ब्लॉक की प्रतीक्षा की जानी चाहिए।

फ्लश() को प्रोसेस_कैप्चर_रेक्वेस्ट() पर समवर्ती रूप से कॉल किया जा सकता है, इस उम्मीद के साथ कि प्रोसेस_कैप्चर_रेक्वेस्ट जल्दी वापस आ जाएगा और उस प्रोसेस_कैप्चर_रेक्वेस्ट कॉल में सबमिट किए गए अनुरोध को अन्य सभी इन-फ़्लाइट अनुरोधों की तरह माना जाएगा। समवर्ती मुद्दों के कारण, यह संभव है कि एचएएल के दृष्टिकोण से, एक प्रोसेस_कैप्चर_रेक्वेस्ट() कॉल फ्लश लागू होने के बाद शुरू हो सकती है लेकिन अभी तक वापस नहीं आई है। यदि ऐसी कोई कॉल फ्लश() रिटर्न से पहले होती है, तो एचएएल को नए कैप्चर अनुरोध को अन्य इन-फ़्लाइट लंबित अनुरोधों की तरह मानना ​​चाहिए (नीचे #4 देखें)।

अधिक विशेष रूप से, एचएएल को विभिन्न मामलों के लिए निम्नलिखित आवश्यकताओं का पालन करना होगा:

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

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

    3.2. कैप्चर के लिए उत्पादित नहीं किए जाने वाले प्रत्येक बफ़र के लिए CAMERA3_MSG_ERROR_BUFFER के साथ कॉल सूचित करें।

    3.3 किसी भी बफ़र्स/मेटाडेटा को प्रोसेस_कैप्चर_रिजल्ट के साथ वापस करने से पहले कैप्चर टाइमस्टैम्प के साथ CAMERA3_MSG_SHUTTER के साथ कॉल को सूचित करें।

    3.4 कैप्चर के लिए जो कुछ परिणाम देगा, एचएएल को CAMERA3_MSG_ERROR_REQUEST को कॉल नहीं करना चाहिए, क्योंकि यह पूर्ण विफलता को इंगित करता है।

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

    3.6. विफल बफ़र्स को केस 2 में वर्णित अनुसार फ्रेमवर्क में वापस कर दिया जाना चाहिए। लेकिन विफल बफ़र्स को वैध बफ़र्स के सख्त आदेश का पालन करने की आवश्यकता नहीं है, और वैध बफ़र्स के संबंध में ऑर्डर से बाहर हो सकते हैं। उदाहरण के लिए, यदि बफ़र्स ए, बी, सी, डी, ई भेजे जाते हैं, डी और ई विफल हो जाते हैं, तो ए, ई, बी, डी, सी एक स्वीकार्य रिटर्न ऑर्डर है।

    3.7. पूरी तरह से गायब मेटाडेटा के लिए, CAMERA3_MSG_ERROR_RESULT को कॉल करना पर्याप्त है, NULL मेटाडेटा या समकक्ष के साथ प्रोसेस_कैप्चर_रिजल्ट को कॉल करने की कोई आवश्यकता नहीं है।

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

फ्लश() केवल तभी वापस आना चाहिए जब एचएएल में कोई बकाया बफ़र्स या अनुरोध नहीं बचे हों। फ़्रेमवर्क config_streams को कॉल कर सकता है (क्योंकि HAL स्थिति अब समाप्त हो गई है) या नए अनुरोध जारी कर सकता है।

ध्यान दें कि यह केवल पूर्ण-सफल और पूर्ण-असफल परिणाम मामलों का समर्थन करने के लिए पर्याप्त है। हालाँकि, आंशिक विफलता के मामलों का भी समर्थन करना अत्यधिक वांछनीय है, क्योंकि यह फ्लश कॉल के समग्र प्रदर्शन को बेहतर बनाने में मदद कर सकता है।

प्रदर्शन संबंधी जरूरतें:

एचएएल को इस कॉल से 100 एमएस में वापस आना चाहिए, और इस कॉल से 1000 एमएस में वापस आना चाहिए। और इस कॉल को पाइपलाइन विलंबता से अधिक समय तक अवरुद्ध नहीं किया जाना चाहिए (परिभाषा के लिए S7 देखें)।

संस्करण जानकारी:

केवल तभी उपलब्ध है जब डिवाइस संस्करण >= CAMERA_DEVICE_API_VERSION_3_1 हो।

वापसी मान:

0: कैमरे के सफल फ्लश पर एचएएल।

-EINVAL: यदि इनपुट ख़राब है (डिवाइस मान्य नहीं है)।

-एनोडेव: यदि कैमरा डिवाइस में कोई गंभीर त्रुटि आई है। इस त्रुटि के वापस आने के बाद, फ्रेमवर्क द्वारा केवल क्लोज़() विधि को सफलतापूर्वक कॉल किया जा सकता है।

कैमरा3.एच फ़ाइल की पंक्ति 3077 पर परिभाषा।

शून्य(* get_metadata_vendor_tag_ops)(const struct कैमरा3_डिवाइस *, विक्रेता_टैग_क्वेरी_ops_t *ops)

get_metadata_vendor_tag_ops:

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

वेंडर_टैग_क्वेरी_ऑप्स_टी की परिभाषा system/media/camera/include/system/camera_metadata.h में पाई जा सकती है।

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

कैमरा3.एच फ़ाइल की लाइन 2950 पर परिभाषा।

int(* इनिशियलाइज़)(कॉन्स्ट स्ट्रक्चर कैमरा3_डिवाइस *, कास्ट कैमरा3_कॉलबैक_ऑप्स_टी *कॉलबैक_ऑप्स)

प्रारंभ करें:

एचएएल को फ्रेमवर्क कॉलबैक फ़ंक्शन पॉइंटर्स पास करने के लिए एक बार आरंभीकरण। सफल ओपन() कॉल के बाद, कैमरा3_डिवाइस_ऑप्स संरचना पर किसी अन्य फ़ंक्शन को कॉल करने से पहले एक बार कॉल किया जाएगा।

प्रदर्शन संबंधी जरूरतें:

यह एक नॉन-ब्लॉकिंग कॉल होनी चाहिए. एचएएल को इस कॉल से 5ms में वापस आना चाहिए, और इस कॉल से 10ms में वापस आना चाहिए।

वापसी मान:

0: सफल आरंभीकरण पर

-ENODEV: यदि आरंभीकरण विफल हो जाता है। इसके बाद फ्रेमवर्क द्वारा केवल क्लोज़() को सफलतापूर्वक कॉल किया जा सकता है।

कैमरा3.एच फ़ाइल की पंक्ति 2530 पर परिभाषा।

int(* प्रोसेस_कैप्चर_रेक्वेस्ट)(कास्ट स्ट्रक्चर कैमरा3_डिवाइस *, कैमरा3_कैप्चर_रेक्वेस्ट_टी *रिक्वेस्ट)

प्रक्रिया_कैप्चर_अनुरोध:

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

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

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

यदि इनपुट_बफ़र शून्य नहीं है, तो एचएएल को इनपुट बफ़र के रिलीज़ सिंक फ़ेंस के लिए फ़ाइल डिस्क्रिप्टर को इनपुट_बफ़र->रिलीज़_फ़ेंस में लिखना होगा। यदि एचएएल इनपुट बफर रिलीज सिंक बाड़ के लिए -1 लौटाता है, तो फ्रेमवर्क तुरंत इनपुट बफर का पुन: उपयोग करने के लिए स्वतंत्र है। अन्यथा, फ्रेमवर्क इनपुट बफ़र को फिर से भरने और पुन: उपयोग करने से पहले सिंक बाड़ पर प्रतीक्षा करेगा।

>= CAMERA_DEVICE_API_VERSION_3_2:

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


प्रदर्शन संबंधी विचार:

नए बफ़र को संभालना बेहद हल्का होना चाहिए और इसमें कोई फ़्रेम दर में गिरावट या फ़्रेम घबराहट नहीं होनी चाहिए।

यह कॉल इतनी तेजी से लौटनी चाहिए कि यह सुनिश्चित हो सके कि अनुरोधित फ्रेम दर को कायम रखा जा सके, विशेष रूप से स्ट्रीमिंग मामलों के लिए (पोस्ट-प्रोसेसिंग गुणवत्ता सेटिंग्स फास्ट पर सेट)। एचएएल को इस कॉल को 1 फ्रेम अंतराल में वापस करना चाहिए, और इस कॉल को 4 फ्रेम अंतराल में वापस करना चाहिए।

वापसी मान:

0: कैप्चर अनुरोध को संसाधित करने की सफल शुरुआत पर

-EINVAL: यदि इनपुट विकृत है (अनुमति नहीं होने पर सेटिंग्स शून्य हैं, 0 आउटपुट बफ़र्स हैं, आदि) और कैप्चर प्रोसेसिंग शुरू नहीं हो सकती है। अनुरोध प्रसंस्करण के दौरान विफलताओं को कैमरा3_कॉलबैक_ऑप्स_t.notify() पर कॉल करके नियंत्रित किया जाना चाहिए। इस त्रुटि के मामले में, फ्रेमवर्क स्ट्रीम बफ़र्स की बाड़ और बफ़र हैंडल के लिए जिम्मेदारी बनाए रखेगा; एचएएल को बाड़ बंद नहीं करनी चाहिए या इन बफ़र्स को प्रोसेस_कैप्चर_रिजल्ट के साथ वापस नहीं करना चाहिए।

-एनोडेव: यदि कैमरा डिवाइस में कोई गंभीर त्रुटि आई है। इस त्रुटि के वापस आने के बाद, फ्रेमवर्क द्वारा केवल क्लोज़() विधि को सफलतापूर्वक कॉल किया जा सकता है।

कैमरा3.एच फ़ाइल की पंक्ति 2928 पर परिभाषा।

int(* रजिस्टर_स्ट्रीम_बफ़र्स)(कास्ट स्ट्रक्चर कैमरा3_डिवाइस *, कास्ट कैमरा3_स्ट्रीम_बफ़र_सेट_टी *बफ़र_सेट)

रजिस्टर_स्ट्रीम_बफ़र्स:

>= CAMERA_DEVICE_API_VERSION_3_2:

पदावनत. इसे कॉल नहीं किया जाएगा और इसे NULL पर सेट किया जाना चाहिए।

<= CAMERA_DEVICE_API_VERSION_3_1:

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

फ्रेमवर्क को पहला कैप्चर अनुरोध सबमिट करने से पहले सभी कॉन्फ़िगर स्ट्रीम के लिए बफ़र्स पंजीकृत करने की आवश्यकता नहीं है। यह पूर्वावलोकन (या समान उपयोग के मामलों) के लिए त्वरित स्टार्टअप की अनुमति देता है जबकि अन्य स्ट्रीम अभी भी आवंटित की जा रही हैं।

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

यदि स्ट्रीम प्रारूप HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED पर सेट किया गया था, तो कैमरा HAL को किसी भी प्लेटफ़ॉर्म-निजी पिक्सेल प्रारूप जानकारी निर्धारित करने के लिए यहां पारित बफ़र्स का निरीक्षण करना चाहिए।

प्रदर्शन संबंधी जरूरतें:

यह एक नॉन-ब्लॉकिंग कॉल होनी चाहिए. एचएएल को इस कॉल से 1ms में वापस आना चाहिए, और इस कॉल से 5ms में वापस आना चाहिए।

वापसी मान:

0: नए स्ट्रीम बफ़र्स के सफल पंजीकरण पर

-EINVAL: यदि स्ट्रीम_बफ़र_सेट एक वैध सक्रिय स्ट्रीम को संदर्भित नहीं करता है, या यदि बफ़र्स सरणी अमान्य है।

-ENOMEM: यदि बफ़र्स को पंजीकृत करने में कोई विफलता हुई थी। फ्रेमवर्क को सभी स्ट्रीम बफ़र्स को अपंजीकृत मानना ​​चाहिए, और बाद में फिर से पंजीकरण करने का प्रयास कर सकता है।

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

कैमरा3.एच फ़ाइल की पंक्ति 2823 पर परिभाषा।

शून्य* आरक्षित[8]

कैमरा3.एच फ़ाइल की पंक्ति 3080 पर परिभाषा।


इस संरचना के लिए दस्तावेज़ीकरण निम्नलिखित फ़ाइल से तैयार किया गया था:
  • हार्डवेयर/लिबहार्डवेयर/शामिल/हार्डवेयर/ कैमरा3.एच