Совместимое перекодирование медиафайлов

Совместимое перекодирование медиафайлов, появившееся в Android 12, позволяет устройствам использовать для видеосъемки более современные и эффективные форматы, например HEVC, сохраняя при этом совместимость с приложениями. Благодаря этой функции производители устройств могут использовать HEVC вместо AVC по умолчанию, чтобы улучшить качество видео и снизить требования к хранилищу и пропускной способности. Если на устройстве включено совместимое медиакодирование, Android может автоматически конвертировать видео (длительностью до одной минуты), записанные в таких форматах, как HEVC или HDR, когда они открываются в приложении, которое не поддерживает эти форматы. Это позволяет приложениям работать, даже если видео на устройстве сняты в новых форматах.

По умолчанию перекодирование медиафайлов в совместимый формат отключено. Чтобы запросить перекодирование медиафайлов, приложения должны объявить о своих возможностях работы с медиаконтентом. Подробнее о том, как объявлять мультимедийные возможности, рассказывается в разделе Совместимое перекодирование медиаконтента на сайте для разработчиков Android.

Принцип работы

Функция совместимого перекодирования медиаконтента состоит из двух основных частей:

  • Сервисы перекодирования в медиафреймворке. Эти сервисы преобразуют файлы из одного формата в другой, используя аппаратное обеспечение для низкой задержки и высокого качества преобразования. В нее входят API и сервис перекодирования, плагин OEM для пользовательских фильтров и аппаратное обеспечение. Подробнее об архитектуре…
  • Функция перекодирования медиаконтента в медиаконтент-провайдерах. Этот компонент, который можно найти в медиаконтент-провайдерах, перехватывает запросы приложений на доступ к медиафайлам и предоставляет либо исходный файл, либо перекодированный файл в зависимости от заявленных возможностей приложения. Если приложение поддерживает формат медиафайла, никаких специальных действий не требуется. Если приложение не поддерживает формат, фреймворк преобразует файл в более старый формат, например AVC, когда приложение обращается к файлу.

На рисунке 1 показан обзор процесса перекодирования медиаконтента.

Совместимый процесс перекодирования медиафайлов

Рисунок 1. Обзор перекодирования медиафайлов в совместимый формат.

Поддерживаемые форматы

Функция совместимого перекодирования медиаконтента поддерживает следующие преобразования форматов:

  • HEVC (8-битный) в AVC. Преобразование кодеков выполняется путем подключения одного декодера mediacodec и одного кодировщика mediacode.
  • HDR10+ (10-битный) в AVC (SDR). Преобразование HDR в SDR выполняется с помощью экземпляров mediacodec и подключаемого модуля поставщика, встроенного в экземпляры декодера. Подробнее о кодировании HDR в SDR…

Поддерживаемые источники контента

Функция перекодирования медиафайлов в совместимый формат поддерживает медиафайлы, созданные на устройстве с помощью встроенного приложения камеры и хранящиеся в папке DCIM/Camera/ на основном внешнем накопителе. Функция не поддерживает медиафайлы на дополнительном хранилище. Контент, переданный на устройства по электронной почте или с помощью SD-карт, не поддерживается.

Приложения получают доступ к файлам по разным путям. Ниже описаны пути к файлам, для которых включено или отключено перекодирование:

  • Перекодирование включено:

    • Доступ приложения через MediaStore API
    • Доступ к приложению через API прямого пути к файлу, включая Java и нативный код
    • Доступ к приложениям через Storage Access Framework (SAF)
    • Доступ к приложению через намерения функции "Поделиться" в ОС. (только URI MediaStore)
    • Передача файлов с телефона на ПК с помощью MTP/PTP

  • Перекодирование пропущено:

    • Перенос файла с устройства путем извлечения SD-карты
    • Передача файлов между устройствами с помощью таких функций, как "Быстрая отправка" или Bluetooth.

Добавьте настраиваемые пути к файлам для перекодирования

Производители устройств могут добавить пути к файлам для перекодирования медиаконтента в каталог DCIM/. Все пути за пределами каталога DCIM/ отклоняются. Добавление таких путей к файлам может быть необходимо для соблюдения требований оператора связи или местного законодательства.

