Воспроизведение HDR-видео

Видео с расширенным динамическим диапазоном (HDR) — это новый рубеж в области высококачественного декодирования видео, обеспечивающий непревзойденное качество воспроизведения сцен. Это достигается за счет значительного увеличения динамического диапазона компонента яркости (с нынешних 100 кд/м 2 до 1000 кд/м 2 ) и использования гораздо более широкого цветового пространства (BT 2020). Сейчас это центральный элемент эволюции 4K UHD в телевизионном пространстве.

Android 10 поддерживает следующие HDR-видео.

  • HDR10
  • ВП9
  • HDR10+

Начиная с Android 9 и более поздних версий, MediaCodec сообщает метаданные HDR независимо от туннелированного режима. Вы можете получить декодированные данные вместе со статическими/динамическими метаданными в нетуннелируемом режиме. Для HDR10 и VP9Profile2, использующих статические метаданные, они сообщаются в выходном формате с ключом KEY_HDR_STATIC_INFO . Для HDR10+, использующего динамические метаданные, это указывается с помощью ключа KEY_HDR10_PLUS_INFO в выходном формате и может меняться для каждого выходного кадра. Дополнительную информацию см. в разделе Мультимедийное туннелирование .

Начиная с Android 7.0, первоначальная поддержка HDR включает создание правильных констант для обнаружения и настройки видеоконвейеров HDR. Это означает определение типов кодеков и режимов отображения, а также определение того, как данные HDR должны передаваться в MediaCodec и передаваться в декодеры HDR.

Цель этого документа — помочь разработчикам приложений поддерживать воспроизведение потока HDR, а также помочь OEM-производителям и SOC включить функции HDR.

Поддерживаемые технологии HDR

Начиная с Android 7.0 и более поздних версий поддерживаются следующие технологии HDR.

Технология Dolby-Vision HDR10 ВП9-HLG ВП9-PQ
Кодек AVC/HEVC HEVC ВП9 ВП9
Передаточная функция СТ-2084 СТ-2084 ГВУ СТ-2084
Тип метаданных HDR Динамический Статический Никто Статический

В Android 7.0 определено только воспроизведение HDR через туннельный режим , но устройства могут добавить поддержку воспроизведения HDR на SurfaceViews с использованием непрозрачных видеобуферов. Другими словами:

  • Не существует стандартного API Android для проверки поддержки воспроизведения HDR с использованием нетуннельных декодеров.
  • Туннельные видеодекодеры, рекламирующие возможность воспроизведения HDR, должны поддерживать воспроизведение HDR при подключении к дисплеям с поддержкой HDR.
  • Состав GL HDR-контента не поддерживается версией AOSP Android 7.0.

Открытие

Для воспроизведения HDR требуется декодер с поддержкой HDR и подключение к дисплею с поддержкой HDR. Необязательно, для некоторых технологий требуется специальный экстрактор.

Отображать

Приложения должны использовать новый API Display.getHdrCapabilities для запроса технологий HDR, поддерживаемых указанным дисплеем. По сути, это информация в блоке статических метаданных EDID, как определено в CTA-861.3:

  • public Display.HdrCapabilities getHdrCapabilities()
    Возвращает возможности HDR дисплея.
  • Display.HdrCapabilities
    Инкапсулирует возможности HDR данного дисплея. Например, какие типы HDR он поддерживает, а также сведения о желаемых данных яркости.

Константы:

  • int HDR_TYPE_DOLBY_VISION
    Поддержка Dolby Vision.
  • int HDR_TYPE_HDR10
    Поддержка HDR10/PQ.
  • int HDR_TYPE_HDR10_PLUS
    Поддержка HDR10+.
  • int HDR_TYPE_HLG
    Поддержка гибридной логарифмической гаммы.
  • float INVALID_LUMINANCE
    Недопустимое значение яркости.

Публичные методы:

  • float getDesiredMaxAverageLuminance()
    Возвращает желаемые данные максимальной средней яркости контента в кд/кд/м 2 для этого дисплея.
  • float getDesiredMaxLuminance()
    Возвращает желаемые данные максимальной яркости контента в кд/кд/м 2 для этого дисплея.
  • float getDesiredMinLuminance()
    Возвращает требуемые данные минимальной яркости контента в кд/кд/м 2 для этого дисплея.
  • int[] getSupportedHdrTypes()
    Получает поддерживаемые типы HDR этого дисплея (см. константы). Возвращает пустой массив, если HDR не поддерживается дисплеем.

Декодер

Приложения должны использовать существующий API CodecCapabilities.profileLevels для проверки поддержки новых профилей с поддержкой HDR:

Dolby-Vision

Константа mime MediaFormat :

String MIMETYPE_VIDEO_DOLBY_VISION

Константы профиля MediaCodecInfo.CodecProfileLevel :

int DolbyVisionProfileDvavPen
int DolbyVisionProfileDvavPer
int DolbyVisionProfileDvheDen
int DolbyVisionProfileDvheDer
int DolbyVisionProfileDvheDtb
int DolbyVisionProfileDvheDth
int DolbyVisionProfileDvheDtr
int DolbyVisionProfileDvheStn

Видеослои и метаданные Dolby Vision должны быть объединены в один буфер для каждого кадра с помощью видеоприложений. Это делается автоматически с помощью MediaExtractor с поддержкой Dolby-Vision.

ХВК HDR 10

Константы профиля MediaCodecInfo.CodecProfileLevel :

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG и PQ

Константы профиля MediaCodecInfo.CodecProfileLevel :

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Если платформа поддерживает декодер с поддержкой HDR, она также должна поддерживать экстрактор с поддержкой HDR.

Только туннельные декодеры гарантированно воспроизводят HDR-контент. Воспроизведение с помощью нетуннельных декодеров может привести к потере информации HDR и сведению контента в цветовой объем SDR.

Экстрактор

Следующие контейнеры поддерживаются для различных технологий HDR в Android 7.0:

Технология Dolby-Vision HDR10 ВП9-HLG ВП9-PQ
Контейнер МП4 МП4 ВебМ ВебМ

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

Краткое содержание

Требования к компонентам для каждой технологии HDR показаны в следующей таблице:

Технология Dolby-Vision HDR10 ВП9-HLG ВП9-PQ
Поддерживаемый тип HDR (Дисплей) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Контейнер (Экстрактор) МП4 МП4 ВебМ ВебМ
Декодер MIMETYPE_VIDEO_DOLBY_VISION MIMETYPE_VIDEO_HEVC MIMETYPE_VIDEO_VP9 MIMETYPE_VIDEO_VP9
Профиль (декодер) Один из профилей Dolby HEVCПрофильMain10HDR10 VP9Profile2HDR или VP9Profile3HDR VP9Profile2HDR или VP9Profile3HDR

Примечания:

  • Битовые потоки Dolby-Vision упаковываются в контейнер MP4 способом, определенным Dolby. Приложения могут реализовывать свои собственные экстракторы с поддержкой Dolby при условии, что они упаковывают блоки доступа из соответствующих уровней в единый блок доступа для декодера, как определено Dolby.
  • Платформа может поддерживать экстрактор с поддержкой HDR, но не поддерживать соответствующий декодер с поддержкой HDR.

Воспроизведение

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

  • Для Dolby-Vision вопрос о том, требует ли конкретный медиафайл/дорожка декодера с поддержкой HDR, не доступен сразу. Приложение должно иметь эту информацию заранее или иметь возможность получить ее путем анализа раздела данных MediaFormat, специфичного для кодека.
  • CodecCapabilities.isFormatSupported не учитывает, требуется ли функция туннелированного декодера для поддержки такого профиля.

Включить поддержку платформы HDR

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

Изменения платформы в Android 7.0 для HDR

Вот некоторые ключевые изменения в платформе (приложение/родной уровень), о которых необходимо знать OEM-производителям и SOC.

Отображать

Аппаратный состав

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

  1. Определите линейное цветовое пространство/объем, содержащее все слои, подлежащие компоновке, на основе цвета, мастеринга и потенциальных динамических метаданных слоев.
    При компоновке непосредственно на дисплей это может быть линейное пространство, соответствующее цветовому объему дисплея.
  2. Преобразуйте все слои в общее цветовое пространство.
  3. Выполните смешивание.
  4. При отображении через HDMI:
    1. Определите цвет, мастеринг и потенциальные динамические метаданные для смешанной сцены.
    2. Преобразуйте полученную смешанную сцену в производное цветовое пространство/объем.
  5. При отображении непосредственно на дисплее преобразуйте полученную смешанную сцену в необходимые сигналы дисплея для создания этой сцены.

Открытие дисплея

Обнаружение HDR-дисплея поддерживается только через HWC2. Разработчики устройств должны выборочно включить адаптер HWC2, выпущенный с Android 7.0, чтобы эта функция работала. Поэтому платформы должны добавить поддержку HWC2 или расширить структуру AOSP, чтобы обеспечить возможность предоставления этой информации. HWC2 предоставляет новый API для распространения статических данных HDR в платформу и приложение.

HDMI

  • Подключенный дисплей HDMI объявляет о своих возможностях HDR через HDMI EDID, как определено в разделе 4.2 CTA-861.3 .
  • Должно использоваться следующее отображение EOTF:
    • ET_0 Традиционная гамма — диапазон яркости SDR: не сопоставлен ни с одним типом HDR
    • ET_1 Традиционная гамма – диапазон яркости HDR: не сопоставлен ни с одним типом HDR.
    • ET_2 SMPTE ST 2084 — сопоставлен с типом HDR HDR10.
  • Сигнализация о поддержке Dolby Vision или HLG через HDMI осуществляется в соответствии с определением соответствующих органов.
  • Обратите внимание, что API HWC2 использует значения желаемой яркости с плавающей запятой, поэтому 8-битные значения EDID должны быть преобразованы соответствующим образом.

Декодеры

Платформы должны добавлять туннельные декодеры с поддержкой HDR и рекламировать свою поддержку HDR. Как правило, декодеры с поддержкой HDR должны:

  • Поддержка туннельного декодирования ( FEATURE_TunneledPlayback ).
  • Поддержка статических метаданных HDR ( OMX.google.android.index.describeHDRColorInfo ) и их распространение на композицию дисплея/оборудования. Для HLG на дисплей должны быть отправлены соответствующие метаданные.
  • Поддержка описания цвета ( OMX.google.android.index.describeColorAspects ) и его распространение на композицию дисплея/оборудования.
  • Поддержка встроенных метаданных HDR, как определено соответствующим стандартом.

