ক্যামেরা HAL3 বাফার ম্যানেজমেন্ট API

অ্যান্ড্রয়েড 10 ঐচ্ছিক ক্যামেরা HAL3 বাফার ম্যানেজমেন্ট APIগুলি প্রবর্তন করে যা আপনাকে বিভিন্ন মেমরি অর্জন করতে এবং ক্যামেরা HAL বাস্তবায়নে লেটেন্সি ট্রেডঅফগুলি ক্যাপচার করতে বাফার ম্যানেজমেন্ট লজিক প্রয়োগ করতে দেয়৷

ক্যামেরা HAL এর পাইপলাইনে সারিবদ্ধ N অনুরোধগুলি (যেখানে N পাইপলাইনের গভীরতার সমান) প্রয়োজন, তবে এটি প্রায়শই একই সময়ে আউটপুট বাফারগুলির সমস্ত N সেটের প্রয়োজন হয় না।

উদাহরণস্বরূপ, পাইপলাইনে HAL-এর আটটি অনুরোধ সারিবদ্ধ থাকতে পারে, কিন্তু পাইপলাইনের শেষ পর্যায়ে দুটি অনুরোধের জন্য শুধুমাত্র আউটপুট বাফারের প্রয়োজন। অ্যান্ড্রয়েড 9 এবং তার নিচের ডিভাইসগুলিতে, ক্যামেরা ফ্রেমওয়ার্ক বাফারগুলি বরাদ্দ করে যখন অনুরোধটি HAL-এ সারিবদ্ধ থাকে যাতে HAL-এ ছয় সেট বাফার থাকতে পারে যেগুলি ব্যবহার করা হয় না৷ অ্যান্ড্রয়েড 10-এ, ক্যামেরা HAL3 বাফার ম্যানেজমেন্ট এপিআই ছয় সেট বাফার মুক্ত করতে আউটপুট বাফারগুলির ডিকপলিং করার অনুমতি দেয়। এটি হাই-এন্ড ডিভাইসগুলিতে শত শত মেগাবাইট মেমরি সঞ্চয় করতে পারে এবং কম মেমরির ডিভাইসগুলির জন্যও উপকারী হতে পারে।

চিত্র 1 এন্ড্রয়েড 9 এবং তার নীচের সংস্করণে চলমান ডিভাইসগুলির জন্য ক্যামেরা HAL ইন্টারফেসের একটি চিত্র দেখায়৷ চিত্র 2 Android 10-এ ক্যামেরা HAL3 বাফার ম্যানেজমেন্ট এপিআই প্রয়োগ করে ক্যামেরা HAL ইন্টারফেস দেখায়।

9 বা তার কম সময়ে বাফার ব্যবস্থাপনা

চিত্র 1. অ্যান্ড্রয়েড 9 এবং তার নিচের ক্যামেরা HAL ইন্টারফেস

Android 10 এ বাফার ম্যানেজমেন্ট

চিত্র 2. বাফার ম্যানেজমেন্ট API ব্যবহার করে Android 10-এ ক্যামেরা HAL ইন্টারফেস

বাফার ম্যানেজমেন্ট এপিআই প্রয়োগ করুন

বাফার ম্যানেজমেন্ট APIs বাস্তবায়ন করতে, ক্যামেরা HAL-কে অবশ্যই:

ক্যামেরা HAL ICameraDeviceCallback.hal এ requestStreamBuffers এবং returnStreamBuffers পদ্ধতি ব্যবহার করে বাফারের অনুরোধ করতে এবং ফেরত দেয়। HAL কে অবশ্যই ICameraDeviceSession.hal এ signalStreamFlush পদ্ধতি প্রয়োগ করতে হবে যাতে ক্যামেরা HAL কে বাফার ফেরত দেওয়ার জন্য সংকেত দেয়।

অনুরোধ স্ট্রিমবাফার

