Os vídeos em High Dynamic Range (HDR) são a próxima fronteira da 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/m2 para milhares de s de cd/m2) 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 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 encapsulamento.
É possível receber dados decodificados junto com metadados estáticos/dinâmicos no modo sem túnel. 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.
Consulte Encapsulamento multimídia para mais informações.
Desde o Android 7.0, o suporte inicial a HDR inclui a criação de constantes adequadas para a descoberta e a configuração de pipelines de vídeo em HDR. 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 à reprodução de streaming HDR e ajudar OEMs e SOCs a ativar os recursos de HDR.
Tecnologias HDR com suporte
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 em HDR pelo modo encapsulado é definida, mas os dispositivos podem adicionar suporte à reprodução de HDR em SurfaceViews usando buffers de vídeo opaco. Resumindo:
- Não existe uma API Android padrão para verificar se a reprodução em HDR é compatível usando decodificadores sem encapsulamento.
- Os decodificadores de vídeo em túnel que anunciam o recurso de reprodução em HDR precisam oferecer suporte a esse recurso quando conectados a telas compatíveis com HDR.
- A composição GL de conteúdo HDR não tem suporte na versão do Android 7.0 do AOSP.
Descoberta
A reprodução em HDR exige um decodificador com suporte a HDR e uma conexão com uma tela compatível com HDR. Opcionalmente, algumas tecnologias exigem um extrator específico.
Tela
Os aplicativos precisam usar a nova API
Display.getHdrCapabilities
para consultar as tecnologias HDR com suporte à tela especificada. Basicamente, essas são as informações no bloco de dados de metadados estáticos EDID, conforme definido na CTA-861.3:
public Display.HdrCapabilities getHdrCapabilities()
Retorna os recursos 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 do Dolby Vision.int HDR_TYPE_HDR10
Suporte a HDR10 / PQ.int HDR_TYPE_HDR10_PLUS
Suporte a HDR10+.int HDR_TYPE_HLG
Suporte híbrido 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 de frame máximo do conteúdo desejado em cd/cd/m2 para essa tela.float getDesiredMaxLuminance()
Retorna os dados de luminância máxima do conteúdo desejados em cd/cd/m2 para esta tela.float getDesiredMinLuminance()
Retorna os dados de luminância mínima de conteúdo desejados em cd/cd/m2 para a tela.int[] getSupportedHdrTypes()
Recebe os tipos de HDR compatíveis com essa tela (consulte constantes). Retorna uma matriz vazia se a tela não oferecer suporte a HDR.
Decodificador
Os aplicativos precisam usar a API
CodecCapabilities.profileLevels
já existente para verificar o suporte aos
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 e os metadados do vídeo 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 de perfil
MediaCodecInfo.CodecProfileLevel
:
int VP9Profile2HDR int VP9Profile2HDR10Plus int VP9Profile3HDR int VP9Profile3HDR10Plus
Se uma plataforma for compatível com um decodificador compatível com HDR, também precisará ser compatível com um extrator compatível com HDR.
Somente decodificadores encapsulados têm a garantia de reproduzir conteúdo HDR. A reprodução por decodificadores sem túnel pode resultar na perda das informações HDR e no achatamento do conteúdo em um volume de cor SDR.
Extrator
Os contêineres abaixo têm suporte para as várias tecnologias HDR no Android 7.0:
Tecnologia | Dolby-Vision | HDR10 | VP9-HLG | VP9-PQ |
---|---|---|---|---|
Contêiner | MP4 | MP4 | WebM | WebM |
A plataforma não oferece suporte à descoberta de uma faixa (de um arquivo) que exige suporte a 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:
Tecnologia | Dolby-Vision | HDR10 | VP9-HLG | VP9-PQ |
---|---|---|---|---|
Tipo de HDR com suporte (tela) | HDR_TYPE_DOLBY_VISION | HDR_TYPE_HDR10 | HDR_TYPE_HLG | HDR_TYPE_HDR10 |
Contêiner (extrator) | MP4 | MP4 | WebM | WebM |
Decodificador | MIMETYPE_VIDEO_DOLBY_VISION | MIMETYPE_VIDEO_HEVC | MIMETYPE_VIDEO_VP9 | MIMETYPE_VIDEO_VP9 |
Perfil (Decodificador) | Um dos perfis Dolby | HEVCProfileMain10HDR10 | VP9Profile2HDR ou VP9Profile3HDR | VP9Profile2HDR ou VP9Profile3HDR |
Observações:
- Os streams de bits Dolby Vision são empacotados em um contêiner MP4 de uma forma 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 oferecer suporte a um extrator compatível com HDR, mas não a um decodificador correspondente.
Reprodução
Depois de verificar a compatibilidade de um app com a reprodução em HDR, ele poderá reproduzir conteúdo em HDR praticamente da mesma forma que conteúdo não HDR, com as seguintes ressalvas:
- Para a Dolby-Vision, se um arquivo/faixa de mídia específico exige ou não um decodificador compatível com HDR não está disponível imediatamente. O aplicativo precisa ter essas informações com antecedência ou ser capaz de extraí-las analisando a seção de dados específica 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 mais trabalho para ativar o suporte à plataforma HDR para um dispositivo.
Mudanças na plataforma do Android 7.0 para HDR
Estas são algumas mudanças importantes na plataforma (camada nativa do app/app) que os OEMs e SOCs precisam estar cientes.
Tela
Composição de hardware
As plataformas compatíveis com HDR precisam oferecer suporte à mesclagem de conteúdo HDR com conteúdo não HDR. As características e operações de combinação exatas não são definidas pelo Android a partir da versão 7.0, mas o processo geralmente segue estas etapas:
- Determine um espaço/volume de cor linear que contenha todas as camadas a serem
compostas, com base na cor, no master e nos possíveis metadados
dinâmicos das camadas.
Ao compor diretamente em uma tela, pode ser o espaço linear que corresponde ao volume de cor da tela. - Converte todas as camadas para o espaço de cores comum.
- Realize a mistura.
- Se estiver usando HDMI:
- Determine a cor, a masterização e os possíveis metadados dinâmicos da cena mista.
- Converte a cena combinada resultante no espaço/volume de cores derivados.
- Se estiver exibindo diretamente na tela, converta a cena combinada resultante nos sinais de exibição necessários para produzir essa cena.
Descoberta de exibição
A descoberta de tela HDR só é possível 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 ao HWC2 ou estender o framework do AOSP para permitir uma maneira de fornecer essas informações. O HWC2 expõe uma nova API para propagar dados estáticos HDR para o framework e o aplicativo.
HDMI
- Uma tela HDMI conectada anuncia seu recurso HDR por meio do HDMI EDID, conforme definido na seção 4.2 da CTA-861.3.
- O seguinte mapeamento EOTF precisa ser usado:
- Gama tradicional ET_0 - Intervalo de luminância SDR: não mapeado para nenhum tipo HDR
- Gama tradicional ET_1 - Intervalo de luminância HDR: não mapeado para nenhum tipo HDR
- ET_2 SMPTE ST 2084: mapeado para o tipo HDR 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 flutuantes desejados. Portanto, os valores de EDID de 8 bits precisam ser convertidos de maneira adequada.
Decodificadores
As plataformas precisam adicionar decodificadores com encapsulamento compatíveis com HDR e anunciar o suporte a HDR. Geralmente, os decodificadores compatíveis com HDR precisam:
- Suporte à decodificação por túnel (
FEATURE_TunneledPlayback
). - Oferecer suporte a metadados estáticos HDR
(
OMX.google.android.index.describeHDRColorInfo
) e à propagação deles para a composição de tela/hardware. Para HLG, os metadados apropriados precisam ser enviados para a tela. - Suporte à descrição de cores
(
OMX.google.android.index.describeColorAspects
) e à 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 à Dolby Vision, as plataformas precisam adicionar um decodificador HDR OMX compatível com Dolby-Vision. Considerando as especificidades do Dolby Vision, 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".
- Anunciar perfis/níveis Dolby Vision compatíveis.
- Aceite unidades de acesso que contenham as unidades de subacesso de todas as camadas, conforme definido pela Dolby.
- Aceita dados específicos do codec definidos pelo 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 à alternância adaptativa entre perfis/níveis Dolby Vision, conforme exigido pela Dolby.
Ao configurar o decodificador, o perfil Dolby real não é comunicado ao codec. Isso só é feito por meio de dados específicos do codec após o decodificador ter sido iniciado. Uma plataforma pode optar por oferecer suporte a vários decodificadores Dolby Vision: um para perfis AVC e outra 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 à alternância entre eles dinamicamente de maneira adaptável.
Se uma plataforma oferecer um decodificador compatível com Dolby Vision além do suporte geral ao decodificador HDR, ela precisará:
- Forneça um extrator com reconhecimento de Dolby-Vision, mesmo que ele não seja compatível com a 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 a HDR10, as plataformas precisam adicionar um decodificador OMX compatível com HDR10. Normalmente, é um decodificador HEVC em túnel que também é compatível com a análise e o processamento de metadados relacionados a HDMI. Esse decodificador (além do suporte geral ao decodificador HDR) precisa:
- Suporte ao tipo MIME "video/hevc".
- Anunciar HEVCMain10HDR10 compatível. O suporte ao perfil HEVCMain10HRD10 também requer suporte ao perfil HEVCMain10, que exige suporte ao perfil HEVCMain nos mesmos níveis.
- Compatibilidade com a análise dos blocos SEI de metadados de masterização, além de outras informações relacionadas a HDR contidas no SPS.
Suporte a decodificadores VP9
Para oferecer suporte ao VP9 HDR, as plataformas precisam adicionar um decodificador OMX HDR compatível com o perfil 2 do VP9. Normalmente, é um decodificador VP9 encapsulado que também é compatível com o processamento de metadados relacionados a HDMI. Esses decodificadores (além do suporte geral ao decodificador HDR) precisam:
- Suporte ao tipo MIME "video/x-vnd.on2.vp9".
- Anunciar VP9Profile2HDR compatível. O 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 suporte ao extrator Dolby (chamado Dolby Extractor) para conteúdo do Dolby Video.
- Um extrator MP4 normal só pode extrair a camada de base de um arquivo, mas não as camadas de aprimoramento ou de metadados. Portanto, um extrator especial do Dolby é necessário para extrair os dados do arquivo.
- O extrator Dolby precisa expor de 1 a 2 faixas para cada faixa de vídeo Dolby
(grupo):
- Uma faixa Dolby Vision HDR com o tipo "video/dolby-vision" para o stream Dolby de 2/3 camadas combinado. 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 para ser decodificado em um único frame HDR, precisa ser definido pela Dolby.
- Se uma faixa de vídeo Dolby Vision contiver uma camada base (BL) separada (compatível com versões anteriores), o extrator também precisará expor isso como uma faixa "video/avc" ou "video/hevc" separada. O extrator precisa fornecer unidades de acesso AVC/HEVC regulares para essa faixa.
- A faixa BL precisa ter o mesmo track-unique-ID ("track-ID") que a faixa HDR para que o app entenda que essas 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 oferece um decodificador compatível com Dolby Vision, ela também precisa fornecer um extrator compatível com Dolby Vision, mesmo que não ofereça suporte à reprodução em HDR.
Suporte a extratores HDR10 e VP9 HDR
Não há outros requisitos de extrator para oferecer suporte a HDR10 ou VP9. As plataformas precisam estender o extrator de MP4 para oferecer suporte a VP9 PQ em MP4. Os metadados estáticos de HDR precisam ser propagados no bitstream VP9 PQ, de modo que esses metadados sejam transmitidos para o decodificador VP9 PQ e para a tela pelo pipeline normal MediaExtractor => MediaCodec.
Extensões Stagefright para compatibilidade com Dolby Vision
As plataformas precisam adicionar suporte ao formato Dolby Vision ao 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 do DV para faixas HDR do DV.
Detalhes de implementação específicos de tecnologia
Pipeline do decodificador HDR10
Os bitstreams HDR10 são empacotados em contêineres MP4. Os aplicativos usam um extrator MP4 comum para extrair os dados do frame e enviá-los ao decodificador.
- MPEG4 Extractor
Os bitstreams HDR10 são reconhecidos como apenas um fluxo HEVC normal por um MPEG4Extractor, e a faixa HDR com o tipo "video/HEVC" será extraida. O framework escolhe um decodificador de vídeo HEVC que ofereça suporte ao perfil Main10HDR10 para decodificar essa faixa. - Decifrador HEVC
As informações de HDR estão em SEI ou SPS. O decodificador HEVC primeiro recebe frames que contêm informações de HDR. Em seguida, o decodificador extrai as informações de HDR e notifica o app 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
- Anunciar um perfil de decodificador HDR com suporte e o tipo OMX de nível. Exemplo:
OMX_VIDEO_HEVCProfileMain10HDR10
(eMain10
) - Implementar suporte para índice:
'
OMX.google.android.index.describeHDRColorInfo
' - Implementar suporte para índice:
'
OMX.google.android.index.describeColorAspects
' - Implementar suporte para análise de SEI de metadados de masterização.
Pipeline do decodificador do Dolby Vision
Os streams de bits Dolby são empacotados em contêineres MP4, conforme definido pela Dolby. Em teoria, os aplicativos podem usar um extrator MP4 normal para extrair a camada de base, a camada de aprimoramento e a camada de metadados de forma independente. No entanto, isso não se encaixa no modelo atual do MediaExtractor/MediaCodec do Android.
- DolbyExtractor:
- Os bitstreams Dolby são reconhecidos por um DolbyExtractor, que expõe as
várias camadas como 1 a 2 faixas para cada faixa de vídeo Dolby (grupo):
- Uma faixa HDR com o tipo de "video/dolby-vision" para o stream dolby de 2/3 camadas combinado. O formato de 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 ser decodificado em um único frame HDR, precisa ser definido pela Dolby.
- (Opcional, somente se o BL for compatível com versões anteriores) Uma faixa BL contém apenas a camada base, que precisa ser decodificável pelo decodificador normal do MediaCodec, por exemplo, o decodificador AVC/HEVC. O extrator precisa fornecer unidades de acesso AVC/HEVC regulares para essa faixa. Essa faixa BL precisa ter o mesmo track-unique-ID ("track-ID") que a faixa Dolby para que o aplicativo entenda que essas 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 de HDR 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.
- Os bitstreams Dolby são reconhecidos por um DolbyExtractor, que expõe as
várias camadas como 1 a 2 faixas para cada faixa de vídeo Dolby (grupo):
- DolbyDecoder:
- O DolbyDecoder recebe unidades de acesso que contêm as unidades de acesso 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 empacotadas em um frame CSD a ser definido pelo Dolby. É necessário ter um único frame CSD.
Ações do Dolby
- Define a embalagem 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).
- Defina a embalagem do CSD para o decodificador abstrato Dolby.
Ações do fornecedor
- Implementar o extrator Dolby. Isso também pode ser feito pela Dolby.
- Integrar o DolbyExtractor ao framework. O ponto de entrada é
frameworks/av/media/libstagefright/MediaExtractor.cpp
. - Declara o perfil do decodificador HDR e o tipo OMX
de nível. Exemplo:
OMX_VIDEO_DOLBYPROFILETYPE
eOMX_VIDEO_DOLBYLEVELTYP
. - Implementar suporte para o índice:
'OMX.google.android.index.describeColorAspects
' - Propagar 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 pelo Dolby, porque o padrão HDMI não oferece uma maneira de transmiti-las para a tela.
Pipeline do decodificador VP9
Os bitstreams 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 bitstream antes de enviar frames ao decodificador.
- Extrator de WebM:
- Decodificador VP9:
- O decodificador recebe bitstreams do Perfil2 e os decodifica como fluxos VP9 normais.
- O decodificador recebe todos os metadados estáticos HDR do framework.
- O decodificador recebe metadados estáticos pelas unidades de acesso de bitstream para fluxos PQ VP9.
- O decodificador VP9 precisa ser capaz de propagar os metadados estáticos/dinâmicos HDR para a tela.
Ações do fornecedor
- Implementar suporte para índice:
OMX.google.android.index.describeHDRColorInfo
- Implementar suporte para índice:
OMX.google.android.index.describeColorAspects
- Propagar metadados estáticos HDR