Поддержка декодера Dolby Vision.

Для поддержки Dolby Vision платформы должны добавить декодер HDR OMX с поддержкой Dolby-Vision. Учитывая специфику Dolby Vision, обычно это декодер-обертка вокруг одного или нескольких декодеров AVC и/или HEVC, а также композитор. Такие декодеры должны:

  • Поддержка типа mime «video/dolby-vision».
  • Рекламируйте поддерживаемые профили/уровни Dolby Vision.
  • Принимайте единицы доступа, которые содержат подединицы доступа всех слоев, как определено Dolby.
  • Принимайте данные, специфичные для кодека, определенные Dolby. Например, данные, содержащие профиль/уровень Dolby Vision и, возможно, данные, относящиеся к кодеку для внутренних декодеров.
  • Поддержка адаптивного переключения между профилями/уровнями Dolby Vision в соответствии с требованиями Dolby.

При настройке декодера фактический профиль Dolby не передается кодеку. Это делается только с помощью данных, специфичных для кодека, после запуска декодера. Платформа может выбрать поддержку нескольких декодеров Dolby Vision: один для профилей AVC, а другой для профилей HEVC, чтобы иметь возможность инициализировать базовые кодеки во время настройки. Если один декодер Dolby Vision поддерживает оба типа профилей, он также должен поддерживать динамическое адаптивное переключение между ними.

Если платформа предоставляет декодер с поддержкой Dolby-Vision в дополнение к общей поддержке декодера HDR, она должна:

  • Предоставьте экстрактор с поддержкой Dolby-Vision, даже если он не поддерживает воспроизведение HDR.
  • Предоставьте декодер, который поддерживает профиль изображения, определенный Dolby.

Поддержка декодера HDR10

Для поддержки HDR10 платформы должны добавить декодер OMX с поддержкой HDR10. Обычно это туннельный декодер HEVC, который также поддерживает анализ и обработку метаданных, связанных с HDMI. Такой декодер (помимо общей поддержки HDR-декодера) должен:

  • Поддержка типа mime «video/hevc».
  • Реклама поддерживает HEVCMain10HDR10. Для поддержки профиля HEVCMain10HRD10 также требуется поддержка профиля HEVCMain10, что требует поддержки профиля HEVCMain на тех же уровнях.
  • Поддержка анализа блоков SEI метаданных мастеринга, а также другой информации, связанной с HDR, содержащейся в SPS.

Поддержка декодера VP9

Для поддержки VP9 HDR платформы должны добавить декодер HDR OMX с поддержкой VP9 Profile2. Обычно это туннельный декодер VP9, ​​который также поддерживает обработку метаданных, связанных с HDMI. Такие декодеры (помимо общей поддержки декодера HDR) должны:

  • Поддержка типа mime «video/x-vnd.on2.vp9».
  • Рекламируйте поддерживаемый VP9Profile2HDR. Для поддержки профиля VP9Profile2HDR также требуется поддержка профиля VP9Profile2 на том же уровне.

Экстракторы

Поддержка экстрактора Dolby Vision

Платформы, поддерживающие декодеры Dolby Vision, должны добавить поддержку экстрактора Dolby (называемого Dolby Extractor) для контента Dolby Video.

  • Обычный экстрактор MP4 может извлечь из файла только базовый слой, но не слои расширения или метаданных. Поэтому для извлечения данных из файла необходим специальный экстрактор Dolby.
  • Экстрактор Dolby должен отображать от 1 до 2 дорожек для каждой видеодорожки (группы) Dolby:
    • Трек Dolby Vision HDR с типом «видео/dolby-vision» для комбинированного 2/3-слойного потока Dolby. Формат единиц доступа к дорожке HDR, который определяет, как упаковать единицы доступа из базового/улучшенного уровня/слоев метаданных в один буфер для декодирования в один кадр HDR, должен определяться Dolby.
    • Если видеодорожка Dolby Vision содержит отдельный (обратно совместимый) базовый слой (BL), экстрактор также должен представить его как отдельную дорожку «video/avc» или «video/hevc». Экстрактор должен предоставить обычные блоки доступа AVC/HEVC для этого трека.
    • Дорожка BL должна иметь тот же уникальный идентификатор дорожки («идентификатор дорожки»), что и дорожка HDR, чтобы приложение понимало, что это две кодировки одного и того же видео.
    • Приложение может решить, какой трек выбрать, исходя из возможностей платформы.
  • Профиль/уровень Dolby Vision должен быть представлен в формате дорожки HDR.
  • Если платформа предоставляет декодер с поддержкой Dolby-Vision, она также должна предоставить экстрактор с поддержкой Dolby-Vision, даже если он не поддерживает воспроизведение HDR.

Поддержка экстрактора HDR10 и VP9 HDR

Для поддержки HDR10 или VP9 HLG не требуется никаких дополнительных требований к экстрактору. Платформы должны расширять экстрактор MP4 для поддержки VP9 PQ в MP4. Статические метаданные HDR должны распространяться в битовом потоке VP9 PQ, чтобы эти метаданные передавались в декодер VP9 PQ и на дисплей через обычный конвейер MediaExtractor => MediaCodec.

Расширения Stagefright для поддержки Dolby Vision

Платформы должны добавить в Stagefright поддержку формата Dolby Vision:

  • Поддержка запроса определения порта для сжатого порта.
  • Поддержка перечисления профилей/уровней для декодера DV.
  • Поддержка экспонирования профиля/уровня DV для дорожек DV HDR.

Подробности реализации конкретной технологии

Конвейер декодера HDR10

Рисунок 1. Конвейер HDR10

Битовые потоки HDR10 упаковываются в контейнеры MP4. Приложения используют обычный экстрактор MP4 для извлечения данных кадра и отправки их в декодер.

  • Экстрактор MPEG4
    Битовые потоки HDR10 распознаются MPEG4Extractor как обычный поток HEVC, и будет извлечена дорожка HDR с типом «видео/HEVC». Платформа выбирает видеодекодер HEVC, который поддерживает профиль Main10HDR10, для декодирования этой дорожки.
  • HEVC-декодер
    Информация HDR находится либо в SEI, либо в SPS. Декодер HEVC сначала принимает кадры, содержащие информацию HDR. Затем декодер извлекает информацию HDR и уведомляет приложение о том, что он декодирует HDR-видео. Информация HDR объединяется в выходной формат декодера, который позже передается на поверхность.

Действия продавца

  1. Объявите поддерживаемый профиль декодера HDR и тип уровня OMX. Пример:
    OMX_VIDEO_HEVCProfileMain10HDR10 (и Main10 )
  2. Реализовать поддержку индекса: ' OMX.google.android.index.describeHDRColorInfo '.
  3. Реализовать поддержку индекса: ' OMX.google.android.index.describeColorAspects '.
  4. Реализовать поддержку SEI-анализа метаданных мастеринга.

Конвейер декодера Dolby Vision

Рисунок 2. Конвейер Dolby Vision

Битовые потоки Dolby упаковываются в контейнеры MP4, как это определено Dolby. Теоретически приложения могут использовать обычный экстрактор MP4 для независимого извлечения базового уровня, уровня расширения и уровня метаданных; однако это не соответствует текущей модели Android MediaExtractor/MediaCodec.

  • ДолбиЭкстрактор:
    • Битовые потоки Dolby распознаются DolbyExtractor, который отображает различные слои как 1–2 дорожки для каждой дорожки (группы) видео Dolby:
      • HDR-дорожка с типом «видео/долби-видение» для комбинированного 2/3-слойного потока dolby. Формат единиц доступа дорожки HDR, который определяет, как упаковать единицы доступа из базового/улучшенного уровня/слоев метаданных в один буфер для декодирования в один кадр HDR, должен определяться Dolby.
      • (Необязательно, только если BL обратно совместим) Дорожка BL содержит только базовый уровень, который должен быть декодирован обычным декодером MediaCodec, например, декодером AVC/HEVC. Экстрактор должен предоставлять обычные блоки доступа AVC/HEVC для этого трека. Эта дорожка BL должна иметь тот же уникальный идентификатор дорожки («идентификатор дорожки»), что и дорожка Dolby, чтобы приложение понимало, что это две кодировки одного и того же видео.
    • Приложение может решить, какой трек выбрать, исходя из возможностей платформы.
    • Поскольку дорожка HDR имеет определенный тип HDR, платформа выберет видеодекодер Dolby для декодирования этой дорожки. Дорожка BL будет декодирована обычным видеодекодером AVC/HEVC.
  • Долбидекодер:
    • DolbyDecoder получает единицы доступа, которые содержат необходимые единицы доступа для всех уровней (EL+BL+MD или BL+MD).
    • Информация CSD (специфические данные кодека, такие как SPS+PPS+VPS) для отдельных уровней может быть упакована в 1 кадр CSD, определяемый Dolby. Требуется наличие одного кадра CSD.

Действия Dolby

  1. Определите упаковку единиц доступа для различных схем контейнера Dolby (например, BL+EL+MD) для абстрактного декодера Dolby (т. е. формата буфера, ожидаемого декодером HDR).
  2. Определите упаковку CSD для абстрактного декодера Dolby.

Действия продавца

  1. Внедрить экстрактор Dolby. Это также можно сделать с помощью Dolby.
  2. Интегрируйте DolbyExtractor в инфраструктуру. Точка входа — frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Объявите профиль декодера HDR и тип уровня OMX. Пример: OMX_VIDEO_DOLBYPROFILETYPE и OMX_VIDEO_DOLBYLEVELTYP .
  4. Реализовать поддержку индекса: 'OMX.google.android.index.describeColorAspects ».
  5. Распространяйте динамические метаданные HDR в приложение и отображайте их в каждом кадре. Обычно эта информация должна быть упакована в декодированный кадр, как это определено Dolby, поскольку стандарт HDMI не предоставляет способа передать ее на дисплей.

Конвейер декодера VP9

Рисунок 3. Конвейер VP9-PQ

Битовые потоки VP9 упаковываются в контейнеры WebM способом, определенным командой WebM. Приложениям необходимо использовать экстрактор WebM для извлечения метаданных HDR из битового потока перед отправкой кадров в декодер.

  • Экстрактор WebM:
  • Декодер VP9:
    • Декодер получает потоки битов Profile2 и декодирует их как обычные потоки VP9.
    • Декодер получает любые статические метаданные HDR из платформы.
    • Декодер получает статические метаданные через блоки доступа к битовому потоку для потоков VP9 PQ.
    • Декодер VP9 должен иметь возможность передавать статические/динамические метаданные HDR на дисплей.