ক্যামেরা ফ্রেমওয়ার্ক থেকে বাফারের অনুরোধ করতে requestStreamBuffers পদ্ধতি ব্যবহার করুন। ক্যামেরা HAL3 বাফার ম্যানেজমেন্ট এপিআই ব্যবহার করার সময়, ক্যামেরা ফ্রেমওয়ার্ক থেকে ক্যাপচারের অনুরোধে আউটপুট বাফার থাকে না, অর্থাৎ StreamBuffer bufferId ক্ষেত্রটি হল 0 । অতএব, ক্যামেরা ফ্রেমওয়ার্ক থেকে বাফারের অনুরোধ করতে ক্যামেরা HAL-কে অবশ্যই requestStreamBuffers ব্যবহার করতে হবে।

requestStreamBuffers পদ্ধতি কলকারীকে একক কলে একাধিক আউটপুট স্ট্রীম থেকে একাধিক বাফারের অনুরোধ করতে দেয়, কম HIDL IPC কলের অনুমতি দেয়। যাইহোক, একই সময়ে আরও বাফারের অনুরোধ করা হলে কলগুলি আরও বেশি সময় নেয় এবং এটি মোট অনুরোধ-থেকে-ফলাফল লেটেন্সিকে নেতিবাচকভাবে প্রভাবিত করতে পারে। এছাড়াও, যেহেতু requestStreamBuffers কলগুলি ক্যামেরা পরিষেবাতে সিরিয়ালাইজ করা হয়, তাই বাফারগুলির অনুরোধ করার জন্য ক্যামেরা HAL একটি ডেডিকেটেড উচ্চ-প্রধান থ্রেড ব্যবহার করার পরামর্শ দেওয়া হয়।

যদি একটি বাফার অনুরোধ ব্যর্থ হয়, ক্যামেরা HAL অবশ্যই অপ্রত্যাশিত ত্রুটিগুলি সঠিকভাবে পরিচালনা করতে সক্ষম হবে। নিম্নলিখিত তালিকাটি সাধারণ কারণগুলি বর্ণনা করে যেগুলি বাফার অনুরোধগুলি ব্যর্থ হয় এবং কীভাবে সেগুলি ক্যামেরা HAL দ্বারা পরিচালনা করা উচিত৷

  • অ্যাপটি আউটপুট স্ট্রীম থেকে সংযোগ বিচ্ছিন্ন করে: এটি একটি মারাত্মক ত্রুটি। একটি সংযোগ বিচ্ছিন্ন স্ট্রীম লক্ষ্য করে যে কোনো ক্যাপচার অনুরোধের জন্য ক্যামেরা HAL কে ERROR_REQUEST পাঠাতে হবে এবং পরবর্তী অনুরোধগুলি সাধারণত প্রক্রিয়া করার জন্য প্রস্তুত থাকতে হবে।
  • সময়সীমা: এটি ঘটতে পারে যখন কোনো অ্যাপ কিছু বাফার ধরে রেখে নিবিড় প্রক্রিয়াকরণে ব্যস্ত থাকে। ক্যামেরা HAL কে ক্যাপচারের অনুরোধের জন্য ERROR_REQUEST পাঠাতে হবে যা একটি টাইমআউট ত্রুটির কারণে পূরণ করা যাবে না এবং পরবর্তী অনুরোধগুলি স্বাভাবিকভাবে প্রক্রিয়া করার জন্য প্রস্তুত থাকতে হবে।
  • ক্যামেরা ফ্রেমওয়ার্ক একটি নতুন স্ট্রিম কনফিগারেশন প্রস্তুত করছে: requestStreamBuffers আবার কল করার আগে ক্যামেরা HAL-এর পরবর্তী configureStreams কল সম্পূর্ণ না হওয়া পর্যন্ত অপেক্ষা করা উচিত।
  • ক্যামেরা HAL তার বাফার সীমাতে পৌঁছেছে ( maxBuffers ক্ষেত্র): ক্যামেরা HAL-এর অপেক্ষা করা উচিত যতক্ষণ না এটি স্ট্রিমের অন্তত একটি বাফার ফেরত না আসা পর্যন্ত requestStreamBuffers আবার কল করার আগে।

রিটার্ন স্ট্রিমবাফার

