رمزگذاری رسانه سازگار

تبدیل فرمت سازگار با رسانه‌ها که در اندروید ۱۲ معرفی شد، قابلیتی است که به دستگاه‌ها اجازه می‌دهد از فرمت‌های رسانه‌ای مدرن‌تر و کم‌مصرف‌تر برای ضبط ویدیو، مانند HEVC، استفاده کنند و در عین حال سازگاری با برنامه‌ها را حفظ کنند. با این ویژگی، تولیدکنندگان دستگاه می‌توانند به طور پیش‌فرض از HEVC به جای AVC استفاده کنند تا کیفیت ویدیو را بهبود بخشند و در عین حال نیازهای ذخیره‌سازی و پهنای باند را کاهش دهند. برای دستگاه‌هایی که تبدیل فرمت سازگار با رسانه‌ها فعال است، اندروید می‌تواند به طور خودکار ویدیوهای ضبط شده با فرمت‌هایی مانند HEVC یا HDR را هنگام باز شدن توسط برنامه‌ای که از این فرمت پشتیبانی نمی‌کند، تبدیل کند. این امر به برنامه‌ها اجازه می‌دهد حتی زمانی که ویدیوها با فرمت‌های جدیدتر در دستگاه ضبط می‌شوند، کار کنند.

قابلیت تبدیل کد رسانه‌های سازگار به طور پیش‌فرض غیرفعال است. برای درخواست تبدیل کد رسانه‌ها، برنامه‌ها باید قابلیت‌های رسانه‌ای خود را اعلام کنند. برای اطلاعات بیشتر در مورد اعلام قابلیت‌های رسانه‌ای، به بخش تبدیل کد رسانه‌های سازگار در سایت توسعه‌دهندگان اندروید مراجعه کنید.

چگونه کار می‌کند؟

ویژگی تبدیل کد رسانه‌های سازگار از دو بخش اصلی تشکیل شده است:

  • سرویس‌های تبدیل کد در چارچوب رسانه: این سرویس‌ها با استفاده از سخت‌افزار، فایل‌ها را از یک فرمت به فرمت دیگر تبدیل می‌کنند تا تأخیر کم و کیفیت تبدیل بالا باشد. این شامل API تبدیل کد، سرویس تبدیل کد، یک افزونه OEM برای فیلترهای سفارشی و سخت‌افزار می‌شود. برای جزئیات بیشتر، به نمای کلی معماری مراجعه کنید.
  • ویژگی تبدیل کد سازگار با رسانه در ارائه‌دهندگان رسانه: این مؤلفه که در ارائه‌دهندگان رسانه یافت می‌شود، برنامه‌هایی را که به فایل‌های رسانه‌ای دسترسی دارند، رهگیری می‌کند و یا فایل اصلی یا یک فایل تبدیل کد شده را بر اساس قابلیت‌های اعلام شده برنامه ارائه می‌دهد. اگر برنامه‌ای از فرمت فایل رسانه‌ای پشتیبانی کند، نیازی به مدیریت خاصی نیست. اگر برنامه‌ای از این فرمت پشتیبانی نکند، چارچوب هنگام دسترسی برنامه به فایل، آن را به فرمت قدیمی‌تری مانند AVC تبدیل می‌کند.

شکل ۱ نمای کلی از فرآیند تبدیل کد رسانه را نشان می‌دهد.

فرآیند تبدیل کد رسانه‌های سازگار

شکل ۱. مروری بر کدگذاری سازگار رسانه‌ها.

فرمت‌های پشتیبانی‌شده

قابلیت تبدیل فرمت سازگار با رسانه، از تبدیل فرمت‌های زیر پشتیبانی می‌کند:

  • HEVC (8 بیتی) به AVC: تبدیل کدک از طریق اتصال یک رمزگشای کدک رسانه و یک رمزگذار کد رسانه انجام می‌شود.
  • HDR10+ (10 بیتی) به AVC (SDR): تبدیل‌های HDR به SDR با استفاده از نمونه‌های مدیاک و یک افزونه‌ی فروشنده که به نمونه‌های دیکدر متصل می‌شود، انجام می‌شود. برای اطلاعات بیشتر، به کدگذاری HDR به SDR مراجعه کنید.

منابع محتوای پشتیبانی‌شده

