Reprodução de vídeo HDR

Os vídeos em High Dynamic Range (HDR) são a próxima fronteira da alta qualidade decodificação de vídeo, oferecendo qualidades de reprodução de cena incomparáveis. Assim, ao aumentar significativamente o intervalo dinâmico do componente de luminância (dos atuais 100 cd/m² a milhares de cd/m²) e usando uma espaço de cores (BT 2020). Agora esse é um elemento central da evolução do 4K Ultra HD no espaço da TV.

O Android 10 é compatível com os vídeos em HDR a seguir.

• HDR10
• VP9
• HDR10+

A partir do Android 9 e versões mais recentes, o MediaCodec informa metadados HDR, independentemente do modo de túnel. É possível receber dados decodificados junto com metadados estáticos/dinâmicos no modo sem túnel. Para HDR10 e o VP9Profile2 que usa metadados estáticos, eles são relatados no formato de saída com chaves KEY_HDR_STATIC_INFO: Para HDR10+ que usa metadados dinâmicos, isso é informado com KEY_HDR10_PLUS_INFO no formato de saída e pode mudar para cada frame de saída. Consulte Encapsulamento multimídia para mais informações.

Desde o Android 7.0, o suporte inicial a HDR inclui as criação de constantes adequadas para a descoberta e configuração de vídeos HDR pipelines de dados. Isso significa definir tipos de codec e modos de exibição e especificar como os dados HDR precisam ser transmitidos ao MediaCodec e fornecidos aos decodificadores de HDR.

O objetivo deste documento é ajudar os desenvolvedores de aplicativos a oferecer suporte a transmissões HDR a reprodução de conteúdo e ajudar OEMs e SOCs a ativar os recursos HDR.

Tecnologias HDR compatíveis

A partir do Android 7.0 e versões mais recentes, as seguintes tecnologias HDR são compatíveis.

Tecnologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Codec	AVC/HEVC	HEVC	VP9	VP9
Função de transferência	ST-2084	ST-2084	HLG	ST-2084
Tipo de metadados HDR	Dinâmico	Estático	Nenhum	Estático

No Android 7.0, somente a reprodução HDR por meio do modo encapsulado é definida, mas os dispositivos podem oferecer suporte à reprodução de HDR em SurfaceViews usando em buffer de vídeo. Resumindo:

• Não existe uma API Android padrão para verificar se a reprodução em HDR é compatível usando decodificadores sem túnel.
• Os decodificadores de vídeo encapsulados que anunciam a capacidade de reprodução em HDR precisam oferecer suporte à reprodução em HDR quando conectadas a telas compatíveis com HDR.
• A composição GL de conteúdo HDR não é compatível com o Android do AOSP versão 7.0.

Descoberta

A reprodução em HDR exige um decodificador compatível com HDR e uma conexão com um Tela compatível com HDR. Opcionalmente, algumas tecnologias exigem uma configuração extrator.

Tela

Os apps precisam usar o novo Display.getHdrCapabilities API para consultar as tecnologias HDR com suporte à tela especificada. Isso é basicamente as informações no bloco de dados de metadados estáticos EDID, conforme definido no CTA-861.3:

• public Display.HdrCapabilities getHdrCapabilities() e
  Retorna os recursos de HDR da tela.
• Display.HdrCapabilities e
  Encapsula os recursos de HDR de uma determinada tela. Por exemplo, qual HDR os tipos compatíveis e detalhes sobre os dados de luminância desejados.

Constantes:

• int HDR_TYPE_DOLBY_VISION e
  Suporte a Dolby Vision.
• int HDR_TYPE_HDR10 e
  Compatível com HDR10 / PQ.
• int HDR_TYPE_HDR10_PLUS e
  Suporte a HDR10+.
• int HDR_TYPE_HLG e
  Suporte a Log-Gamma híbrido.
• float INVALID_LUMINANCE e
  Valor de luminância inválido.

Métodos públicos:

• float getDesiredMaxAverageLuminance() e
  Retorna os dados de luminância da média máxima de frames do conteúdo desejado em cd/cd/m² para esta tela.
• float getDesiredMaxLuminance() e
  Retorna os dados de luminância máxima do conteúdo desejado em cd/cd/m² para esta tela.
• float getDesiredMinLuminance() e
  Retorna os dados de luminância mínima de conteúdo desejados em cd/cd/m² para esta tela.
