Comment un décodeur démarre : de la mise sous tension à la première image

Un téléviseur moderne affiche une image deux ou trois secondes après la mise sous tension. Le décodeur branché dessus en prend parfois quarante. La comparaison est injuste, mais elle revient assez souvent pour valoir une réponse détaillée: ce délai n'est pas de la lenteur, c'est une chaîne de dépendances où chaque maillon existe pour une raison précise. En voici le parcours, du premier octet exécuté jusqu'à la première image décodée.

Le bootloader et la chaîne de confiance

À la mise sous tension, le processeur exécute un petit programme gravé en ROM, impossible à modifier après la fabrication. Son rôle est de charger l'étage suivant — le bootloader — et, avant de lui céder la main, de vérifier sa signature cryptographique. Ce bootloader vérifie à son tour la signature du noyau Linux, qui vérifie celle du système de fichiers. C'est ce qu'on appelle une chaîne de confiance: chaque étage refuse de démarrer l'étage suivant s'il n'a pas été signé par la bonne clé.

Cette vérification n'est pas une précaution optionnelle qu'on pourrait désactiver pour gagner quelques secondes. Un décodeur détient des secrets qui ne lui appartiennent pas: des clés de déchiffrement confiées par les diffuseurs de contenu, sous contrat. Si on pouvait remplacer le logiciel du boîtier par le sien, on pourrait extraire ces clés — et l'opérateur perdrait le droit de distribuer le contenu. La chaîne de confiance est une exigence contractuelle avant d'être une exigence technique.

Un système de fichiers vérifié n'est pas non plus un système de fichiers déjà lu. Sur un boîtier d'entrée de gamme, la mémoire flash est lente, et vérifier une image système de plusieurs centaines de mégaoctets prend un temps mesurable. C'est le premier poste de dépense du démarrage.

Le réseau avant tout le reste

Le noyau démarré, le boîtier n'est encore rien: c'est un ordinateur Linux sans identité et sans droits. Il lui faut le réseau, dans un ordre précis. Une adresse par DHCP. Un résolveur DNS pour joindre les services de l'opérateur par leur nom plutôt que par une adresse figée dans le firmware. Puis — et c'est l'étape que personne ne soupçonne — l'heure, par NTP.

L'horloge d'un décodeur est une dépendance de sécurité, pas un confort d'affichage. Un certificat TLS possède une date de début et une date de fin de validité; si le boîtier croit être en 1970, tout certificat qu'il rencontre est refusé et absolument aucune connexion sécurisée n'aboutit. Les licences DRM portent elles aussi une fenêtre temporelle. Une bonne partie des pannes de démarrage les plus déroutantes en intégration se ramènent, après enquête, à une horloge fausse: rien ne fonctionne, et aucun message d'erreur ne parle d'heure.

C'est aussi pour ça que les décodeurs conservent rarement l'heure sur une pile comme le faisait un magnétoscope. On préfère la redemander au réseau à chaque démarrage: une heure garantie fraîche vaut mieux qu'une heure locale qui a pu dériver.

L'autorisation: qui es-tu, et à quoi as-tu droit

Le boîtier peut maintenant se présenter au back-office de l'opérateur. Il transmet son identifiant matériel, reçoit en retour son profil: à quel compte d'abonné il est rattaché, quelles chaînes ce compte a le droit de recevoir, quelles fonctions sont activées, quelle version de logiciel il devrait exécuter.

C'est ici que se décide une mise à jour éventuelle. Si le profil indique une version plus récente que celle installée, le boîtier télécharge et applique la mise à jour — ce qui explique les démarrages occasionnels beaucoup plus longs que la normale, avec une barre de progression que l'abonné n'avait pas demandée. Les opérateurs déploient généralement ces mises à jour la nuit, par vagues, précisément pour éviter que ça arrive à l'heure du souper.

Le profil d'autorisation est aussi ce qui permet de désactiver un boîtier à distance quand un abonné résilie. Le matériel reste fonctionnel; il ne reçoit simplement plus de droits.

Le middleware et l'interface

Vient ensuite la couche que l'abonné identifie comme «le décodeur»: le middleware. C'est lui qui orchestre tout ce qui est visible — le guide de programmation, la navigation, les menus, l'écran d'accueil, les applications. Sur les plateformes modernes, cette couche est souvent une application web qui s'exécute dans un moteur de rendu embarqué, ce qui simplifie énormément le développement mais ajoute son propre temps d'initialisation.

Le middleware doit aussi peupler ses données avant d'être utilisable. Un guide de programmation vide n'est pas un guide: il faut récupérer les métadonnées des prochaines heures, au minimum, avant que l'écran d'accueil ait quoi que ce soit à montrer. Sur un boîtier qui n'a pas démarré depuis des jours, ce rattrapage est substantiel.

Le premier accord

Reste à afficher de la vidéo, et là le chemin diverge selon la technologie de distribution.

En QAM, le décodeur accorde son tuner sur la fréquence porteuse de la chaîne, verrouille le signal, démodule, extrait le flux de transport, puis désembrouille à l'aide des droits obtenus à l'étape d'autorisation. Enfin, il attend la prochaine image de référence — une image complète, autonome, par opposition aux images intermédiaires qui ne décrivent que les différences. C'est cette attente qui crée le petit délai résiduel à chaque changement de chaîne, bien après que le démarrage soit terminé.

En IPTV, la séquence est différente mais l'idée finale est la même. Pour un flux linéaire en multicast, le boîtier émet une demande d'adhésion au groupe, le réseau lui achemine le flux, il remplit un tampon, puis décode. Pour de la vidéo à la demande en diffusion adaptative, il télécharge d'abord un manifeste décrivant les qualités disponibles, choisit un débit de départ, télécharge un premier segment, obtient sa licence DRM, et décode. Dans les deux cas il faut accumuler quelques secondes d'avance avant d'afficher: c'est ce tampon qui absorbera les irrégularités du réseau ensuite.

Pourquoi le démarrage à froid est devenu rare

Tout ce qui précède décrit un démarrage complet. Dans la vraie vie, il ne se produit presque jamais, parce que le bouton d'alimentation d'un décodeur n'éteint pas le décodeur. Il le met en veille: le processeur ralentit, la sortie vidéo se coupe, mais le réseau reste actif, l'horloge reste juste, le profil reste chargé et les métadonnées continuent de se rafraîchir. Le retour est alors quasi immédiat.

Ce compromis a un coût électrique, et il est encadré. Les normes de consommation en veille poussent dans la direction opposée — éteindre le plus de composants possible — pendant que l'expérience utilisateur exige un réveil instantané. Les modes de veille intermédiaires des décodeurs récents sont exactement la négociation entre ces deux pressions. Débrancher physiquement le boîtier annule ce compromis: on recommence la chaîne complète, du premier octet en ROM jusqu'à la première image.

C'est la conclusion que je retiens après des années à déboguer des séquences de démarrage: chaque seconde du parcours correspond à une dépendance qu'on a volontairement acceptée — la sécurité, l'heure, l'autorisation, les métadonnées. On peut en optimiser l'exécution, rarement en supprimer une.