Reprodução de vídeo HDR

O vídeo em High Dynamic Range (HDR) é a próxima fronteira na decodificação de vídeo de alta qualidade, oferecendo qualidades de reprodução de cena incomparáveis. Isso é feito aumentando significativamente o intervalo dinâmico do componente de luminância (dos atuais 100 cd/m² para milhares de cd/m²) e usando um espaço de cores muito mais amplo (BT 2020). Esse é um elemento central da evolução do 4K UHD no espaço da TV.

O Android 10 é compatível com os seguintes vídeos HDR.

• HDR10
• VP9
• HDR10+

A partir do Android 9 e versões mais recentes, o MediaCodec informa metadados HDR, independente do modo tunelado. Você pode receber dados decodificados junto com metadados estáticos/dinâmicos no modo não tunelado. Para HDR10 e VP9Profile2, que usam metadados estáticos, eles são informados no formato de saída com a chave KEY_HDR_STATIC_INFO. Para HDR10+ que usa metadados dinâmicos, isso é informado com a chave KEY_HDR10_PLUS_INFO no formato de saída e pode mudar para cada frame de saída. Para mais informações, consulte Encapsulamento multimídia.

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

O objetivo deste documento é ajudar os desenvolvedores de aplicativos a oferecer suporte à reprodução de streams HDR e ajudar OEMs e SOCs a ativar os recursos de HDR.

Tecnologias HDR compatíveis

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

No Android 7.0, apenas a reprodução HDR no modo tunelado é definida, mas os dispositivos podem adicionar suporte para reprodução HDR em SurfaceViews usando buffers de vídeo opacos. Resumindo:

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

Descoberta

Para reproduzir conteúdo em HDR, é necessário ter um decodificador e uma tela compatíveis com esse formato. Algumas tecnologias exigem um extrator específico.

Tela

Os aplicativos precisam usar a nova API Display.getHdrCapabilities para consultar as tecnologias HDR compatíveis com a tela especificada. Essas são basicamente as informações no bloco de dados de metadados estáticos do EDID, conforme definido em CTA-861.3:

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

Constantes:

• int HDR_TYPE_DOLBY_VISION
  Suporte ao Dolby Vision.
• int HDR_TYPE_HDR10
  Compatibilidade com HDR10 / PQ.
• int HDR_TYPE_HDR10_PLUS
  Compatibilidade com HDR10+.
• int HDR_TYPE_HLG
  Suporte a Hybrid Log-Gamma.
• float INVALID_LUMINANCE
  Valor de luminância inválido.

Métodos públicos:

• float getDesiredMaxAverageLuminance()
  Retorna os dados de luminância média máxima por frame do conteúdo desejado em cd/cd/m² para esta tela.
• float getDesiredMaxLuminance()
  Retorna os dados de luminância máxima do conteúdo desejado em cd/cd/m² para esta tela.
• float getDesiredMinLuminance()
  Retorna os dados de luminância mínima de conteúdo desejados em cd/cd/m² para esta tela.
• int[] getSupportedHdrTypes()
  Recebe os tipos de HDR compatíveis com esta tela. Consulte as constantes. Retorna uma matriz vazia se o HDR não for compatível com a tela.

Decodificador

Os aplicativos precisam usar a API CodecCapabilities.profileLevels atual para verificar a compatibilidade com os novos perfis compatíveis com HDR:

Dolby Vision

MediaFormat constante MIME:

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 do Dolby Vision precisam ser concatenados em um único buffer por frames pelos aplicativos de vídeo. Isso é feito automaticamente pelo MediaExtractor compatível com Dolby Vision.

HEVC HDR 10

Constantes de perfil MediaCodecInfo.CodecProfileLevel:

int HEVCProfileMain10HDR10
int HEVCProfileMain10HDR10Plus

VP9 HLG e PQ

Constantes do perfil MediaCodecInfo.CodecProfileLevel:

int VP9Profile2HDR
int VP9Profile2HDR10Plus
int VP9Profile3HDR
int VP9Profile3HDR10Plus

Se uma plataforma for compatível com um decodificador HDR, ela também precisará ser compatível com um extrator HDR.

Somente os decodificadores em túnel garantem a reprodução de conteúdo HDR. A reprodução por decodificadores não tunelados pode resultar na perda das informações de HDR e na redução do conteúdo para um volume de cores SDR.

Extrator

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

A plataforma não oferece suporte à descoberta de se uma faixa (de um arquivo) exige compatibilidade com HDR. Os aplicativos podem analisar os dados específicos do codec para determinar se uma faixa requer um perfil HDR específico.

Resumo

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

Observações:

• Os bitstreams Dolby Vision são empacotados em um contêiner MP4 de uma maneira definida pela Dolby. Os aplicativos podem implementar os próprios extratores compatíveis com Dolby, desde que empacotem as unidades de acesso das camadas correspondentes em uma única unidade de acesso para o decodificador, conforme definido pela Dolby.
• Uma plataforma pode ser compatível com um extrator compatível com HDR, mas não com um decodificador correspondente.

Reprodução

Depois que um aplicativo verifica o suporte à reprodução em HDR, ele pode reproduzir conteúdo HDR quase da mesma forma que conteúdo não HDR, com as seguintes ressalvas:

• Para o Dolby Vision, não é possível saber imediatamente se um arquivo/faixa de mídia específico exige um decodificador compatível com HDR. O aplicativo precisa ter essas informações com antecedência ou ser capaz de obtê-las analisando a seção de dados específicos do codec do MediaFormat.
• O 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

Os fornecedores de SoC e OEMs precisam fazer um trabalho extra para ativar o suporte da plataforma HDR em um dispositivo.

Mudanças na plataforma do Android 7.0 para HDR

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

Tela

Composição de hardware

As plataformas compatíveis com HDR precisam permitir a combinação de conteúdo HDR e não HDR. As características e operações exatas de combinação não são definidas pelo Android até a versão 7.0, mas o processo geralmente segue estas etapas:

1. Determine um espaço/volume de cor linear que contenha todas as camadas a serem combinadas, com base na cor, na masterização e nos possíveis metadados dinâmicos das camadas.
   Se a composição for feita diretamente em uma tela, esse poderá ser o espaço linear que corresponde ao volume de cores da tela.
2. Converter todas as camadas para o espaço de cores comum.
3. Faça a combinação.
4. Se você estiver usando HDMI:
   1. Determine a cor, a masterização e os possíveis metadados dinâmicos para a cena combinada.
   2. Converta a cena combinada resultante no espaço/volume de cores derivado.
5. Se você estiver mostrando diretamente na tela, converta a cena combinada resultante nos sinais de exibição necessários para produzir essa cena.

Descoberta de display

A descoberta de telas HDR é compatível apenas com o HWC2. Os implementadores de dispositivos precisam ativar seletivamente o adaptador HWC2 lançado com o Android 7.0 para que esse recurso funcione. Portanto, as plataformas precisam adicionar suporte para HWC2 ou estender o framework AOSP para permitir uma maneira de fornecer essas informações. O HWC2 expõe uma nova API para propagar dados estáticos de HDR para o framework e o aplicativo.

HDMI

• Uma tela HDMI conectada anuncia a capacidade de HDR por HDMI EDID, conforme definido na seção 4.2 da CTA-861.3.
• O seguinte mapeamento de EOTF será usado:
  • ET_0 Gama tradicional: intervalo de luminância SDR não mapeado para nenhum tipo de HDR
  • ET_1 Gamma tradicional: intervalo de luminância HDR não mapeado para nenhum tipo de HDR
  • ET_2 SMPTE ST 2084: mapeado para o 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 de luminância desejada de ponto flutuante. Portanto, os valores EDID de 8 bits precisam ser convertidos de maneira adequada.