• int[] getSupportedHdrTypes() e
  Recebe os tipos de HDR compatíveis com esta tela (consulte as constantes). Retorna em branco se a tela não oferecer suporte a HDR.

Decodificador

Os aplicativos devem usar a versão CodecCapabilities.profileLevels para verificar o suporte para o novos perfis compatíveis com HDR:

Dolby Vision

Constante MIME MediaFormat:

String MIMETYPE_VIDEO_DOLBY_VISION

Constantes de perfil MediaCodecInfo.CodecProfileLevel:

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

As camadas de vídeo e os metadados da Dolby Vision precisam ser concatenados em um único por frames por aplicativos de vídeo. Isso é feito automaticamente pelo MediaExtractor com suporte a Dolby-Vision.

HDR 10 de HEVC

Constantes de perfil MediaCodecInfo.CodecProfileLevel:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG e PQ

Perfil do MediaCodecInfo.CodecProfileLevel constantes:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Se uma plataforma for compatível com um decodificador compatível com HDR, também deverá ser compatível com um Extrator compatível com HDR.

Somente decodificadores encapsulados têm a garantia de reproduzir conteúdo HDR. Reprodução por decodificadores sem encapsulamento podem resultar na perda das informações de HDR e o conteúdo sendo nivelado em um volume de cores SDR.

Extrator

Os contêineres a seguir são compatíveis com as várias tecnologias HDR no Android 7.0:

Tecnologia	Dolby Vision	HDR10	VP9-HLG	VP9-PQ
Contêiner	MP4	MP4	WebM	WebM

Não é possível descobrir se uma faixa (de um arquivo) exige compatibilidade com HDR com suporte na plataforma. Os aplicativos podem analisar os dados específicos do codec para determinar se uma faixa exige um perfil HDR específico.

Resumo

Os requisitos de componentes para cada tecnologia HDR são mostrados na tabela abaixo:

Observações:

• Os bitstreams do Dolby-Vision são empacotados em um contêiner MP4 de uma maneira definida pela Dolby. Os aplicativos podem implementar seus próprios extratores com Dolby desde que reúnam as unidades de acesso das camadas correspondentes em um única unidade de acesso para o decodificador, conforme definido pela Dolby.
• Uma plataforma pode oferecer suporte a um extrator compatível com HDR, mas nenhum decodificador compatível com HDR.

Reprodução

Depois que um aplicativo verificar a compatibilidade com a reprodução em HDR, ele poderá reproduzir conteúdo HDR quase da mesma forma que reproduz conteúdo não HDR, com as seguintes ressalvas:

• Para Dolby-Vision, se um arquivo/faixa de mídia específico exige um decodificador compatível com HDR não ficará disponível imediatamente. O aplicativo precisa têm essas informações com antecedência ou podem consegui-las analisando a seção de dados específicos do codec do MediaFormat.
• CodecCapabilities.isFormatSupported não considera se o recurso de decodificador em túnel é necessário para oferecer suporte a esse perfil.

Ativar o suporte à plataforma HDR

Fornecedores de SoC e OEMs precisam trabalhar mais para ativar a plataforma HDR suporte para um dispositivo.

Mudanças de plataforma no Android 7.0 para HDR

Confira algumas mudanças importantes na plataforma (camada nativa/app) que OEMs e SOCs precisam conhecer.

Tela

Composição de hardware

Plataformas compatíveis com HDR precisam ser compatíveis com a combinação de conteúdo HDR com não HDR conteúdo. As características e operações de combinação exatas não estão definidas pelo Android a partir da versão 7.0, mas o processo geralmente segue estas etapas:

1. Determinar um espaço de cor/volume linear que contém todas as camadas a serem compostas, com base nas camadas cores, masterização e potencial de dinâmica metadados.
   Ao compor diretamente em uma tela, pode ser o espaço linear que corresponde ao volume de cores da tela.
2. Converta todas as camadas para o espaço de cor comum.
3. Realize a combinação.
4. Se estiver sendo exibido por HDMI:
   1. Determine a cor, a masterização e os possíveis metadados dinâmicos do cena mista.
   2. Converter a cena mesclada resultante na cor derivada espaço/volume.
5. Se ele for exibido diretamente na tela, converta o resultado cena aos sinais de exibição necessários para produzir essa cena.

Descoberta de exibição

A descoberta de tela HDR só é compatível com HWC2. Os implementadores de dispositivos precisam ative seletivamente o adaptador HWC2 lançado com o Android 7.0 para funcionar. Portanto, as plataformas devem adicionar suporte para HWC2 ou estender a Framework do AOSP para fornecer essas informações. O HWC2 expõe um novo API para propagar dados estáticos HDR para o framework e o aplicativo.

