[Netease Yunxin] Análise e experiência prática de problemas comuns no lado da reprodução de cenas de transmissão ao vivo

Processo de reprodução comum

 

Análise do processo principal do jogador

O processo de reprodução do player é semelhante ao processo de streaming, mas a ordem é inversa. O terminal de streaming primeiro coleta áudio e vídeo, codifica e encapsula áudio e vídeo e os processa de acordo com o protocolo de mídia de streaming para finalmente obter o fluxo de saída. O player analisa e desencapsula o fluxo de entrada para obter pacotes de áudio (como AAC) e pacotes de vídeo (como H.264, H.265) e os decodifica para obter o quadro de áudio PCM e o quadro de vídeo YUV. Por fim, o player precisa renderizar e reproduzir o vídeo e o áudio por meio do módulo de sincronização de áudio e vídeo e, por fim, apresentá-lo ao usuário.

A partir da análise do modelo de encadeamento, o encadeamento central do mecanismo de reprodução geralmente pode ser dividido em " encadeamento de desencapsulamento (encadeamento de leitura) ", " encadeamento de decodificação de áudio/vídeo " e " encadeamento de reprodução de áudio/vídeo ". é melhor para o mecanismo de reprodução e aplicativos da camada superior Com a cooperação, o mecanismo de reprodução geralmente mantém um "segmento de mensagem" para relatar à camada superior, como "código de erro de falha na reprodução, tempo de reprodução do primeiro quadro de vídeo/áudio, dados estatísticos durante reprodução (como primeiro quadro demorado, taxa de código de áudio/vídeo, número do quadro de recepção de áudio e vídeo/segundo, número do quadro de decodificação de áudio e vídeo/segundo, número/segundo do quadro de reprodução de áudio e vídeo, tempos de congelamento da reprodução, duração do congelamento da reprodução , diferença de clock de sincronização de áudio e vídeo, etc.)".

Pode-se ver no modelo de encadeamento que os encadeamentos principais do mecanismo de reprodução são um modelo produtor-consumidor muito significativo. Este modelo pode utilizar com eficiência as vantagens do paralelismo multi-core da CPU e, por meio de um gerenciamento de buffer de mídia razoável, pode resistir à rede e ao jitter de decodificação até certo ponto e evitar congelamentos frequentes.

Os problemas comuns durante o processo de reprodução concentram-se principalmente em problemas como incapacidade de reproduzir, sem som ou imagem, tela desfocada, congelamento e alto atraso . Normalmente, o link de solução de problemas é realizado ao contrário pelo lado da reprodução. Abaixo, analisaremos alguns problemas comuns durante a reprodução de transmissões ao vivo com base em alguns casos que acumulamos em nosso trabalho.

A resolução é muito pequena para causar falha de decodificação de hardware

Fenômeno: feedback do cliente de que, durante a transmissão ao vivo, a tela congela repentinamente, mas o som está normal.

Análise: por meio da análise do log de reprodução e do despejo do stream de vídeo, descobrimos que quando o problema ocorreu, o player estava usando decodificação de hardware Android e a resolução do stream de vídeo puxado mudou (1080p->16p). Bloqueamos o problema consultando os dados A causa raiz é que o codec MediaCodec do Android oferece suporte a uma variedade de resoluções que variam de dispositivo para dispositivo. Você pode visualizá-lo visualizando /vendor/etc/media_codecs_xxx.xml no dispositivo, como media_codecs_mediatek_video.xml do dispositivo "M2006C3LC", a descrição de decodificação do H264 é a seguinte, a resolução suportada pelo "OMX.MTK.VIDEO .DECODER.AVC" O intervalo é (64*64) - (2048*1088), portanto, pode haver alguns problemas imprevisíveis ao analisar vídeos com uma resolução de 16*16.

 

Experiência prática: recursos de hardware Android para adaptação

1.  Em comparação com dispositivos IOS, os dispositivos Android são mais fragmentados . Adaptar-se às diferentes capacidades de diferentes modelos pode reduzir bastante os problemas semelhantes acima. Felizmente, a interface MediaCodec fornece aos desenvolvedores uma interface de consulta de capacidade relativamente abrangente, como algumas interfaces fornecidas em MediaCodecInfo.VideoCapabilities:

public Range<Integer> getBitrateRange ()
public Range<Integer> getSupportedFrameRates ()
public Range<Integer> getSupportedHeights ()
public boolean isSizeSupported (int width, int height)
...

Esta parte da interface fornecida pelo MediaCodec pode nos ajudar a escolher melhor se usar um decodificador rígido ou um decodificador flexível de acordo com a capacidade do dispositivo ao inicializar o codec/decodificador e evitar falhas de decodificação e fallbacks causados ​​por problemas de capacidade do dispositivo tanto quanto possível . Para o lado da codificação, inclui principalmente se MediaFormat é suportado, se Profile/Level é suportado, se a resolução de codificação é suportada, se a taxa de bits de codificação é suportada, se a taxa de quadros de codificação é suportada, se o número de instâncias de codificação excede o intervalo máximo suportado, etc. O final da decodificação é semelhante ao final da codificação.