Decodificadores

As plataformas precisam adicionar decodificadores tunelados compatíveis com HDR e anunciar o suporte a HDR. Em geral, os decodificadores compatíveis com HDR precisam:

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

Suporte ao decodificador Dolby Vision

Para oferecer suporte ao Dolby Vision, as plataformas precisam adicionar um decodificador HDR OMX compatível com Dolby Vision. Devido às especificidades do Dolby Vision, esse é normalmente um decodificador de wrapper em torno de um ou mais decodificadores AVC e/ou HEVC, além de um compositor. Esses decodificadores precisam:

• Suporte ao tipo MIME "video/dolby-vision".
• Anuncie os perfis/níveis do Dolby Vision compatíveis.
• Aceita unidades de acesso que contêm as subunidades de acesso de todas as camadas, conforme definido pela Dolby.
• Aceita dados específicos do codec definidos pela Dolby. Por exemplo, dados que contêm o perfil/nível do Dolby Vision e possivelmente os dados específicos do codec para os decodificadores internos.
• Suporte à troca adaptativa entre perfis/níveis do Dolby Vision conforme exigido pela Dolby.

Ao configurar o decodificador, o perfil Dolby real não é comunicado ao codec. Isso só é feito por dados específicos do codec depois que o decodificador é iniciado. Uma plataforma pode oferecer suporte a vários decodificadores Dolby Vision: um para perfis AVC e outro para perfis HEVC, para poder inicializar codecs subjacentes durante o tempo de configuração. Se um único decodificador Dolby Vision for compatível com os dois tipos de perfis, ele também precisará oferecer suporte à troca dinâmica entre eles de maneira adaptativa.

Se uma plataforma oferecer um decodificador compatível com Dolby Vision além do suporte geral a decodificadores HDR, ela precisará:

• Forneça um extrator compatível com Dolby Vision, mesmo que ele não tenha suporte para reprodução em HDR.
• Forneça um decodificador compatível com o perfil de visão definido pela Dolby.

Compatibilidade com decodificador HDR10

Para oferecer suporte ao HDR10, as plataformas precisam adicionar um decodificador OMX compatível com HDR10. Normalmente, esse é um decodificador HEVC em túnel que também oferece suporte à análise e ao processamento de metadados relacionados a HDMI. Esse decodificador (além do suporte geral ao decodificador HDR) precisa:

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

Suporte ao decodificador VP9

Para oferecer suporte ao VP9 HDR, as plataformas precisam adicionar um decodificador HDR OMX compatível com VP9 Profile2. Normalmente, é um decodificador VP9 em túnel que também oferece suporte ao processamento de metadados relacionados a HDMI. Esses decodificadores (além do suporte geral a decodificadores HDR) precisam:

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

Extratores

Suporte ao extrator Dolby Vision

As plataformas que oferecem suporte a decodificadores Dolby Vision precisam adicionar suporte ao extrator Dolby (chamado de Dolby Extractor) para conteúdo de vídeo Dolby.

• Um extrator de MP4 comum só pode extrair a camada de base de um arquivo, mas não as camadas de melhoria ou metadados. Por isso, é necessário um extrator Dolby especial 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 HDR Dolby Vision com o tipo "video/dolby-vision" para o fluxo Dolby de 2/3 camadas combinado. O formato da unidade de acesso da faixa HDR, que define como empacotar as unidades de acesso das camadas de base/melhoria/metadados em um único buffer para serem decodificadas em um único frame HDR, precisa ser definido pela Dolby.
  • Se uma faixa de vídeo Dolby Vision tiver uma camada básica (BL) separada (compatível com versões anteriores), o extrator também precisará expor isso como uma faixa separada "video/avc" ou "video/hevc". O extrator precisa fornecer unidades de acesso AVC/HEVC regulares para essa faixa.
  • A faixa BL precisa ter o mesmo ID exclusivo da faixa ("track-ID") que a faixa HDR para que o app entenda que são duas codificações do mesmo vídeo.
  • O aplicativo pode decidir qual faixa escolher com base na capacidade da plataforma.
