camera3_device_ops স্ট্রাকট রেফারেন্স
#include < camera3.h >
ডেটা ক্ষেত্র | |
| int(* | আরম্ভ করুন )(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 টাইপ) |
| int(* | process_capture_request )(const struct camera3_device *, camera3_capture_request_t *request) |
| অকার্যকর(* | get_metadata_vendor_tag_ops )(const struct camera3_device *, vendor_tag_query_ops_t *ops) |
| অকার্যকর(* | ডাম্প )(const struct camera3_device *, int fd) |
| int(* | ফ্লাশ )(const struct camera3_device *) |
| অকার্যকর * | সংরক্ষিত [8] |
বিস্তারিত বিবরণ
ফিল্ড ডকুমেন্টেশন
| int(* configure_streams)(const struct camera3_device *, camera3_stream_configuration_t *stream_list) |
configure_streams:
শুধুমাত্র CAMERA_DEVICE_API_VERSION_3_0:
HAL ক্যামেরা ডিভাইস প্রক্রিয়াকরণ পাইপলাইন পুনরায় সেট করুন এবং নতুন ইনপুট এবং আউটপুট স্ট্রীম সেট আপ করুন৷ এই কলটি স্ট্রিম_লিস্টে সংজ্ঞায়িত স্ট্রিমগুলির সাথে বিদ্যমান যেকোনো স্ট্রিম কনফিগারেশনকে প্রতিস্থাপন করে। process_capture_request() এর সাথে একটি অনুরোধ জমা দেওয়ার আগে এই পদ্ধতিটি অন্তত একবার initialize() এর পরে কল করা হবে।
স্ট্রীম_লিস্টে অবশ্যই অন্তত একটি আউটপুট-সক্ষম স্ট্রীম থাকতে হবে এবং এতে একাধিক ইনপুট-সক্ষম স্ট্রীম থাকতে পারে না।
স্ট্রীম_তালিকায় এমন স্ট্রীম থাকতে পারে যা বর্তমানে সক্রিয় স্ট্রীমের সেটে রয়েছে (আগের কল থেকে কনফিগার_স্ট্রিম())। এই স্ট্রীমগুলিতে ইতিমধ্যেই ব্যবহার, max_buffers এবং ব্যক্তিগত পয়েন্টারের জন্য বৈধ মান থাকবে৷
যদি এই ধরনের একটি স্ট্রীমের বাফারগুলি ইতিমধ্যেই নিবন্ধিত হয়ে থাকে, তাহলে register_stream_buffers() স্ট্রীমের জন্য আবার কল করা হবে না এবং স্ট্রীম থেকে বাফারগুলি অবিলম্বে ইনপুট অনুরোধগুলিতে অন্তর্ভুক্ত করা যেতে পারে৷
নতুন কনফিগারেশনের কারণে যদি HAL-কে একটি বিদ্যমান স্ট্রিমের জন্য স্ট্রিম কনফিগারেশন পরিবর্তন করতে হয়, তাহলে কনফিগার কলের সময় এটি ব্যবহারের মান এবং/অথবা max_buffers পুনরায় লিখতে পারে।
ফ্রেমওয়ার্ক এই ধরনের পরিবর্তন শনাক্ত করবে, এবং তারপরে স্ট্রীম বাফারগুলিকে পুনরায় বরাদ্দ করবে, এবং অনুরোধে সেই স্ট্রীম থেকে বাফারগুলি ব্যবহার করার আগে আবার register_stream_buffers() কল করবে।
যদি একটি বর্তমানে-সক্রিয় স্ট্রীম স্ট্রিম_লিস্টে অন্তর্ভুক্ত না করা হয়, তবে HAL নিরাপদে সেই স্ট্রীমের কোনো রেফারেন্স মুছে ফেলতে পারে। ফ্রেমওয়ার্ক দ্বারা পরবর্তী কনফিগার() কলে এটি পুনরায় ব্যবহার করা হবে না এবং configure_streams() কল রিটার্ন করার পরে এর জন্য সমস্ত gralloc বাফার মুক্ত করা হবে।
স্ট্রিম_লিস্ট কাঠামোটি ফ্রেমওয়ার্কের মালিকানাধীন, এবং একবার এই কলটি সম্পূর্ণ হয়ে গেলে অ্যাক্সেস করা যাবে না। একটি পৃথক camera3_stream_t কাঠামোর ঠিকানা প্রথম কনফিগার_স্ট্রিম() কলের শেষ না হওয়া পর্যন্ত HAL দ্বারা অ্যাক্সেসের জন্য বৈধ থাকবে যা stream_list আর্গুমেন্টে সেই camera3_stream_tটি আর অন্তর্ভুক্ত করে না। HAL ব্যক্তিগত পয়েন্টারের বাইরে স্ট্রীম কাঠামোর মান পরিবর্তন করতে পারে না, configure_streams() কলের সময় ব্যবহার এবং max_buffers সদস্যদের ছাড়া।
যদি স্ট্রীমটি নতুন হয়, তাহলে স্ট্রিম কাঠামোর ব্যবহার, max_buffer এবং ব্যক্তিগত পয়েন্টার ক্ষেত্রগুলি 0-এ সেট করা হবে৷ HAL ডিভাইসটিকে configure_streams() কল রিটার্ন করার আগে এই ক্ষেত্রগুলি অবশ্যই সেট করতে হবে৷ এই ক্ষেত্রগুলি তারপর ফ্রেমওয়ার্ক এবং প্ল্যাটফর্ম গ্র্যালক মডিউল দ্বারা প্রতিটি স্ট্রিমের জন্য গ্র্যালক বাফারগুলি বরাদ্দ করতে ব্যবহৃত হয়।
এই ধরনের একটি নতুন স্ট্রীম একটি ক্যাপচার অনুরোধে এর বাফারগুলি অন্তর্ভুক্ত করার আগে, ফ্রেমওয়ার্কটি সেই স্ট্রীমের সাথে register_stream_buffers() কল করবে। যাইহোক, একটি অনুরোধ জমা দেওয়ার আগে সমস্ত স্ট্রীমের জন্য বাফার নিবন্ধন করার জন্য ফ্রেমওয়ার্কের প্রয়োজন নেই। এটি একটি প্রিভিউ স্ট্রিমের (উদাহরণস্বরূপ) দ্রুত স্টার্টআপের অনুমতি দেয়, পরবর্তীতে বা একযোগে ঘটতে থাকা অন্যান্য স্ট্রিমগুলির জন্য বরাদ্দ সহ।
শুধুমাত্র CAMERA_DEVICE_API_VERSION_3_1:
HAL ক্যামেরা ডিভাইস প্রক্রিয়াকরণ পাইপলাইন পুনরায় সেট করুন এবং নতুন ইনপুট এবং আউটপুট স্ট্রীম সেট আপ করুন৷ এই কলটি স্ট্রিম_লিস্টে সংজ্ঞায়িত স্ট্রিমগুলির সাথে বিদ্যমান যেকোনো স্ট্রিম কনফিগারেশনকে প্রতিস্থাপন করে। process_capture_request() এর সাথে একটি অনুরোধ জমা দেওয়ার আগে এই পদ্ধতিটি অন্তত একবার initialize() এর পরে কল করা হবে।
স্ট্রীম_লিস্টে অবশ্যই অন্তত একটি আউটপুট-সক্ষম স্ট্রীম থাকতে হবে এবং এতে একাধিক ইনপুট-সক্ষম স্ট্রীম থাকতে পারে না।
স্ট্রীম_তালিকায় এমন স্ট্রীম থাকতে পারে যা বর্তমানে সক্রিয় স্ট্রীমের সেটে রয়েছে (আগের কল থেকে কনফিগার_স্ট্রিম())। এই স্ট্রীমগুলিতে ইতিমধ্যেই ব্যবহার, max_buffers এবং ব্যক্তিগত পয়েন্টারের জন্য বৈধ মান থাকবে৷
যদি এই ধরনের একটি স্ট্রীমের বাফারগুলি ইতিমধ্যেই নিবন্ধিত হয়ে থাকে, তাহলে register_stream_buffers() স্ট্রীমের জন্য আবার কল করা হবে না এবং স্ট্রীম থেকে বাফারগুলি অবিলম্বে ইনপুট অনুরোধগুলিতে অন্তর্ভুক্ত করা যেতে পারে৷
নতুন কনফিগারেশনের কারণে যদি HAL-কে একটি বিদ্যমান স্ট্রিমের জন্য স্ট্রিম কনফিগারেশন পরিবর্তন করতে হয়, তাহলে কনফিগার কলের সময় এটি ব্যবহারের মান এবং/অথবা max_buffers পুনরায় লিখতে পারে।
ফ্রেমওয়ার্ক এই ধরনের পরিবর্তন শনাক্ত করবে, এবং তারপরে স্ট্রীম বাফারগুলিকে পুনরায় বরাদ্দ করবে, এবং অনুরোধে সেই স্ট্রীম থেকে বাফারগুলি ব্যবহার করার আগে আবার register_stream_buffers() কল করবে।
যদি একটি বর্তমানে-সক্রিয় স্ট্রীম স্ট্রিম_লিস্টে অন্তর্ভুক্ত না করা হয়, তবে HAL নিরাপদে সেই স্ট্রীমের কোনো রেফারেন্স মুছে ফেলতে পারে। ফ্রেমওয়ার্ক দ্বারা পরবর্তী কনফিগার() কলে এটি পুনরায় ব্যবহার করা হবে না এবং configure_streams() কল রিটার্ন করার পরে এর জন্য সমস্ত gralloc বাফার মুক্ত করা হবে।
স্ট্রিম_লিস্ট কাঠামোটি ফ্রেমওয়ার্কের মালিকানাধীন, এবং একবার এই কলটি সম্পূর্ণ হয়ে গেলে অ্যাক্সেস করা যাবে না। একটি পৃথক camera3_stream_t কাঠামোর ঠিকানা প্রথম কনফিগার_স্ট্রিম() কলের শেষ না হওয়া পর্যন্ত HAL দ্বারা অ্যাক্সেসের জন্য বৈধ থাকবে যা stream_list আর্গুমেন্টে সেই camera3_stream_tটি আর অন্তর্ভুক্ত করে না। HAL ব্যক্তিগত পয়েন্টারের বাইরে স্ট্রীম কাঠামোর মান পরিবর্তন করতে পারে না, configure_streams() কলের সময় ব্যবহার এবং max_buffers সদস্যদের ছাড়া।
স্ট্রীমটি নতুন হলে, স্ট্রীম কাঠামোর max_buffer এবং ব্যক্তিগত পয়েন্টার ক্ষেত্রগুলি 0-এ সেট করা হবে৷ ব্যবহারটি ভোক্তা ব্যবহারের পতাকাগুলিতে সেট করা হবে৷ configure_streams() কল রিটার্ন করার আগে HAL ডিভাইসটিকে অবশ্যই এই ক্ষেত্রগুলি সেট করতে হবে৷ এই ক্ষেত্রগুলি তারপর ফ্রেমওয়ার্ক এবং প্ল্যাটফর্ম গ্র্যালক মডিউল দ্বারা প্রতিটি স্ট্রিমের জন্য গ্র্যালক বাফারগুলি বরাদ্দ করতে ব্যবহৃত হয়।
এই ধরনের একটি নতুন স্ট্রীম একটি ক্যাপচার অনুরোধে এর বাফারগুলি অন্তর্ভুক্ত করার আগে, ফ্রেমওয়ার্কটি সেই স্ট্রীমের সাথে register_stream_buffers() কল করবে। যাইহোক, একটি অনুরোধ জমা দেওয়ার আগে সমস্ত স্ট্রীমের জন্য বাফার নিবন্ধন করার জন্য ফ্রেমওয়ার্কের প্রয়োজন নেই। এটি একটি প্রিভিউ স্ট্রিমের (উদাহরণস্বরূপ) দ্রুত স্টার্টআপের অনুমতি দেয়, পরবর্তীতে বা একযোগে ঘটতে থাকা অন্যান্য স্ট্রিমগুলির জন্য বরাদ্দ সহ।
>= CAMERA_DEVICE_API_VERSION_3_2:
HAL ক্যামেরা ডিভাইস প্রক্রিয়াকরণ পাইপলাইন পুনরায় সেট করুন এবং নতুন ইনপুট এবং আউটপুট স্ট্রীম সেট আপ করুন৷ এই কলটি স্ট্রিম_লিস্টে সংজ্ঞায়িত স্ট্রিমগুলির সাথে বিদ্যমান যেকোনো স্ট্রিম কনফিগারেশনকে প্রতিস্থাপন করে। process_capture_request() এর সাথে একটি অনুরোধ জমা দেওয়ার আগে এই পদ্ধতিটি অন্তত একবার initialize() এর পরে কল করা হবে।
স্ট্রীম_লিস্টে অবশ্যই অন্তত একটি আউটপুট-সক্ষম স্ট্রীম থাকতে হবে এবং এতে একাধিক ইনপুট-সক্ষম স্ট্রীম থাকতে পারে না।
স্ট্রীম_তালিকায় এমন স্ট্রীম থাকতে পারে যা বর্তমানে সক্রিয় স্ট্রীমের সেটে রয়েছে (আগের কল থেকে কনফিগার_স্ট্রিম())। এই স্ট্রীমগুলিতে ইতিমধ্যেই ব্যবহার, max_buffers এবং ব্যক্তিগত পয়েন্টারের জন্য বৈধ মান থাকবে৷
নতুন কনফিগারেশনের কারণে যদি HAL-কে একটি বিদ্যমান স্ট্রিমের জন্য স্ট্রিম কনফিগারেশন পরিবর্তন করতে হয়, তাহলে কনফিগার কলের সময় এটি ব্যবহারের মান এবং/অথবা max_buffers পুনরায় লিখতে পারে।
ফ্রেমওয়ার্ক এই ধরনের পরিবর্তন শনাক্ত করবে এবং অনুরোধে সেই স্ট্রীম থেকে বাফারগুলি ব্যবহার করার আগে স্ট্রিম বাফারগুলি পুনরায় বরাদ্দ করতে পারে।
যদি একটি বর্তমানে-সক্রিয় স্ট্রীম স্ট্রিম_লিস্টে অন্তর্ভুক্ত না করা হয়, তবে HAL নিরাপদে সেই স্ট্রীমের কোনো রেফারেন্স মুছে ফেলতে পারে। ফ্রেমওয়ার্ক দ্বারা পরবর্তী কনফিগার() কলে এটি পুনরায় ব্যবহার করা হবে না এবং configure_streams() কল রিটার্ন করার পরে এর জন্য সমস্ত gralloc বাফার মুক্ত করা হবে।
স্ট্রিম_লিস্ট কাঠামোটি ফ্রেমওয়ার্কের মালিকানাধীন, এবং একবার এই কলটি সম্পূর্ণ হয়ে গেলে অ্যাক্সেস করা যাবে না। একটি পৃথক camera3_stream_t কাঠামোর ঠিকানা প্রথম কনফিগার_স্ট্রিম() কলের শেষ না হওয়া পর্যন্ত HAL দ্বারা অ্যাক্সেসের জন্য বৈধ থাকবে যা stream_list আর্গুমেন্টে সেই camera3_stream_tটি আর অন্তর্ভুক্ত করে না। HAL ব্যক্তিগত পয়েন্টারের বাইরে স্ট্রীম কাঠামোর মান পরিবর্তন করতে পারে না, configure_streams() কলের সময় ব্যবহার এবং max_buffers সদস্যদের ছাড়া।
স্ট্রীমটি নতুন হলে, স্ট্রীম কাঠামোর max_buffer এবং ব্যক্তিগত পয়েন্টার ক্ষেত্রগুলি 0-এ সেট করা হবে৷ ব্যবহারটি ভোক্তা ব্যবহারের পতাকাগুলিতে সেট করা হবে৷ configure_streams() কল রিটার্ন করার আগে HAL ডিভাইসটিকে অবশ্যই এই ক্ষেত্রগুলি সেট করতে হবে৷ এই ক্ষেত্রগুলি তারপর ফ্রেমওয়ার্ক এবং প্ল্যাটফর্ম গ্র্যালক মডিউল দ্বারা প্রতিটি স্ট্রিমের জন্য গ্র্যালক বাফারগুলি বরাদ্দ করতে ব্যবহৃত হয়।
নতুন বরাদ্দ করা বাফারগুলি ফ্রেমওয়ার্ক দ্বারা যে কোনও সময় ক্যাপচার অনুরোধে অন্তর্ভুক্ত হতে পারে। একবার একটি gralloc বাফার প্রসেস_ক্যাপচার_রেজাল্ট সহ ফ্রেমওয়ার্কে ফিরে গেলে (এবং এর সংশ্লিষ্ট রিলিজ_ফেনস সিগন্যাল করা হয়েছে) ফ্রেমওয়ার্কটি যেকোন সময় মুক্ত বা পুনরায় ব্যবহার করতে পারে।
পূর্বশর্ত:
ফ্রেমওয়ার্ক শুধুমাত্র এই পদ্ধতিটিকে কল করবে যখন কোনো ক্যাপচার প্রক্রিয়া করা হচ্ছে না। অর্থাৎ, সমস্ত ফলাফল ফ্রেমওয়ার্কে ফেরত দেওয়া হয়েছে, এবং সমস্ত ইন-ফ্লাইট ইনপুট এবং আউটপুট বাফারগুলি ফিরিয়ে দেওয়া হয়েছে এবং তাদের রিলিজ সিঙ্ক বেড়াগুলি HAL দ্বারা সংকেত দেওয়া হয়েছে। configure_streams() কল চলাকালীন ফ্রেমওয়ার্ক ক্যাপচারের জন্য নতুন অনুরোধ জমা দেবে না।
পোস্ট শর্ত:
ক্যামেরা ডিভাইসের স্ট্যাটিক মেটাডেটাতে নথিভুক্ত আউটপুট স্ট্রীমগুলির আকার এবং বিন্যাস অনুযায়ী সর্বাধিক সম্ভাব্য আউটপুট ফ্রেম রেট প্রদান করতে HAL ডিভাইসটিকে অবশ্যই নিজেকে কনফিগার করতে হবে।
কর্মক্ষমতা প্রয়োজনীয়তা:
এই কলটি হেভিওয়েট হতে পারে বলে আশা করা হচ্ছে এবং সম্ভবত এটি সম্পূর্ণ হতে কয়েকশ মিলিসেকেন্ড সময় লাগবে, কারণ এটির জন্য ইমেজ সেন্সর এবং ক্যামেরা প্রসেসিং পাইপলাইন রিসেট এবং পুনরায় কনফিগার করার প্রয়োজন হতে পারে। তবুও, HAL ডিভাইসের অ্যাপ্লিকেশন অপারেশনাল মোড পরিবর্তনের সময় ব্যবহারকারী-দৃশ্যমান বিরতিগুলিকে (যেমন স্থির ক্যাপচার থেকে ভিডিও রেকর্ডিং-এ স্যুইচ করা) কমানোর জন্য পুনরায় কনফিগারেশন বিলম্ব কমানোর চেষ্টা করা উচিত।
HAL-এর এই কল থেকে 500ms-এ ফিরতে হবে, এবং 1000ms-এর মধ্যে এই কল থেকে ফিরতে হবে।
রিটার্ন মান:
0: সফল স্ট্রিম কনফিগারেশনে
-EINVAL: যদি অনুরোধ করা স্ট্রিম কনফিগারেশন অবৈধ হয়। অবৈধ স্ট্রিম কনফিগারেশনের কিছু উদাহরণের মধ্যে রয়েছে:
- 1 টিরও বেশি ইনপুট-সক্ষম স্ট্রীম সহ (INPUT বা BIDIRECTIONAL)
- কোনো আউটপুট-সক্ষম স্ট্রীম অন্তর্ভুক্ত নয় (আউটপুট বা দ্বিমুখী)
- অসমর্থিত ফর্ম্যাট সহ স্ট্রীম বা সেই ফর্ম্যাটের জন্য অসমর্থিত আকার সহ।
- একটি নির্দিষ্ট বিন্যাসের অনেকগুলি আউটপুট স্ট্রীম সহ।
- অসমর্থিত ঘূর্ণন কনফিগারেশন (শুধুমাত্র সংস্করণ সহ ডিভাইসগুলিতে প্রযোজ্য >= CAMERA_DEVICE_API_VERSION_3_3)
- স্ট্রীমের আকার/ফরম্যাটগুলি নন-নর্মাল মোডের জন্য ক্যামেরা3_স্ট্রিম_কনফিগারেশন_টি->অপারেশন_মোড প্রয়োজনীয়তা পূরণ করে না বা অনুরোধ করা অপারেশন_মোড HAL দ্বারা সমর্থিত নয়। (শুধুমাত্র >= CAMERA_DEVICE_API_VERSION_3_3 সংস্করণ সহ ডিভাইসগুলিতে প্রযোজ্য)
মনে রাখবেন যে একটি অবৈধ স্ট্রীম কনফিগারেশন জমা দেওয়া ফ্রেমওয়ার্ক স্বাভাবিক কাজ নয়, যেহেতু স্ট্রিম কনফিগারেশনগুলি কনফিগার করার আগে চেক করা হয়। একটি অবৈধ কনফিগারেশনের অর্থ হল ফ্রেমওয়ার্ক কোডে একটি বাগ বিদ্যমান, অথবা HAL এর স্ট্যাটিক মেটাডেটা এবং স্ট্রিমগুলির প্রয়োজনীয়তার মধ্যে একটি অমিল রয়েছে৷
-এনোডেভ: যদি কোনও মারাত্মক ত্রুটি হয়ে থাকে এবং ডিভাইসটি আর চালু না থাকে। এই ত্রুটিটি ফিরে আসার পরে ফ্রেমওয়ার্ক দ্বারা শুধুমাত্র close() কে সফলভাবে কল করা যেতে পারে।
| const camera_metadata_t *(* construct_default_request_settings)(const struct camera3_device *, int প্রকার) |
construct_default_request_settings:
স্ট্যান্ডার্ড ক্যামেরা ব্যবহারের ক্ষেত্রে ক্যাপচার সেটিংস তৈরি করুন।
ডিভাইসটিকে অবশ্যই একটি সেটিংস বাফার ফেরত দিতে হবে যা অনুরোধকৃত ব্যবহারের ক্ষেত্রে মেটানোর জন্য কনফিগার করা হয়েছে, যা অবশ্যই CAMERA3_TEMPLATE_* enums এর একটি হতে হবে। সমস্ত অনুরোধ নিয়ন্ত্রণ ক্ষেত্র অন্তর্ভুক্ত করা আবশ্যক.
এইচএএল এই কাঠামোর মালিকানা ধরে রাখে, তবে ডিভাইসটি বন্ধ না হওয়া পর্যন্ত কাঠামোর নির্দেশক অবশ্যই বৈধ হতে হবে। ফ্রেমওয়ার্ক এবং এইচএএল এই কল দ্বারা ফিরে আসার পরে বাফারটি পরিবর্তন করতে পারে না। একই টেমপ্লেট বা অন্যান্য টেমপ্লেটের জন্য পরবর্তী কলগুলির জন্য একই বাফার ফেরত দেওয়া হতে পারে।
কর্মক্ষমতা প্রয়োজনীয়তা:
এটি একটি নন-ব্লকিং কল হওয়া উচিত। HAL-এর এই কল থেকে 1ms-এর মধ্যে ফিরতে হবে, এবং এই কল থেকে 5ms-এর মধ্যে ফিরতে হবে।
রিটার্ন মান:
বৈধ মেটাডেটা: একটি ডিফল্ট সেটিংস বাফার সফলভাবে তৈরি করা হয়েছে।
NULL: একটি মারাত্মক ত্রুটির ক্ষেত্রে। এটি প্রত্যাবর্তনের পরে, ফ্রেমওয়ার্ক দ্বারা শুধুমাত্র close() পদ্ধতি সফলভাবে কল করা যেতে পারে।
| void(* ডাম্প)(const struct camera3_device *, int fd) |
ডাম্প:
ক্যামেরা ডিভাইসের জন্য ডিবাগিং অবস্থা মুদ্রণ করুন। এটিকে ফ্রেমওয়ার্ক দ্বারা বলা হবে যখন ক্যামেরা পরিষেবাকে একটি ডিবাগ ডাম্পের জন্য বলা হবে, যা ডাম্পসিস টুল ব্যবহার করার সময় বা একটি বাগ রিপোর্ট ক্যাপচার করার সময় ঘটে।
পাস-ইন ফাইল বর্ণনাকারী dprintf() বা write() ব্যবহার করে ডিবাগিং টেক্সট লিখতে ব্যবহার করা যেতে পারে। পাঠ্যটি শুধুমাত্র ASCII এনকোডিং-এ হওয়া উচিত।
কর্মক্ষমতা প্রয়োজনীয়তা:
এটি অবশ্যই একটি নন-ব্লকিং কল হতে হবে। HAL এই কল থেকে 1ms এর মধ্যে ফিরতে হবে, এই কল থেকে 10ms এর মধ্যে ফিরতে হবে। এই কলটি অবশ্যই অচলাবস্থা এড়াতে হবে, কারণ এটি ক্যামেরা অপারেশন চলাকালীন যেকোনো সময়ে কল করা যেতে পারে। ব্যবহৃত যেকোন সিঙ্ক্রোনাইজেশন প্রাইমিটিভস (যেমন মিউটেক্স লক বা সেমাফোরস) একটি সময়সীমার সাথে অর্জিত হওয়া উচিত।
| int(* ফ্লাশ)(const struct camera3_device *) |
ফ্লাশ:
প্রদত্ত ডিভাইসে পাইপলাইনে থাকা সমস্ত বর্তমানে প্রক্রিয়াধীন ক্যাপচার এবং সমস্ত বাফার ফ্লাশ করুন। একটি configure_streams() কলের জন্য প্রস্তুত করার জন্য ফ্রেমওয়ার্ক যত তাড়াতাড়ি সম্ভব সমস্ত স্টেট ডাম্প করতে এটি ব্যবহার করবে।
সফলভাবে ফেরত দেওয়ার জন্য কোনো বাফারের প্রয়োজন নেই, তাই flush() এর সময় ধরে রাখা প্রতিটি বাফার (সফলভাবে পূরণ হোক বা না হোক) CAMERA3_BUFFER_STATUS_ERROR দিয়ে ফেরত দেওয়া হতে পারে। মনে রাখবেন HAL এখনও এই কল চলাকালীন বৈধ (CAMERA3_BUFFER_STATUS_OK) বাফারগুলি ফেরত দেওয়ার অনুমতি দেয়, যদি সেগুলি সফলভাবে পূরণ করা হয়।
বর্তমানে HAL-এর সমস্ত অনুরোধ যত তাড়াতাড়ি সম্ভব ফেরত দেওয়া হবে বলে আশা করা হচ্ছে। নট-ইন-প্রক্রিয়ার অনুরোধগুলি অবিলম্বে ত্রুটিগুলি ফিরিয়ে দেওয়া উচিত। কোনো বাধাহীন হার্ডওয়্যার ব্লক বন্ধ করা উচিত, এবং কোনো নিরবচ্ছিন্ন ব্লকের জন্য অপেক্ষা করা উচিত।
flush() কে একই সাথে process_capture_request() এ কল করা যেতে পারে, এই প্রত্যাশার সাথে যে process_capture_request দ্রুত ফিরে আসবে এবং সেই process_capture_request কলে জমা দেওয়া অনুরোধটিকে অন্যান্য সমস্ত ইন-ফ্লাইট অনুরোধের মতোই বিবেচনা করা হবে। কনকারেন্সি সমস্যার কারণে, এটা সম্ভব যে HAL-এর দৃষ্টিকোণ থেকে, একটি process_capture_request() কল শুরু হতে পারে ফ্লাশ চালু করার পরে কিন্তু এখনও ফিরে আসেনি। যদি ফ্লাশ() ফেরত আসার আগে এই ধরনের কল হয়, তবে HAL-এর উচিত অন্যান্য ইন-ফ্লাইট মুলতুবি থাকা অনুরোধগুলির মতো নতুন ক্যাপচার অনুরোধের সাথে আচরণ করা উচিত (নীচে #4 দেখুন)।
আরও নির্দিষ্টভাবে, HAL-কে অবশ্যই বিভিন্ন ক্ষেত্রে নিম্নলিখিত প্রয়োজনীয়তাগুলি অনুসরণ করতে হবে:
- ক্যাপচারের জন্য যেগুলি HAL-এর বাতিল/বন্ধ করতে দেরি হয়ে গেছে, এবং HAL দ্বারা সাধারণত সম্পন্ন হবে; অর্থাৎ HAL স্বাভাবিক হিসাবে শাটার/নোটিফাই এবং প্রক্রিয়া_ক্যাপচার_রেজাল্ট এবং বাফার পাঠাতে পারে।
- মুলতুবি থাকা অনুরোধগুলির জন্য যেগুলির কোনও প্রক্রিয়াকরণ করা হয়নি, এইচএএলকে অবশ্যই CAMERA3_MSG_ERROR_REQUEST বিজ্ঞপ্তিতে কল করতে হবে এবং ত্রুটির অবস্থায় (CAMERA3_BUFFER_STATUS_ERROR) প্রসেস_ক্যাপচার_ফলাফল সহ সমস্ত আউটপুট বাফার ফেরত দিতে হবে। HAL অবশ্যই রিলিজ বেড়াকে একটি ত্রুটির অবস্থায় রাখবে না, পরিবর্তে, মুক্তির বেড়াগুলিকে অবশ্যই ফ্রেমওয়ার্ক দ্বারা পাস করা অধিগ্রহণের বেড়াগুলিতে সেট করতে হবে, অথবা -1 যদি সেগুলি ইতিমধ্যে HAL দ্বারা অপেক্ষা করে থাকে। এটি যে কোনও ক্যাপচারের জন্য অনুসরণ করার পথ যার জন্য HAL ইতিমধ্যে CAMERA3_MSG_SHUTTER-এর সাথে notify() কল করেছে কিন্তু এর জন্য কোনও মেটাডেটা/বৈধ বাফার তৈরি করবে না। CAMERA3_MSG_ERROR_REQUEST-এর পরে, একটি প্রদত্ত ফ্রেমের জন্য, শুধুমাত্র CAMERA3_BUFFER_STATUS_ERROR-এ বাফার সহ process_capture_results অনুমোদিত৷ নন-নাল মেটাডেটা সহ আর কোনো বিজ্ঞপ্তি বা প্রক্রিয়া_ক্যাপচার_রিজাল্ট অনুমোদিত নয়।
আংশিকভাবে সম্পূর্ণ মুলতুবি থাকা অনুরোধগুলির জন্য যেখানে সমস্ত আউটপুট বাফার থাকবে না বা সম্ভবত অনুপস্থিত মেটাডেটা থাকবে না, HAL-এর নীচে অনুসরণ করা উচিত:
3.1। CAMERA3_MSG_ERROR_RESULT এর সাথে কল করুন যদি কিছু প্রত্যাশিত ফলাফলের মেটাডেটা (যেমন এক বা একাধিক আংশিক মেটাডেটা) ক্যাপচারের জন্য উপলব্ধ না হয়।
3.2। ক্যাপচারের জন্য তৈরি করা হবে না এমন প্রতিটি বাফারের জন্য CAMERA3_MSG_ERROR_BUFFER এর সাথে কল করুন।
3.3 কোনো বাফার/মেটাডেটা প্রক্রিয়া_ক্যাপচার_ফলাফলের সাথে ফেরত দেওয়ার আগে ক্যাপচার টাইমস্ট্যাম্প সহ CAMERA3_MSG_SHUTTER-এর সাথে কল করুন।
3.4 ক্যাপচারের জন্য যা কিছু ফলাফল দেবে, HAL অবশ্যই CAMERA3_MSG_ERROR_REQUEST কল করবে না, কারণ এটি সম্পূর্ণ ব্যর্থতা নির্দেশ করে।
3.5। বৈধ বাফার/মেটাডেটা স্বাভাবিক হিসাবে ফ্রেমওয়ার্কে পাস করা উচিত।
3.6। ব্যর্থ বাফারগুলি কেস 2-এর জন্য বর্ণিত ফ্রেমওয়ার্কে ফেরত দেওয়া উচিত। তবে ব্যর্থ বাফারগুলিকে বৈধ বাফারের কঠোর আদেশ অনুসরণ করতে হবে না এবং বৈধ বাফারগুলির ক্ষেত্রে ক্রম-বর্জিত হতে পারে। উদাহরণস্বরূপ, যদি বাফার A, B, C, D, E পাঠানো হয়, D এবং E ব্যর্থ হয়, তাহলে A, E, B, D, C হল একটি গ্রহণযোগ্য রিটার্ন অর্ডার।
3.7। সম্পূর্ণভাবে অনুপস্থিত মেটাডেটার জন্য, CAMERA3_MSG_ERROR_RESULT কল করাই যথেষ্ট, NULL মেটাডেটা বা সমতুল্য সহ process_capture_result কল করার দরকার নেই৷
- একটি process_capture_request() আমন্ত্রণ সক্রিয় থাকাকালীন একটি flush() আহ্বান করা হলে, সেই প্রক্রিয়া কল যত তাড়াতাড়ি সম্ভব ফিরে আসা উচিত। উপরন্তু, যদি একটি process_capture_request() কল flush() করার পরে করা হয় কিন্তু flush() ফিরে আসার আগে, দেরী process_capture_request কল দ্বারা প্রদত্ত ক্যাপচার অনুরোধটি উপরের ক্ষেত্রে #2-এর ক্ষেত্রে একটি মুলতুবি অনুরোধের মতো বিবেচনা করা উচিত।
flush() শুধুমাত্র তখনই ফিরে আসা উচিত যখন HAL-এ আর কোনো অসামান্য বাফার বা অনুরোধ অবশিষ্ট থাকে না। ফ্রেমওয়ার্ক configure_streams কল করতে পারে (যেহেতু HAL স্টেট এখন শান্ত) অথবা নতুন অনুরোধ জারি করতে পারে।
মনে রাখবেন যে এটি শুধুমাত্র সম্পূর্ণ-সফল এবং সম্পূর্ণ-বিফল ফলাফলের ক্ষেত্রে সমর্থন করার জন্য যথেষ্ট। যাইহোক, আংশিক ব্যর্থতার ক্ষেত্রেও সমর্থন করা অত্যন্ত বাঞ্ছনীয়, কারণ এটি ফ্লাশ কল সামগ্রিক কর্মক্ষমতা উন্নত করতে সাহায্য করতে পারে।
কর্মক্ষমতা প্রয়োজনীয়তা:
HAL-এর এই কল থেকে 100ms এর মধ্যে ফিরে আসা উচিত এবং 1000ms মধ্যে এই কল থেকে ফিরতে হবে। এবং এই কলটি পাইপলাইন লেটেন্সির চেয়ে বেশি সময় অবরুদ্ধ করা উচিত নয় (সংজ্ঞার জন্য S7 দেখুন)।
সংস্করণ সংক্রান্ত তথ্য:
শুধুমাত্র ডিভাইস সংস্করণ >= CAMERA_DEVICE_API_VERSION_3_1 হলেই উপলব্ধ।
রিটার্ন মান:
0: ক্যামেরা HAL এর সফল ফ্লাশে।
-EINVAL: যদি ইনপুটটি ত্রুটিপূর্ণ হয় (ডিভাইসটি বৈধ নয়)।
-ENODEV: ক্যামেরা ডিভাইস একটি গুরুতর ত্রুটি সম্মুখীন হলে. এই ত্রুটিটি ফেরত দেওয়ার পরে, ফ্রেমওয়ার্ক দ্বারা শুধুমাত্র close() পদ্ধতি সফলভাবে কল করা যেতে পারে।
| void(* get_metadata_vendor_tag_ops)(const struct camera3_device *, vendor_tag_query_ops_t *ops) |
get_metadata_vendor_tag_ops:
বিক্রেতা এক্সটেনশন মেটাডেটা ট্যাগ তথ্যের জন্য অনুসন্ধানের পদ্ধতিগুলি পান৷ HAL-এর উচিত সমস্ত ভেন্ডর ট্যাগ অপারেশন পদ্ধতি পূরণ করা, অথবা কোনো ভেন্ডর ট্যাগ সংজ্ঞায়িত না থাকলে অপারেশনগুলি অপরিবর্তিত রাখা উচিত।
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 প্রয়োগ করুন।
| int(* আরম্ভ করুন)(const struct camera3_device *, const camera3_callback_ops_t *callback_ops) |
আরম্ভ করা:
HAL-এ ফ্রেমওয়ার্ক কলব্যাক ফাংশন পয়েন্টার পাস করার জন্য এক-সময়ের শুরু। অন্য কোনো ফাংশন camera3_device_ops কাঠামোতে কল করার আগে একটি সফল ওপেন() কলের পরে একবার কল করা হবে।
কর্মক্ষমতা প্রয়োজনীয়তা:
এটি একটি নন-ব্লকিং কল হওয়া উচিত। HAL-এর এই কল থেকে 5ms এর মধ্যে ফিরতে হবে, এবং এই কল থেকে 10ms এর মধ্যে ফিরতে হবে৷
রিটার্ন মান:
0: সফল শুরুতে
-এনোডেভ: যদি আরম্ভ ব্যর্থ হয়। এর পরে ফ্রেমওয়ার্ক দ্বারা শুধুমাত্র close() কে সফলভাবে বলা যেতে পারে।
| int(* process_capture_request)(const struct camera3_device *, camera3_capture_request_t *অনুরোধ) |
প্রক্রিয়া_ক্যাপচার_অনুরোধ:
HAL কে একটি নতুন ক্যাপচার অনুরোধ পাঠান৷ প্রক্রিয়া করার জন্য পরবর্তী অনুরোধ গ্রহণ করার জন্য প্রস্তুত না হওয়া পর্যন্ত HAL-এর এই কল থেকে ফিরে আসা উচিত নয়। ফ্রেমওয়ার্ক দ্বারা একটি সময়ে process_capture_request() এ শুধুমাত্র একটি কল করা হবে এবং কলগুলি একই থ্রেড থেকে হবে। একটি নতুন অনুরোধ এবং এর সংশ্লিষ্ট বাফার উপলব্ধ হওয়ার সাথে সাথে process_capture_request() এ পরবর্তী কল করা হবে। একটি সাধারণ প্রিভিউ দৃশ্যে, এর মানে হল ফ্রেমওয়ার্কের মাধ্যমে প্রায় সঙ্গে সঙ্গেই ফাংশনটিকে আবার কল করা হবে।
প্রকৃত অনুরোধ প্রক্রিয়াকরণটি অ্যাসিঙ্ক্রোনাস, ক্যাপচারের ফলাফলগুলি HAL দ্বারা প্রসেস_ক্যাপচার_রেজাল্ট() কলের মাধ্যমে ফেরত দেওয়া হয়। এই কলের জন্য ফলাফলের মেটাডেটা উপলব্ধ হওয়া প্রয়োজন, কিন্তু আউটপুট বাফারগুলি অপেক্ষা করার জন্য কেবল সিঙ্ক বেড়া সরবরাহ করতে পারে। সম্পূর্ণ আউটপুট ফ্রেম রেট বজায় রাখার জন্য একাধিক অনুরোধ একবারে ফ্লাইটে হবে বলে আশা করা হচ্ছে।
ফ্রেমওয়ার্ক অনুরোধ কাঠামোর মালিকানা ধরে রাখে। এটি শুধুমাত্র এই কলের সময় বৈধ হওয়ার নিশ্চয়তা। HAL ডিভাইসটিকে অবশ্যই ক্যাপচার প্রসেসিং এর জন্য যে তথ্যগুলো রাখতে হবে তার কপি তৈরি করতে হবে। HAL বাফারের বেড়া অপেক্ষা করা এবং বন্ধ করা এবং বাফার হ্যান্ডেলগুলিকে ফ্রেমওয়ার্কে ফিরিয়ে দেওয়ার জন্য দায়ী।
HAL-কে অবশ্যই ইনপুট বাফারের রিলিজ সিঙ্ক বেড়ার জন্য ফাইল বর্ণনাকারী লিখতে হবে input_buffer->release_fence-এ, যদি input_buffer NULL না হয়। যদি HAL ইনপুট বাফার রিলিজ সিঙ্ক বেড়ার জন্য -1 প্রদান করে, ফ্রেমওয়ার্ক অবিলম্বে ইনপুট বাফার পুনরায় ব্যবহার করার জন্য বিনামূল্যে। অন্যথায়, ইনপুট বাফার রিফিলিং এবং পুনরায় ব্যবহার করার আগে ফ্রেমওয়ার্ক সিঙ্ক বেড়ার উপর অপেক্ষা করবে।
>= CAMERA_DEVICE_API_VERSION_3_2:
প্রতিটি অনুরোধে ফ্রেমওয়ার্ক দ্বারা প্রদত্ত ইনপুট/আউটপুট বাফারগুলি একেবারে নতুন হতে পারে (এইচএএল এর আগে কখনও দেখেনি)।
কর্মক্ষমতা বিবেচনা:
একটি নতুন বাফার পরিচালনা করা অত্যন্ত হালকা হওয়া উচিত এবং কোনও ফ্রেম রেট অবক্ষয় বা ফ্রেম জীটার চালু করা উচিত নয়।
অনুরোধ করা ফ্রেম রেট টিকিয়ে রাখা যায় কিনা তা নিশ্চিত করার জন্য এই কলটি যথেষ্ট দ্রুত ফিরে আসতে হবে, বিশেষ করে স্ট্রিমিং ক্ষেত্রে (পোস্ট-প্রসেসিং কোয়ালিটি সেটিংস FAST-এ সেট করা)। HAL-এর এই কলটি 1 ফ্রেমের ব্যবধানে ফেরত দেওয়া উচিত এবং 4টি ফ্রেমের ব্যবধানে এই কল থেকে ফিরতে হবে৷
রিটার্ন মান:
0: ক্যাপচার অনুরোধ প্রক্রিয়াকরণের সফল শুরুতে
-EINVAL: যদি ইনপুটটি ত্রুটিপূর্ণ হয় (অনুমতি না থাকলে সেটিংস শূন্য থাকে, 0 আউটপুট বাফার ইত্যাদি থাকে) এবং ক্যাপচার প্রক্রিয়াকরণ শুরু করা যাবে না। অনুরোধ প্রক্রিয়াকরণের সময় ব্যর্থতা ক্যামেরা3_callback_ops_t.notify() কল করে পরিচালনা করা উচিত। এই ত্রুটির ক্ষেত্রে, কাঠামোটি স্ট্রীম বাফারের বেড়া এবং বাফার হ্যান্ডলগুলির জন্য দায়িত্ব বজায় রাখবে; HAL-এর বেড়া বন্ধ করা উচিত নয় বা প্রক্রিয়া_ক্যাপচার_ফলাফল দিয়ে এই বাফারগুলি ফেরত দেওয়া উচিত নয়।
-ENODEV: ক্যামেরা ডিভাইস একটি গুরুতর ত্রুটি সম্মুখীন হলে. এই ত্রুটিটি ফেরত দেওয়ার পরে, ফ্রেমওয়ার্ক দ্বারা শুধুমাত্র close() পদ্ধতি সফলভাবে কল করা যেতে পারে।
| 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 আবার কল করা হবে না ।
ফ্রেমওয়ার্কটি প্রথম ক্যাপচার অনুরোধ জমা দেওয়ার আগে সমস্ত কনফিগার করা স্ট্রিমগুলির জন্য বাফার নিবন্ধন করার প্রয়োজন নেই৷ এটি পূর্বরূপ (বা অনুরূপ ব্যবহারের ক্ষেত্রে) জন্য দ্রুত স্টার্টআপের অনুমতি দেয় যখন অন্যান্য স্ট্রীমগুলি এখনও বরাদ্দ করা হচ্ছে।
এই পদ্ধতিটি এইচএএল ডিভাইসকে ম্যাপ বা অন্যথায় পরবর্তী ব্যবহারের জন্য বাফার প্রস্তুত করার অনুমতি দেওয়ার উদ্দেশ্যে করা হয়েছে। পাস করা বাফারগুলি ইতিমধ্যেই ব্যবহারের জন্য লক করা হবে৷ কলের শেষে, সমস্ত বাফার অবশ্যই প্রবাহে ফিরে যাওয়ার জন্য প্রস্তুত থাকতে হবে। বাফার_সেট আর্গুমেন্ট শুধুমাত্র এই কলের সময়কালের জন্য বৈধ।
যদি স্ট্রিম ফর্ম্যাটটি HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED-এ সেট করা থাকে, তাহলে ক্যামেরা HAL-এর উচিত যে কোনো প্ল্যাটফর্ম-প্রাইভেট পিক্সেল ফর্ম্যাট তথ্য নির্ধারণ করতে এখানে পাস-ইন বাফারগুলি পরীক্ষা করা।
কর্মক্ষমতা প্রয়োজনীয়তা:
এটি একটি নন-ব্লকিং কল হওয়া উচিত। HAL-এর এই কল থেকে 1ms-এর মধ্যে ফিরতে হবে, এবং এই কল থেকে 5ms-এর মধ্যে ফিরতে হবে।
রিটার্ন মান:
0: নতুন স্ট্রীম বাফারের সফল নিবন্ধন
-EINVAL: যদি stream_buffer_set একটি বৈধ সক্রিয় স্ট্রীম উল্লেখ না করে, অথবা যদি বাফার অ্যারে অবৈধ হয়।
-এনওমেম: যদি বাফারগুলি নিবন্ধন করতে ব্যর্থ হয়। ফ্রেমওয়ার্ককে অবশ্যই সমস্ত স্ট্রিম বাফারগুলিকে অনিবন্ধিত হিসাবে বিবেচনা করতে হবে এবং পরে আবার নিবন্ধন করার চেষ্টা করতে পারে৷
-ENODEV: যদি একটি মারাত্মক ত্রুটি থাকে, এবং ডিভাইসটি আর চালু হয় না। এই ত্রুটিটি ফিরে আসার পরে ফ্রেমওয়ার্ক দ্বারা শুধুমাত্র close() কে সফলভাবে কল করা যেতে পারে।
এই কাঠামোর জন্য ডকুমেন্টেশন নিম্নলিখিত ফাইল থেকে তৈরি করা হয়েছিল:
- hardware/libhardware/include/hardware/ camera3.h