Действия продавца

  1. Реализовать поддержку индекса: OMX.google.android.index.describeHDRColorInfo
  2. Реализовать поддержку индекса: OMX.google.android.index.describeColorAspects
  3. Распространение статических метаданных HDR
,

Видео с расширенным динамическим диапазоном (HDR) — это новый рубеж в области высококачественного декодирования видео, обеспечивающий непревзойденное качество воспроизведения сцен. Это достигается за счет значительного увеличения динамического диапазона компонента яркости (с нынешних 100 кд/м 2 до 1000 кд/м 2 ) и использования гораздо более широкого цветового пространства (BT 2020). Сейчас это центральный элемент эволюции 4K UHD в телевизионном пространстве.

Android 10 поддерживает следующие HDR-видео.

  • HDR10
  • ВП9
  • HDR10+

Начиная с Android 9 и более поздних версий, MediaCodec сообщает метаданные HDR независимо от туннелированного режима. Вы можете получить декодированные данные вместе со статическими/динамическими метаданными в нетуннелируемом режиме. Для HDR10 и VP9Profile2, использующих статические метаданные, они сообщаются в выходном формате с ключом KEY_HDR_STATIC_INFO . Для HDR10+, использующего динамические метаданные, это указывается с помощью ключа KEY_HDR10_PLUS_INFO в выходном формате и может меняться для каждого выходного кадра. Дополнительную информацию см. в разделе Мультимедийное туннелирование .

Начиная с Android 7.0, первоначальная поддержка HDR включает создание правильных констант для обнаружения и настройки видеоконвейеров HDR. Это означает определение типов кодеков и режимов отображения, а также определение того, как данные HDR должны передаваться в MediaCodec и передаваться в декодеры HDR.

Цель этого документа — помочь разработчикам приложений поддерживать воспроизведение потока HDR, а также помочь OEM-производителям и SOC включить функции HDR.

Поддерживаемые технологии HDR

Начиная с Android 7.0 и более поздних версий поддерживаются следующие технологии HDR.

Технология Dolby-Vision HDR10 ВП9-HLG ВП9-PQ
Кодек AVC/HEVC HEVC ВП9 ВП9
Передаточная функция СТ-2084 СТ-2084 ГВУ СТ-2084
Тип метаданных HDR Динамический Статический Никто Статический

В Android 7.0 определено только воспроизведение HDR через туннельный режим , но устройства могут добавить поддержку воспроизведения HDR на SurfaceViews с использованием непрозрачных видеобуферов. Другими словами:

  • Не существует стандартного API Android для проверки поддержки воспроизведения HDR с использованием нетуннельных декодеров.
  • Туннельные видеодекодеры, рекламирующие возможность воспроизведения HDR, должны поддерживать воспроизведение HDR при подключении к дисплеям с поддержкой HDR.
  • Состав GL HDR-контента не поддерживается версией AOSP Android 7.0.

Открытие

Для воспроизведения HDR требуется декодер с поддержкой HDR и подключение к дисплею с поддержкой HDR. Необязательно, для некоторых технологий требуется специальный экстрактор.

Отображать

Приложения должны использовать новый API Display.getHdrCapabilities для запроса технологий HDR, поддерживаемых указанным дисплеем. По сути, это информация в блоке статических метаданных EDID, как определено в CTA-861.3:

  • public Display.HdrCapabilities getHdrCapabilities()
    Возвращает возможности HDR дисплея.
  • Display.HdrCapabilities
    Инкапсулирует возможности HDR данного дисплея. Например, какие типы HDR он поддерживает, а также сведения о желаемых данных яркости.

Константы:

  • int HDR_TYPE_DOLBY_VISION
    Поддержка Dolby Vision.
  • int HDR_TYPE_HDR10
    Поддержка HDR10/PQ.
  • int HDR_TYPE_HDR10_PLUS
    Поддержка HDR10+.
  • int HDR_TYPE_HLG
    Поддержка гибридной логарифмической гаммы.
  • float INVALID_LUMINANCE
    Недопустимое значение яркости.

Публичные методы:

  • float getDesiredMaxAverageLuminance()
    Возвращает желаемые данные максимальной средней яркости контента в кд/кд/м 2 для этого дисплея.
  • float getDesiredMaxLuminance()
    Возвращает желаемые данные максимальной яркости контента в кд/кд/м 2 для этого дисплея.
  • float getDesiredMinLuminance()
    Возвращает требуемые данные минимальной яркости контента в кд/кд/м 2 для этого дисплея.
  • int[] getSupportedHdrTypes()
    Получает поддерживаемые типы HDR этого дисплея (см. константы). Возвращает пустой массив, если HDR не поддерживается дисплеем.

Декодер

Приложения должны использовать существующий API CodecCapabilities.profileLevels для проверки поддержки новых профилей с поддержкой HDR:

Dolby-Vision

Константа mime MediaFormat :

String MIMETYPE_VIDEO_DOLBY_VISION

Константы профиля MediaCodecInfo.CodecProfileLevel :

int DolbyVisionProfileDvavPen
int DolbyVisionProfileDvavPer
int DolbyVisionProfileDvheDen
int DolbyVisionProfileDvheDer
int DolbyVisionProfileDvheDtb
int DolbyVisionProfileDvheDth
int DolbyVisionProfileDvheDtr
int DolbyVisionProfileDvheStn

Видеослои и метаданные Dolby Vision должны быть объединены в один буфер для каждого кадра с помощью видеоприложений. Это делается автоматически с помощью MediaExtractor с поддержкой Dolby-Vision.

ХВК HDR 10

Константы профиля MediaCodecInfo.CodecProfileLevel :

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG и PQ

Константы профиля MediaCodecInfo.CodecProfileLevel :

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Если платформа поддерживает декодер с поддержкой HDR, она также должна поддерживать экстрактор с поддержкой HDR.

Только туннельные декодеры гарантированно воспроизводят HDR-контент. Воспроизведение с помощью нетуннельных декодеров может привести к потере информации HDR и сведению контента в цветовой объем SDR.

Экстрактор

Следующие контейнеры поддерживаются для различных технологий HDR в Android 7.0:

Технология Dolby-Vision HDR10 ВП9-HLG ВП9-PQ
Контейнер МП4 МП4 ВебМ ВебМ

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

Краткое содержание

Требования к компонентам для каждой технологии HDR показаны в следующей таблице:

Технология Dolby-Vision HDR10 ВП9-HLG ВП9-PQ
Поддерживаемый тип HDR (Дисплей) HDR_TYPE_DOLBY_VISION HDR_TYPE_HDR10 HDR_TYPE_HLG HDR_TYPE_HDR10
Контейнер (Экстрактор) МП4 МП4 ВебМ ВебМ
Декодер MIMETYPE_VIDEO_DOLBY_VISION MIMETYPE_VIDEO_HEVC MIMETYPE_VIDEO_VP9 MIMETYPE_VIDEO_VP9
Профиль (декодер) Один из профилей Dolby HEVCПрофильMain10HDR10 VP9Profile2HDR или VP9Profile3HDR VP9Profile2HDR или VP9Profile3HDR

Примечания:

  • Битовые потоки Dolby-Vision упаковываются в контейнер MP4 способом, определенным Dolby. Приложения могут реализовывать свои собственные экстракторы с поддержкой Dolby при условии, что они упаковывают блоки доступа из соответствующих уровней в единый блок доступа для декодера, как определено Dolby.
  • Платформа может поддерживать экстрактор с поддержкой HDR, но не поддерживать соответствующий декодер с поддержкой HDR.

Воспроизведение

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

  • Для Dolby-Vision вопрос о том, требует ли конкретный медиафайл/дорожка декодера с поддержкой HDR, не доступен сразу. Приложение должно иметь эту информацию заранее или иметь возможность получить ее путем анализа раздела данных MediaFormat, специфичного для кодека.
  • CodecCapabilities.isFormatSupported не учитывает, требуется ли функция туннелированного декодера для поддержки такого профиля.

Включить поддержку платформы HDR

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

Изменения платформы в Android 7.0 для HDR

Вот некоторые ключевые изменения в платформе (приложение/родной уровень), о которых необходимо знать OEM-производителям и SOC.

Отображать

Аппаратный состав

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

  1. Определите линейное цветовое пространство/объем, содержащее все слои, подлежащие компоновке, на основе цвета, мастеринга и потенциальных динамических метаданных слоев.
    При компоновке непосредственно на дисплей это может быть линейное пространство, соответствующее цветовому объему дисплея.
  2. Преобразуйте все слои в общее цветовое пространство.
  3. Выполните смешивание.
  4. При отображении через HDMI:
    1. Определите цвет, мастеринг и потенциальные динамические метаданные для смешанной сцены.
    2. Преобразуйте полученную смешанную сцену в производное цветовое пространство/объем.
  5. При отображении непосредственно на дисплее преобразуйте полученную смешанную сцену в необходимые сигналы дисплея для создания этой сцены.

Открытие дисплея

Обнаружение HDR-дисплея поддерживается только через HWC2. Разработчики устройств должны выборочно включить адаптер HWC2, выпущенный с Android 7.0, чтобы эта функция работала. Поэтому платформы должны добавить поддержку HWC2 или расширить структуру AOSP, чтобы обеспечить возможность предоставления этой информации. HWC2 предоставляет новый API для распространения статических данных HDR в платформу и приложение.

HDMI

  • Подключенный дисплей HDMI объявляет о своих возможностях HDR через HDMI EDID, как определено в разделе 4.2 CTA-861.3 .
  • Должно использоваться следующее отображение EOTF:
    • ET_0 Традиционная гамма — диапазон яркости SDR: не сопоставлен ни с одним типом HDR
    • ET_1 Традиционная гамма – диапазон яркости HDR: не сопоставлен ни с одним типом HDR.
    • ET_2 SMPTE ST 2084 — сопоставлен с типом HDR HDR10.
  • Сигнализация о поддержке Dolby Vision или HLG через HDMI осуществляется в соответствии с определением соответствующих органов.
  • Обратите внимание, что API HWC2 использует значения желаемой яркости с плавающей запятой, поэтому 8-битные значения EDID должны быть преобразованы соответствующим образом.