ক্যামেরা ফ্রেমওয়ার্কে অতিরিক্ত বাফার ফেরত দিতে returnStreamBuffers পদ্ধতি ব্যবহার করুন। ক্যামেরা HAL সাধারণত processCaptureResult পদ্ধতির মাধ্যমে ক্যামেরা ফ্রেমওয়ার্কে বাফার ফেরত দেয়, কিন্তু এটি শুধুমাত্র ক্যামেরা HAL-এ পাঠানো ক্যাপচার অনুরোধের জন্য অ্যাকাউন্ট করতে পারে। requestStreamBuffers পদ্ধতির সাহায্যে, ক্যামেরা HAL বাস্তবায়নের জন্য ক্যামেরা ফ্রেমওয়ার্কের অনুরোধের চেয়ে বেশি বাফার ধরে রাখা সম্ভব। এটি হল যখন returnStreamBuffers পদ্ধতি ব্যবহার করা উচিত। যদি HAL বাস্তবায়নে অনুরোধের চেয়ে বেশি বাফার না থাকে তবে ক্যামেরা HAL বাস্তবায়নের জন্য returnStreamBuffers পদ্ধতিতে কল করার প্রয়োজন নেই।

সিগন্যালস্ট্রিমফ্লাশ

signalStreamFlush পদ্ধতিটি ক্যামেরা ফ্রেমওয়ার্ক দ্বারা ফোন করা হয় যাতে ক্যামেরা HAL কে সমস্ত বাফার ফেরত দেওয়ার জন্য অবহিত করা হয়। এটি সাধারণত বলা হয় যখন ক্যামেরা ফ্রেমওয়ার্ক configureStreams কল করতে চলেছে এবং অবশ্যই ক্যামেরা ক্যাপচার পাইপলাইন ড্রেন করতে হবে। returnStreamBuffers পদ্ধতির মতো, যদি একটি ক্যামেরা HAL বাস্তবায়ন অনুরোধের চেয়ে বেশি বাফার না রাখে, তাহলে এই পদ্ধতির একটি খালি বাস্তবায়ন করা সম্ভব।

ক্যামেরা ফ্রেমওয়ার্ক signalStreamFlush কল করার পরে, সমস্ত বাফার ক্যামেরা ফ্রেমওয়ার্কে ফিরে না আসা পর্যন্ত ফ্রেমওয়ার্ক ক্যামেরা HAL-কে নতুন ক্যাপচার অনুরোধ পাঠানো বন্ধ করে দেয়। যখন সমস্ত বাফার ফেরত দেওয়া হয়, requestStreamBuffers পদ্ধতির কলগুলি ব্যর্থ হয় এবং ক্যামেরা ফ্রেমওয়ার্ক একটি পরিষ্কার অবস্থায় তার কাজ চালিয়ে যেতে পারে। ক্যামেরা ফ্রেমওয়ার্ক তখন configureStreams বা processCaptureRequest পদ্ধতিতে কল করে। ক্যামেরা ফ্রেমওয়ার্ক configureStreams পদ্ধতিতে কল করলে, configureStreams কল সফলভাবে ফিরে আসার পরে ক্যামেরা HAL আবার বাফারের অনুরোধ করা শুরু করতে পারে। যদি ক্যামেরা ফ্রেমওয়ার্ক processCaptureRequest পদ্ধতিতে কল করে, ক্যামেরা HAL processCaptureRequest কল চলাকালীন বাফারের অনুরোধ করা শুরু করতে পারে।

signalStreamFlush পদ্ধতি এবং flush পদ্ধতির জন্য শব্দার্থবিদ্যা আলাদা। যখন flush পদ্ধতি বলা হয়, HAL যত তাড়াতাড়ি সম্ভব পাইপলাইন নিষ্কাশন করার জন্য ERROR_REQUEST সাথে মুলতুবি থাকা ক্যাপচার অনুরোধগুলি বাতিল করতে পারে। যখন signalStreamFlush পদ্ধতিটি কল করা হয়, তখন HAL কে অবশ্যই সমস্ত মুলতুবি থাকা ক্যাপচার অনুরোধগুলি স্বাভাবিকভাবে শেষ করতে হবে এবং ক্যামেরা ফ্রেমওয়ার্কে সমস্ত বাফার ফিরিয়ে দিতে হবে।

