Solução de problemas

Como corrigir a mensagem "Tráfego HTTP de texto não permitido não permitido" erros

Esse erro ocorrerá se o aplicativo solicitar tráfego HTTP de texto não criptografado (ou seja, http:// em vez de https://) quando a Configuração de segurança de rede não permitir. Caso seu app seja direcionado ao Android 9 (nível 28 da API) ou versões mais recentes, usar texto não criptografado O tráfego HTTP está desativado pela configuração padrão.

Caso seu aplicativo precise trabalhar com tráfego HTTP de texto não criptografado, use uma Configuração de segurança de rede que permita. Consulte as documentação sobre segurança de rede para mais detalhes. Para ativar todo o tráfego HTTP de texto não criptografado, basta adicionar android:usesCleartextTraffic="true", ao elemento application do objeto AndroidManifest.xml

O app de demonstração do ExoPlayer usa a configuração de segurança de rede padrão. Portanto, ele não permite tráfego HTTP de texto não criptografado. Para ativar, siga as instruções acima.

Como corrigir "SSLHandshakeException", "CertPathValidatorException" e "ERR_CERT_AUTHORITY_INVALID" erros

SSLHandshakeException, CertPathValidatorException e ERR_CERT_AUTHORITY_INVALID indicam um problema com o SSL do servidor certificado. Esses erros não são específicos do ExoPlayer. Consulte Documentação de SSL do Android para mais detalhes.

Por que alguns arquivos de mídia não podem ser pesquisados?

Por padrão, o ExoPlayer não oferece suporte à busca em mídia em que o único método para a execução de operações de busca precisas serve para que o jogador verifique e indexe em todo o arquivo. O ExoPlayer considera esses arquivos como não pesquisáveis. A mídia mais moderna de contêiner incluem metadados para busca (como um índice de amostra), tenham um um algoritmo de busca bem definido (por exemplo, pesquisa de bissecção interpolada para Ogg); ou indicam que o conteúdo é uma taxa de bits constante. Operações de busca eficientes são possível e apoiado pelo ExoPlayer nesses casos.

Se você precisar de busca, mas tiver uma mídia que não está disponível, sugerimos converter seu usando um formato de contêiner mais apropriado. Para arquivos MP3, ADTS e AMR, também é possível ativar a busca presumindo que os arquivos têm uma da taxa de bits, conforme descrito aqui.

Por que a busca é imprecisa em alguns arquivos MP3?

Arquivos MP3 com taxa de bits variável (VBR) são fundamentalmente inadequados para casos de uso que que exigem uma busca exata. Há duas razões para isso acontecer:

  1. Para a busca exata, um formato de contêiner fornecerá um um mapeamento de tempo a byte em um cabeçalho. Esse mapeamento permite que o jogador mapeie o tempo de busca solicitado para o deslocamento de byte correspondente e começar a solicitar, para analisar e reproduzir mídia desse deslocamento. Os cabeçalhos disponíveis para especificar esse mapeamento em MP3 (como cabeçalhos XING) são, infelizmente, frequentemente imprecisos.
  2. Para formatos de contêiner que não fornecem um mapeamento preciso de tempo a byte (ou qualquer mapeamento de tempo a byte), ainda é possível realizar uma operação procure se o contêiner inclui carimbos de data/hora de amostra absolutos no stream. Em Nesse caso, um jogador pode mapear o tempo de busca para o melhor palpite do tempo deslocamento de byte, começar a solicitar mídia a partir desse deslocamento, analisar o primeiro data e hora absoluta da amostra e realizar uma pesquisa binária guiada na mídia até encontrar a amostra certa. Infelizmente, o MP3 não incluir carimbos de data/hora de amostra absolutos no fluxo, portanto, essa abordagem não é sempre que possível.

Por essas razões, a única maneira de executar uma busca exata em um arquivo MP3 VBR é verificar todo o arquivo e criar manualmente um mapeamento de tempo a byte na de futebol. Essa estratégia pode ser ativada usando FLAG_ENABLE_INDEX_SEEKING, que pode ser definido em um DefaultExtractorsFactory usando setMp3ExtractorFlags. Observe que ele não é bem dimensionado para grandes arquivos MP3, especialmente se o usuário tentar chegar ao final da transmissão logo em seguida após o início da reprodução, o que exige que o player aguarde o download ser concluído e indexou todo o stream antes de realizar a busca. No ExoPlayer, neste caso, otimizar a velocidade em vez da acurácia Portanto, o FLAG_ENABLE_INDEX_SEEKING fica desativado por padrão.

Se você controla a mídia reproduzida, recomendamos o uso de uma em um formato de contêiner apropriado, como MP4. Não há casos de uso conhecidos em que MP3 é a melhor opção de formato de mídia.

Por que a busca está lenta no meu vídeo?

Quando o player busca uma nova posição de reprodução em um vídeo, é preciso fazer duas coisas:

  1. Carregar os dados correspondentes à nova posição de reprodução no buffer Isso pode não ser necessário se esses dados já estiverem armazenados em buffer.
  2. Limpe o decodificador de vídeo e comece a decodificar a partir do I-frame (keyframe) antes a nova posição de reprodução, devido à codificação intraframe usada pela maioria dos vídeos. formatos de compactação. Para garantir que a busca seja precisa (ou seja, a reprodução começa exatamente na posição de busca), todos os frames entre o o I-frame anterior e a posição de busca precisam ser decodificados e imediatamente descartado (sem ser exibido na tela).

A latência gerada por (1) pode ser atenuada com o aumento do de dados armazenados em buffer na memória pelo player ou armazenando previamente os dados em cache no disco.

A latência introduzida por (2) pode ser atenuada pela redução da acurácia da busca usando ExoPlayer.setSeekParameters ou recodificando o vídeo ter I-frames mais frequentes (o que resultará em um arquivo de saída maior).

Por que alguns arquivos MPEG-TS não são reproduzidos?

Alguns arquivos MPEG-TS não contêm delimitadores de unidade de acesso (AUDs). Por padrão, O ExoPlayer depende de AUDs para detectar limites de frame de forma econômica. Da mesma forma, algumas Os arquivos MPEG-TS não contêm frames-chave IDR. Por padrão, esses são o único tipo de frames-chave considerados pelo ExoPlayer.

O ExoPlayer aparecerá travado no estado de armazenamento em buffer quando for solicitado que você reproduza um Arquivo MPEG-TS sem frames-chave AUD ou IDR. Se você precisar reproduzir esses arquivos, faça isso usando FLAG_DETECT_ACCESS_UNITS e FLAG_ALLOW_NON_IDR_KEYFRAMES, respectivamente. Essas sinalizações podem ser definidas em uma DefaultExtractorsFactory usando setTsExtractorFlags ou em um DefaultHlsExtractorFactory usando o construtor. O uso de FLAG_DETECT_ACCESS_UNITS não tem nenhum efeito colateral além de ser computacionalmente caro em relação à detecção de limites de frame baseada em AUD. Uso de FLAG_ALLOW_NON_IDR_KEYFRAMES pode resultar em corrupção visual temporária no início da reprodução e imediatamente após buscas ao reproduzir alguns arquivos MPEG-TS.

Por que as legendas não são encontradas em alguns arquivos MPEG-TS?

Alguns arquivos MPEG-TS incluem faixas CEA-608, mas não as declaram no metadados do contêiner, de modo que o ExoPlayer não consegue detectá-los. É possível fazer isso manualmente especificar faixas de legendas com uma lista de músicas formatos de legendas para o DefaultExtractorsFactory, incluindo a acessibilidade canais que podem ser usados para identificá-los no fluxo MPEG-TS:

Kotlin

val extractorsFactory =
  DefaultExtractorsFactory()
    .setTsSubtitleFormats(
      listOf(
        Format.Builder()
          .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
          .setAccessibilityChannel(accessibilityChannel)
          // Set other subtitle format info, such as language.
          .build()
      )
    )
val player: Player =
  ExoPlayer.Builder(context, DefaultMediaSourceFactory(context, extractorsFactory)).build()

Java

DefaultExtractorsFactory extractorsFactory =
    new DefaultExtractorsFactory()
        .setTsSubtitleFormats(
            ImmutableList.of(
                new Format.Builder()
                    .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
                    .setAccessibilityChannel(accessibilityChannel)
                    // Set other subtitle format info, such as language.
                    .build()));
Player player =
    new ExoPlayer.Builder(context, new DefaultMediaSourceFactory(context, extractorsFactory))
        .build();

Por que alguns arquivos MP4/FMP4 não são reproduzidos corretamente?

Alguns arquivos MP4/FMP4 contêm listas de edição que reescrevem a linha do tempo da mídia pular, mover ou repetir listas de amostras. O ExoPlayer tem suporte parcial para aplicar listas de edição. Por exemplo, ele pode atrasar ou repetir grupos de amostras iniciando com uma amostra de sincronização, mas não trunca amostras de áudio ou mídia precedente para edições que não começam em uma amostra de sincronização.

Se você vir que parte da mídia está inesperadamente ausente ou repetida, Tente definir Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS ou FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS, o que fará o extrator ignore completamente as listas de edição. Eles podem ser definidos em uma DefaultExtractorsFactory usando setMp4ExtractorFlags ou setFragmentedMp4ExtractorFlags.

Por que alguns streams falham com o código de resposta HTTP 301 ou 302?

Os códigos de resposta HTTP 301 e 302 indicam redirecionamento. Descrições breves podem ser encontrados na Wikipédia. Quando o ExoPlayer faz uma solicitação e recebe uma resposta com o código de status 301 ou 302, ele normalmente seguirá o redirecionamento e inicie a reprodução normalmente. O único caso em que isso não acontece por padrão é para redirecionamento entre protocolos. O redirecionamento entre protocolos é aquele que de HTTPS para HTTP ou vice-versa (ou menos comumente, entre outro par de protocolos). Você pode testar se um URL causa um redirecionamento entre protocolos usando o seguinte: a ferramenta de linha de comando wget da seguinte maneira:

wget "https://yourserver.com/test.mp3" 2>&1  | grep Location

A saída será semelhante a esta:

Location: https://second.com/test.mp3 [following]
Location: http://third.com/test.mp3 [following]

Neste exemplo, há dois redirecionamentos. O primeiro redirecionamento é https://yourserver.com/test.mp3 para https://second.com/test.mp3. Ambos são HTTPS. Portanto, esse não é um redirecionamento entre protocolos. O segundo redirecionamento é https://second.com/test.mp3 para http://third.com/test.mp3. Isso redireciona de HTTPS para HTTP, assim como o redirecionamento entre protocolos. O ExoPlayer não vai seguir esse redirecionamento em sua configuração padrão, o que significa que a reprodução falhará.

Se precisar, configure o ExoPlayer para seguir redirecionamentos entre protocolos. ao instanciar instâncias DefaultHttpDataSource.Factory usadas na sua para o aplicativo. Saiba como selecionar e configurar a pilha de rede aqui.

Por que alguns fluxos falham com UnReconhecedInputFormatException?

Esta pergunta está relacionada a falhas de reprodução da seguinte forma:

UnrecognizedInputFormatException: None of the available extractors
(MatroskaExtractor, FragmentedMp4Extractor, ...) could read the stream.

Há duas possíveis causas para essa falha. A causa mais comum é que você está tentando reproduzir DASH (mpd), HLS (m3u8) ou SmoothStreaming (ismo, isml) conteúdo, mas o player tenta reproduzi-lo como um stream progressivo. Para reproduzir tais streams, você precisa depender do respectivo módulo do ExoPlayer. Nos casos em que o URI de fluxo não terminar com a extensão de arquivo padrão, também será possível transmitir MimeTypes.APPLICATION_MPD, MimeTypes.APPLICATION_M3U8 ou MimeTypes.APPLICATION_SS a setMimeType de MediaItem.Builder para explicitamente especificar o tipo de transmissão.

A segunda causa menos comum é que o ExoPlayer não oferece suporte ao contêiner formato da mídia que você está tentando reproduzir. Nesse caso, a falha funcionando conforme o esperado, mas fique à vontade para enviar uma solicitação de recurso para nosso Issue Tracker, incluindo detalhes do formato do contêiner e um stream de teste Pesquise uma solicitação de recurso existente antes de enviar uma nova.

Por que setPlaybackParameters não funciona corretamente em alguns dispositivos?

Ao executar um build de depuração do seu app no Android M e versões anteriores, você pode desempenho instável, artefatos audíveis e alta utilização da CPU quando usando a API setPlaybackParameters. Isso acontece porque uma otimização importante para esta API está desativado para builds de depuração em execução nesses mais recentes do Android.

Esse problema afeta apenas builds de depuração. Ele não afetam builds de lançamento, para os quais a otimização está sempre ativada. Por isso, as versões fornecidas aos usuários finais não serão afetadas por esse problema.

O que "O player é acessado na linha de execução errada"? do que os erros significam?

Consulte Uma observação sobre conversas na página de iniciação.

Como corrigir "Unexpected status line: ICY 200 OK"?

Esse problema poderá ocorrer se a resposta do servidor incluir uma linha de status ICY, em vez de um que seja compatível com HTTP. As linhas de status ICY foram descontinuadas e não deve ser usado, portanto, se você controla o servidor, deve atualizá-lo para fornecer uma resposta em conformidade com HTTP. Se não for possível fazer isso, use o A biblioteca OkHttp do ExoPlayer (link em inglês) resolverá o problema, já que pode lidar com ICY linhas de status corretamente.

Como posso consultar se a transmissão é ao vivo?

Você pode consultar o método isCurrentWindowLive do player. Além disso, você pode verificar isCurrentWindowDynamic para descobrir se a janela é dinâmica (ou seja, ainda atualizando ao longo do tempo).

Como manter o áudio em reprodução quando meu app está em segundo plano?

Siga estas etapas para garantir a reprodução contínua de áudio quando o app estiver segundo plano:

  1. Você precisa ter um serviço em primeiro plano em execução. Isso impede que o sistema elimine seu processo para liberar recursos.
  2. Você precisa manter um WifiLock e uma WakeLock. Elas garantem que os mantém o rádio Wi-Fi e a CPU ativados. Isso pode ser feito facilmente se usar ExoPlayer chamando setWakeMode, que vai automaticamente para adquirir e liberar os bloqueios necessários nos momentos corretos.

É importante que você solte as travas (se não estiver usando setWakeMode) e pare o serviço assim que o áudio não estiver mais sendo reproduzido.

Por que o ExoPlayer oferece suporte ao meu conteúdo, mas a biblioteca do Cast do ExoPlayer não oferece suporte?

É possível que o conteúdo que você está tentando reproduzir não CORS ativado. O framework do Cast exige que o conteúdo seja ativado para CORS na para tocá-la.

Por que o conteúdo não é reproduzido, mas nenhum erro é exibido?

É possível que o dispositivo no qual você está reproduzindo o conteúdo não dão suporte a um formato de amostra de mídia específico. Isso pode ser facilmente confirmado adicionando um EventLogger como ouvinte do player e procurando uma linha semelhante a este no Logcat:

[ ] Track:x, id=x, mimeType=mime/type, ... , supported=NO_UNSUPPORTED_TYPE

NO_UNSUPPORTED_TYPE significa que o dispositivo não consegue decodificar a mídia. formato de amostra especificado por mimeType. Veja os formatos de mídia do Android Documentação para informações sobre os formatos de amostra compatíveis. Como uma biblioteca de decodificação para carregar e ser usada para reprodução? também pode ser útil.

Como posso fazer com que uma biblioteca de decodificação carregue e seja usada para reprodução?

  • A maioria das bibliotecas de decodificador tem etapas manuais para verificar e criar as dependências. É necessário seguir as etapas no README da biblioteca relevante. Por exemplo, para a biblioteca do ExoPlayer FFmpeg, é necessário seguir o instruções em libraries/decoder_ffmpeg/README.md, incluindo a transmissão flags de configuração para ativar decodificadores para qualquer formato que você queira reproduzir.
  • Para bibliotecas com código nativo, verifique se você está usando a versão do Android NDK conforme especificado no README, e procure por erros que aparecem durante a configuração e a criação. Você vai ver .so. aparecem no subdiretório libs do caminho da biblioteca para cada com suporte após seguir as etapas no README.
  • Para testar a reprodução com a biblioteca no aplicativo de demonstração, consulte como ativar decodificadores agrupados. Consulte o README da biblioteca para instruções sobre como usar a biblioteca do seu próprio aplicativo.
  • Se você usa o DefaultRenderersFactory, vai aparecer um nível de informações linha de registro como "Loaded FfmpegAudioRenderer" no Logcat, quando o decodificador é carregado. Se isso estiver faltando, certifique-se de que o aplicativo depende da decodificação de código.
  • Se aparecerem registros de nível de aviso de LibraryLoader no Logcat, indica que o carregamento do componente nativo da biblioteca falhou. Se esse acontecer, verifique se você seguiu as etapas no arquivo README da biblioteca corretamente, e que nenhum erro seja gerado ao seguir as instruções.

Se você ainda tiver problemas ao usar bibliotecas de decodificação, consulte a O Issue Tracker da Media3 é útil para encontrar problemas recentes relevantes. Se você precisar registrar um novo problema relacionado à criação da parte nativa da biblioteca, incluir a saída completa da linha de comando das instruções README para nos ajudar e diagnosticar o problema.

Posso abrir vídeos do YouTube diretamente com o ExoPlayer?

Não, o ExoPlayer não pode abrir vídeos do YouTube, como URLs no formato https://www.youtube.com/watch?v=...: Em vez disso, você deve usar o YouTube a API do IFrame Player, que é a forma oficial de reproduzir vídeos do YouTube no Android.

A reprodução do vídeo está falhando

O dispositivo pode não ser capaz de decodificar o conteúdo rápido o suficiente se, por exemplo, a taxa de bits ou a resolução do conteúdo exceder a capacidade do dispositivo. Talvez seja necessário a usar conteúdo de baixa qualidade para ter um bom desempenho nesses dispositivos.

Se o vídeo estiver travando em um dispositivo com uma versão do Android do Android 6.0 (nível 23 da API) até o Android 11 (nível 30 da API) especialmente ao reproduzir conteúdo protegido por DRM ou com alto frame rate, tente Como ativar o enfileiramento do buffer assíncrono.

Erros de lint de API instáveis

A Media3 garante a compatibilidade binária para um subconjunto da superfície da API. A as partes que não garantem compatibilidade binária são marcadas com @UnstableApi. Para esclarecer essa distinção, o uso de imagens instáveis Os símbolos da API geram um erro de lint, a menos que sejam anotados com @OptIn.

A anotação @UnstableApi não diz nada sobre a qualidade ou o desempenho de uma API, apenas o fato de que ela não está "congelada pela API".

Você tem duas opções para lidar com erros de lint instáveis da API:

  • Mude para uma API estável que alcance o mesmo resultado.
  • Continue usando a API instável e anote o uso com @OptIn, conforme mais adiante.
Adicionar a anotação @OptIn

O Android Studio pode ajudar você a adicionar a anotação:

Captura de tela: como adicionar a anotação de ativação
Figura 2: adição de uma anotação @androidx.annotations.OptIn com o Android Studio.

Também é possível anotar manualmente sites de uso específicos no Kotlin:

import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi

@OptIn(UnstableApi::class)
fun functionUsingUnstableApi() { ... }

E também em Java:

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

@OptIn(markerClass = UnstableApi.class)
private void methodUsingUnstableApis() { ... }

É possível ativar pacotes inteiros adicionando um arquivo package-info.java:

@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

É possível ativar projetos inteiros suprimindo o erro específico do lint na Arquivo lint.xml:

 <?xml version="1.0" encoding="utf-8"?>
 <lint>
   <issue id="UnsafeOptInUsageError">
     <option name="opt-in" value="androidx.media3.common.util.UnstableApi" />
   </issue>
 </lint>

Há também uma anotação kotlin.OptIn que não pode ser usada. Está é importante usar a anotação androidx.annotation.OptIn.