Декодеры

Платформы должны добавлять туннельные декодеры с поддержкой HDR и рекламировать свою поддержку HDR. Как правило, декодеры с поддержкой HDR должны:

  • Поддержка туннельного декодирования ( FEATURE_TunneledPlayback ).
  • Поддержка статических метаданных HDR ( OMX.google.android.index.describeHDRColorInfo ) и их распространение на композицию дисплея/оборудования. Для HLG на дисплей должны быть отправлены соответствующие метаданные.
  • Поддержка описания цвета ( OMX.google.android.index.describeColorAspects ) и его распространение на композицию дисплея/оборудования.
  • Поддержка встроенных метаданных HDR, как определено соответствующим стандартом.

Поддержка декодера Dolby Vision.

Для поддержки Dolby Vision платформы должны добавить декодер HDR OMX с поддержкой Dolby-Vision. Учитывая специфику Dolby Vision, обычно это декодер-обертка вокруг одного или нескольких декодеров AVC и/или HEVC, а также композитор. Такие декодеры должны:

  • Поддержка типа mime «video/dolby-vision».
  • Рекламируйте поддерживаемые профили/уровни Dolby Vision.
  • Принимайте единицы доступа, которые содержат подединицы доступа всех слоев, как определено Dolby.
  • Принимайте данные, специфичные для кодека, определенные Dolby. Например, данные, содержащие профиль/уровень Dolby Vision и, возможно, данные, относящиеся к кодеку для внутренних декодеров.
  • Поддержка адаптивного переключения между профилями/уровнями Dolby Vision в соответствии с требованиями Dolby.

При настройке декодера фактический профиль Dolby не передается кодеку. Это делается только с помощью данных, специфичных для кодека, после запуска декодера. Платформа может выбрать поддержку нескольких декодеров Dolby Vision: один для профилей AVC, а другой для профилей HEVC, чтобы иметь возможность инициализировать базовые кодеки во время настройки. Если один декодер Dolby Vision поддерживает оба типа профилей, он также должен поддерживать динамическое адаптивное переключение между ними.

Если платформа предоставляет декодер с поддержкой Dolby-Vision в дополнение к общей поддержке декодера HDR, она должна:

  • Предоставьте экстрактор с поддержкой Dolby-Vision, даже если он не поддерживает воспроизведение HDR.
  • Предоставьте декодер, который поддерживает профиль изображения, определенный Dolby.

Поддержка декодера HDR10

Для поддержки HDR10 платформы должны добавить декодер OMX с поддержкой HDR10. Обычно это туннельный декодер HEVC, который также поддерживает анализ и обработку метаданных, связанных с HDMI. Такой декодер (помимо общей поддержки HDR-декодера) должен:

  • Поддержка типа mime «video/hevc».
  • Реклама поддерживает HEVCMain10HDR10. Для поддержки профиля HEVCMain10HRD10 также требуется поддержка профиля HEVCMain10, что требует поддержки профиля HEVCMain на тех же уровнях.
  • Поддержка анализа блоков SEI метаданных мастеринга, а также другой информации, связанной с HDR, содержащейся в SPS.

Поддержка декодера VP9

Для поддержки VP9 HDR платформы должны добавить декодер HDR OMX с поддержкой VP9 Profile2. Обычно это туннельный декодер VP9, ​​который также поддерживает обработку метаданных, связанных с HDMI. Такие декодеры (помимо общей поддержки декодера HDR) должны:

  • Поддержка типа mime «video/x-vnd.on2.vp9».
  • Рекламируйте поддерживаемый VP9Profile2HDR. Для поддержки профиля VP9Profile2HDR также требуется поддержка профиля VP9Profile2 на том же уровне.

Экстракторы

Поддержка экстрактора Dolby Vision

Платформы, поддерживающие декодеры Dolby Vision, должны добавить поддержку экстрактора Dolby (называемого Dolby Extractor) для контента Dolby Video.

  • Обычный экстрактор MP4 может извлечь из файла только базовый слой, но не слои расширения или метаданных. Поэтому для извлечения данных из файла необходим специальный экстрактор Dolby.
  • Экстрактор Dolby должен отображать от 1 до 2 дорожек для каждой видеодорожки (группы) Dolby:
    • Трек Dolby Vision HDR с типом «видео/dolby-vision» для комбинированного 2/3-слойного потока Dolby. Формат единиц доступа к дорожке HDR, который определяет, как упаковать единицы доступа из базового/улучшенного уровня/слоев метаданных в один буфер для декодирования в один кадр HDR, должен определяться Dolby.
    • Если видеодорожка Dolby Vision содержит отдельный (обратно совместимый) базовый слой (BL), экстрактор также должен представить его как отдельную дорожку «video/avc» или «video/hevc». Экстрактор должен предоставить обычные блоки доступа AVC/HEVC для этого трека.
    • Дорожка BL должна иметь тот же уникальный идентификатор дорожки («идентификатор дорожки»), что и дорожка HDR, чтобы приложение понимало, что это две кодировки одного и того же видео.
    • Приложение может решить, какой трек выбрать, исходя из возможностей платформы.
  • Профиль/уровень Dolby Vision должен быть представлен в формате дорожки HDR.
  • Если платформа предоставляет декодер с поддержкой Dolby-Vision, она также должна предоставить экстрактор с поддержкой Dolby-Vision, даже если он не поддерживает воспроизведение HDR.

Поддержка экстрактора HDR10 и VP9 HDR

Для поддержки HDR10 или VP9 HLG не требуется никаких дополнительных требований к экстрактору. Платформы должны расширять экстрактор MP4 для поддержки VP9 PQ в MP4. Статические метаданные HDR должны распространяться в битовом потоке VP9 PQ, чтобы эти метаданные передавались в декодер VP9 PQ и на дисплей через обычный конвейер MediaExtractor => MediaCodec.

Расширения Stagefright для поддержки Dolby Vision

Платформы должны добавить в Stagefright поддержку формата Dolby Vision:

  • Поддержка запроса определения порта для сжатого порта.
  • Поддержка перечисления профилей/уровней для декодера DV.
  • Поддержка экспонирования профиля/уровня DV для дорожек DV HDR.

Подробности реализации конкретной технологии

Конвейер декодера HDR10

Рисунок 1. Конвейер HDR10

Битовые потоки HDR10 упаковываются в контейнеры MP4. Приложения используют обычный экстрактор MP4 для извлечения данных кадра и отправки их в декодер.

  • Экстрактор MPEG4
    Битовые потоки HDR10 распознаются MPEG4Extractor как обычный поток HEVC, и будет извлечена дорожка HDR с типом «видео/HEVC». Платформа выбирает видеодекодер HEVC, который поддерживает профиль Main10HDR10, для декодирования этой дорожки.
  • HEVC-декодер
    Информация HDR находится либо в SEI, либо в SPS. Декодер HEVC сначала принимает кадры, содержащие информацию HDR. Затем декодер извлекает информацию HDR и уведомляет приложение, что оно декодирует видео HDR. Информация о HDR объединяется в выходной формат декодера, который пропагандируется на поверхность позже.

Действия продавца

  1. Рекламный поддержанный профиль декодера HDR и тип OMX Уровень. Пример:
    OMX_VIDEO_HEVCProfileMain10HDR10 (и Main10 )
  2. Реализовать поддержку индекса: ' OMX.google.android.index.describeHDRColorInfo '
  3. Реализовать поддержку индекса: ' OMX.google.android.index.describeColorAspects '
  4. Реализовать поддержку для SEI -аналитического анализа метаданных.

Dolby Vision Decoder Pipeline

Рисунок 2. Трубопровод Dolby Vision

Dolby-Bitstreams упаковываются в контейнеры MP4, как определено Dolby. Приложения могут, теоретически, использовать обычный экстрактор MP4 для самостоятельного извлечения базового слоя, слоя улучшения и метаданного слоя; Однако это не соответствует текущей модели Android MediaExtractor/MediaCodec.

  • DolbyExtractor:
    • Dolby-bitstreams распознается Dolbyextractor, который выставляет различные слои как от 1 до 2 треков для каждой видео-треки Dolby (группа):
      • HDR-трек с типом «видео/Dolby-Vision» для комбинированного 2/3-слоя Dolby Stream. Формат доступа к доступу HDR, который определяет, как упаковать единицы доступа из слоев базового/улучшения/метаданных в один буфер, который будет декодирован в одну кадр HDR, должен быть определен Dolby.
      • (Необязательно, только если BL совместим с обратной задачей), трек BL содержит только базовый слой, который должен быть декодируется обычным декодером MediaCodec, например, декодером AVC/HEVC. Экстрактор должен предоставлять регулярные подразделения AVC/HEVC для этого трека. Этот трек BL должен иметь тот же самый трек-Unique-ID («Track-ID»), что и трек Dolby, поэтому приложение понимает, что это две кодировки одного и того же видео.
    • Приложение может решить, какой трек выбрать в зависимости от возможностей платформы.
    • Поскольку HDR -трек имеет определенный HDR -тип, Framework выберет видео -декодер Dolby, чтобы расшифровать этот трек. Трек BL будет декодирован обычным видео -декодером AVC/HEVC.
  • Dolbydecoder:
    • Dolbydecoder получает единицы доступа, которые содержат необходимые единицы доступа для всех слоев (EL+BL+MD или BL+MD)
    • CSD (конкретные данные, конкретные кодек, такие как SPS+PPS+VPS) для отдельных слоев можно упаковать в 1 кадр CSD, который будет определяться Dolby. Требуется одна рама CSD.

Действия Долби

  1. Определите упаковку единиц доступа для различных схем контейнеров Dolby (например, BL+EL+MD) для абстрактного декодера Dolby (то есть формат буфера, ожидаемый HDR Decoder).
  2. Определите упаковку CSD для абстрактного Dolby Decoder.

Действия продавца

  1. Реализуйте Dolby Extractor. Это также может быть сделано Долби.
  2. Интегрируйте DolbyExtractor в рамку. Точкой входа является frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Объявите профиль декодера HDR и тип OMX Уровень. Пример: OMX_VIDEO_DOLBYPROFILETYPE и OMX_VIDEO_DOLBYLEVELTYP .
  4. Реализовать поддержку индекса: 'OMX.google.android.index.describeColorAspects '
  5. Распространять динамические метаданные HDR в приложение и поверхность в каждом кадре. Как правило, эта информация должна быть упакована в декодированную раму, как определено Dolby, поскольку стандарт HDMI не предоставляет способ передать это на дисплей.

