Corriger la mise en mémoire tampon et les saccades : une liste de contrôle qui commence par la bonne question

La plupart des conseils sur la mise en mémoire tampon commencent par « vérifiez votre connexion internet ». Vous l’avez déjà fait. Le meilleur premier geste consiste à déterminer laquelle de plusieurs pannes vous avez, parce que chacune a un correctif différent et que l’application l’a déjà classée pour vous.

Neuf pannes, pas une#

Le lecteur n’a aucune notion unique de « ne fonctionne pas ». Il classe les défauts en 9 catégories, et la catégorie décide quelle récupération s’exécute :

F1  NetStall      no bytes arriving at all
F2  SilentEof     the stream ended without you asking
F3  HardError     the stream would not open
F4  DemuxStarve   bytes arriving, no frames coming out
F5  VideoFreeze   picture stopped, audio still playing
F6  TotalFreeze   both stopped, data still flowing
F7  BlackFrames   everything healthy, picture is black
F8  ClockStall    the input clock stopped advancing
F9  RebufferLoop  repeated rebuffering in a rolling window

Ce sont des problèmes différents. F1, c’est votre réseau ou celui du fournisseur. F4, c’est un flux qui envoie du remplissage au lieu de vidéo, un problème de fournisseur que votre connexion ne peut pas corriger. F7, c’est généralement la source qui diffuse du noir, ce qu’aucun redémarrage ne résoudra.

Rien n’est déclaré instantanément. Un défaut doit d’abord persister pendant une fenêtre : 4 secondes sans aucun octet, 6 secondes de démultiplexeur affamé, 4 secondes de vidéo bloquée, 4 secondes de gel total. Ces fenêtres existent parce qu’un à-coup de 2 secondes n’est pas un défaut. Un lecteur qui réagirait à chacun passerait la soirée à redémarrer un flux qui allait se rétablir.

Ce que le lecteur fait déjà avant que vous n’interveniez#

Trois choses, pour que vous ne les refassiez pas en double.

Il adapte ses propres tampons. Quand la remise en tampon se répète, le lecteur relève son plancher de cache de 1000 millisecondes par verdict, jusqu’à 5000. Sur une connexion limite, l’application s’est probablement déjà accordé plus de tampon que les 1200 millisecondes de cache réseau et les 800 de cache direct avec lesquelles elle démarre. Monter un réglage de tampon à la main refait souvent un travail déjà accompli.

Il est aussi prudent sur ce qui compte comme remise en tampon. Un épisode n’est compté que lorsque le cache descend sous 62 pour cent, et il se termine à 88. Cette hystérésis existe parce que les lectures de cache du HLS en direct oscillent aux frontières de segments, et que compter chaque baisse sous le plein signalerait des flux sains comme cassés.

Et il attrape la panne qui ne produit aucune erreur, ce qui fait de « ça reste planté là » une vraie catégorie. Un flux peut cesser d’émettre tout en laissant sa socket ouverte. Nous l’avons testé sur un banc d’injection de pannes et le résultat était sans ambiguïté : le delta du compteur d’octets tombe à 0 et il n’y a aucun événement du lecteur. Rien ne signale d’erreur. Rien ne lève d’exception. L’image reste sur la dernière trame qu’elle avait.

C’est pourquoi la détection est un minuteur qui surveille des compteurs plutôt qu’un gestionnaire d’erreur, et pourquoi il y a une attente de 4 secondes avant que quoi que ce soit ne se produise. Si votre flux se fige et repart quelques secondes plus tard, vous avez vu ce mécanisme à l’œuvre.

Je ne m’attendais pas à ce que le côté nouvelle tentative soit le plus grand levier. Avec les deux délais de grâce de connexion à 8 secondes, un blocage total des octets passait 8 de ses 15.7 secondes à redémarrer une URL encore morte. Raccourcir le délai de grâce de la nouvelle tentative à 4 secondes, les mêmes 4 secondes sans octet déjà jugées suffisantes pour condamner un flux établi, a été la plus grande amélioration du temps mesuré entre défaut et bascule. L’échelle n’autorise aussi qu’exactement 1 redémarrage avant de changer de source, parce que les données de terrain ont montré qu’un second redémarrage d’une source morte n’aide jamais.

La liste de contrôle, dans l’ordre qui trouve le plus vite#

1. Est-ce une chaîne ou toutes ? Une seule chaîne, c’est un problème de source et aucun réglage sur votre machine ne le corrigera. Si votre fournisseur propose la même chaîne dans une autre qualité ou depuis un autre serveur, essayez-la. Toutes les chaînes, c’est de votre côté.

2. Est-ce en filaire ou en sans fil ? C’est la question la plus productive de toutes. Un flux en direct est une lecture continue en temps réel, et un sans fil limite produit exactement le symptôme que les gens attribuent au lecteur. Essayez un câble une fois, purement à titre de diagnostic.

3. La même chaîne se lit-elle sur un autre appareil du même réseau ? Si elle se lit sur un téléphone et pas sur le PC, vous avez circonscrit le problème à la machine. Si elle échoue sur les deux, vous l’avez circonscrit au réseau ou au fournisseur.

4. Êtes-vous à votre limite de connexions ? Deux connexions et trois appareils, c’est une saccade qui ressemble à un manque de bande passante et n’en est pas un. Connexions maximales explique pourquoi une connexion peut rester consommée après que vous avez arrêté de regarder.

5. L’image s’arrête-t-elle vraiment, ou est-ce du judder ? Une saccade régulière et rythmique sur les panoramiques est généralement un décalage de fréquence de rafraîchissement : du contenu 50 Hz sur un écran 60 Hz. C’est un réglage d’affichage, pas un problème de tampon, et aucune quantité de cache n’y changera rien. Brancher un portable au téléviseur en HDMI traite le sujet.

Si vous utilisez un proxy ou un VPN dans l’application#

Un comportement à prévoir. Quand un profil de connexion est configuré, un média que le transport ne peut pas acheminer échoue de manière fermée plutôt que de se rabattre discrètement sur une connexion directe. C’est délibéré. Un réglage de confidentialité qui cesse de s’appliquer en silence est pire qu’un réglage qui cesse de fonctionner visiblement.

Donc une chaîne qui fonctionnait avant la configuration d’un profil et échoue après n’est pas forcément un profil cassé. Ce peut être un flux dont le schéma ne peut pas être acheminé par le relais, et qui refuse de fuir. C’est le profil qui fonctionne. VPN et performance des flux explique ce qui compte vraiment à ce sujet.

Si l’image est figée mais que le son continue, c’est précisément F5 et cela a son propre article : la vidéo se fige, le son continue pour le mécanisme, et du son mais pas d’image pour ce qu’il faut faire.