Совместимое транскодирование мультимедиа

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

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

Как это работает

Совместимая функция транскодирования мультимедиа состоит из двух основных частей:

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

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

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

Рисунок 1. Обзор совместимого транскодирования медиаданных.

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

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

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

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

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

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

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

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

  • Транскодирование обойдено:

    • Передача файла с устройства путем извлечения SD-карты
    • Передача файлов с устройства на устройство с использованием таких опций, как Nearby Share или передача по 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

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

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

медиа-транскодирование-архитектура

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

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

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

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

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

Совместимое перекодирование мультимедиа построено на основе файловой системы Filesystem in Userspace (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 производители устройств могут использовать плагин фильтра AOSP sample Codec 2.0, расположенный в /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 to SDR tone-mapper, затронутыми параметрами являются цветовые аспекты.

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

    Возвращает true если компонент фильтра изменяет буфер. Например, фильтр тонального отображения возвращает 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