VP9 Decoder Pipeline

Рисунок 3. Конвейер VP9-PQ

Bitstreams VP9 упакованы в контейнеры Webm таким образом, определяемые командой Webm. Приложения должны использовать экстрактор WebM для извлечения метаданных HDR из бит -стрижки перед отправкой кадров в декодер.

  • Экстрактор Webm:
  • Декодер VP9:
    • Декодер получает Profile2 BITStreams и декодирует их как обычные потоки VP9.
    • Декодер получает любые статические метаданные HDR из рамки.
    • Декодер получает статические метаданные через единицы доступа к бит -обработке для потоков PQ VP9.
    • Декодер VP9 должен иметь возможность распространять HDR статические/динамические метаданные на дисплей.

Действия продавца

  1. Реализовать поддержку индекса: OMX.google.android.index.describeHDRColorInfo
  2. Реализовать поддержку индекса: OMX.google.android.index.describeColorAspects
  3. Распространять статические метаданные HDR
,

Видео с высоким динамическим диапазоном (HDR) является следующей границей в высококачественной видео декодировании, в результате чего непревзойденные качества размножения сцены. Это происходит путем значительного увеличения динамического диапазона компонента яркости (от текущего 100 кд/м 2 до 1000 с CD/M 2 ) и с использованием гораздо более широкого цветового пространства (BT 2020). Теперь это центральный элемент эволюции 4K UHD в телевизионном пространстве.

Android 10 поддерживает следующие видео HDR.

  • HDR10
  • ВП9
  • HDR10+

Начиная с Android 9 и выше, MediaCodec сообщает о метаданных HDR независимо от туннелированного режима. Вы можете получить декодированные данные вместе со статическими/динамическими метаданными в неплощенном режиме. Для HDR10 и VP9Profile2, который использует статические метаданные, они сообщаются в выходном формате с Key KEY_HDR_STATIC_INFO . Для HDR10+, который использует динамические метаданные, об этом сообщается с ключом KEY_HDR10_PLUS_INFO в формате вывода и может изменяться для каждого выходного кадра. Смотрите мультимедийное туннелирование для получения дополнительной информации.

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

Цель этого документа - помочь разработчикам приложений поддержать воспроизведение HDR Stream, а также помочь OEM -производителям и SOCS обеспечить функции HDR.

Поддерживаемые HDR Technologies

По состоянию на Android 7.0 и выше, поддерживаются следующие технологии HDR.

Технология Dolby-Vision HDR10 VP9-HLG VP9-PQ
Кодек AVC/HEVC HEVC ВП9 ВП9
Передача функции ST-2084 ST-2084 ГВУ ST-2084
HDR Метаданные тип Динамический Статический Никто Статический

В Android 7.0 определяется только воспроизведение HDR через туннельный режим , но устройства могут добавить поддержку воспроизведения HDR на Surfaceviews с помощью непрозрачных видео буферов. Другими словами:

  • Нет стандартного API Android, чтобы проверить, поддерживается ли воспроизведение HDR с использованием неплощенных декодеров.
  • Туннельные видео декодеры, которые рекламируют возможность воспроизведения HDR, должны поддерживать воспроизведение HDR при подключении к дисплеям с поддержкой HDR.
  • Композиция GL HDR не поддерживается выпуском AOSP Android 7.0.

Открытие

Воспроизведение HDR требует декодера с поддержкой HDR и соединением с HDR-способным дисплеем. При желании некоторые технологии требуют конкретного экстрактора.

Отображать

Приложения должны использовать новый Display.getHdrCapabilities . Это в основном информация в блоке данных статических метаданных EDID, как определено в CTA-861.3:

  • public Display.HdrCapabilities getHdrCapabilities()
    Возвращает возможности HDR дисплея.
  • Display.HdrCapabilities
    Инкапсулирует возможности HDR данного дисплея. Например, какие HDR типы он поддерживает, и подробно о желаемых данных о яркости.

Константы:

  • int HDR_TYPE_DOLBY_VISION
    Dolby Vision Support.
  • int HDR_TYPE_HDR10
    HDR10 / PQ поддержка.
  • int HDR_TYPE_HDR10_PLUS
    HDR10+ поддержка.
  • int HDR_TYPE_HLG
    Гибридная логарифмическая поддержка.
  • float INVALID_LUMINANCE
    Неверное значение яркости.

Публичные методы:

  • float getDesiredMaxAverageLuminance()
    Возвращает желаемый контент MAX-средний фрейм в среднем данных в CD/CD/M 2 для этого дисплея.
  • float getDesiredMaxLuminance()
    Возвращает желаемый контент Max Luminance Data в CD/CD/M 2 для этого дисплея.
  • float getDesiredMinLuminance()
    Возвращает желаемые данные о свете контента в CD/CD/M 2 для этого дисплея.
  • int[] getSupportedHdrTypes()
    Получает поддерживаемые типы HDR этого дисплея (см. Константы). Возвращает пустой массив, если HDR не поддерживается дисплеем.

Декодер

Заявки должны использовать существующие CodecCapabilities.profileLevels .

Dolby-Vision

MediaFormat Mime Constant:

String MIMETYPE_VIDEO_DOLBY_VISION

MediaCodecInfo.CodecProfileLevel Constants:

int DolbyVisionProfileDvavPen
int DolbyVisionProfileDvavPer
int DolbyVisionProfileDvheDen
int DolbyVisionProfileDvheDer
int DolbyVisionProfileDvheDtb
int DolbyVisionProfileDvheDth
int DolbyVisionProfileDvheDtr
int DolbyVisionProfileDvheStn

Видео -слои Dolby Vision и метаданные должны быть объединены в один буфер на кадры с помощью видео приложений. Это делается автоматически с помощью Dolby-Vision, способного MediaExtractor.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel Constants:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG & PQ

MediaCodecInfo.CodecProfileLevel Constants:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Если платформа поддерживает декодер с поддержкой HDR, она также должна поддерживать HDR-способный экстрактор.

Только туннельные декодеры гарантированно воспроизводят контент HDR. Воспроизведение неплощенными декодерами может привести к тому, что информация о HDR будет потеряна, а содержание сглаживается в объем цвета SDR.

Экстрактор

Следующие контейнеры поддерживаются для различных технологий HDR на Android 7.0:

Технология Dolby-Vision HDR10 VP9-HLG VP9-PQ
Контейнер МП4 МП4 ВебМ ВебМ

Обнаружение того, требует ли трек (из файла), не поддерживается поддержка HDR. Приложения могут анализировать данные, специфичные для кодекса, чтобы определить, требует ли треке определенный HDR-профиль.

Краткое содержание

Требования к компонентам для каждой технологии HDR показаны в следующей таблице:

Технология Dolby-Vision HDR10 VP9-HLG VP9-PQ
Поддерживаемый тип HDR (дисплей) Hdr_type_dolby_vision HDR_TYPE_HDR10 Hdr_type_hlg HDR_TYPE_HDR10
Контейнер (экстрактор) МП4 МП4 ВебМ ВебМ
Декодер MimeType_video_dolby_vision MIMETYPE_VIDEO_HEVC MimeType_video_vp9 MimeType_video_vp9
Профиль (декодер) Один из профилей Dolby HEVCPROFILEMAIN10HDR10 Vp9profile2hdr или vp9profile3hdr Vp9profile2hdr или vp9profile3hdr

Примечания:

  • Битстрии Dolby-Vision упаковываются в контейнер MP4 таким образом, определяемый Dolby. Приложения могут реализовать свои собственные экстракторы, способные Dolby, если они упаковывают подразделения Access из соответствующих слоев в единый блок доступа для декодера, как определено Dolby.
  • Платформа может поддерживать экстрактора, способствующего HDR, но нет соответствующего декодера, способствующего HDR.

Воспроизведение

После того, как приложение подтвердила поддержку воспроизведения HDR, оно может воспроизводить контент HDR почти так же, как он воспроизводит не HDR-контент, со следующими предостережениями:

  • Для Dolby-Vision, независимо от того, требуется ли для конкретного медиа-файла/трека, не сразу доступен декодер HDR. Приложение должна иметь эту информацию заранее или иметь возможность получить эту информацию, анализируя раздел данных, специфичный для кода, MediaFormat.
  • CodecCapabilities.isFormatSupported не учитывает, требуется ли туннельная функция декодера для поддержки такого профиля.

Включить поддержку платформы HDR

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

Изменения платформы в Android 7.0 для HDR

Вот некоторые ключевые изменения в платформе (приложение/нативное слой), о которых должны знать OEM и SOC.

Отображать

Аппаратная композиция

Платформы, способствующие HDR, должны поддерживать смешивание контента HDR с не HDR-контентом. Точные характеристики и операции смешивания не определены Android на выпуске 7.0, но процесс обычно следует этим шагам:

  1. Определите линейное цветовое пространство/объем, который содержит все слои, которые должны быть композиция, в зависимости от цвета, мастеринга и потенциальных динамических метаданных слоев.
    Если композиция непосредственно на дисплей, это может быть линейное пространство, которое соответствует цветовому громкости дисплея.
  2. Преобразуйте все слои в общее цветовое пространство.
  3. Выполнить смешивание.
  4. Если отображение через HDMI:
    1. Определите цвет, мастерство и потенциальные динамические метаданные для смешанной сцены.
    2. Преобразуйте полученную смешанную сцену в производное цветовое пространство/том.
  5. Если отображается непосредственно на дисплей, преобразуйте полученную смешанную сцену в необходимые сигналы дисплея, чтобы создать эту сцену.

Показать обнаружение

HDR Display Discovery поддерживается только через HWC2. Реализаторы устройств должны выборочно включить адаптер HWC2, который выпускается с Android 7.0 для работы этой функции. Следовательно, платформы должны добавить поддержку HWC2 или расширить структуру AOSP, чтобы позволить способ предоставить эту информацию. HWC2 раскрывает новый API для распространения статических данных HDR в структуру и приложение.