HDMI

• Uma tela HDMI conectada anuncia a capacidade HDR por meio de HDMI EDID, conforme definido em CTA-861.3 (link em inglês) seção 4.2.
• O seguinte mapeamento EOTF precisa ser usado:
  • Gama tradicional ET_0 - Faixa de luminância SDR: não mapeado para nenhum HDR tipo
  • Gama tradicional ET_1 - Faixa de luminância HDR: não mapeado para nenhum HDR tipo
  • ET_2 SMPTE ST 2084 - mapeado para tipo HDR10
• A sinalização do suporte a Dolby Vision ou HLG por HDMI é feita conforme definido pelos órgãos relevantes.
• A API HWC2 usa valores flutuantes de luminância desejados, ou seja, Os valores de EDID precisam ser convertidos de maneira adequada.

Decodificadores

As plataformas precisam adicionar decodificadores compatíveis com HDR e anunciar o HDR suporte. Geralmente, os decodificadores compatíveis com HDR precisam:

• Suporte à decodificação em túnel (FEATURE_TunneledPlayback).
• Suporte a metadados estáticos HDR (OMX.google.android.index.describeHDRColorInfo) e as propagação para a composição de tela/hardware. Para HLG, os metadados adequados devem ser enviados para a tela.
• Descrição de cor do suporte (OMX.google.android.index.describeColorAspects) e as propagação para a composição de tela/hardware.
• Oferecer suporte a metadados HDR incorporados, conforme definido pelo padrão relevante.

Suporte ao decodificador Dolby Vision

Para oferecer suporte ao Dolby Vision, as plataformas precisam adicionar um dispositivo compatível com Dolby-Vision Decodificador OMX HDR. Com as especificidades do Dolby Vision, isso normalmente é um decodificador de wrapper em torno de um ou mais decodificadores AVC e/ou HEVC, bem como um compositor. Esses decodificadores precisam:

• Suporte ao tipo MIME "video/dolby-vision".
• Anunciar perfis/níveis Dolby Vision compatíveis.
• Aceitar as unidades de acesso que contêm as subunidades de acesso de todas as camadas como definida pela Dolby.
• Aceita dados específicos do codec definidos pelo Dolby. Por exemplo, dados que contêm Perfil/nível do Dolby Vision e, possivelmente, os dados específicos do codec para o decodificadores internos.
• Ofereça suporte à alternância adaptável entre perfis/níveis Dolby Vision como exigido pela Dolby.

Ao configurar o decodificador, o perfil Dolby real não é comunicado ao codec. Isso só é feito via dados específicos do codec após o decodificador, for iniciado. Uma plataforma pode optar por oferecer suporte a vários dispositivos Dolby Vision decodificadores: um para perfis AVC e outro para perfis HEVC para poder para inicializar codecs subjacentes durante a configuração. Se um único Dolby Vision decodificador suporta os dois tipos de perfis, ele também deve oferecer suporte à troca entre aqueles dinamicamente de maneira adaptável.

Se uma plataforma fornece um decodificador com suporte a Dolby-Vision, além suporte geral ao decodificador HDR, ele precisa:

• Forneça um extrator com reconhecimento Dolby-Vision, mesmo que não seja compatível Reprodução em HDR.
• Forneça um decodificador que ofereça suporte ao perfil de visão, conforme definido pela Dolby.

Compatibilidade com decodificador HDR10

Para oferecer suporte a HDR10, as plataformas precisam adicionar um decodificador OMX compatível com HDR10. Isso é normalmente um decodificador HEVC em túnel que também aceita análise e tratamento Metadados relacionados a HDMI. Esse decodificador (além do decodificador HDR geral suporte) precisa:

• Suporte ao tipo MIME "video/hevc".
• Anunciar HEVCMain10HDR10 compatível. Suporte ao perfil HEVCMain10HRD10 também requer suporte para o perfil HEVCMain10, o que requer suporte o perfil HEVCMain nos mesmos níveis.
• Compatibilidade com a análise de blocos SEI de metadados de masterização, bem como outros elementos de HDR informações relacionadas contidas no SPS.

Compatibilidade com decodificador VP9

