Esta página foi traduzida pela API Cloud Translation.

Tunelamento multimídia

O tunelamento multimídia permite que dados de vídeo compactados sejam canalizados através de um decodificador de vídeo de hardware diretamente para um monitor, sem serem processados pelo código do aplicativo ou pelo código da estrutura do Android. O código específico do dispositivo abaixo da pilha do Android determina quais quadros de vídeo enviar para a tela e quando enviá-los, comparando os carimbos de data/hora de apresentação do quadro de vídeo com um dos seguintes tipos de relógio interno:

Para reprodução de vídeo sob demanda no Android 5 ou superior, um relógio AudioTrack sincronizado com os carimbos de data e hora da apresentação de áudio transmitidos pelo aplicativo
Para reprodução de transmissão ao vivo no Android 11 ou superior, um relógio de referência de programa (PCR) ou relógio de tempo do sistema (STC) acionado por um sintonizador

Fundo

A reprodução de vídeo tradicional no Android notifica o aplicativo quando um quadro de vídeo compactado é decodificado. O aplicativo então libera o quadro de vídeo decodificado para a tela para ser renderizado no mesmo horário do relógio do sistema que o quadro de áudio correspondente, recuperando instâncias históricas AudioTimestamps para calcular o tempo correto.

Como a reprodução de vídeo em túnel ignora o código do aplicativo e reduz o número de processos que atuam no vídeo, ela pode fornecer uma renderização de vídeo mais eficiente, dependendo da implementação do OEM. Ele também pode fornecer cadência de vídeo e sincronização mais precisas com o relógio escolhido (PRC, STC ou áudio), evitando problemas de tempo introduzidos por possíveis distorções entre o tempo das solicitações do Android para renderizar vídeo e o tempo de vsyncs de hardware reais. No entanto, o tunelamento também pode reduzir o suporte para efeitos de GPU, como desfoque ou cantos arredondados em janelas picture-in-picture (PiP), porque os buffers ignoram a pilha de gráficos do Android.

O diagrama a seguir mostra como o tunelamento simplifica o processo de reprodução de vídeo.

comparação dos modos tradição e túnel

Figura 1. Comparação de processos de reprodução de vídeo tradicionais e em túnel

Para desenvolvedores de aplicativos

Como a maioria dos desenvolvedores de aplicativos se integra a uma biblioteca para implementação de reprodução, na maioria dos casos a implementação requer apenas a reconfiguração dessa biblioteca para reprodução em túnel. Para implementação de baixo nível de um player de vídeo em túnel, use as instruções a seguir.

Para reprodução de vídeo sob demanda no Android 5 ou superior:

Crie uma instância SurfaceView .
Crie uma instância audioSessionId .
Crie instâncias AudioTrack e MediaCodec com a instância audioSessionId criada na etapa 2.
Coloque os dados de áudio na AudioTrack com o carimbo de data/hora da apresentação do primeiro quadro de áudio nos dados de áudio.

Para reprodução de transmissão ao vivo no Android 11 ou superior:

Crie uma instância SurfaceView .
Obtenha uma instância avSyncHwId de Tuner .
Crie instâncias AudioTrack e MediaCodec com a instância avSyncHwId criada na etapa 2.

O fluxo de chamada da API é mostrado nos seguintes trechos de código:

aab.setContentType(AudioAttributes.CONTENT_TYPE_MOVIE);

// configure for audio clock sync
aab.setFlag(AudioAttributes.FLAG_HW_AV_SYNC);
// or, for tuner clock sync (Android 11 or higher)
new tunerConfig = TunerConfiguration(0, avSyncId);
aab.setTunerConfiguration(tunerConfig);

if (codecName == null) {
  return FAILURE;
}

// configure for audio clock sync
mf.setInteger(MediaFormat.KEY_AUDIO_SESSION_ID, audioSessionId);
// or, for tuner clock sync (Android 11 or higher)
mf.setInteger(MediaFormat.KEY_HARDWARE_AV_SYNC_ID, avSyncId);