HDMI

  • Подключенный HDMI-дисплей рекламирует свои возможности HDR через HDMI EDID, как определено в CTA-861.3 Раздел 4.2.
  • Следующее отображение EOTF должно использоваться:
    • ET_0 Традиционная гамма - диапазон яркости SDR: не нанесен на карту ни один тип HDR
    • ET_1 Традиционная гамма - диапазон яркости HDR: не нанесен на карту ни один тип HDR
    • ET_2 SMPTE ST 2084 - отображается с HDR Type HDR10
  • Передача сигналов Dolby Vision или HLG -поддержки над HDMI выполняется, как определено их соответствующими телами.
  • Обратите внимание, что API HWC2 использует желаемые значения Float Float, поэтому 8-битные значения EDID должны быть переведены подходящим образом.

Декодеры

Платформы должны добавлять туннелированные туннельные декодеры HDR и рекламировать их поддержку HDR. Как правило, декодеры с поддержкой HDR должны:

  • Поддержка туннелированного декодирования ( FEATURE_TunneledPlayback ).
  • Поддерживают статические метаданные HDR ( OMX.google.android.index.describeHDRColorInfo ) и его распространение в состав дисплея/оборудования. Для HLG соответствующие метаданные должны быть отправлены на дисплей.
  • Описание цвета поддержки ( OMX.google.android.index.describeColorAspects ) и его распространение в композицию дисплея/оборудование.
  • Поддержка метаданных встроенных HDR, как определено соответствующим стандартом.

Dolby Vision Decoder

Для поддержки Dolby Vision платформы должны добавить Dolby-Vision, способный HDR OMX Decoder. Учитывая специфику зрения Dolby, это обычно декодер обертки вокруг одного или нескольких декодеров AVC и/или HEVC, а также композитора. Такие декодеры должны:

  • Поддержка типа MIME "Video/Dolby-Vision."
  • Реклама поддерживает профили/уровни Dolby Vision.
  • Примите подразделения доступа, которые содержат подразделения по подъезду всех слоев, как определено Dolby.
  • Примите кодек-специфические данные, определенные Dolby. Например, данные, содержащие профиль/уровень зрения Dolby Vision, и, возможно, данные, специфичные для кодекса для внутренних декодеров.
  • Поддержка адаптивного переключения между профилями/уровнями Dolby Vision, как того требует Dolby.

При настройке декодера фактический профиль Dolby не передается кодеку. Это делается только с помощью данных, специфичных для кодек, после начала декодера. Платформа может поддерживать несколько декодеров Dolby Vision: один для профилей AVC, а другой для профилей HEVC, чтобы иметь возможность инициализировать основные кодеки во время настройки. Если один декодер Dolby Vision поддерживает оба типа профилей, он также должен поддерживать переключение между теми, которые динамически адаптивно.

Если платформа предоставляет декодер Dolby-Vision, в дополнение к общей поддержке декодера HDR, она должна: она должна:

  • Предоставьте экстрактора, осведомленного Dolby-Vision, даже если он не поддерживает воспроизведение HDR.
  • Предоставьте декодер, который поддерживает профиль видения, как определено Dolby.

Поддержка декодера HDR10

Чтобы поддержать HDR10, платформы должны добавить декодер OMX, способный OMX, способный HDR10. Обычно это туннельный декодер HEVC, который также поддерживает анализ и обработку метаданных HDMI. Такой декодер (в дополнение к общей поддержке декодера HDR) должен:

  • Поддержка типа Mime "Video/HEVC".
  • Реклама поддерживает HEVCMAIN10HDR10. Поддержка профиля HEVCMAIN10HRD10 также требует поддержки профиля HEVCMAIN10, который требует поддержки профиля HEVCMAIN на тех же уровнях.
  • Поддержка разбора блоков SEI Mastering Metadata, а также другую информацию, связанную с HDR, содержащуюся в SPS.

Поддержка декодера VP9

Чтобы поддержать VP9 HDR, платформы должны добавить VP9 Profile2-Capable Decoder HDR OMX. Обычно это туннельный декодер VP9, ​​который также поддерживает обработку метаданных HDMI. Такие декодеры (в дополнение к общей поддержке декодера HDR) должны:

  • Поддержка типа Mime "Video/x-Vnd.on2.vp9."
  • Реклама поддерживается VP9Profile2HDR. Поддержка профиля VP9Profile2HDR также требует поддержки профиля VP9Profile2 на том же уровне.

Экстракторы

Поддержка экстрактора Dolby Vision

Платформы, которые поддерживают декодеры Dolby Vision, должны добавить поддержку Dolby Extractor (называемый Dolby Extractor) для видеоконтента Dolby.

  • Обычный экстрактор MP4 может извлекать базовый слой из файла, но не слои улучшения или метаданных. Таким образом, для извлечения данных из файла необходим специальный экстрактор Dolby.
  • Экстрактор Dolby должен разоблачить от 1 до 2 треков для каждой видео -треки Dolby (группа):
    • Трек Dolby Vision HDR с типом «видео/Dolby-Vision» для комбинированного 2/3-слоя Dolby Stream. Формат доступа к доступу HDR, который определяет, как упаковать единицы доступа из слоев базового/улучшения/метаданных в один буфер, который будет декодирован в одну кадр HDR, должен быть определен Dolby.
    • Если видео-трека Dolby Vision содержит отдельный (обратный совместимый) базовый слой (BL), экстрактор также должен выявлять это как отдельный «видео/AVC» или «Видео/HEVC». Экстрактор должен предоставлять регулярные подразделения AVC/HEVC для этого трека.
    • Трек BL должен иметь тот же самый трек-Unique-ID («Track-ID»), что и HDR-трек, чтобы приложение понимает, что это две кодировки того же видео.
    • Приложение может решить, какой трек выбрать в зависимости от возможностей платформы.
  • Профиль/уровень зрения Dolby Vision должен быть обнаружен в формате трека HDR -трека.
  • Если платформа предоставляет декодер Dolby-Vision Decoder, она также должна предоставить экстрактор Dolby-Vision, даже если он не поддерживает воспроизведение HDR.

Поддержка экстрактора HDR10 и VP9 HDR

Не существует дополнительных требований к экстрактору для поддержки HDR10 или VP9 HLG. Платформы должны расширять экстрактора MP4 для поддержки VP9 PQ в MP4. Статические метаданные HDR должны распространяться в бите VP9 PQ Bitstream, так что эти метаданные передаются в декодер VP9 PQ и на дисплей через обычный конвейер MediaExtractor => MediaCodec.

Расширения StageFright для поддержки Dolby Vision

Платформы должны добавить поддержку формата Vision Dolby к StageFright:

  • Поддержка запроса определения порта для сжатого порта.
  • Поддержка профиля/перечисление уровня для декодера DV.
  • Поддержка разоблачения профиля DV/уровня для треков DV HDR.

Технологические детали реализации

HDR10 Декодер трубопровод

Рисунок 1. Трубопровод HDR10

Битстрии HDR10 упаковываются в контейнеры MP4. Приложения используют обычный экстрактор MP4 для извлечения данных рамки и отправки его декодером.

  • Экстрактор MPEG4
    Bitstreams HDR10 распознаются как обычный поток HEVC MPEG4Extractor, и будет извлечен трек HDR с типом «видео/HEVC». Framework выбирает декодер видео HEVC, который поддерживает профиль Main10HDR10, чтобы расшифровать этот трек.
  • Декодер HEVC
    Информация HDR находится в SEI или SPS. Декодер HEVC впервые получает кадры, которые содержат информацию HDR. Затем декодер извлекает информацию HDR и уведомляет приложение, что оно декодирует видео HDR. Информация о HDR объединяется в выходной формат декодера, который пропагандируется на поверхность позже.

Действия продавца

  1. Рекламный поддержанный профиль декодера HDR и тип OMX Уровень. Пример:
    OMX_VIDEO_HEVCProfileMain10HDR10 (и Main10 )
  2. Реализовать поддержку индекса: ' OMX.google.android.index.describeHDRColorInfo '
  3. Реализовать поддержку индекса: ' OMX.google.android.index.describeColorAspects '
  4. Реализовать поддержку для SEI -аналитического анализа метаданных.

Dolby Vision Decoder Pipeline

Рисунок 2. Трубопровод Dolby Vision

Dolby-Bitstreams упаковываются в контейнеры MP4, как определено Dolby. Приложения могут, теоретически, использовать обычный экстрактор MP4 для самостоятельного извлечения базового слоя, слоя улучшения и метаданного слоя; Однако это не соответствует текущей модели Android MediaExtractor/MediaCodec.

  • DolbyExtractor:
    • Dolby-bitstreams распознается Dolbyextractor, который выставляет различные слои как от 1 до 2 треков для каждой видео-треки Dolby (группа):
      • HDR-трек с типом «видео/Dolby-Vision» для комбинированного 2/3-слоя Dolby Stream. Формат доступа к доступу HDR, который определяет, как упаковать единицы доступа из слоев базового/улучшения/метаданных в один буфер, который будет декодирован в одну кадр HDR, должен быть определен Dolby.
      • (Необязательно, только если BL совместим с обратной задачей), трек BL содержит только базовый слой, который должен быть декодируется обычным декодером MediaCodec, например, декодером AVC/HEVC. Экстрактор должен предоставлять регулярные подразделения AVC/HEVC для этого трека. Этот трек BL должен иметь тот же самый трек-Unique-ID («Track-ID»), что и трек Dolby, поэтому приложение понимает, что это две кодировки одного и того же видео.
    • Приложение может решить, какой трек выбрать в зависимости от возможностей платформы.
    • Поскольку HDR -трек имеет определенный HDR -тип, Framework выберет видео -декодер Dolby, чтобы расшифровать этот трек. Трек BL будет декодирован обычным видео -декодером AVC/HEVC.
  • Dolbydecoder:
    • Dolbydecoder получает единицы доступа, которые содержат необходимые единицы доступа для всех слоев (EL+BL+MD или BL+MD)
    • CSD (конкретные данные, конкретные кодек, такие как SPS+PPS+VPS) для отдельных слоев можно упаковать в 1 кадр CSD, который будет определяться Dolby. Требуется одна рама CSD.

Действия Долби

  1. Определите упаковку единиц доступа для различных схем контейнеров Dolby (например, BL+EL+MD) для абстрактного декодера Dolby (то есть формат буфера, ожидаемый HDR Decoder).
  2. Определите упаковку CSD для абстрактного Dolby Decoder.