قابلیت تبدیل فرمت سازگار با رسانه، از رسانه‌های تولید شده توسط برنامه دوربین اصلی OEM که در پوشه DCIM/Camera/ در درایو خارجی اصلی ذخیره می‌شوند، پشتیبانی می‌کند. این قابلیت از رسانه‌های موجود در حافظه ثانویه پشتیبانی نمی‌کند. محتوایی که از طریق ایمیل یا کارت‌های SD به دستگاه‌ها ارسال می‌شود، پشتیبانی نمی‌شود.

برنامه‌ها بر اساس مسیرهای فایل مختلف به فایل‌ها دسترسی پیدا می‌کنند. در ادامه مسیرهای فایلی که در آن‌ها قابلیت تبدیل کد فعال یا غیرفعال است، شرح داده شده است:

  • فعال‌سازی ترانس‌کدینگ:

    • دسترسی به برنامه از طریق API های MediaStore
    • دسترسی به برنامه از طریق APIهای مسیر فایل مستقیم شامل جاوا و کد بومی
    • دسترسی به برنامه از طریق چارچوب دسترسی به فضای ذخیره‌سازی (SAF)
    • دسترسی به برنامه از طریق Intentهای صفحه اشتراک‌گذاری سیستم عامل. (فقط آدرس MediaStore)
    • انتقال فایل MTP/PTP از گوشی به کامپیوتر

  • گذر از کدگذاری:

    • انتقال فایل از دستگاه با خارج کردن کارت SD
    • انتقال فایل‌ها از دستگاهی به دستگاه دیگر با استفاده از گزینه‌هایی مانند Nearby Share یا Bluetooth transfer.

اضافه کردن مسیرهای فایل سفارشی برای تبدیل کد

تولیدکنندگان دستگاه می‌توانند به صورت اختیاری مسیرهای فایل را برای کدگذاری رسانه در زیر دایرکتوری DCIM/ اضافه کنند. هر مسیری خارج از دایرکتوری DCIM/ رد می‌شود. افزودن چنین مسیرهای فایلی ممکن است برای برآورده کردن الزامات اپراتور یا مقررات محلی لازم باشد.

برای افزودن مسیر فایل، از تابع transcode path runtime resource overlay (RRO) و config_supported_transcoding_relative_paths استفاده کنید. در زیر مثالی از نحوه افزودن مسیر فایل آمده است:

<string-array name="config_supported_transcoding_relative_paths" translatable="false">
    <item>DCIM/JCF/</item>
</string-array>

برای تأیید مسیرهای فایل پیکربندی شده، از دستور زیر استفاده کنید:

adb shell dumpsys activity provider com.google.android.providers.media.module/com.android.providers.media.MediaProvider | head -n 20

نمای کلی معماری

این بخش معماری ویژگی تبدیل کد رسانه را شرح می‌دهد.

معماری-رمزگشایی-رسانه

شکل ۲. معماری کدگذاری رسانه.

معماری کدگذاری رسانه از اجزای زیر تشکیل شده است:

  • رابط برنامه‌نویسی کاربردی سیستم MediaTranscodingManager: رابطی که به کلاینت اجازه می‌دهد با سرویس MediaTranscoding ارتباط برقرار کند. ماژول MediaProvider از این رابط برنامه‌نویسی کاربردی استفاده می‌کند.
  • MediaTranscodingService: سرویس بومی که ارتباطات کلاینت را مدیریت می‌کند، درخواست‌های تبدیل کد را زمان‌بندی می‌کند و حسابداری TranscodingSessions را مدیریت می‌کند.
  • MediaTranscoder: کتابخانه بومی که عمل تبدیل کد را انجام می‌دهد. این کتابخانه بر پایه چارچوب رسانه‌ای NDK ساخته شده است تا با ماژول‌ها سازگار باشد.

ویژگی تبدیل کد سازگار رسانه، معیارهای تبدیل کد را هم در سرویس و هم در تبدیل کد رسانه ثبت می‌کند. کدهای سمت کلاینت و سمت سرویس در ماژول MediaProvider قرار دارند تا امکان رفع اشکال و به‌روزرسانی‌های به‌موقع فراهم شود.

دسترسی به فایل

کدگذاری سازگار رسانه بر روی سیستم فایل Filesystem in Userspace (FUSE) ساخته شده است که برای ذخیره‌سازی محدود استفاده می‌شود. FUSE ماژول MediaProvider را قادر می‌سازد تا عملیات فایل را در فضای کاربر بررسی کند و بر اساس سیاست اجازه، رد یا محدود کردن دسترسی، دسترسی به فایل‌ها را مسدود کند.

