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

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

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

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

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

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

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

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

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

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

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

  • HEVC (8-бит) в AVC: преобразования кодеков выполняются путем подключения одного декодера медиакодека и одного кодера медиакода.
  • HDR10+ (10-бит) в AVC (SDR): Преобразования HDR в SDR выполняются с использованием экземпляров медиакодека и подключаемого модуля поставщика к экземплярам декодера. Подробнее см. в разделе Кодирование 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 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 в SDR затрагиваемыми параметрами являются цветовые аспекты.

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

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

Подробности FilterWrapper

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

Создание

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

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

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

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

Рисунок 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