Dépannage

Correction de l'erreur "Trafic HTTP en texte clair non autorisé" erreurs

Cette erreur se produit si votre application demande du trafic HTTP en texte clair (par exemple, http:// au lieu de https://) lorsque sa configuration de sécurité réseau le fait ne le permettent pas. Si votre application cible Android 9 (niveau d'API 28) ou une version ultérieure, texte clair Le trafic HTTP est désactivé par défaut.

Si votre application doit fonctionner avec du trafic HTTP en texte clair, vous devez utiliser un Configuration de la sécurité réseau qui le permet. Découvrez documentation sur la sécurité réseau pour en savoir plus. Pour activer tout le trafic HTTP en texte clair, il vous suffit d'ajouter android:usesCleartextTraffic="true" à l'élément application du AndroidManifest.xml

L'application de démonstration ExoPlayer utilise la configuration de sécurité réseau par défaut. le trafic HTTP en texte clair n'est pas autorisé. Vous pouvez l'activer en suivant les instructions ci-dessus.

Correction de "SSLHandshakeException", "CertPathValidatorException" et "ERR_CERT_AUTHORITY_INVALID" erreurs

SSLHandshakeException, CertPathValidatorException et ERR_CERT_AUTHORITY_INVALID indiquent tous un problème avec le protocole SSL du serveur certificat. Ces erreurs ne sont pas spécifiques à ExoPlayer. Voir Documentation SSL pour Android pour en savoir plus.

Pourquoi la recherche de certains fichiers multimédias est-elle impossible ?

Par défaut, ExoPlayer ne prend pas en charge la recherche dans les contenus multimédias dont la seule méthode des opérations de recherche précises permettent au joueur d'analyser et d'indexer l'intégralité du fichier. ExoPlayer considère ces fichiers comme impossibles à rechercher. Médias les plus modernes les formats de conteneur incluent des métadonnées pour la recherche (comme un exemple d'index), Un algorithme de recherche bien défini (par exemple, une recherche bissectionnelle interpolée pour Ogg) indiquent que le débit de leur contenu est constant. Des opérations de recherche efficaces sont possible et pris en charge par ExoPlayer dans ces cas.

Si vous avez besoin de rechercher des éléments multimédias, mais que vous ne les trouvez pas, nous vous conseillons de convertir votre contenu afin d'utiliser un format de conteneur plus approprié. Pour les fichiers MP3, ADTS et AMR, vous pouvez également activer la recherche en partant du principe que les fichiers ont une constante comme indiqué cliquez ici.

Pourquoi la recherche est-elle inexacte dans certains fichiers MP3 ?

Les fichiers MP3 à débit variable (VBR) ne sont pas du tout adaptés aux cas d'utilisation qui requièrent une recherche exacte. Il y a deux raisons à cela:

  1. Pour une recherche exacte, un format de conteneur fournira dans un en-tête. Ce mappage permet au joueur de mapper demandé le temps de recherche du décalage d'octets correspondant, et commencer à demander, l'analyse et la lecture des contenus multimédias à partir de ce décalage. Les en-têtes disponibles pour spécifier ce mappage au format MP3 (comme les en-têtes XING) sont malheureusement souvent imprécises.
  2. Pour les formats de conteneurs qui n'offrent pas de mappage précis tout mappage time-to-octet), il est toujours possible d'effectuer une vérifie si le conteneur inclut des échantillons de codes temporels absolus dans le flux. Dans Dans ce cas, le joueur peut mapper la durée de recherche sur la meilleure estimation de la le décalage des octets, commencer à demander des médias à partir de ce décalage, analyser le premier le code temporel absolu de l'échantillon et effectuer efficacement une recherche binaire guidée jusqu'à ce qu'il trouve l'échantillon approprié. Malheureusement, le format MP3 n'est pas inclure des horodatages d'échantillons absolus dans le flux. Cette approche n'est donc pas possible.