وقتی یک برنامه سعی می‌کند به یک فایل دسترسی پیدا کند، سرویس FUSE دسترسی خواندن فایل را از برنامه قطع می‌کند. اگر برنامه از فرمت جدیدتری (مانند HEVC) پشتیبانی کند، فایل اصلی بازگردانده می‌شود. اگر برنامه از این فرمت پشتیبانی نکند، فایل به فرمت قدیمی‌تر (مانند AVC) تبدیل کد می‌شود یا اگر نسخه تبدیل کد شده موجود باشد، از حافظه پنهان بازگردانده می‌شود.

درخواست فایل‌های تبدیل‌شده

قابلیت تبدیل کد رسانه‌های سازگار به طور پیش‌فرض غیرفعال است. برنامه‌ها می‌توانند با استفاده از گزینه‌های زیر، فایل‌های تبدیل کد شده را درخواست کنند:

  • فرمت‌های پشتیبانی نشده را در فایل مانیفست اعلام کنید. برای جزئیات بیشتر، به بخش «اعلان قابلیت‌ها در یک منبع» و «اعلان قابلیت‌ها در کد» مراجعه کنید.
  • قالب‌های پشتیبانی‌شده با چارچوب سازگاری برنامه را در زمان اجرا غیرفعال کنید (کاربران همچنین می‌توانند این را برای هر برنامه در تنظیمات غیرفعال کنند).
  • یک فایل را با MediaStore باز کنید در حالی که فرمت‌های پشتیبانی نشده را به طور صریح با API openTypedAssetFileDescriptor مشخص می‌کنید.

برای انتقال از طریق USB (دستگاه به کامپیوتر)، کدگذاری به طور پیش‌فرض غیرفعال است، اما کاربران می‌توانند با استفاده از گزینه‌ی «تبدیل ویدیوها به AVC» در صفحه‌ی تنظیمات USB Preferences ، همانطور که در شکل ۳ نشان داده شده است، کدگذاری را فعال کنند.

برای فعال کردن تبدیل کد رسانه، دکمه را فشار دهید

شکل ۳. فعال کردن تبدیل کد رسانه در صفحه تنظیمات USB.

محدودیت‌های درخواست فایل‌های تبدیل‌شده

برای جلوگیری از قفل شدن منابع سیستم توسط درخواست‌های تبدیل کد برای مدت طولانی، برنامه‌هایی که درخواست جلسات تبدیل کد دارند، به موارد زیر محدود می‌شوند:

  • ۱۰ جلسه متوالی
  • زمان کل اجرا سه دقیقه

اگر یک برنامه از همه این محدودیت‌ها فراتر رود، چارچوب، توصیفگر فایل اصلی را برمی‌گرداند.

الزامات دستگاه

برای پشتیبانی از قابلیت تبدیل فرمت سازگار رسانه‌ها، دستگاه‌ها باید شرایط زیر را داشته باشند:

  • رمزگذاری HEVC به طور پیش‌فرض در برنامه دوربین اصلی دستگاه فعال است.
  • (دستگاه‌هایی که از تبدیل HDR به SDR پشتیبانی می‌کنند) دستگاه از ضبط ویدیوی HDR پشتیبانی می‌کند

برای اطمینان از عملکرد دستگاه برای تبدیل کد رسانه، سخت‌افزار ویدئو و عملکرد دسترسی خواندن/نوشتن حافظه باید بهینه شوند. هنگامی که کدک‌های رسانه با اولویت برابر با 1 پیکربندی می‌شوند، کدک‌ها باید با بالاترین توان عملیاتی ممکن عمل کنند. توصیه می‌کنیم عملکرد تبدیل کد حداقل به ۲۰۰ فریم در ثانیه برسد. برای آزمایش عملکرد سخت‌افزار خود، معیار تبدیل کد رسانه را در frameworks/av/media/libmediatranscoding/transcoder/benchmark اجرا کنید.

اعتبارسنجی

برای تأیید قابلیت تبدیل کد رسانه سازگار، آزمایش‌های CTS زیر را اجرا کنید:

  • android.media.mediatranscoding.cts
  • android.mediaprovidertranscode.cts

فعال کردن تبدیل کد رسانه به صورت سراسری