Comportamento da reprodução de vídeo sob demanda

Como a reprodução de vídeo sob demanda em túnel está implicitamente vinculada à reprodução AudioTrack , o comportamento da reprodução de vídeo em túnel pode depender do comportamento da reprodução de áudio.

Na maioria dos dispositivos, por padrão, um quadro de vídeo não é renderizado até que a reprodução do áudio comece. No entanto, o aplicativo pode precisar renderizar um quadro de vídeo antes de iniciar a reprodução de áudio, por exemplo, para mostrar ao usuário a posição atual do vídeo durante a busca.
- Para sinalizar que o primeiro quadro de vídeo na fila deve ser renderizado assim que for decodificado, defina o parâmetro PARAMETER_KEY_TUNNEL_PEEK como 1 . Quando os quadros de vídeo compactados são reordenados na fila (como quando há quadros B ), isso significa que o primeiro quadro de vídeo exibido deve ser sempre um quadro I.
- Se você não quiser que o primeiro quadro de vídeo na fila seja renderizado até o início da reprodução do áudio, defina esse parâmetro como 0 .
- Se esse parâmetro não estiver definido, o OEM determinará o comportamento do dispositivo.
Quando os dados de áudio não são fornecidos ao AudioTrack e os buffers estão vazios (falta de áudio), a reprodução do vídeo é interrompida até que mais dados de áudio sejam gravados porque o relógio de áudio não está mais avançando.
Durante a reprodução, as descontinuidades que o aplicativo não consegue corrigir podem aparecer nos carimbos de data/hora da apresentação de áudio. Quando isso acontece, o OEM corrige as lacunas negativas paralisando o quadro de vídeo atual, e as lacunas positivas eliminando os quadros de vídeo ou inserindo quadros de áudio silenciosos (dependendo da implementação do OEM). A posição do quadro AudioTimestamp não aumenta para quadros de áudio silenciosos inseridos.

Para fabricantes de dispositivos

Configuração

Os OEMs devem criar um decodificador de vídeo separado para suportar a reprodução de vídeo em túnel. Este decodificador deve anunciar que é capaz de reprodução em túnel no arquivo media_codecs.xml :

<Feature name="tunneled-playback" required="true"/>

Quando uma instância MediaCodec em túnel é configurada com um ID de sessão de áudio, ela consulta AudioFlinger em busca deste ID HW_AV_SYNC :

if (entry.getKey().equals(MediaFormat.KEY_AUDIO_SESSION_ID)) {
    int sessionId = 0;
    try {
        sessionId = (Integer)entry.getValue();
    }
    catch (Exception e) {
        throw new IllegalArgumentException("Wrong Session ID Parameter!");
    }
    keys[i] = "audio-hw-sync";
    values[i] = AudioSystem.getAudioHwSyncForSession(sessionId);
}

Durante esta consulta, AudioFlinger recupera o ID HW_AV_SYNC do dispositivo de áudio primário e o associa internamente ao ID da sessão de áudio:

audio_hw_device_t *dev = mPrimaryHardwareDev->hwDevice();
char *reply = dev->get_parameters(dev, AUDIO_PARAMETER_HW_AV_SYNC);
AudioParameter param = AudioParameter(String8(reply));
int hwAVSyncId;
param.getInt(String8(AUDIO_PARAMETER_HW_AV_SYNC), hwAVSyncId);

Se uma instância AudioTrack já tiver sido criada, o ID HW_AV_SYNC será passado para o fluxo de saída com o mesmo ID de sessão de áudio. Se ainda não tiver sido criado, o ID HW_AV_SYNC será passado para o fluxo de saída durante a criação AudioTrack . Isso é feito pelo thread de reprodução :

mOutput->stream->common.set_parameters(&mOutput->stream->common, AUDIO_PARAMETER_STREAM_HW_AV_SYNC, hwAVSyncId);

