[Netease Yunxin] Analyse et expérience pratique des problèmes courants du côté de la lecture des scènes de diffusion en direct

Processus de lecture commun

 

Analyse du processus principal du joueur

Le processus de lecture du lecteur est similaire au processus de diffusion en continu, mais l'ordre est inversé. Le terminal de streaming collecte d'abord l'audio et la vidéo, encode et encapsule l'audio et la vidéo, et les traite selon le protocole multimédia de streaming pour finalement obtenir le flux de sortie. Le lecteur analyse et décapsule le flux d'entrée pour obtenir des paquets audio (tels que AAC) et des paquets vidéo (tels que H.264, H.265), et les décode pour obtenir une trame audio PCM et une trame vidéo YUV. Enfin, le lecteur doit rendre et lire la vidéo et l'audio via le module de synchronisation audio et vidéo, et enfin le présenter à l'utilisateur.

À partir de l'analyse du modèle de thread, le thread central du moteur de lecture peut généralement être divisé en " thread de décapsulation (thread de lecture) ", " thread de décodage audio/vidéo " et " thread de lecture audio/vidéo ". est meilleur pour le moteur de lecture et les applications de la couche supérieure. Avec la coopération, le moteur de lecture maintient généralement un "fil de message" pour signaler à la couche supérieure tel que "le code d'erreur d'échec de lecture, le temps de lecture de la première image vidéo/audio, les données statistiques pendant lecture (comme la première image longue, le taux de code audio/vidéo, le nombre d'images de réception audio et vidéo/seconde, le nombre d'images de décodage audio et vidéo/seconde, le nombre d'images de lecture audio et vidéo/seconde, les temps de gel de lecture, la durée de gel de lecture , différence d'horloge de synchronisation audio et vidéo, etc.)".

On peut voir à partir du modèle de thread que les threads centraux du moteur de lecture sont un modèle producteur-consommateur très important. Ce modèle peut utiliser efficacement les avantages du parallélisme multicœur du processeur et, grâce à une gestion raisonnable du tampon multimédia, il peut résister dans une certaine mesure à la gigue du réseau et du décodage et éviter les blocages fréquents.

Les problèmes courants pendant le processus de lecture se concentrent principalement sur des problèmes tels que l'incapacité de jouer, pas de son ou d'image, écran flou, gel et retard élevé . Habituellement, le lien de dépannage est effectué à l'envers par le côté lecture. Ci-dessous, nous analyserons certains problèmes courants lors de la lecture de flux en direct sur la base de certains cas que nous avons accumulés dans notre travail.

La résolution est trop petite pour provoquer une panne de décodage matériel

Phénomène : Retour de clients selon lequel lors de la diffusion en direct, l'écran se fige soudainement, mais le son est normal.

Analyse : grâce à l'analyse du journal de lecture et du vidage du flux vidéo, nous avons constaté que lorsque le problème s'est produit, le lecteur utilisait le décodage matériel Android et que la résolution du flux vidéo extrait avait changé (1080p -> 16p). Nous avons verrouillé le problème. en consultant les données La cause principale est que le codec MediaCodec d'Android prend en charge une gamme de résolutions qui varient d'un appareil à l'autre. Vous pouvez l'afficher en affichant /vendor/etc/media_codecs_xxx.xml dans l'appareil, tel que media_codecs_mediatek_video.xml de l'appareil "M2006C3LC". La description de décodage de H264 est comme indiqué dans la figure ci-dessous. La résolution prise en charge par le "OMX .MTK.VIDEO.DECODER.AVC" La plage est (64*64) - (2048*1088), il peut donc y avoir des problèmes imprévisibles lors de l'analyse de vidéos avec une résolution de 16*16.

 

Expérience pratique : capacités matérielles Android pour l'adaptation

1.  Par rapport aux appareils IOS, les appareils Android sont plus fragmentés . L'adaptation aux différentes capacités de différents modèles peut réduire considérablement les problèmes similaires ci-dessus. Heureusement, l'interface MediaCodec fournit aux développeurs une interface de requête de capacité relativement complète, comme certaines interfaces fournies dans MediaCodecInfo.VideoCapabilities :

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

Cette partie de l'interface fournie par MediaCodec peut nous aider à mieux choisir d'utiliser un décodeur matériel ou un décodeur logiciel en fonction de la capacité de l'appareil lors de l'initialisation du codec/décodeur, et d'éviter autant que possible les échecs de décodage et les replis causés par les problèmes de capacité de l'appareil. . Pour le côté encodage, cela inclut principalement si MediaFormat est pris en charge, si Profile/Level est pris en charge, si la résolution d'encodage est prise en charge, si le débit binaire d'encodage est pris en charge, si la fréquence d'images d'encodage est prise en charge, si le nombre d'instances d'encodage dépasse la plage maximale prise en charge, etc. La fin de décodage est similaire à la fin de codage.