Действия продавца

  1. Реализуйте Dolby Extractor. Это также может быть сделано Долби.
  2. Интегрируйте DolbyExtractor в рамку. Точкой входа является frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Объявите профиль декодера HDR и тип OMX Уровень. Пример: OMX_VIDEO_DOLBYPROFILETYPE и OMX_VIDEO_DOLBYLEVELTYP .
  4. Реализовать поддержку индекса: 'OMX.google.android.index.describeColorAspects '
  5. Распространять динамические метаданные HDR в приложение и поверхность в каждом кадре. Как правило, эта информация должна быть упакована в декодированную раму, как определено Dolby, поскольку стандарт HDMI не предоставляет способ передать это на дисплей.

VP9 Decoder Pipeline

Рисунок 3. Конвейер VP9-PQ

Bitstreams VP9 упакованы в контейнеры Webm таким образом, определяемые командой Webm. Приложения должны использовать экстрактор WebM для извлечения метаданных HDR из бит -стрижки перед отправкой кадров в декодер.

  • Экстрактор Webm:
  • Декодер VP9:
    • Декодер получает Profile2 BITStreams и декодирует их как обычные потоки VP9.
    • Декодер получает любые статические метаданные HDR из рамки.
    • Декодер получает статические метаданные через единицы доступа к бит -обработке для потоков PQ VP9.
    • Декодер VP9 должен иметь возможность распространять HDR статические/динамические метаданные на дисплей.

Действия продавца

  1. Реализовать поддержку индекса: OMX.google.android.index.describeHDRColorInfo
  2. Реализовать поддержку индекса: OMX.google.android.index.describeColorAspects
  3. Распространять статические метаданные HDR
,

Видео с высоким динамическим диапазоном (HDR) является следующей границей в высококачественной видео декодировании, в результате чего непревзойденные качества размножения сцены. Это происходит путем значительного увеличения динамического диапазона компонента яркости (от текущего 100 кд/м 2 до 1000 с CD/M 2 ) и с использованием гораздо более широкого цветового пространства (BT 2020). Теперь это центральный элемент эволюции 4K UHD в телевизионном пространстве.

Android 10 поддерживает следующие видео HDR.

  • HDR10
  • ВП9
  • HDR10+

Начиная с Android 9 и выше, MediaCodec сообщает о метаданных HDR независимо от туннелированного режима. Вы можете получить декодированные данные вместе со статическими/динамическими метаданными в неплощенном режиме. Для HDR10 и VP9Profile2, который использует статические метаданные, они сообщаются в выходном формате с Key KEY_HDR_STATIC_INFO . Для HDR10+, который использует динамические метаданные, об этом сообщается с ключом KEY_HDR10_PLUS_INFO в формате вывода и может изменяться для каждого выходного кадра. Смотрите мультимедийное туннелирование для получения дополнительной информации.

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

Цель этого документа - помочь разработчикам приложений поддержать воспроизведение HDR Stream, а также помочь OEM -производителям и SOCS обеспечить функции HDR.

Поддерживаемые HDR Technologies

По состоянию на Android 7.0 и выше, поддерживаются следующие технологии HDR.

Технология Dolby-Vision HDR10 VP9-HLG VP9-PQ
Кодек AVC/HEVC HEVC ВП9 ВП9
Передача функции ST-2084 ST-2084 ГВУ ST-2084
HDR Метаданные тип Динамический Статический Никто Статический

В Android 7.0 определяется только воспроизведение HDR через туннельный режим , но устройства могут добавить поддержку воспроизведения HDR на Surfaceviews с помощью непрозрачных видео буферов. Другими словами:

  • Нет стандартного API Android, чтобы проверить, поддерживается ли воспроизведение HDR с использованием неплощенных декодеров.
  • Туннельные видео декодеры, которые рекламируют возможность воспроизведения HDR, должны поддерживать воспроизведение HDR при подключении к дисплеям с поддержкой HDR.
  • Композиция GL HDR не поддерживается выпуском AOSP Android 7.0.

Открытие

Воспроизведение HDR требует декодера с поддержкой HDR и соединением с HDR-способным дисплеем. При желании некоторые технологии требуют конкретного экстрактора.

Отображать

Приложения должны использовать новый Display.getHdrCapabilities . Это в основном информация в блоке данных статических метаданных EDID, как определено в CTA-861.3:

  • public Display.HdrCapabilities getHdrCapabilities()
    Возвращает возможности HDR дисплея.
  • Display.HdrCapabilities
    Инкапсулирует возможности HDR данного дисплея. Например, какие HDR типы он поддерживает, и подробно о желаемых данных о яркости.

Константы:

  • int HDR_TYPE_DOLBY_VISION
    Dolby Vision Support.
  • int HDR_TYPE_HDR10
    HDR10 / PQ поддержка.
  • int HDR_TYPE_HDR10_PLUS
    HDR10+ поддержка.
  • int HDR_TYPE_HLG
    Гибридная логарифмическая поддержка.
  • float INVALID_LUMINANCE
    Неверное значение яркости.

Публичные методы:

  • float getDesiredMaxAverageLuminance()
    Возвращает желаемый контент MAX-средний фрейм в среднем данных в CD/CD/M 2 для этого дисплея.
  • float getDesiredMaxLuminance()
    Возвращает желаемый контент Max Luminance Data в CD/CD/M 2 для этого дисплея.
  • float getDesiredMinLuminance()
    Возвращает желаемые данные о свете контента в CD/CD/M 2 для этого дисплея.
  • int[] getSupportedHdrTypes()
    Получает поддерживаемые типы HDR этого дисплея (см. Константы). Возвращает пустой массив, если HDR не поддерживается дисплеем.

Декодер

Заявки должны использовать существующие CodecCapabilities.profileLevels .

Dolby-Vision

MediaFormat Mime Constant:

String MIMETYPE_VIDEO_DOLBY_VISION

MediaCodecInfo.CodecProfileLevel Constants:

int DolbyVisionProfileDvavPen
int DolbyVisionProfileDvavPer
int DolbyVisionProfileDvheDen
int DolbyVisionProfileDvheDer
int DolbyVisionProfileDvheDtb
int DolbyVisionProfileDvheDth
int DolbyVisionProfileDvheDtr
int DolbyVisionProfileDvheStn

Видео -слои Dolby Vision и метаданные должны быть объединены в один буфер на кадры с помощью видео приложений. Это делается автоматически с помощью Dolby-Vision, способного MediaExtractor.

HEVC HDR 10

MediaCodecInfo.CodecProfileLevel Constants:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG & PQ

MediaCodecInfo.CodecProfileLevel Constants:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Если платформа поддерживает декодер с поддержкой HDR, она также должна поддерживать HDR-способный экстрактор.

Только туннельные декодеры гарантированно воспроизводят контент HDR. Воспроизведение неплощенными декодерами может привести к тому, что информация о HDR будет потеряна, а содержание сглаживается в объем цвета SDR.

Экстрактор

Следующие контейнеры поддерживаются для различных технологий HDR на Android 7.0:

Технология Dolby-Vision HDR10 VP9-HLG VP9-PQ
Контейнер МП4 МП4 ВебМ ВебМ

Обнаружение того, требует ли трек (из файла), не поддерживается поддержка HDR. Приложения могут анализировать данные, специфичные для кодекса, чтобы определить, требует ли треке определенный HDR-профиль.

Краткое содержание

Требования к компонентам для каждой технологии HDR показаны в следующей таблице:

Технология Dolby-Vision HDR10 VP9-HLG VP9-PQ
Поддерживаемый тип HDR (дисплей) Hdr_type_dolby_vision HDR_TYPE_HDR10 Hdr_type_hlg HDR_TYPE_HDR10
Контейнер (экстрактор) МП4 МП4 ВебМ ВебМ
Декодер MimeType_video_dolby_vision MIMETYPE_VIDEO_HEVC MimeType_video_vp9 MimeType_video_vp9
Профиль (декодер) Один из профилей Dolby HEVCPROFILEMAIN10HDR10 Vp9profile2hdr или vp9profile3hdr Vp9profile2hdr или vp9profile3hdr

Примечания:

  • Битстрии Dolby-Vision упаковываются в контейнер MP4 таким образом, определяемый Dolby. Приложения могут реализовать свои собственные экстракторы, способные Dolby, если они упаковывают подразделения Access из соответствующих слоев в единый блок доступа для декодера, как определено Dolby.
  • Платформа может поддерживать экстрактора, способствующего HDR, но нет соответствующего декодера, способствующего HDR.

Воспроизведение

После того, как приложение подтвердила поддержку воспроизведения HDR, оно может воспроизводить контент HDR почти так же, как он воспроизводит не HDR-контент, со следующими предостережениями:

  • Для Dolby-Vision, независимо от того, требуется ли для конкретного медиа-файла/трека, не сразу доступен декодер HDR. Приложение должна иметь эту информацию заранее или иметь возможность получить эту информацию, анализируя раздел данных, специфичный для кода, MediaFormat.
  • CodecCapabilities.isFormatSupported не учитывает, требуется ли туннельная функция декодера для поддержки такого профиля.

Включить поддержку платформы HDR

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

Изменения платформы в Android 7.0 для HDR

Вот некоторые ключевые изменения в платформе (приложение/нативное слой), о которых должны знать OEM и SOC.

Отображать

Аппаратная композиция

Платформы, способствующие HDR, должны поддерживать смешивание контента HDR с не HDR-контентом. Точные характеристики и операции смешивания не определены Android на выпуске 7.0, но процесс обычно следует этим шагам:

  1. Определите линейное цветовое пространство/объем, который содержит все слои, которые должны быть композиция, в зависимости от цвета, мастеринга и потенциальных динамических метаданных слоев.
    Если композиция непосредственно на дисплей, это может быть линейное пространство, которое соответствует цветовому громкости дисплея.
  2. Преобразуйте все слои в общее цветовое пространство.
  3. Выполнить смешивание.
  4. Если отображение через HDMI:
    1. Определите цвет, мастерство и потенциальные динамические метаданные для смешанной сцены.
    2. Преобразуйте полученную смешанную сцену в производное цветовое пространство/том.
  5. Если отображается непосредственно на дисплей, преобразуйте полученную смешанную сцену в необходимые сигналы дисплея, чтобы создать эту сцену.

Показать обнаружение

HDR Display Discovery поддерживается только через HWC2. Реализаторы устройств должны выборочно включить адаптер HWC2, который выпускается с Android 7.0 для работы этой функции. Следовательно, платформы должны добавить поддержку HWC2 или расширить структуру AOSP, чтобы позволить способ предоставить эту информацию. HWC2 раскрывает новый API для распространения статических данных HDR в структуру и приложение.