Чтобы добавить путь к файлу, используйте переопределение ресурсов во время выполнения (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

Обзор архитектуры

В этом разделе описывается архитектура функции перекодирования медиафайлов.

media-transcoding-architecture

Рисунок 2. Архитектура перекодирования медиафайлов.

Архитектура перекодирования медиаконтента состоит из следующих компонентов:

  • Системный API MediaTranscodingManager. Интерфейс, позволяющий клиенту взаимодействовать с сервисом MediaTranscoding. Этот API используется модулем MediaProvider.
  • MediaTranscodingService. Нативный сервис, который управляет подключениями клиентов, планирует запросы на перекодирование и ведет учет для TranscodingSessions.
  • MediaTranscoder – нативная библиотека, которая выполняет перекодирование. Эта библиотека создана на основе медиафреймворка NDK и совместима с модулями.

Функция перекодирования медиафайлов в совместимый формат регистрирует показатели перекодирования как в сервисе, так и в транскодере. Код на стороне клиента и на стороне сервиса находится в модуле MediaProvider, чтобы можно было своевременно исправлять ошибки и выпускать обновления.

Доступ к файлам

Перекодирование медиафайлов в совместимый формат основано на файловой системе в пользовательском пространстве (FUSE), которая используется для областей хранения данных. FUSE позволяет модулю MediaProvider проверять операции с файлами в пользовательском пространстве и ограничивать доступ к файлам на основе правил, разрешающих, запрещающих или редактирующих доступ.

Когда приложение пытается получить доступ к файлу, демон FUSE перехватывает запрос на чтение файла из приложения. Если приложение поддерживает более новый формат (например, HEVC), возвращается исходный файл. Если приложение не поддерживает формат, файл будет перекодирован в более старый формат (например, AVC) или возвращен из кеша, если доступна перекодированная версия.

Как запросить перекодированные файлы

Функция перекодирования медиаконтента в совместимый формат по умолчанию отключена. Приложения могут запрашивать перекодированные объекты, используя следующие параметры:

  • Укажите неподдерживаемые форматы в файле манифеста. Подробнее о том, как объявлять возможности в ресурсе и как объявлять возможности в коде…
  • Отключить поддерживаемые форматы с помощью фреймворка совместимости приложений во время выполнения (пользователи также могут отключить эту функцию для каждого приложения в настройках).
  • Откройте файл с помощью MediaStore, явно указав неподдерживаемые форматы с помощью API openTypedAssetFileDescriptor.

При передаче файлов через USB (с устройства на ПК) перекодирование по умолчанию отключено, но пользователи могут включить его с помощью переключателя Преобразовывать видео в AVC на экране Настройки USB, как показано на рисунке 3.

Переключатель для включения транскодирования медиафайлов.

Рисунок 3. Включите перекодирование медиафайлов на экране настроек USB.

Ограничения на запросы перекодированных файлов

Чтобы запросы на транскодирование не блокировали системные ресурсы на длительное время, приложения, запрашивающие сеансы транскодирования, ограничены следующими параметрами:

  • 10 сеансов подряд
  • Общая продолжительность – три минуты.

Если приложение не нарушает ни одно из этих ограничений, фреймворк возвращает исходный дескриптор файла.

Требования к устройствам

Чтобы поддерживать функцию перекодирования медиафайлов в совместимый формат, устройства должны соответствовать следующим требованиям:

  • На устройстве по умолчанию включено кодирование HEVC в стандартном приложении камеры.
  • (Устройства, поддерживающие транскодирование HDR в SDR) Устройство поддерживает съемку видео в формате HDR.

Чтобы обеспечить производительность устройства при перекодировании медиафайлов, необходимо оптимизировать производительность видеооборудования и доступа для чтения и записи в хранилище. Если для медиакодеков задан приоритет 1, они должны работать с максимально возможной пропускной способностью. Рекомендуем, чтобы производительность перекодирования составляла не менее 200 кадров в секунду. Чтобы проверить производительность оборудования, запустите тест медиаконвертера на сайте frameworks/av/media/libmediatranscoding/transcoder/benchmark.

Проверка

Чтобы проверить функцию перекодирования медиафайлов в совместимый формат, выполните следующие тесты CTS:

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

Как включить перекодирование медиафайлов на уровне организации

Чтобы протестировать фреймворк для перекодирования медиаконтента или поведение приложения при перекодировании, вы можете включить или отключить функцию совместимого перекодирования медиаконтента на уровне системы. На странице параметров для разработчиков Настройки > Система > Для разработчиков > Перекодирование медиафайлов установите переключатель Переопределить настройки перекодирования по умолчанию в положение включено, а затем установите переключатель Включить перекодирование в положение включено или отключено. Если этот параметр включен, перекодирование медиафайлов может выполняться в фоновом режиме для приложений, отличных от разрабатываемого.

Как проверить статус перекодирования

Во время тестирования вы можете использовать следующую команду оболочки ADB, чтобы проверить статус перекодирования, включая текущие и прошлые сеансы перекодирования:

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, производители устройств могут использовать образец плагина фильтра Codec 2.0 из AOSP, расположенный в каталоге /platform/frameworks/av/media/codec2/hidl/plugin/. В этом разделе рассказывается, как работает плагин фильтрации, как его реализовать и протестировать.

Если на устройстве нет плагина, поддерживающего кодирование HDR в SDR, приложение, получающее доступ к HDR-видео, получает исходный дескриптор файла независимо от возможностей мультимедиа, заявленных в манифесте приложения.

Принцип работы

В этом разделе описывается общее поведение плагина фильтра Codec 2.0.

Фон

Android предоставляет реализацию адаптивного уровня между интерфейсом Codec 2.0 и интерфейсом HAL android.hardware.media.c2 на уровне android::hardware::media::c2. Для плагинов фильтров в AOSP предусмотрен механизм оболочки, который объединяет декодеры с плагинами фильтров. MediaCodec распознает эти компоненты как декодеры с функциями фильтрации.

Обзор

Класс FilterWrapper принимает кодеки поставщика и возвращает обернутые кодеки обратно в адаптационный слой media.c2. Класс FilterWrapper загружает libc2filterplugin.so через API FilterWrapper::Plugin и записывает доступные фильтры из плагина. При создании FilterWrapper используются все доступные фильтры. При запуске запускаются только фильтры, которые изменяют буфер.

Архитектура плагина фильтра

Рисунок 4. Архитектура плагина фильтра.

Интерфейс плагина фильтров

Интерфейс FilterPlugin.h определяет следующие API для фильтров:

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    Возвращает объект C2ComponentStore, содержащий фильтры. Это не связано с тем, что предоставляет реализация Codec 2.0 от поставщика. Обычно в этом хранилище содержатся только фильтры, используемые классом FilterWrapper.

  • bool describe(C2String name, Descriptor *desc)

    Описывает фильтры в дополнение к тому, что доступно в C2ComponentStore. Описания могут быть следующими:

    • controlParam – параметры, управляющие поведением фильтров. Например, для тонального компрессора HDR-SDR управляющим параметром является целевая функция передачи.
    • affectedParams: параметры, на которые влияют операции фильтрации. Например, для тонального компрессора HDR-SDR затронутыми параметрами являются цветовые аспекты.

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

    Возвращает true, если компонент фильтра изменяет буфер. Например, фильтр tone-mapping возвращает значение true, если целевая передаточная функция – SDR, а входная – HDR (HLG или PQ).

Сведения о FilterWrapper

В этом разделе описаны сведения о классе FilterWrapper.

Создание

Обернутый компонент создает экземпляр базового декодера и всех определенных фильтров при создании.

Запрос и конфигурация

Обернутый компонент отделяет входящие параметры от запросов или запросов конфигурации в соответствии с описанием фильтра. Например, конфигурация параметра управления фильтром направляется в соответствующий фильтр, а затронутые параметры из фильтров присутствуют в запросах (вместо того, чтобы считываться из декодера, в котором есть незатронутые параметры).

Запрос и конфигурация

Рисунок 5. Запрос и конфигурация.

Начать

При запуске обернутый компонент запускает декодер и все фильтры, которые изменяют буферы. Если фильтр не включен, упакованный компонент запускает декодер и сквозные буферы и отправляет команды самому декодеру.

Обработка буфера

Обработка буфера

Рисунок 6. Обработка буфера.

Буферы, поставленные в очередь для декодера, передаются основному декодеру. Обернутый компонент получает выходной буфер от декодера через обратный вызов onWorkDone_nb(), а затем помещает его в очередь фильтров. Клиенту передается последний буфер выходных данных фильтра.

Чтобы буферы обрабатывались правильно, обернутый компонент должен настроить C2PortBlockPoolsTuning для последнего фильтра, чтобы фреймворк выводил буферы из ожидаемого пула блоков.

Остановка, сброс и отпускание

При остановке обернутый компонент останавливает декодер и все включенные фильтры, которые были запущены. При сбросе и освобождении все компоненты сбрасываются или освобождаются независимо от того, включены они или нет.

Как реализовать образец плагина фильтра

Чтобы включить плагин, выполните следующие действия:

  1. Реализуйте интерфейс FilterPlugin в библиотеке и поместите ее в каталог /vendor/lib[64]/libc2filterplugin.so..
  2. При необходимости добавьте дополнительные разрешения для mediacodec.te.
  3. Обновите уровень адаптации до Android 12 и пересоберите сервис 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