O ID HW_AV_SYNC , seja ele correspondente a um fluxo de saída de áudio ou a uma configuração Tuner , é passado para o componente OMX ou Codec2 para que o código OEM possa associar o codec ao fluxo de saída de áudio correspondente ou ao fluxo do sintonizador.

Durante a configuração do componente, o componente OMX ou Codec2 deve retornar um identificador de banda lateral que pode ser usado para associar o codec a uma camada Hardware Composer (HWC). Quando o aplicativo associa uma superfície ao MediaCodec , esse identificador de banda lateral é transmitido ao HWC por meio de SurfaceFlinger , que configura a camada como uma camada de banda lateral .

err = native_window_set_sideband_stream(nativeWindow.get(), sidebandHandle);
if (err != OK) {
  ALOGE("native_window_set_sideband_stream(%p) failed! (err %d).", sidebandHandle, err);
  return err;
}

O HWC é responsável por receber novos buffers de imagem da saída do codec no momento apropriado, seja sincronizado com o fluxo de saída de áudio associado ou com o relógio de referência do programa sintonizador, compondo os buffers com o conteúdo atual de outras camadas e exibindo a imagem resultante. Isto acontece independentemente do ciclo normal de preparação e configuração. As chamadas prepare e set acontecem somente quando outras camadas mudam ou quando as propriedades da camada da banda lateral (como posição ou tamanho) mudam.

OMX

Um componente decodificador em túnel deve suportar o seguinte:

Definir o parâmetro estendido OMX.google.android.index.configureVideoTunnelMode , que usa a estrutura ConfigureVideoTunnelModeParams para passar o ID HW_AV_SYNC associado ao dispositivo de saída de áudio.
Configurando o parâmetro OMX_IndexConfigAndroidTunnelPeek que informa ao codec para renderizar ou não o primeiro quadro de vídeo decodificado, independentemente de a reprodução de áudio ter sido iniciada.
Envio do evento OMX_EventOnFirstTunnelFrameReady quando o primeiro quadro de vídeo encapsulado tiver sido decodificado e estiver pronto para ser renderizado.

A implementação do AOSP configura o modo túnel no ACodec por meio de OMXNodeInstance conforme mostrado no seguinte trecho de código:

OMX_INDEXTYPE index;
OMX_STRING name = const_cast<OMX_STRING>(
        "OMX.google.android.index.configureVideoTunnelMode");

OMX_ERRORTYPE err = OMX_GetExtensionIndex(mHandle, name, &index);

ConfigureVideoTunnelModeParams tunnelParams;
InitOMXParams(&tunnelParams);
tunnelParams.nPortIndex = portIndex;
tunnelParams.bTunneled = tunneled;
tunnelParams.nAudioHwSync = audioHwSync;
err = OMX_SetParameter(mHandle, index, &tunnelParams);
err = OMX_GetParameter(mHandle, index, &tunnelParams);
sidebandHandle = (native_handle_t*)tunnelParams.pSidebandWindow;

Se o componente suportar essa configuração, ele deverá alocar um identificador de banda lateral para esse codec e passá-lo de volta por meio do membro pSidebandWindow para que o HWC possa identificar o codec associado. Se o componente não suportar esta configuração, ele deverá definir bTunneled como OMX_FALSE .

Codec2

No Android 11 ou superior, Codec2 oferece suporte à reprodução em túnel. O componente decodificador deve suportar o seguinte:

Configurando C2PortTunneledModeTuning , que configura o modo túnel e passa o HW_AV_SYNC recuperado do dispositivo de saída de áudio ou da configuração do sintonizador.
Consultando C2_PARAMKEY_OUTPUT_TUNNEL_HANDLE , para alocar e recuperar o identificador da banda lateral para HWC.
Manipulando C2_PARAMKEY_TUNNEL_HOLD_RENDER quando anexado a um C2Work , que instrui o codec a decodificar e sinalizar a conclusão do trabalho, mas não a renderizar o buffer de saída até que 1) o codec seja posteriormente instruído a renderizá-lo ou 2) a reprodução de áudio comece.
Tratamento de C2_PARAMKEY_TUNNEL_START_RENDER , que instrui o codec a renderizar imediatamente o quadro marcado com C2_PARAMKEY_TUNNEL_HOLD_RENDER , mesmo que a reprodução de áudio não tenha iniciado.
Deixe debug.stagefright.ccodec_delayed_params desconfigurado (recomendado). Se você configurá-lo, defina como false .
Nota: Não defina debug.stagefright.ccodec_delayed_params como true , pois isso causa um atraso no envio de C2_PARAMKEY_TUNNEL_START_RENDER para o codec.

A implementação do AOSP configura o modo túnel no CCodec por meio de C2PortTunnelModeTuning , conforme mostrado no seguinte trecho de código:

if (msg->findInt32("audio-hw-sync", &tunneledPlayback->m.syncId[0])) {
    tunneledPlayback->m.syncType =
            C2PortTunneledModeTuning::Struct::sync_type_t::AUDIO_HW_SYNC;
} else if (msg->findInt32("hw-av-sync-id", &tunneledPlayback->m.syncId[0])) {
    tunneledPlayback->m.syncType =
            C2PortTunneledModeTuning::Struct::sync_type_t::HW_AV_SYNC;
} else {
    tunneledPlayback->m.syncType =
            C2PortTunneledModeTuning::Struct::sync_type_t::REALTIME;
    tunneledPlayback->setFlexCount(0);
}
c2_status_t c2err = comp->config({ tunneledPlayback.get() }, C2_MAY_BLOCK,
        failures);
std::vector<std::unique_ptr<C2Param>> params;
c2err = comp->query({}, {C2PortTunnelHandleTuning::output::PARAM_TYPE},
        C2_DONT_BLOCK, &params);
if (c2err == C2_OK && params.size() == 1u) {
    C2PortTunnelHandleTuning::output *videoTunnelSideband =
            C2PortTunnelHandleTuning::output::From(params[0].get());
    return OK;
}

Se o componente suportar essa configuração, ele deverá alocar um identificador de banda lateral para esse codec e passá-lo de volta por meio de C2PortTunnelHandlingTuning para que o HWC possa identificar o codec associado.

Áudio HAL

Para reprodução de vídeo sob demanda, o Audio HAL recebe os carimbos de data/hora da apresentação de áudio alinhados com os dados de áudio no formato big-endian dentro de um cabeçalho encontrado no início de cada bloco de dados de áudio que o aplicativo grava:

struct TunnelModeSyncHeader {
  // The 32-bit data to identify the sync header (0x55550002)
  int32 syncWord;
  // The size of the audio data following the sync header before the next sync
  // header might be found.
  int32 sizeInBytes;
  // The presentation timestamp of the first audio sample following the sync
  // header.
  int64 presentationTimestamp;
  // The number of bytes to skip after the beginning of the sync header to find the
  // first audio sample (20 bytes for compressed audio, or larger for PCM, aligned
  // to the channel count and sample size).
  int32 offset;
}

Para que o HWC renderize quadros de vídeo em sincronia com os quadros de áudio correspondentes, o Audio HAL deve analisar o cabeçalho de sincronização e usar o carimbo de data/hora da apresentação para ressincronizar o relógio de reprodução com a renderização de áudio. Para ressincronizar quando o áudio compactado está sendo reproduzido, o HAL de áudio pode precisar analisar metadados dentro dos dados de áudio compactados para determinar a duração da reprodução.

Pausar suporte

O Android 5 ou inferior não inclui suporte para pausa. Você pode pausar a reprodução em túnel apenas por privação de A/V, mas se o buffer interno para vídeo for grande (por exemplo, há um segundo de dados no componente OMX), a pausa parecerá sem resposta.