signalStreamFlush পদ্ধতি এবং অন্যান্য পদ্ধতির মধ্যে আরেকটি পার্থক্য হল যে signalStreamFlush হল একটি একমুখী HIDL পদ্ধতি, যার মানে হল HAL signalStreamFlush কল পাওয়ার আগে ক্যামেরা ফ্রেমওয়ার্ক অন্যান্য ব্লকিং APIগুলিতে কল করতে পারে। এর মানে হল যে signalStreamFlush পদ্ধতি এবং অন্যান্য পদ্ধতিগুলি (বিশেষত configureStreams পদ্ধতি) ক্যামেরা ফ্রেমওয়ার্কে যে ক্রমটি বলা হয়েছিল তার চেয়ে ভিন্ন ক্রমে ক্যামেরা HAL-এ পৌঁছাতে পারে৷ এই অ্যাসিঙ্ক্রোনি সমস্যাটি সমাধান করার জন্য, streamConfigCounter ক্ষেত্রটি StreamConfiguration যুক্ত করা হয়েছিল এবং signalStreamFlush পদ্ধতিতে একটি যুক্তি হিসাবে যুক্ত করা হয়েছিল। একটি signalStreamFlush কল তার সংশ্লিষ্ট configureStreams কলের চেয়ে পরে আসে কিনা তা নির্ধারণ করতে ক্যামেরা HAL বাস্তবায়নের streamConfigCounter আর্গুমেন্ট ব্যবহার করা উচিত। একটি উদাহরণের জন্য চিত্র 3 দেখুন।

দেরিতে আসা কলগুলি পরিচালনা করা

চিত্র 3. ক্যামেরা HAL কীভাবে দেরিতে আসা সিগন্যালস্ট্রিমফ্লাশ কলগুলি সনাক্ত এবং পরিচালনা করবে

বাফার ম্যানেজমেন্ট এপিআই প্রয়োগ করার সময় আচরণ পরিবর্তন হয়

বাফার ম্যানেজমেন্ট লজিক বাস্তবায়নের জন্য বাফার ম্যানেজমেন্ট API ব্যবহার করার সময়, ক্যামেরা এবং ক্যামেরা HAL বাস্তবায়নে নিম্নলিখিত সম্ভাব্য আচরণ পরিবর্তনগুলি বিবেচনা করুন:

  • ক্যামেরা HAL-এ ক্যাপচারের অনুরোধগুলি দ্রুত এবং আরও ঘন ঘন আসে: বাফার ম্যানেজমেন্ট API ছাড়া, ক্যামেরা HAL-এ ক্যাপচার অনুরোধ পাঠানোর আগে ক্যামেরা ফ্রেমওয়ার্ক প্রতিটি ক্যাপচার অনুরোধের জন্য আউটপুট বাফারের অনুরোধ করে। বাফার ম্যানেজমেন্ট এপিআই ব্যবহার করার সময়, ক্যামেরা ফ্রেমওয়ার্ককে আর বাফারের জন্য অপেক্ষা করতে হবে না এবং তাই আগে ক্যামেরা HAL কে ক্যাপচারের অনুরোধ পাঠাতে পারে।

    এছাড়াও, বাফার ম্যানেজমেন্ট এপিআই ছাড়া, ক্যামেরা ফ্রেমওয়ার্ক ক্যাপচার অনুরোধ পাঠানো বন্ধ করে দেয় যদি ক্যাপচার অনুরোধের আউটপুট স্ট্রীমগুলির মধ্যে একটি HAL এক সময়ে ধরে রাখতে পারে এমন বাফারগুলির সর্বাধিক সংখ্যায় পৌঁছে যায় (এই মানটি ক্যামেরা HAL দ্বারা HalStream::maxBuffers ক্ষেত্রে একটি configureStreams কলের রিটার্ন মানের মধ্যে মনোনীত করা হয়েছে)। বাফার ম্যানেজমেন্ট API-এর সাথে, এই থ্রোটলিং আচরণটি আর বিদ্যমান নেই এবং HAL-এর কাছে অনেকগুলি ক্যাপচার অনুরোধ সারিবদ্ধ থাকলে ক্যামেরা HAL বাস্তবায়ন processCaptureRequest কলগুলি গ্রহণ করবে না।

  • requestStreamBuffers কল লেটেন্সি উল্লেখযোগ্যভাবে পরিবর্তিত হয়: একটি requestStreamBuffers কল গড়ের চেয়ে বেশি সময় নিতে পারে এমন অনেক কারণ রয়েছে। যেমন:

    • একটি নতুন তৈরি স্ট্রিমের প্রথম কয়েকটি বাফারের জন্য, কলগুলি বেশি সময় নিতে পারে কারণ ডিভাইসটিকে মেমরি বরাদ্দ করতে হবে৷
    • প্রতিটি কলে অনুরোধ করা বাফারের সংখ্যার অনুপাতে প্রত্যাশিত লেটেন্সি বৃদ্ধি পায়।
    • অ্যাপটি বাফার ধরে আছে এবং প্রক্রিয়াকরণে ব্যস্ত। এটি বাফারের অভাব বা ব্যস্ত CPU এর কারণে বাফার অনুরোধগুলিকে ধীর করতে বা টাইমআউটকে আঘাত করতে পারে।