برای آزمایش چارچوب تبدیل کد رسانه یا رفتار برنامه با تبدیل کد، می‌توانید ویژگی تبدیل کد سازگار رسانه را به صورت سراسری فعال یا غیرفعال کنید. در صفحه تنظیمات > سیستم > توسعه‌دهنده > گزینه‌های توسعه‌دهنده تبدیل کد رسانه ، گزینه « رد کردن پیش‌فرض‌های تبدیل کد» را روی روشن قرار دهید و سپس گزینه «فعال کردن تبدیل کد» را روی روشن یا خاموش تنظیم کنید. اگر این تنظیم فعال باشد، تبدیل کد رسانه ممکن است در پس‌زمینه برای برنامه‌هایی غیر از برنامه‌ای که در حال توسعه آن هستید، رخ دهد.

بررسی وضعیت ترانس‌کدینگ

در حین آزمایش، می‌توانید از دستور ADB shell زیر برای بررسی وضعیت ترانس‌کدینگ، شامل جلسات ترانس‌کدینگ فعلی و گذشته، استفاده کنید:

adb shell dumpsys media.transcoding

افزایش محدودیت طول ویدیو

برای آزمایش، می‌توانید با استفاده از دستور زیر، محدودیت طول یک دقیقه‌ای ویدیو برای تبدیل کد را افزایش دهید. ممکن است پس از اجرای این دستور، راه‌اندازی مجدد لازم باشد.

adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>

منبع و مراجع AOSP

موارد زیر کد منبع AOSP مربوط به کدگذاری سازگار با رسانه‌ها است.

تبدیل HDR به SDR

برای پشتیبانی از کدگذاری HDR به SDR، تولیدکنندگان دستگاه می‌توانند از افزونه فیلتر AOSP sample Codec 2.0 واقع در /platform/frameworks/av/media/codec2/hidl/plugin/ استفاده کنند. این بخش نحوه عملکرد افزونه فیلتر، نحوه پیاده‌سازی افزونه و نحوه آزمایش افزونه را شرح می‌دهد.

اگر دستگاهی افزونه‌ای که از کدگذاری HDR به SDR پشتیبانی می‌کند را نداشته باشد، برنامه‌ای که به یک ویدیوی HDR دسترسی دارد، صرف نظر از قابلیت‌های رسانه‌ای برنامه که در مانیفست اعلام شده است، توصیفگر فایل اصلی را دریافت می‌کند.

چگونه کار می‌کند؟

این بخش رفتار کلی افزونه فیلتر Codec 2.0 را شرح می‌دهد.

پیشینه

اندروید یک پیاده‌سازی لایه انطباق بین رابط Codec 2.0 و رابط android.hardware.media.c2 HAL در android::hardware::media::c2 ارائه می‌دهد. برای افزونه‌های فیلتر، AOSP شامل یک مکانیزم پوشش‌دهنده است که رمزگشاها را به همراه افزونه‌های فیلتر پوشش می‌دهد. MediaCodec این اجزای پوشش داده شده را به عنوان رمزگشاهایی با ویژگی‌های فیلتر تشخیص می‌دهد.

نمای کلی

کلاس FilterWrapper کدک‌های فروشنده را دریافت کرده و کدک‌های بسته‌بندی‌شده را به لایه انطباق media.c2 برمی‌گرداند. کلاس FilterWrapper فایل libc2filterplugin.so را از طریق API FilterWrapper::Plugin بارگذاری می‌کند و فیلترهای موجود از افزونه را ثبت می‌کند. هنگام ایجاد، FilterWrapper تمام فیلترهای موجود را نمونه‌سازی می‌کند. فقط فیلترهایی که بافر را تغییر می‌دهند، در ابتدا شروع به کار می‌کنند.

معماری افزونه فیلتر

شکل ۴. معماری افزونه فیلتر.

رابط افزونه فیلتر

رابط FilterPlugin.h رابط‌های برنامه‌نویسی کاربردی (API) زیر را برای نمایش فیلترها تعریف می‌کند:

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    یک شیء C2ComponentStore را برمی‌گرداند که شامل فیلترها است. این جدا از چیزی است که پیاده‌سازی Codec 2.0 فروشنده ارائه می‌دهد. معمولاً، این مخزن فقط شامل فیلترهایی است که توسط کلاس FilterWrapper استفاده می‌شوند.

  • bool describe(C2String name, Descriptor *desc)

    فیلترها را علاوه بر آنچه از C2ComponentStore در دسترس است، شرح می‌دهد. توضیحات زیر تعریف شده‌اند:

    • controlParam : پارامترهایی که رفتار فیلترها را کنترل می‌کنند. برای مثال، برای HDR به SDR tone-mapper، پارامتر کنترل، تابع انتقال هدف است.
    • affectedParams : پارامترهایی که تحت تأثیر عملیات فیلترینگ قرار می‌گیرند. برای مثال، برای HDR to SDR tone-mapper، پارامترهای تحت تأثیر، جنبه‌های رنگی هستند.

  • bool isFilteringEnabled(const std::shared_ptr<C2ComponentInterface> &intf)

    اگر مؤلفه فیلتر، بافر را تغییر دهد، true را برمی‌گرداند. برای مثال، فیلتر نگاشت تُن اگر تابع انتقال هدف SDR و تابع انتقال ورودی HDR (HLG یا PQ) باشد، true را برمی‌گرداند.