No Android 5.1 ou superior, AudioFlinger suporta pausa e retomada para saídas de áudio diretas (em túnel). Se o HAL implementar pausa e retomada, a pausa e a retomada da trilha serão encaminhadas para o HAL.

A sequência de chamadas de pausa, liberação e retomada é respeitada pela execução das chamadas HAL no thread de reprodução (o mesmo que descarregamento).

Sugestões de implementação

Áudio HAL

Para o Android 11, o ID de sincronização de HW do PCR ou STC pode ser usado para sincronização A/V, portanto, o streaming somente de vídeo é compatível.

Para Android 10 ou inferior, os dispositivos compatíveis com a reprodução de vídeo em túnel devem ter pelo menos um perfil de fluxo de saída de áudio com os sinalizadores FLAG_HW_AV_SYNC e AUDIO_OUTPUT_FLAG_DIRECT em seu arquivo audio_policy.conf . Esses sinalizadores são usados para definir o relógio do sistema a partir do relógio de áudio.

OMX

Os fabricantes de dispositivos devem ter um componente OMX separado para reprodução de vídeo em túnel (os fabricantes podem ter componentes OMX adicionais para outros tipos de reprodução de áudio e vídeo, como reprodução segura). O componente encapsulado deve:

Especifique 0 buffers ( nBufferCountMin , nBufferCountActual ) em sua porta de saída.
Implemente a extensão OMX.google.android.index.prepareForAdaptivePlayback setParameter .

Especifique seus recursos no arquivo media_codecs.xml e declare o recurso de reprodução em túnel. Deve também esclarecer quaisquer limitações no tamanho do quadro, alinhamento ou taxa de bits. Um exemplo é mostrado abaixo:

<MediaCodec name="OMX.OEM_NAME.VIDEO.DECODER.AVC.tunneled"
type="video/avc" >
    <Feature name="adaptive-playback" />
    <Feature name="tunneled-playback" required=”true” />
    <Limit name="size" min="32x32" max="3840x2160" />
    <Limit name="alignment" value="2x2" />
    <Limit name="bitrate" range="1-20000000" />
        ...
</MediaCodec>

Se o mesmo componente OMX for usado para suportar decodificação com e sem túnel, ele deverá deixar o recurso de reprodução em túnel como não obrigatório. Tanto os decodificadores com túnel quanto os sem túnel têm as mesmas limitações de capacidade. Um exemplo é mostrado abaixo:

<MediaCodec name="OMX._OEM\_NAME_.VIDEO.DECODER.AVC" type="video/avc" >
    <Feature name="adaptive-playback" />
    <Feature name="tunneled-playback" />
    <Limit name="size" min="32x32" max="3840x2160" />
    <Limit name="alignment" value="2x2" />
    <Limit name="bitrate" range="1-20000000" />
        ...
</MediaCodec>

Compositor de Hardware (HWC)

Quando há uma camada de túnel (uma camada com HWC_SIDEBAND compositionType ) em um display, o sidebandStream da camada é o identificador de banda lateral alocado pelo componente de vídeo OMX.

O HWC sincroniza quadros de vídeo decodificados (do componente OMX encapsulado) para a trilha de áudio associada (com o ID audio-hw-sync ). Quando um novo quadro de vídeo se torna atual, o HWC o compõe com o conteúdo atual de todas as camadas recebidas durante a última chamada de preparação ou definição e exibe a imagem resultante. As chamadas prepare ou set acontecem somente quando outras camadas mudam ou quando as propriedades da camada da banda lateral (como posição ou tamanho) mudam.

A figura a seguir representa o HWC trabalhando com o sincronizador de hardware (ou kernel ou driver), para combinar quadros de vídeo (7b) com a última composição (7a) para exibição no horário correto, baseado em áudio (7c).

HWC combinando quadros de vídeo com base em áudio

Figura 2. Sincronizador de hardware HWC (ou kernel ou driver)