বাফার ব্যবস্থাপনা কৌশল

বাফার ম্যানেজমেন্ট এপিআই বিভিন্ন ধরনের বাফার ম্যানেজমেন্ট কৌশল বাস্তবায়নের অনুমতি দেয়। কিছু উদাহরণ হল:

  • ব্যাকওয়ার্ড সামঞ্জস্যপূর্ণ: HAL processCaptureRequest কলের সময় একটি ক্যাপচার অনুরোধের জন্য বাফারের অনুরোধ করে। এই কৌশলটি কোনো মেমরি সঞ্চয় প্রদান করে না, তবে বাফার ম্যানেজমেন্ট API-এর প্রথম বাস্তবায়ন হিসাবে কাজ করতে পারে, বিদ্যমান ক্যামেরা HAL-তে খুব কম কোড পরিবর্তনের প্রয়োজন।
  • সর্বাধিক মেমরি সঞ্চয়: ক্যামেরা HAL শুধুমাত্র একটি পূরণ করার আগে অবিলম্বে আউটপুট বাফারের অনুরোধ করে। এই কৌশলটি সর্বাধিক মেমরি সঞ্চয় করার অনুমতি দেয়। সম্ভাব্য নেতিবাচক দিক হল আরও ক্যামেরা পাইপলাইন জ্যাঙ্ক যখন বাফার অনুরোধগুলি শেষ হতে অস্বাভাবিকভাবে দীর্ঘ সময় নেয়।
  • ক্যাশে: ক্যামেরা HAL কয়েকটি বাফার ক্যাশে করে যাতে এটি মাঝে মাঝে ধীরগতির বাফার অনুরোধ দ্বারা প্রভাবিত হওয়ার সম্ভাবনা কম থাকে।

ক্যামেরা HAL বিশেষ ব্যবহারের ক্ষেত্রে বিভিন্ন কৌশল অবলম্বন করতে পারে, উদাহরণস্বরূপ, প্রচুর মেমরি ব্যবহার করে এমন ব্যবহারের ক্ষেত্রে সর্বাধিক মেমরি সংরক্ষণের কৌশল ব্যবহার করা এবং অন্যান্য ব্যবহারের ক্ষেত্রে ব্যাকওয়ার্ড-সামঞ্জস্যপূর্ণ কৌশল ব্যবহার করা।

বহিরাগত ক্যামেরা HAL-এ নমুনা বাস্তবায়ন

বাহ্যিক ক্যামেরা এইচএএল অ্যান্ড্রয়েড 9 এ চালু করা হয়েছিল এবং hardware/interfaces/camera/device/3.5/ সোর্স ট্রিতে পাওয়া যাবে। অ্যান্ড্রয়েড 10-এ, এটিকে ExternalCameraDeviceSession.cpp cpp অন্তর্ভুক্ত করার জন্য আপডেট করা হয়েছে, যা বাফার ম্যানেজমেন্ট API-এর একটি বাস্তবায়ন। এই বাহ্যিক ক্যামেরা HAL C++ কোডের কয়েকশ লাইনে বাফার ম্যানেজমেন্ট কৌশলগুলিতে উল্লিখিত সর্বাধিক মেমরি সঞ্চয় কৌশল প্রয়োগ করে।