2. Mantenha uma lista negra: ativar a codificação/decodificação de hardware de vídeo pode reduzir a carga da CPU até certo ponto e melhorar o desempenho do vídeo. No entanto, devido à grave fragmentação do Android, muitos recursos de codificação e decodificação do MediaCodec são implementados pelos fabricantes de dispositivos. É é difícil obter consistência no desempenho. Em nossos casos anteriores, podemos descobrir que os recursos de codificação e decodificação de hardware de alguns modelos são muito ruins e a causa raiz do desempenho ruim não pode ser encontrada, portanto, podemos optar por usar uma lista negra para manutenção.

3. Melhorar o mecanismo de solução de fallback de decodificação de hardware: problemas de decodificação de hardware relativamente comuns, como decodificação de hardware leva muito tempo, erros de API de decodificação de hardware, etc. usar as informações de erro capturadas Realizar a discriminação, reverter o processamento de decodificação de software para erros de chave ou relatar para a camada de aplicativo para processamento, mas não há erro relatado na chamada de interface, mas o problema de longo tempo de decodificação ainda afetará muito a experiência do usuário , portanto, no caso de tempo de decodificação excessivo, também é necessário reverter e relatar para a camada de aplicativo.

O problema de desfoque da tela causado pela atualização incorreta dos parâmetros sps/pps

Fenômeno: durante o teste de nosso projeto, encontramos o problema de decodificação de tela desfocada de hardware em cenas como pk.

Análise: Depois de nossos testes, descobrimos que a solução soft não causa tela embaçada, mas a decodificação de hardware causará tela embaçada. Ao usar o ffmpeg dump para analisar os dados do fluxo de código da extremidade receptora, descobrimos que quando a tela embaçada ocorre , o sps/pps do vídeo mudou, e o problema é muito sério. É claro que é um problema típico de decodificação de tela desfocada causado pela atualização incorreta do sps/pps.

Experiência prática: Em circunstâncias normais, o sps/pps geralmente não muda durante um único push de fluxo estável. Geralmente, quando a resolução de vídeo muda, o mecanismo de reprodução ijk original está no módulo de decodificação de hardware. Suporta atualizações sps/pps ao alternar resoluções . No entanto, o negócio de alguns terminais de streaming pode ser mais complicado, envolvendo comutação dinâmica de codificadores, etc., o que também causará alterações em sps/pps quando a resolução permanecer inalterada. Portanto, do ponto de vista da versatilidade, cada vez que as informações do cabeçalho do vídeo são recebidas, elas devem ser comparadas com as informações do cabeçalho do vídeo atual e atualizadas no momento em que ocorrem alterações, para evitar problemas como telas desfocadas.

Problemas de tela desfocada causados ​​por falta de quadros-chave e quadros de referência ausentes

Fenômeno: a tela fica embaçada e se recupera após um período de tempo.

Análise: Através da análise do code stream dump, verificamos que não há nenhum problema com o code stream. Posteriormente, através da análise do log, identificamos a causa raiz do problema: "A tela de decodificação está embaçada devido ao perda do referencial" .

Experiência prática: Problemas de Huaping geralmente ocorrem em cenas como quadros-chave ausentes e quadros de referência ausentes. A qualquer momento, após a codificação e antes da decodificação, não é recomendável descartar os quadros de vídeo, caso contrário, pode causar problemas de tela embaçada no final da decodificação. Na cena da transmissão ao vivo, para eliminar o atraso acumulado, alguns jogadores irão optar por descartar alguns quadros não decodificados no frame buffer. Neste caso, uma estratégia mais razoável é descartar um GOP inteiro, ou usar o método de dupla velocidade O método de reprodução é usado para acompanhar o atraso e a estratégia de velocidade dupla é interrompida quando o atraso atende aos requisitos da transmissão ao vivo. Além disso, para evitar ao máximo problemas de tela borrada causados ​​por tais problemas, a detecção de quadros-chave deve ser realizada em cenários como a primeira transmissão, desconexão e reconexão da rede, e a decodificação deve começar a partir do quadro-chave.

Problemas inesperados de reprodução causados ​​pela alternância de operações de áudio e vídeo no final do streaming

Fenômeno: durante o teste do projeto, o áudio e o vídeo no final da reprodução pararam de tocar repentinamente.

Análise: Ao analisar o fluxo de código na extremidade receptora, descobrimos que o fluxo de mídia de áudio parou repentinamente durante a transmissão ao vivo. Por meio de investigação, descobrimos que a extremidade de streaming oferece suporte à função de desligamento dinâmico de fluxos de mídia de áudio/vídeo. Esta função fará com que o fluxo de mídia de áudio ou vídeo da extremidade receptora seja interrompido repentinamente e entre em conflito com a lógica existente da extremidade de reprodução, resultando em alguns problemas imprevisíveis.