جزئیات FilterWrapper

این بخش جزئیات کلاس FilterWrapper را شرح می‌دهد.

خلقت

کامپوننتِ پوشش داده شده، رمزگشای اصلی و تمام فیلترهای تعریف شده را در زمان ایجاد، نمونه‌سازی می‌کند.

پرس و جو و پیکربندی

کامپوننتِ بسته‌بندی‌شده، پارامترهای ورودی را از پرس‌وجوها یا درخواست‌های پیکربندی بر اساس توضیحات فیلتر جدا می‌کند. برای مثال، پیکربندی پارامتر کنترل فیلتر به فیلتر مربوطه هدایت می‌شود و پارامترهای تحت تأثیر فیلترها در پرس‌وجوها وجود دارند (به جای خواندن از رمزگشا که پارامترهای بدون تأثیر دارد).

پرس و جو و پیکربندی

شکل ۵. پرس‌وجو و پیکربندی.

شروع

در شروع، کامپوننتِ بسته‌بندی‌شده، رمزگشا و تمام فیلترهایی که بافرها را تغییر می‌دهند، شروع به کار می‌کند. اگر هیچ فیلتری فعال نباشد، کامپوننت بسته‌بندی‌شده، رمزگشا و بافرهای عبوری را شروع می‌کند و دستوراتی را به خود رمزگشا ارسال می‌کند.

مدیریت بافر

مدیریت بافر

شکل ۶. مدیریت بافر.

بافرهایی که در صف دیکدرِ بسته‌بندی‌شده قرار می‌گیرند، به دیکدرِ زیرین می‌روند. کامپوننت بسته‌بندی‌شده، بافر خروجی را از طریق فراخوانی onWorkDone_nb() از دیکدر می‌گیرد و سپس آن را در صف فیلترها قرار می‌دهد. بافر خروجی نهایی از آخرین فیلتر به کلاینت گزارش می‌شود.

برای اینکه این مدیریت بافر کار کند، کامپوننتِ بسته‌بندی‌شده باید C2PortBlockPoolsTuning را روی آخرین فیلتر پیکربندی کند تا چارچوب، بافرها را از مجموعه بلوک مورد انتظار خروجی دهد.

متوقف کنید، تنظیم مجدد کنید و رها کنید

در زمان توقف، کامپوننتِ بسته‌بندی‌شده، دیکدر و تمام فیلترهای فعال‌شده‌ای که شروع شده بودند را متوقف می‌کند. در زمان بازنشانی و رهاسازی، تمام کامپوننت‌ها صرف نظر از اینکه فعال باشند یا نه، بازنشانی یا رها می‌شوند.

افزونه فیلتر نمونه را پیاده‌سازی کنید

برای فعال کردن افزونه، موارد زیر را انجام دهید:

  1. رابط FilterPlugin را در یک کتابخانه پیاده‌سازی کنید و آن را در /vendor/lib[64]/libc2filterplugin.so.
  2. در صورت نیاز، مجوزهای اضافی را به mediacodec.te اضافه کنید.
  3. لایه انطباق را به اندروید ۱۲ به‌روزرسانی کنید و سرویس media.c2 را بازسازی کنید.

افزونه را تست کنید

برای آزمایش افزونه نمونه، موارد زیر را انجام دهید:

  1. دستگاه را بازسازی و فلش کنید.

  2. افزونه نمونه را با استفاده از دستور زیر بسازید:

    m sample-codec2-filter-plugin

  3. دستگاه را دوباره مانت کنید و افزونه فروشنده را تغییر نام دهید تا توسط سرویس کدک شناسایی شود.

    adb root
adb remount
adb reboot
adb wait-for-device
adb root
adb remount
adb
push /out/target/<...>/lib64/sample-codec2-filter-plugin.so \

/vendor/lib64/libc2filterplugin.so
adb push
/out/target/<...>/lib/sample-codec2-filter-plugin.so \

/vendor/lib/libc2filterplugin.so
adb reboot