2. Maintenir une liste noire : l'activation de l'encodage/décodage du matériel vidéo peut réduire la charge du processeur dans une certaine mesure et améliorer les performances vidéo. Cependant, en raison de la grave fragmentation d'Android, de nombreuses capacités d'encodage et de décodage de MediaCodec sont mises en œuvre par les fabricants d'appareils. Il Il est difficile d'obtenir une cohérence dans les performances. D'après nos cas précédents, nous pouvons constater que les capacités matérielles d'encodage et de décodage de certains modèles sont très médiocres et que la cause profonde des mauvaises performances est introuvable. Nous pouvons donc choisir d'utiliser une liste noire. pour la maintenance.

3. Améliorez le mécanisme de solution logicielle de repli du décodage matériel : des problèmes de décodage matériel relativement courants tels que le décodage matériel prend beaucoup de temps, les erreurs d'API de décodage matériel, etc. Les erreurs signalées par l'appel d'interface MediaCodec sont généralement relativement faciles à capturer, et vous pouvez utiliser les informations d'erreur capturées Effectuer une discrimination, annuler le traitement de décodage logiciel pour les erreurs clés ou signaler à la couche application pour traitement, mais aucune erreur n'est signalée dans l'appel d'interface, mais le problème du long temps de décodage affectera toujours considérablement l'expérience utilisateur , donc en cas de temps de décodage excessif, il est également nécessaire de revenir en arrière et de signaler à la couche application.

Le problème de flou d'écran causé par une mise à jour incorrecte des paramètres sps/pps

Phénomène : Lors du test de notre projet, nous avons rencontré le problème de décodage matériel d'écran flou dans des scènes telles que pk.

Analyse : après nos tests, nous avons constaté que la solution logicielle ne provoque pas d'écran flou, mais que le décodage matériel provoque un écran flou. En utilisant ffmpeg dump pour analyser les données du flux de code de l'extrémité réceptrice, nous avons constaté que lorsque l'écran flou se produit , le sps/pps de la vidéo a changé et le problème est très grave. Il est clair qu'il s'agit d'un problème d'écran flou de décodage typique causé par une mise à jour incorrecte du sps/pps.

Expérience pratique : dans des circonstances normales, le sps/pps ne change généralement pas lors d'une seule poussée de flux stable. Généralement, lorsque la résolution vidéo change, le moteur de lecture ijk d'origine se trouve dans le module de décodage matériel. Prend en charge les mises à jour sps/pps lors du changement de résolution . Cependant, le métier de certains terminaux de streaming peut être plus compliqué, impliquant des commutations dynamiques d'encodeurs, etc., ce qui entraînera également des changements de sps/pps lorsque la résolution reste inchangée. Par conséquent, du point de vue de la polyvalence, chaque fois que les informations d'en-tête vidéo sont reçues, elles doivent être comparées aux informations d'en-tête vidéo actuelles et mises à jour à temps lorsque des changements se produisent, pour éviter des problèmes tels que des écrans flous.

Problèmes d'écran flou causés par des images clés manquantes et des images de référence manquantes

Phénomène : L'écran est flou et récupère après un certain temps.

Analyse : grâce à l'analyse du vidage du flux de code, nous avons constaté qu'il n'y avait aucun problème avec le flux de code. Plus tard, grâce à l'analyse du journal, nous avons identifié la cause première du problème : "L'écran de décodage est flou en raison du perte du référentiel" .

Expérience pratique : les problèmes de Huaping surviennent souvent dans des scènes telles que des images clés manquantes et des images de référence manquantes. À tout moment, après l'encodage et avant le décodage, il n'est pas recommandé de supprimer les images vidéo, sinon cela pourrait entraîner des problèmes d'écran flou à la fin du décodage. Dans la scène de diffusion en direct, afin d'éliminer le retard accumulé, certains joueurs choisiront d'éliminer certaines images non décodées dans le tampon d'images. Dans ce cas, une stratégie plus raisonnable consiste à éliminer un GOP entier ou à utiliser la double vitesse. La méthode de lecture est utilisée pour rattraper le retard, et la stratégie à double vitesse est arrêtée lorsque le retard répond aux exigences de la diffusion en direct. De plus, afin d'éviter autant que possible les problèmes d'écran flou causés par de tels problèmes, la détection d'image clé doit être effectuée dans des scénarios tels que la première diffusion, la déconnexion et la reconnexion du réseau, et le décodage doit commencer à partir de l'image clé.

Problèmes de lecture inattendus causés par la commutation des opérations audio et vidéo du côté du streaming

Phénomène : pendant le test du projet, l'audio et la vidéo à la fin de la lecture ont soudainement cessé de jouer.

Analyse : en analysant le flux de code à l'extrémité de réception, nous avons constaté que le flux multimédia audio s'est soudainement arrêté pendant la diffusion en direct. Après enquête, nous avons constaté que l'extrémité de diffusion prend en charge la fonction d'arrêt dynamique des flux multimédia audio/vidéo. Cette fonction entraînera une interruption soudaine du flux multimédia audio ou vidéo de l'extrémité réceptrice et entrera en conflit avec la logique existante de l'extrémité de lecture, ce qui entraînera des problèmes imprévisibles.