Para oferecer suporte ao VP9 HDR, as plataformas precisam adicionar um OMX HDR compatível com VP9 Profile2 decodificador. Normalmente, é um decodificador VP9 encapsulado que também aceita o processamento Metadados relacionados a HDMI. Esses decodificadores (além do decodificador HDR geral suporte) precisa:

• Suporte ao tipo MIME "video/x-vnd.on2.vp9".
• Anunciar VP9Profile2HDR compatível. Suporte ao perfil VP9Profile2HDR também requer suporte ao perfil VP9Profile2 no mesmo nível.

Extratores

Suporte ao extrator Dolby Vision

As plataformas compatíveis com decodificadores Dolby Vision precisam adicionar um extrator Dolby (chamado Dolby Extractor) para conteúdo Dolby Video.

• Um extrator de MP4 normal só pode extrair a camada de base de um arquivo. mas não as camadas de aprimoramento ou de metadados. Então, um extrator Dolby especial necessárias para extrair os dados do arquivo.
• O extrator Dolby precisa expor de uma a duas faixas para cada faixa de vídeo Dolby (grupo):
  • Uma faixa Dolby Vision HDR com o tipo de "vídeo/dolby-vision" para o fluxo Dolby de 2/3 camadas combinado. O formato de unidade de acesso da faixa HDR, que define como empacotar as unidades de acesso da base/aprimoramento/metadados camadas em um único buffer para serem decodificadas em um único quadro HDR, definida pela Dolby.
  • Se uma faixa de vídeo Dolby Vision tiver um vídeo separado (compatível com versões anteriores) camada de base (BL, na sigla em inglês), o extrator também precisará expor isso como um "video/avc" separado ou "video/hevc" trilhos. O extrator precisa fornecer acesso regular AVC/HEVC unidades para esta faixa.
  • A faixa BL deve ter o mesmo track-unique-ID ("track-ID") que faixa HDR para que o app entenda que essas são duas codificações do mesmo vídeo.
  • O aplicativo pode decidir qual trilha escolher com base no capacidade de processamento.
• O perfil/nível do Dolby Vision precisa ser exposto no formato de faixa de faixa HDR.
• Se uma plataforma tem um decodificador compatível com Dolby-Vision, ela também deve fornecer um extrator com reconhecimento Dolby-Vision, mesmo que não seja compatível com a reprodução HDR.

Compatibilidade com o extrator HDR10 e VP9 HDR

Não há outros requisitos de extrator para oferecer suporte a HDR10 ou VP9 HLG. As plataformas precisam estender o extrator de MP4 para oferecer suporte a VP9 PQ em MP4. HDR metadados estáticos devem ser propagados no bitstream VP9 PQ, de modo que este são passados para o decodificador VP9 PQ e para a tela por meio do MediaExtractor => pipeline do MediaCodec.

Extensões Stagefright para compatibilidade com Dolby Vision

As plataformas precisam adicionar compatibilidade com o formato Dolby Vision ao Stagefright:

• Suporte para consulta de definição de porta para porta compactada.
• Suporte para enumeração de perfil/nível para o decodificador de DV.
• Suporte à exposição do perfil/nível do DV para faixas HDR do DV.

Detalhes de implementação específicos de tecnologia

Pipeline do decodificador HDR10

Figura 1. Pipeline HDR10

Os bitstreams HDR10 são empacotados em contêineres MP4. Os aplicativos usam uma conexão Extrator MP4 para extrair os dados do frame e enviá-los ao decodificador.

• Extrator MPEG4
  Os bitstreams HDR10 são reconhecidos como apenas um stream HEVC normal por um MPEG4Extractor e faixa HDR com o tipo "video/HEVC" será extraídos. O framework escolhe um decodificador de vídeo HEVC com suporte à Main10HDR10 para decodificar a faixa.
• Decodificador HEVC
  As informações de HDR estão em SEI ou SPS. Primeiro, o decodificador HEVC recebe quadros que contêm as informações de HDR. Depois, o decodificador extrai o HDR e notifica o aplicativo de que está decodificando um vídeo HDR. HDR as informações são agrupadas em um formato de saída do decodificador, que é propagado para na superfície mais tarde.

Ações do fornecedor

1. Anunciar um perfil de decodificador HDR com suporte e o tipo OMX de nível. Exemplo:
   OMX_VIDEO_HEVCProfileMain10HDR10 (e Main10)
2. Implementar suporte para índice: "OMX.google.android.index.describeHDRColorInfo"
3. Implementar suporte para índice: "OMX.google.android.index.describeColorAspects"
4. Implementar suporte para análise de SEI de metadados de masterização.