HDMI

  • Подключенный HDMI-дисплей рекламирует свои возможности HDR через HDMI EDID, как определено в CTA-861.3 Раздел 4.2.
  • Следующее отображение EOTF должно использоваться:
    • ET_0 Традиционная гамма - диапазон яркости SDR: не нанесен на карту ни один тип HDR
    • ET_1 Традиционная гамма - диапазон яркости HDR: не нанесен на карту ни один тип HDR
    • ET_2 SMPTE ST 2084 - отображается с HDR Type HDR10
  • Передача сигналов Dolby Vision или HLG -поддержки над HDMI выполняется, как определено их соответствующими телами.
  • Обратите внимание, что API HWC2 использует желаемые значения Float Float, поэтому 8-битные значения EDID должны быть переведены подходящим образом.

Декодеры

Платформы должны добавлять туннелированные туннельные декодеры HDR и рекламировать их поддержку HDR. Как правило, декодеры с поддержкой HDR должны:

  • Поддержка туннелированного декодирования ( FEATURE_TunneledPlayback ).
  • Поддерживают статические метаданные HDR ( OMX.google.android.index.describeHDRColorInfo ) и его распространение в состав дисплея/оборудования. Для HLG соответствующие метаданные должны быть отправлены на дисплей.
  • Описание цвета поддержки ( OMX.google.android.index.describeColorAspects ) и его распространение в композицию дисплея/оборудование.
  • Поддержка метаданных встроенных HDR, как определено соответствующим стандартом.

Dolby Vision Decoder

Для поддержки Dolby Vision платформы должны добавить Dolby-Vision, способный HDR OMX Decoder. Учитывая специфику зрения Dolby, это обычно декодер обертки вокруг одного или нескольких декодеров AVC и/или HEVC, а также композитора. Такие декодеры должны:

  • Поддержка типа MIME "Video/Dolby-Vision."
  • Реклама поддерживает профили/уровни Dolby Vision.
  • Примите подразделения доступа, которые содержат подразделения по подъезду всех слоев, как определено Dolby.
  • Примите кодек-специфические данные, определенные Dolby. Например, данные, содержащие профиль/уровень зрения Dolby Vision, и, возможно, данные, специфичные для кодекса для внутренних декодеров.
  • Поддержка адаптивного переключения между профилями/уровнями Dolby Vision, как того требует Dolby.

При настройке декодера фактический профиль Dolby не передается кодеку. Это делается только с помощью данных, специфичных для кодек, после начала декодера. Платформа может поддерживать несколько декодеров Dolby Vision: один для профилей AVC, а другой для профилей HEVC, чтобы иметь возможность инициализировать основные кодеки во время настройки. Если один декодер Dolby Vision поддерживает оба типа профилей, он также должен поддерживать переключение между теми, которые динамически адаптивно.

If a platform provides a Dolby-Vision capable decoder in addition to the general HDR decoder support, it must:

  • Provide a Dolby-Vision aware extractor, even if it does not support HDR playback.
  • Provide a decoder that supports the vision profile as defined by Dolby.

HDR10 decoder support

To support HDR10, platforms must add an HDR10-capable OMX decoder. This is normally a tunneled HEVC decoder that also supports parsing and handling HDMI related metadata. Such a decoder (in addition to the general HDR decoder support) must:

  • Support mime type "video/hevc."
  • Advertise supported HEVCMain10HDR10. HEVCMain10HRD10 profile support also requires supporting the HEVCMain10 profile, which requires supporting the HEVCMain profile at the same levels.
  • Support parsing the mastering metadata SEI blocks, as well as other HDR related info contained in SPS.

VP9 decoder support

To support VP9 HDR, platforms must add a VP9 Profile2-capable HDR OMX decoder. This is normally a tunneled VP9 decoder that also supports handling HDMI related metadata. Such decoders (in addition to the general HDR decoder support) must:

  • Support mime type "video/x-vnd.on2.vp9."
  • Advertise supported VP9Profile2HDR. VP9Profile2HDR profile support also requires supporting VP9Profile2 profile at the same level.

Экстракторы

Dolby Vision extractor support

Platforms that support Dolby Vision decoders must add Dolby extractor (called Dolby Extractor) support for Dolby Video content.

  • A regular MP4 extractor can only extract the base layer from a file, but not the enhancement or metadata layers. So a special Dolby extractor is needed to extract the data from the file.
  • The Dolby extractor must expose 1 to 2 tracks for each Dolby video track (group):
    • A Dolby Vision HDR track with the type of "video/dolby-vision" for the combined 2/3-layers Dolby stream. The HDR track's access-unit format, which defines how to package the access units from the base/enhancement/metadata layers into a single buffer to be decoded into a single HDR frame, is to be defined by Dolby.
    • If a Dolby Vision video track contains a separate (backward compatible) base-layer (BL), the extractor must also expose this as a separate "video/avc" or "video/hevc" track. The extractor must provide regular AVC/HEVC access units for this track.
    • The BL track must have the same track-unique-ID ("track-ID") as the HDR track so the app understands that these are two encodings of the same video.
    • The application can decide which track to choose based on the platform's capability.
  • The Dolby Vision profile/level must be exposed in the track format of the HDR track.
  • If a platform provides a Dolby-Vision capable decoder, it must also provide a Dolby-Vision aware extractor, even if it does not support HDR playback.

HDR10 and VP9 HDR extractor support

There are no additional extractor requirements to support HDR10 or VP9 HLG. Platforms must extend MP4 extractor to support VP9 PQ in MP4. HDR static metadata must be propagated in the VP9 PQ bitstream, such that this metadata is passed to the VP9 PQ decoder and to the display via the normal MediaExtractor => MediaCodec pipeline.

Stagefright extensions for Dolby Vision support

Platforms must add Dolby Vision format support to Stagefright:

  • Support for port definition query for compressed port.
  • Support profile/level enumeration for DV decoder.
  • Support exposing DV profile/level for DV HDR tracks.

Technology-specific implementation details

HDR10 decoder pipeline

Figure 1. HDR10 pipeline

HDR10 bitstreams are packaged in MP4 containers. Applications use a regular MP4 extractor to extract the frame data and send it to the decoder.

  • MPEG4 Extractor
    HDR10 bitstreams are recognized as just a normal HEVC stream by a MPEG4Extractor and the HDR track with the type "video/HEVC" will be extracted. The framework picks an HEVC video decoder that supports the Main10HDR10 profile to decode that track.
  • HEVC Decoder
    HDR information is in either SEI or SPS. The HEVC decoder first receives frames that contain the HDR information. The decoder then extracts the HDR information and notifies the application that it is decoding an HDR video. HDR information is bundled into decoder output format, which is propagated to the surface later.

Vendor actions

  1. Advertise supported HDR decoder profile and level OMX type. Пример:
    OMX_VIDEO_HEVCProfileMain10HDR10 (and Main10 )
  2. Implement support for index: ' OMX.google.android.index.describeHDRColorInfo '
  3. Implement support for index: ' OMX.google.android.index.describeColorAspects '
  4. Implement support for SEI parsing of mastering metadata.

Dolby Vision decoder pipeline

Figure 2. Dolby Vision pipeline

Dolby-bitstreams are packaged in MP4 containers as defined by Dolby. Applications could, in theory, use a regular MP4 extractor to extract the base layer, enhancement layer, and metadata layer independently; however, this does not fit the current Android MediaExtractor/MediaCodec model.

  • DolbyExtractor:
    • Dolby-bitstreams are recognized by a DolbyExtractor, which exposes the various layers as 1 to 2 tracks for each dolby video track (group):
      • An HDR track with the type of "video/dolby-vision" for the combined 2/3-layers dolby stream. The HDR track's access-unit format, which defines how to package the access units from the base/enhancement/metadata layers into a single buffer to be decoded into a single HDR frame, is to be defined by Dolby.
      • (Optional, only if the BL is backward compatible) A BL track contains only the base layer, which must be decodable by regular MediaCodec decoder, for example, AVC/HEVC decoder. The extractor should provide regular AVC/HEVC access units for this track. This BL track must have the same track-unique-ID ("track-ID") as the Dolby track so the application understands that these are two encodings of the same video.
    • The application can decide which track to choose based on the platform's capability.
    • Because an HDR track has a specific HDR type, the framework will pick a Dolby video decoder to decode that track. The BL track will be decoded by a regular AVC/HEVC video decoder.
  • DolbyDecoder:
    • The DolbyDecoder receives access units that contain the required access units for all layers (EL+BL+MD or BL+MD)
    • CSD (codec specific data, such as SPS+PPS+VPS) information for the individual layers can be packaged into 1 CSD frame to be defined by Dolby. Having a single CSD frame is required.

Dolby actions

  1. Define the packaging of access units for the various Dolby container schemes (eg BL+EL+MD) for the abstract Dolby decoder (ie the buffer format expected by the HDR decoder).
  2. Define the packaging of CSD for the abstract Dolby decoder.

Vendor actions

  1. Implement Dolby extractor. This can also be done by Dolby.
  2. Integrate DolbyExtractor into the framework. The entry point is frameworks/av/media/libstagefright/MediaExtractor.cpp .
  3. Declare HDR decoder profile and level OMX type. Example: OMX_VIDEO_DOLBYPROFILETYPE and OMX_VIDEO_DOLBYLEVELTYP .
  4. Implement support for index: 'OMX.google.android.index.describeColorAspects '
  5. Propagate the dynamic HDR metadata to the app and surface in each frame. Typically this information must be packaged into the decoded frame as defined by Dolby, because the HDMI standard does not provide a way to pass this to the display.

VP9 decoder pipeline

Figure 3. VP9-PQ pipeline

VP9 bitstreams are packaged in WebM containers in a way defined by WebM team. Applications need to use a WebM extractor to extract HDR metadata from the bitstream before sending frames to the decoder.

  • WebM Extractor:
  • VP9 Decoder:
    • Decoder receives Profile2 bitstreams and decodes them as normal VP9 streams.
    • Decoder receives any HDR static metadata from the framework.
    • Decoder receives static metadata via the bitstream access units for VP9 PQ streams.
    • VP9 decoder must be able to propagate the HDR static/dynamic metadata to the display.

Vendor actions

  1. Implement support for index: OMX.google.android.index.describeHDRColorInfo
  2. Implement support for index: OMX.google.android.index.describeColorAspects
  3. Propagate HDR static metadata