Expérience pratique : Si la fin du streaming prend en charge la fermeture dynamique des flux audio et vidéo, il est relativement difficile d'adapter le lecteur. Généralement, les scénarios qui doivent être adaptés incluent, mais ne sont pas limités à : "Scène audio suivie de vidéo" , Scénarios tels que "L'audio d'abord suivi de la vidéo" , "Interruption soudaine du flux vidéo" , "Interruption soudaine du flux audio" et d'autres scénarios. Il est relativement plus facile pour le côté lecture de s'adapter aux scénarios où les flux audio et vidéo augmentent. Il suffit de détecter dynamiquement le nombre de flux multimédias dans le module de désencapsulation pour déterminer si de nouveaux flux sont ajoutés. Cependant, pour les scénarios où l'audio/ les flux de médias vidéo sont soudainement interrompus Il est très difficile à adapter. D'une part, en tant que moteur de lecture général, il n'interagit pas avec la logique de signalisation de la fin du streaming. D'autre part, la scène peut avoir de nombreuses logiques communes avec le lecteur, tels que la synchronisation audio et vidéo (audio synchrone vidéo, audio vidéo synchrone), la logique de mise en mémoire tampon, etc. ont de graves conflits et causent des problèmes. Par exemple, la stratégie de synchronisation par défaut de la fin de lecture générale est l'audio synchrone vidéo, mais lorsque le flux audio est soudainement interrompu, nous devons percevoir que le flux audio sur le bouton poussoir s'est arrêté. Fermez et ajustez la stratégie de synchronisation audio et vidéo du lecteur. Par conséquent, il est difficile d'être compatible avec ces scènes du point de vue du lecteur, mais du point de vue de la diffusion en continu, vous pouvez choisir d'ajouter des images silencieuses/des données vidéo fakeVideo lorsque le flux multimédia audio/vidéo est fermé, de sorte que le flux multimédia peut être garanti.La continuité, de sorte qu'il est compatible avec la plupart des lecteurs du côté du streaming.

De plus, nous avons également constaté dans la pratique que dans le scénario où les flux audio/vidéo sont dynamiquement activés et désactivés à la fin de la diffusion, même si la fin de la lecture est compatible, que le serveur ou le fabricant du CDN le prenne en charge sera une grande question. marque, en particulier dans l'application Dans le scénario où le protocole hls tire des flux, car par rapport à d'autres protocoles de streaming, le protocole hls implique également une logique de découpage côté serveur, et il est probable que la logique de découpage hls du serveur ou du fabricant du CDN n'est pas compatible avec l'opération de commutation audio et vidéo.

 

Impossible de décoder la vidéo ou l'audio en raison d'un en-tête audio/vidéo manquant

Phénomène : commentaires des clients selon lesquels un certain flux vidéo peut être extrait via rtmp, mais ne peut pas être extrait via hls.

Analyse : en obtenant l'adresse de flux source du client, testez les performances des flux rtmp et hls via ffplay respectivement. Parmi eux, le flux hls n'a pas de son et aucune information audio n'a été analysée. L'analyse du flux de code du flux rtmp Dump On peut voir que bien que l'audio puisse être lu normalement, les informations d'en-tête audio sont manquantes.

 

Expérience pratique : le problème causé par le manque d'en-têtes vidéo/audio ne peut pas être résolu par l'adaptation de la fin de lecture, et le problème peut être caché et difficile à trouver. La fin de diffusion doit vérifier si elle est correcte dans chaque cas de en-têtes de prononciation/vidéo Les informations d'en-tête audio et d'en-tête vidéo sont envoyées, telles que les modifications de configuration audio et vidéo, la déconnexion et la reconnexion du réseau, la retransmission et d'autres scénarios.

Exception de lecture causée par des horodatages discontinus

Phénomène : L'audio et la vidéo ne sont pas synchronisés ou sont bloqués.

Analyse : Les anomalies d'horodatage peuvent être grossièrement divisées en deux catégories. La première catégorie est que les horodatages audio et vidéo ne sont pas synchronisés, c'est-à-dire que la plage est grande. La deuxième catégorie est le problème de retour en arrière des horodatages audio et vidéo, tels que dts /pts repartant soudainement de 0. Dans des circonstances normales, afin d'éviter de telles situations telles que le blocage lorsque de telles anomalies se produisent, la fin du streaming sera compatible avec des scénarios avec des horodatages discontinus. La solution générale peut inclure la suppression d'images ou l'abandon de la stratégie de synchronisation d'horloge d'origine en fonction de leur lecture respective. Bien que cette solution puisse continuer à jouer lorsque les horodatages audio et vidéo sont anormaux, cela peut entraîner des problèmes tels que l'audio et la vidéo désynchronisés et des blocages.

Expérience pratique : le côté lecture de ce problème peut être compatible dans une certaine mesure, mais la cause première est que le côté diffusion doit assurer la synchronisation des horodatages audio et vidéo.

Outils couramment utilisés pour analyser les problèmes

• ffmpeg, ffplay, flux de code ffprobe Dump/stream lecture multimédia/afficher les informations multimédias, etc.

• L'analyseur elecard analyse le contenu du flux de code.

• mediaInfo Analyse du format d'information des fichiers multimédias.

• flvAnalyser analyse les informations d'encapsulation au format FLV.

• YUV Eye lit les données YUV.