Pipeline do decodificador do Dolby Vision

Figura 2. Pipeline Dolby Vision

Dolby-bitstreams são empacotados em contêineres MP4 conforme definido pelo Dolby Os aplicativos podem, em teoria, usar um extrator MP4 comum para extrair a camada de base, a camada de aprimoramento e a camada de metadados de forma independente; No entanto, não se ajusta ao modelo atual do Android MediaExtractor/MediaCodec.

• DolbyExtractor:
  • Dolby-bitstreams são reconhecidos por um DolbyExtractor, que expõe a várias camadas como uma ou duas faixas para cada faixa de vídeo dolby (grupo):
    • Uma faixa HDR com o tipo de "video/dolby-vision" para o conjunto de dados Stream Dolby de 2/3 camadas. O formato de unidade de acesso da faixa HDR, que define como empacotar as unidades de acesso das camadas de base/aprimoramento/metadados. em um único buffer a ser decodificado em um único quadro HDR, deve ser definido pela Dolby.
    • (Opcional, somente se o BL for compatível com versões anteriores) Uma faixa BL contém somente a camada de base, que precisa ser decodificável pelo decodificador MediaCodec regular, por exemplo, o decodificador AVC/HEVC. O extrator deve fornecer eventos AVC/HEVC regulares unidades de acesso para esta trilha. Essa faixa de BL precisa ter o mesmo track-unique-ID ("track-ID") como a faixa Dolby para que o aplicativo entenda que essas são duas codificações do mesmo vídeo.
  • O aplicativo pode decidir qual trilha escolher com base no capacidade de processamento.
  • Como uma faixa HDR tem um tipo de HDR específico, o framework escolhe um decodificador de vídeo Dolby para decodificar a faixa. A faixa de BL será decodificada decodificador de vídeo comum AVC/HEVC.
• DolbyDecoder:
  • O DolbyDecoder recebe unidades de acesso que contêm o acesso necessário unidades para todas as camadas (EL+BL+MD ou BL+MD)
  • Informações CSD (dados específicos do codec, como SPS+PPS+VPS) para a camadas individuais podem ser empacotadas em um frame CSD para ser definido Dolby É necessário ter um único frame CSD.

Ações do Dolby

1. Definir o empacotamento de unidades de acesso para os diversos contêineres Dolby esquemas (por exemplo, BL+EL+MD) para o decodificador Dolby abstrato (ou seja, o buffer esperado pelo decodificador HDR).
2. Defina a embalagem do CSD para o decodificador Dolby abstrato.

Ações do fornecedor

1. Implemente o extrator Dolby. Isso também pode ser feito pela Dolby.
2. Integrar o DolbyExtractor ao framework. O ponto de entrada é frameworks/av/media/libstagefright/MediaExtractor.cpp:
3. Declarar o perfil do decodificador HDR e o nível OMX não é válido. Exemplo: OMX_VIDEO_DOLBYPROFILETYPE e OMX_VIDEO_DOLBYLEVELTYP.
4. Implementar suporte para índice: 'OMX.google.android.index.describeColorAspects min
5. Propagar os metadados HDR dinâmicos para o app e a superfície em cada um frame. Normalmente, essas informações precisam ser empacotadas no frame decodificado conforme definido pela Dolby, porque o padrão HDMI não permite passar isso para a tela.

Pipeline do decodificador VP9

Figura 3. Pipeline VP9-PQ

Os bitstreams VP9 são empacotados em contêineres WebM de uma forma definida pelo WebM equipe. Os aplicativos precisam usar um extrator WebM para extrair metadados HDR de ao bitstream antes de enviar frames para o decodificador.

• Extrator WebM:
  • O extrator WebM extrai os metadados HDR e frames do elemento contêiner do Docker.
• Decodificador VP9:
  • O decodificador recebe bitstreams do Profile2 e os decodifica como um VP9 normal córregos.
  • O decodificador recebe todos os metadados estáticos HDR do framework.
  • O decodificador recebe metadados estáticos pelas unidades de acesso bitstream para o VP9 PQ.
  • O decodificador VP9 precisa ser capaz de propagar os metadados estáticos/dinâmicos de HDR na tela.

Ações do fornecedor

1. Implementar suporte para índice: OMX.google.android.index.describeHDRColorInfo
2. Implementar suporte para índice: OMX.google.android.index.describeColorAspects
3. Propagar metadados estáticos HDR