Nous nous efforçons d'améliorer la lecture HLS dans le lecteur Brightcove, de la rendre plus rapide et plus stable. Pour ce faire, nous avons dû abandonner nos hypothèses et commencer à examiner le problème auquel nous étions confrontés sans aucune idée préconçue.
LE DÉFI
L'une des principales responsabilités de tout moteur de lecture exploitant les extensions de source multimédia (MSE) est de décider quelles données vidéo (appelées segments ou fragments) doivent être demandées au serveur à un moment donné.
Avec les sources HLS de vidéo à la demande (VOD), les décisions sont assez simples. Nous connaissons tous les segments et (grosso modo) leur durée. Le choix du segment à télécharger en fonction de ces informations est simple.
Malheureusement, les choses ne sont pas si simples dans un flux HLS en direct. Non seulement nous ne disposons pas de l'historique complet des segments, mais sans les PROGRAM-DATETIME dans HLS (un ajout récent à la spécification HLS), nous n'avons pas non plus de moyen facile de corréler les segments entre les différentes listes de lecture. La seule option laissée au lecteur est de télécharger spéculativement des segments afin d'utiliser les horodatages internes du média.
En résumé, le problème de la lecture en direct est qu'il arrive que les nombreuses "inconnues" rendent difficile la sélection du bon segment la première fois.
ALGORITHME DE RECHERCHE
Pour lutter contre la tendance de tout algorithme de recherche à sélectionner le mauvais segment, nous avons emprunté certains concepts à la théorie du contrôle. Auparavant, l'algorithme de récupération.. :
- Faire la meilleure supposition possible compte tenu des informations limitées
- Si la supposition est erronée, utiliser les informations obtenues à partir de cette demande pour faire une meilleure supposition (réduire l'"erreur").
- Répéter
L'espoir était que l'algorithme s'améliore de manière itérative et finisse par télécharger le segment correct. Le problème survient lorsque l'on commence à se demander ce qu'est une "erreur". Pour notre algorithme, nous avons défini l'erreur comme une région de la mémoire tampon vidéo à laquelle il manque des données.
L'idée est que si nous avons récupéré le segment A suivi du segment C, nous aurons créé un vide de la taille du segment B qui devra être comblé. L'algorithme devrait alors revenir en arrière pour combler cette erreur et sélectionner le segment B avant de continuer vers D.
La bonne nouvelle, c'est que 99 % du temps, cela fonctionnait et fonctionnait très bien. La mauvaise nouvelle, c'est que dans 1% des cas, le système se bloque en essayant de combler un vide qui ne peut pas l'être. Lorsque cela se produisait, c'était généralement dû à la nature des sources que nous jouions. Certaines sources HLS sont mal segmentées, de sorte que l'audio et la vidéo ne sont pas segmentés au même moment dans toutes les variantes, ce qui entraîne des lacunes. Certaines sources HLS ont des images (audio ou vidéo) corrompues ou manquantes, ce qui entraîne également des lacunes.
Quelle qu'en soit la cause, ces parties non remplissables du tampon créaient des situations où l'algorithme était bloqué en essayant de le remplir. Nous avons finalement intégré de nombreuses approches pour tenter d'empêcher l'algorithme de se bloquer :
- Considérer les très petites lacunes comme quelque chose d'intrinsèque à la source et les ignorer.
- Forcer l'algorithme à récupérer un ou plusieurs segments en avant s'il a déjà essayé de récupérer le même segment que lors de la dernière itération.
- considérer comme chargés les segments dont les limites sont représentées à 90 % ou plus dans la mémoire tampon, afin d'éviter de gaspiller de la bande passante inutilement
Le problème de chacune de ces stratégies est qu'elles s'effondrent dans des circonstances très spécifiques. Avec chaque "correction", nous avons tenté de multiplier le nombre de cas particuliers. Dans de nombreux cas, nous avons découvert que même de petites modifications de l'algorithme de récupération échouaient dans des scénarios étranges qui fonctionnaient auparavant.
DÉCOUVERTE FRAÎCHE
Tous ces problèmes nous ont amenés à une conclusion inéluctable : Nous devions modifier radicalement notre approche. En examinant le problème, nous avons réalisé que nous avions beaucoup d'hypothèses sur la façon dont l'algorithme de récupération devait fonctionner, ce qui nous compliquait la tâche.
L'une de ces hypothèses était que l'algorithme de récupération devait toujours éviter de demander des segments déjà mis en mémoire tampon. Le problème est qu'il est très difficile de raisonner sur l'état de la mémoire tampon une fois que l'on combine les effets de la recherche, de la collecte des déchets de la mémoire tampon (ce que MSE fait automatiquement dans les coulisses) et des sources qui introduisent naturellement des lacunes. En fin de compte, notre algorithme était inextricablement dépendant de la mémoire tampon de MSE, qui changeait constamment.
Le nouveau récupérateur supprime cette hypothèse et beaucoup d'autres afin de simplifier les choses autant que possible. Par exemple, le joueur nettoie maintenant la mémoire tampon après chaque recherche afin que l'état de la mémoire tampon soit plus facile à raisonner et qu'il n'essaie pas de se prémunir contre le chargement d'un segment déjà présent dans la mémoire tampon.
LA MARCHE À PIED
Après avoir réexaminé nos hypothèses, nous avons réalisé qu'il était impossible d'obtenir une estimation précise dans 100 % des cas, mais qu'il était tout à fait possible d'obtenir une estimation prudente dans 100 % des cas. Une estimation prudente est une estimation qui correspond au segment situé avant ou après le segment souhaité. Une estimation prudente signifie que vous pouvez toujours trouver le bon segment en avançant simplement dans les segments d'une liste de lecture.
Grâce à cette compréhension, nous changeons radicalement la nature du problème. Désormais, nous récupérons toujours des régions contiguës après avoir fait une première supposition. Cela signifie que les détails concernant l'état de la mémoire tampon - les lacunes - ne nous concernent plus puisqu'ils sont, par définition, intrinsèques au support et ne sont pas dus au comportement de l'algorithme de récupération.
La seule question qui restait était de savoir comment corréler les segments et les durées entre les variantes d'une liste de lecture en direct. Pour ce faire, nous avons introduit le concept de "point de synchronisation". Un point de synchronisation est défini comme une correspondance connue entre un index de segment et un temps d'affichage - le temps que vous obtenez en appelant player.currentTime().
Le nouvel algorithme de recherche ne comporte que trois modes de fonctionnement :
- Estimation prudente du segment à partir duquel le téléchargement doit commencer
- Avancer simplement dans la liste de lecture
- Tentative de création d'un point de synchronisation
Ce dernier état n'est jamais atteint que lorsque l'extracteur ne peut utiliser aucune des informations qu'il a sauvegardées pour faire une supposition. C'est un événement rare, mais lorsque cela se produit, nous devons télécharger un segment - n'importe quel segment - et utiliser les horodatages internes du média pour générer un "point de synchronisation" que l'algorithme de récupération peut ensuite utiliser pour faire une supposition prudente avant d'aller de l'avant.
Le résultat final de ces changements est une expérience de lecture HLS améliorée. La lecture en direct, en particulier, devrait démarrer plus rapidement et être plus fiable.