C'est pourquoi le seul moyen d'effectuer une recherche exacte dans un fichier MP3 VBR est pour analyser l'intégralité du fichier et créer manuellement un mappage "Time-to-byte" dans le joueur. Vous pouvez activer cette stratégie à l'aide de FLAG_ENABLE_INDEX_SEEKING, qui peut être définie sur un DefaultExtractorsFactory en utilisant setMp3ExtractorFlags Notez qu'il n'est pas adapté aux fichiers MP3 volumineux, surtout si l'utilisateur essaie de revenir rapidement à la fin de la diffusion. Après le début de la lecture, ce qui oblige le lecteur à attendre qu'il soit téléchargé et indexé l'intégralité du flux avant d'effectuer la recherche. Dans ExoPlayer, nous a décidé d'optimiser la vitesse plutôt que la précision dans ce cas. FLAG_ENABLE_INDEX_SEEKING est donc désactivé par défaut.

Si vous contrôlez le contenu multimédia que vous lisez, nous vous conseillons vivement d'utiliser un lecteur d'écran plus le format de conteneur approprié, tel que MP4. Il n'existe aucun cas d'utilisation connu où le format MP3 est le meilleur choix de format multimédia.

Pourquoi la recherche est-elle lente dans ma vidéo ?

Lorsque le lecteur recherche une nouvelle position de lecture dans une vidéo, deux choses:

  1. Charger les données correspondant à la nouvelle position de lecture dans le tampon (cela peut ne pas être nécessaire si ces données sont déjà en mémoire tampon).
  2. Videz le décodeur vidéo et commencez le décodage à partir de l'I-frame (image clé) avant La nouvelle position de lecture, en raison du codage intra-frame utilisé par la plupart des vidéos formats de compression. Pour s'assurer que la recherche est précise (c'est-à-dire, la lecture démarre exactement à la position de recherche), toutes les images entre les l'iFrame précédent et la position de recherche doivent être décodés et immédiatement supprimé (sans apparaître à l'écran).

La latence introduite par (1) peut être atténuée en augmentant la quantité de données mises en mémoire tampon par le lecteur, ou la mise en cache préalable des données sur le disque.

La latence introduite par l'option (2) peut être atténuée en réduisant la précision de la recherche à l'aide de ExoPlayer.setSeekParameters ou réencodez la vidéo. d'avoir des I-frames plus fréquents (ce qui se traduira par un fichier de sortie plus volumineux).

Pourquoi la lecture de certains fichiers MPEG-TS échoue-t-elle ?

Certains fichiers MPEG-TS ne contiennent pas de délimiteurs d'unité d'accès (AUD). Par défaut, ExoPlayer s'appuie sur les fichiers AUD pour détecter les limites de frames à moindre coût. De même, certaines Les fichiers MPEG-TS ne contiennent pas d'images clés IDR. Par défaut, il s'agit du seul type d'images clés prises en compte par ExoPlayer.

ExoPlayer semble bloqué à l'état de mise en mémoire tampon lorsque vous êtes invité à lire un Fichier MPEG-TS sans images clés en AUD ou en IDR. Si vous devez lire ces fichiers, vous pouvez le faire à l'aide de FLAG_DETECT_ACCESS_UNITS et FLAG_ALLOW_NON_IDR_KEYFRAMES respectivement. Ces indicateurs peuvent être définis sur un DefaultExtractorsFactory avec setTsExtractorFlags ou sur un DefaultHlsExtractorFactory à l'aide de constructeur. L'utilisation de FLAG_DETECT_ACCESS_UNITS n'a pas d'effets secondaires, hormis le fait d'être coûteuse en calcul par rapport à la détection des limites de trame basée sur l’AUD. Utilisation de FLAG_ALLOW_NON_IDR_KEYFRAMES peut entraîner une corruption temporaire de l'image au niveau au début de la lecture et une recherche immédiatement après lors de la lecture de certains fichiers MPEG-TS.

Pourquoi les sous-titres sont-ils introuvables dans certains fichiers MPEG-TS ?

Certains fichiers MPEG-TS incluent des pistes CEA-608, mais ne les déclarent pas dans le fichier les métadonnées du conteneur. ExoPlayer ne peut donc pas les détecter. Vous pouvez spécifiez les pistes de sous-titres en fournissant une liste de sous-titres dans le DefaultExtractorsFactory, y compris l'accessibilité canaux permettant de les identifier dans le flux 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();

Pourquoi certains fichiers MP4/FMP4 ne sont-ils pas lus correctement ?

Certains fichiers MP4/FMP4 contiennent des listes de modifications qui réécrivent la chronologie du média sauter, déplacer ou répéter des listes d'échantillons. ExoPlayer est partiellement compatible pour appliquer des listes de modifications. Par exemple, elle peut retarder ou répéter des groupes d'échantillons. à partir d'un échantillon de synchronisation, mais ne tronque pas les échantillons audio ni média pré-roll pour les modifications qui ne sont pas lancées sur un exemple de synchronisation.

Si vous constatez qu'une partie du contenu multimédia est manquante ou répétée de façon inattendue, essayez de définir Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS ou FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS, ce qui entraînera l'extracteur pour ignorer complètement les listes de modifications. Vous pouvez les définir sur DefaultExtractorsFactory avec setMp4ExtractorFlags ou setFragmentedMp4ExtractorFlags

Pourquoi certains flux échouent-ils avec le code de réponse HTTP 301 ou 302 ?

Les codes de réponse HTTP 301 et 302 indiquent tous deux une redirection. Brèves descriptions est disponible sur Wikipédia. Quand ExoPlayer effectue une requête et reçoit une avec le code d'état 301 ou 302, le code de redirection est normalement et lancez la lecture normalement. Le seul cas où cela ne se produit pas par défaut est destiné aux redirections interprotocoles. Une redirection interprotocole est une redirection qui redirige du protocole HTTPS au HTTP ou vice-versa (ou, plus rarement, entre une autre paire de protocoles). Vous pouvez vérifier si une URL provoque une redirection interprotocole à l'aide de la méthode l'outil de ligne de commande wget, comme suit:

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

Le résultat doit se présenter comme suit:

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

Cet exemple comporte deux redirections. La première redirection provient De https://yourserver.com/test.mp3 à https://second.com/test.mp3. Les deux sont HTTPS, et il ne s'agit donc pas d'une redirection interprotocole. La deuxième redirection provient De https://second.com/test.mp3 à http://third.com/test.mp3. Cela redirige de HTTPS vers HTTP, ce qui est une redirection interprotocole. ExoPlayer n'effectue pas suivez cette redirection dans sa configuration par défaut, ce qui signifie que la lecture échouera.

Si nécessaire, vous pouvez configurer ExoPlayer pour qu'il suive les redirections interprotocoles lorsque vous instanciez les instances DefaultHttpDataSource.Factory utilisées dans votre application. En savoir plus sur la sélection et la configuration de la pile réseau cliquez ici.

Pourquoi certains flux échouent-ils avec UnrecognizedInputFormatException ?

Cette question concerne les échecs de lecture sous la forme suivante:

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

Deux causes sont possibles. La cause la plus courante est que vous essayez de lire les formats DASH (mpd), HLS (m3u8) ou SmoothStreaming (ism, isml) contenu, mais le lecteur essaie de le lire comme un flux progressif. Pour jouer flux, vous devez dépendre du module ExoPlayer concerné. Dans les cas où l'URI du flux ne se termine pas par l'extension de fichier standard, vous pouvez également transmettre MimeTypes.APPLICATION_MPD, MimeTypes.APPLICATION_M3U8 ou MimeTypes.APPLICATION_SS à setMimeType sur MediaItem.Builder pour indiquer explicitement spécifier le type de flux.

La deuxième cause, moins courante, est qu'ExoPlayer n'est pas compatible avec le conteneur le format du média que vous essayez de lire. Dans ce cas, l'échec est fonctionne comme prévu, mais n'hésitez pas à soumettre une demande de fonctionnalité sur notre Issue Tracker comprenant des informations sur le format du conteneur et un flux de test. Veuillez rechercher une demande de fonctionnalité existante avant d'en soumettre une nouvelle.

Pourquoi setPlaybackParameters ne fonctionne-t-il pas correctement sur certains appareils ?

Lorsque vous exécutez une version de débogage de votre application sur Android M ou une version antérieure, vous pouvez : connaissent des performances saccadées, des artefacts audibles et une utilisation élevée du processeur à l'aide de l'API setPlaybackParameters. En effet, une optimisation importantes pour cette API est désactivée pour les versions de débogage exécutées sur ces versions d'Android.

Il est important de noter que ce problème n'affecte que les versions de débogage. Il n'a pas affecter les builds, pour lesquels l'optimisation est toujours activée. C'est pourquoi que vous fournissez aux utilisateurs finaux ne devraient pas être affectés par ce problème.

Que se passe-t-il ? signifie "erreurs" ?

Consultez la section Remarque sur les fils de discussion sur la page de démarrage.

Comment résoudre le problème "Ligne d'état inattendue: ICY 200 OK" ?

Ce problème peut survenir si la réponse du serveur inclut une ligne d'état ICY, au lieu d'un protocole compatible avec HTTP. Les lignes d'état ICY sont obsolètes et ne doit pas être utilisé. Par conséquent, si vous contrôlez le serveur, vous devez le mettre à jour pour fournir une réponse conforme au protocole HTTP. Si vous n'y parvenez pas, La bibliothèque OkHttp d'ExoPlayer résoudra le problème, car elle est capable de gérer ICY. les lignes d'état.

Comment puis-je savoir si la diffusion en cours de lecture est en direct ?

Vous pouvez interroger la méthode isCurrentWindowLive du joueur. De plus, vous vous pouvez consulter isCurrentWindowDynamic pour savoir si la fenêtre est dynamique (c'est-à-dire toujours mises à jour au fil du temps).

Comment continuer la lecture audio lorsque mon application est en arrière-plan ?

Suivez ces étapes pour assurer la lecture continue du contenu audio lorsque votre application est dans en arrière-plan:

  1. Vous devez disposer d'un service de premier plan en cours d'exécution. Cela empêche le système de tuer votre processus pour libérer des ressources.
  2. Vous devez contenir un WifiLock et un WakeLock. Ceux-ci garantissent que maintient le signal radio Wi-Fi et le CPU actifs. Vous pouvez le faire facilement si vous utilisez ExoPlayer en appelant setWakeMode, qui acquérir et libérer les verrous nécessaires au bon moment.

Il est important de débloquer les serrures (si vous n'utilisez pas setWakeMode) et d'arrêter le service dès que le contenu audio n'est plus lu.

Pourquoi ExoPlayer prend-il en charge mon contenu, mais pas la bibliothèque Cast d'ExoPlayer ?

Il est possible que le contenu que vous essayez de lire CORS activé Le framework Cast nécessite que le contenu CORS soit activé dans pour le lire.

Pourquoi la lecture du contenu échoue-t-elle, mais aucune erreur ne s'affiche ?

Il est possible que l'appareil sur lequel vous lisez le contenu prennent en charge un format d'échantillon de média spécifique. Vous pouvez facilement le confirmer en ajoutant un EventLogger en tant qu'écouteur pour votre lecteur et qui recherche une ligne semblable à celui-ci dans Logcat:

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

NO_UNSUPPORTED_TYPE signifie que l'appareil n'est pas en mesure de décoder le contenu multimédia format d'échantillon spécifié par mimeType. Voir les formats multimédias Android documentation pour en savoir plus sur les formats d'échantillon compatibles. Comment obtenir une bibliothèque de décodage à charger et à utiliser pour la lecture.

Comment obtenir une bibliothèque de décodage à charger et à utiliser pour la lecture ?

  • La plupart des bibliothèques de décodeur comportent des étapes manuelles pour extraire et créer les dépendances. assurez-vous d'avoir suivi les étapes décrites dans le fichier README de la bibliothèque concernée. Par exemple, pour la bibliothèque FFmpeg d'ExoPlayer, il est nécessaire de suivre des instructions dans bibliothèques/decoder_ffmpeg/README.md, y compris la transmission options de configuration permettant d'activer les décodeurs pour tous les formats que vous souhaitez lire.
  • Pour les bibliothèques comportant du code natif, assurez-vous d'utiliser la bonne d'Android NDK comme spécifié dans le fichier README, et recherchez les éventuelles des erreurs qui apparaissent lors de la configuration et de la compilation. .so devrait s'afficher. apparaissent dans le sous-répertoire libs du chemin d'accès à la bibliothèque pour chaque architecture prise en charge après avoir suivi les étapes décrites dans le fichier README.
  • Pour tester la lecture avec la bibliothèque de l'application de démonstration, consultez en activant les décodeurs groupés. Consultez le fichier README de la bibliothèque pour les instructions d'utilisation de la bibliothèque à partir de votre propre application.
  • Si vous utilisez DefaultRenderersFactory, vous devriez voir une ligne de journal telle que "Loaded FfmpegAudioRenderer" dans Logcat lorsque le décodeur est chargé. Si ce n'est pas le cas, assurez-vous que l'application dépend du bibliothèque de décodage.
  • Si vous voyez des journaux au niveau d'avertissement de LibraryLoader dans Logcat, indique que le chargement du composant natif de la bibliothèque a échoué. Si cette se produit, vérifiez que vous avez correctement suivi les étapes décrites dans le fichier README de la bibliothèque. et qu'aucune erreur ne s'est produite en suivant les instructions.

Si vous rencontrez toujours des problèmes lors de l'utilisation des bibliothèques de décodage, veuillez consulter le Issue Tracker de Media3 pour tous les problèmes récents pertinents. Si vous devez signaler un nouveau problème lié à la création de la partie native de la bibliothèque, inclure le résultat complet de la ligne de commande à partir des instructions d'exécution du fichier README, afin de nous aider pour diagnostiquer le problème.

Puis-je lire des vidéos YouTube directement avec ExoPlayer ?

Non, ExoPlayer ne peut pas lire de vidéos YouTube, comme les URL au format suivant : https://www.youtube.com/watch?v=... Utilisez plutôt la page YouTube API iFrame Player qui est le moyen officiel de lire des vidéos YouTube sur Android.

La lecture de la vidéo est saccadée

L'appareil risque de ne pas pouvoir décoder le contenu assez rapidement si, par exemple, le débit ou la résolution du contenu dépassent les capacités de l'appareil ; Vous aurez peut-être besoin d'utiliser du contenu de qualité inférieure pour obtenir de bonnes performances sur ces appareils.

La vidéo est saccadée sur un appareil exécutant une version d'Android d'Android 6.0 (niveau d'API 23) à Android 11 (niveau d'API 30) inclus en particulier si vous lisez des contenus protégés par DRM ou à fréquence d'images élevée, activer la mise en file d'attente asynchrone des tampons.

Erreurs lint de l'API instable

Media3 garantit la compatibilité binaire pour un sous-ensemble de la surface de l'API. La les parties qui ne garantissent pas la compatibilité binaire sont marquées avec @UnstableApi Pour que cette distinction soit claire, les utilisations de fichiers instables Les symboles d'API génèrent une erreur lint, sauf s'ils sont annotés avec @OptIn.

L'annotation @UnstableApi n'implique aucun élément concernant la qualité ou les performances d'une API, mais seulement le fait qu'elle n'est pas "figée" dans l'API.

Deux options s'offrent à vous pour gérer les erreurs lint d'API instables:

  • Passez à une API stable qui permet d'obtenir le même résultat.
  • Continuez à utiliser l'API instable et annotez l'utilisation avec @OptIn, comme présenté plus tard.
Ajouter l'annotation @OptIn

Android Studio peut vous aider à ajouter l'annotation:

<ph type="x-smartling-placeholder">
</ph> Capture d&#39;écran: comment ajouter l&#39;annotation Optin
Figure 2: Ajouter une annotation @androidx.annotations.OptIn avec Android Studio

Vous pouvez également annoter manuellement des sites d'utilisation spécifiques en Kotlin:

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

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

Également en Java:

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

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

Vous pouvez activer les packages entiers en ajoutant un fichier package-info.java:

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

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

Vous pouvez activer des projets entiers en supprimant l'erreur lint spécifique dans leur Fichier 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>

Il existe également une annotation kotlin.OptIn qui ne doit pas être utilisée. Il est important d'utiliser l'annotation androidx.annotation.OptIn.