Experiência prática: Se o final do streaming suportar o fechamento dinâmico de streams de áudio e vídeo, é relativamente difícil adaptar o player. Geralmente, os cenários que precisam ser adaptados incluem, mas não estão limitados a: "Cena de áudio seguida de vídeo " , Cenários como "Áudio primeiro seguido de vídeo" , "Interrupção repentina do fluxo de vídeo" , "Interrupção repentina do fluxo de áudio" e outros cenários. É relativamente mais fácil para o lado da reprodução se adaptar a cenários em que os fluxos de áudio e vídeo aumentam. Ele só precisa detectar dinamicamente o número de fluxos de mídia no módulo de desencapsulamento para determinar se há novos fluxos adicionados. No entanto, para cenários em que áudio/ fluxos de mídia de vídeo são interrompidos repentinamente É muito difícil de se adaptar. Por um lado, como um mecanismo de reprodução geral, ele não interage com a lógica de sinalização do final do streaming. Por outro lado, a cena pode ter muitas lógicas comuns com o player, como sincronização de áudio e vídeo (áudio síncrono de vídeo, vídeo síncrono de áudio), lógica de buffer etc. o fluxo de áudio é interrompido repentinamente, precisamos perceber que o fluxo de áudio no final do push parou Feche e ajuste a estratégia de sincronização de áudio e vídeo do player. Portanto, é difícil ser compatível com essas cenas do ponto de vista do player, mas do ponto de vista do final do streaming, você pode optar por adicionar quadros silenciosos/dados de vídeo de vídeo falso quando o fluxo de mídia de áudio/vídeo estiver fechado, para que o fluxo de mídia pode ser garantido. A continuidade, para que seja compatível com a maioria dos players do lado do streaming.

Além disso, também descobrimos na prática que, no cenário em que os fluxos de áudio/vídeo são ativados e desativados dinamicamente no final do streaming, mesmo que o final da reprodução seja compatível, se o servidor ou o fabricante do CDN oferece suporte, será uma grande questão marca, especialmente no aplicativo No cenário em que o protocolo hls puxa fluxos, porque comparado a outros protocolos de streaming, o protocolo hls também envolve lógica de fatiamento no lado do servidor e é provável que a lógica de fatiamento hls do servidor ou fabricante de CDN não é compatível com a operação de comutação de áudio e vídeo.

 

O vídeo ou o áudio não podem ser decodificados devido à falta de cabeçalho de áudio/cabeçalho de vídeo

Fenômeno: feedback do cliente de que um determinado fluxo de vídeo pode ser obtido por rtmp, mas não por hls.

Análise: Ao obter o endereço do fluxo de origem do cliente, teste o desempenho do streaming rtmp e hls através do ffplay, respectivamente. Entre eles, o streaming hls não tem som e nenhuma informação de áudio foi analisada. A análise do fluxo de código do streaming rtmp Dump Pode-se observar que, embora o áudio possa ser reproduzido normalmente, faltam as informações do cabeçalho do áudio.

 

Experiência prática: O problema causado pela falta de cabeçalhos de vídeo/áudio não pode ser resolvido através da adaptação do final da reprodução, e o problema pode estar oculto e difícil de encontrar. O final do streaming deve verificar se está correto em cada situação do pronúncia complementar/cabeçalho de vídeo As informações de cabeçalho de áudio e vídeo são enviadas, como alterações de configuração de áudio e vídeo, desconexão e reconexão de rede, reenvio e outros cenários.

Exceção de reprodução causada por timestamps descontínuos

Fenômeno: o áudio e o vídeo estão fora de sincronia ou travados.

Análise: as anomalias de timestamp podem ser divididas em duas categorias. A primeira categoria é que os timestamps de áudio e vídeo não estão sincronizados, ou seja, o intervalo é grande. A segunda categoria é o problema de retroceder timestamps de áudio e vídeo, como dts /pts repentinamente começando de 0. Em circunstâncias normais, a fim de evitar situações como ficar preso quando tais anormalidades ocorrem, o final do streaming será compatível com cenários com timestamps descontínuos. A solução geral pode incluir a queda de quadros ou o abandono da estratégia original de sincronização do relógio de acordo com sua respectiva reprodução quadros. Reproduzir em intervalos. Embora esta solução possa continuar a reproduzir quando os carimbos de data/hora de áudio e vídeo estiverem anormais, ela pode causar problemas como áudio e vídeo fora de sincronia e congelamentos.

Experiência prática: O lado da reprodução desse problema pode ser compatível até certo ponto, mas a causa raiz é que o lado do streaming precisa garantir a sincronização dos registros de data e hora de áudio e vídeo.

Ferramentas comumente usadas para analisar problemas

• ffmpeg, ffplay, ffprobe code stream Dump/stream media playback/view media information, etc.

• O analisador elecard analisa o conteúdo do fluxo de código.

• mediaInfo Análise de formato de informação de arquivos de mídia.

• O flvAnalyser analisa as informações de encapsulamento do formato FLV.

• YUV Eye reproduz dados YUV.