• O perfil/nível do Dolby Vision precisa ser exposto no formato da faixa HDR.
• Se uma plataforma fornecer um decodificador compatível com Dolby Vision, ela também precisará fornecer um extrator compatível com Dolby Vision, mesmo que não ofereça suporte à reprodução em HDR.

Compatibilidade com 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 ao VP9 PQ em MP4. Os metadados estáticos HDR precisam ser propagados no fluxo de bits VP9 PQ para que sejam transmitidos ao decodificador VP9 PQ e à tela pela pipeline normal MediaExtractor => MediaCodec.

Extensões do Stagefright para suporte ao Dolby Vision

As plataformas precisam adicionar suporte ao formato Dolby Vision no Stagefright:

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

Detalhes de implementação específicos da tecnologia

Pipeline do decodificador HDR10

Figura 1. Pipeline HDR10

Os bitstreams HDR10 são empacotados em contêineres MP4. Os aplicativos usam um extrator MP4 comum para extrair os dados de frame e enviá-los ao decodificador.

• MPEG4 Extractor
  Os fluxos de bits HDR10 são reconhecidos como um fluxo HEVC normal por um MPEG4Extractor, e a faixa HDR com o tipo "video/HEVC" será extraída. O framework escolhe um decodificador de vídeo HEVC compatível com o perfil Main10HDR10 para decodificar essa faixa.
• Decodificador HEVC
  As informações de HDR estão em SEI ou SPS. O decodificador HEVC primeiro recebe frames que contêm as informações de HDR. Em seguida, o decodificador extrai as informações de HDR e notifica o aplicativo de que está decodificando um vídeo em HDR. As informações de HDR são agrupadas no formato de saída do decodificador, que é propagado para a superfície mais tarde.

Ações do fornecedor

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

Pipeline do decodificador Dolby Vision

Figura 2. Pipeline do Dolby Vision

Os bitstreams Dolby são empacotados em contêineres MP4, conforme definido pela Dolby. Em teoria, os aplicativos podem usar um extrator MP4 comum para extrair a camada de base, a camada de melhoria e a camada de metadados de forma independente. No entanto, isso não se encaixa no modelo atual do Android MediaExtractor/MediaCodec.

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

Ações do Dolby

1. Defina o pacote de unidades de acesso para os vários esquemas de contêiner Dolby (por exemplo, BL+EL+MD) para o decodificador Dolby abstrato (ou seja, o formato de buffer esperado pelo decodificador HDR).
2. Defina o pacote de CSD para o decodificador Dolby abstrato.

Ações do fornecedor

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

Pipeline do decodificador VP9

Figura 3. Pipeline VP9-PQ

Os fluxos de bits VP9 são empacotados em contêineres WebM de uma maneira definida pela equipe do WebM. Os aplicativos precisam usar um extrator WebM para extrair metadados HDR do fluxo de bits antes de enviar frames ao decodificador.

• Extrator WebM:
  • O WebM Extractor extrai os metadados e os frames HDR do contêiner.
• Decodificador VP9:
  • O decodificador recebe fluxos de bits Profile2 e os decodifica como fluxos VP9 normais.
  • O decodificador recebe todos os metadados estáticos de HDR do framework.
  • O decodificador recebe metadados estáticos pelas unidades de acesso de bitstream para fluxos de PQ VP9.
  • O decodificador VP9 precisa conseguir propagar os metadados estáticos/dinâmicos de HDR para a tela.

Ações do fornecedor

1. Implemente a compatibilidade com o índice: OMX.google.android.index.describeHDRColorInfo
2. Implemente a compatibilidade com o índice: OMX.google.android.index.describeColorAspects
3. Propagar metadados estáticos de HDR