Diagnostic de lecture vidéo : trouver l'étape qui a échoué

L'ordre compte, parce que chaque étape dépend de la précédente. Un conteneur qui ne peut pas être identifié signifie que rien en aval ne s'exécute, ce qui explique qu'un fichier impossible à ouvrir ne produise aucun symptôme autre qu'un message d'erreur. Une fois le conteneur ouvert, le séparateur isole les pistes, et à partir de là les branches vidéo et audio échouent indépendamment. Cette indépendance est tout l'intérêt du tri : un silence avec une image correcte et une image noire avec un son correct sont la même panne sur deux branches différentes.

La quatrième étape se comporte encore autrement. Le rendu reçoit des images et des échantillons déjà décodés, donc lorsqu'il échoue, le décodage a réussi et aucun codec ne changera le résultat. La saccade et les sous-titres absents relèvent tous deux de cette étape, ce qui explique qu'ils survivent si souvent à une installation censée les corriger.

Rien dans cet index n'exige un assortiment. La réponse historique à ces trois symptômes consistait à installer un pack de codecs en espérant que cela suffise, et cela fonctionnait assez souvent pour devenir une habitude. Lire le symptôme d'abord remplace l'espoir, et le plus souvent remplace aussi l'installation.

Reste une catégorie de fichiers qui n'a rien à voir avec la vidéo et qui aboutit ici par proximité : les archives de bandes dessinées, dont l'ouverture obéit à une logique différente. Elles sont traitées séparément sur la fiche des fichiers CBR et CBZ, parce que le problème n'y est jamais un décodeur mais une compression et un tri de noms.

Une seule machine peut abriter plusieurs trajets de lecture entièrement distincts, et un fichier n'en emprunte jamais qu'un à la fois. Un lecteur construit autour du graphe de filtres du système demande à Windows quel composant traite un format, et hérite de ce qui se trouve enregistré. Un lecteur à décodage intégré ne demande rien : il transporte sa propre copie de la bibliothèque de décodage et l'utilise quel que soit le contenu du système. Ces deux conceptions produisent des résultats différents sur une entrée identique, ce qui fait de la phrase « cela se lit dans un programme et pas dans l'autre » un diagnostic plutôt qu'une plainte.

La conséquence pratique est qu'essayer un second lecteur est l'étape de diagnostic la moins coûteuse disponible, et qu'elle doit précéder toute installation. Un fichier qui se lit dans un lecteur autonome et échoue dans un lecteur passant par le système a un problème de chaîne, et cette chaîne peut être réparée ou contournée. Un fichier qui échoue dans les deux est soit endommagé, soit encodé avec quelque chose de réellement inhabituel, et aucune installation n'y changera rien.

Ce qui a changé depuis l'époque des assortiments

Deux évolutions ont retiré aux assortiments l'essentiel de leur raison d'être. Le décodage est passé à l'intérieur des lecteurs, si bien que le cas courant ne touche plus le système du tout. Et les nombreux petits composants qu'un lot réunissait ont été regroupés : là où un pack enregistrait un décodeur distinct pour chaque format et un séparateur par conteneur, un seul jeu de filtres couvre aujourd'hui le même terrain depuis une installation unique. Moins de composants enregistrés signifie moins de possibilités que deux d'entre eux revendiquent le même format, ce qui était précisément le mode de défaillance qui rendait ces lots risqués.

Ce qui n'a pas changé, c'est la séquence. Conteneur, séparateur, décodeur, rendu reste l'ordre des opérations, reste la raison pour laquelle un symptôme localise une panne, et reste le chemin le plus court entre « cela ne fonctionne pas » et une action précise à essayer. Les entrées ci-dessus sont cette séquence lue à l'envers depuis les indices disponibles, et c'est le sens de lecture qui fait gagner du temps.