Optimisation du logo de chaîne pour différentes résolutions vidéo

Le logo d'une chaîne FAST — la petite marque dans le coin — est la seule constante visuelle à travers chaque programme, chaque coupure publicitaire, tout élément diffusé par la chaîne. Il doit avoir l'air professionnel à chaque niveau de qualité qu'un spectateur peut recevoir. L'approche naïve — télécharger une image maître et laisser AWS MediaLive la redimensionner par rendu — produit un logo net en 1080p et visiblement flou en 360p. C'est un problème de marque pour chaque spectateur qui n'est pas sur une connexion haut débit. Voici comment nous avons plutôt dimensionné le logo selon la grille de pixels exacte de chaque rendu.

Aperçu rapide

Le problème métier

Une chaîne FAST ne délivre pas un seul niveau de qualité. MediaLive encode la même chaîne en plusieurs rendus — 1080p, 720p, 480p, 360p — et le lecteur de chaque spectateur choisit le meilleur que sa connexion peut supporter. Les spectateurs mobiles sur données cellulaires regardent en 360p ; les spectateurs sur smart TV et connexion haut débit obtiennent du 1080p. Ils regardent tous la même marque, et ils s'attendent tous à ce qu'elle ait l'air professionnelle. Lorsque le logo est net en 1080p et visiblement flou en 360p, la marque est incohérente — ce n'est pas un détail mineur sur une chaîne 24h/24 et 7j/7 où le logo est le seul élément que les spectateurs voient plus que n'importe quel programme.

Où les superpositions sont réellement appliquées

Dans un pipeline d'encodeur multi-rendu, une superposition peut être appliquée à deux endroits : 

Avant le scaler par rendu, où une image maître est composée sur la source et l'ensemble est redimensionné par sortie — c'est ce que MediaLive fait avec une action globale StaticImageActivate

 après le scaler, où chaque sortie reçoit sa propre superposition appliquée une fois que le canevas est déjà à sa taille finale. La différence semble minime dans l'API. Visuellement, ce n'est pas le cas. Tout ce qui est composé avant le scaler hérite de chaque artefact introduit par le scaler, et à 360p, le scaler est agressif.

Pourquoi les correctifs évidents échouent

« Télécharger une image maître et laisser MediaLive la redimensionner. » L'action globale compose l'image maître avant l'exécution du scaler par sortie. Une image maître de grande taille réduite à un logo de 64×21px pour 360p représente une réduction d'environ 40x — même le rééchantillonnage de Lanczos perd des détails fins à ce ratio, et le résultat passe ensuite par la même chaîne de compression que la vidéo elle-même.

« Utiliser une image maître plus grande. » Cela rend le ratio de réduction plus grand, pas plus petit — l'artefact s'aggrave, ne s'améliore pas.

« Ignorer le logo sur les sorties SD. » Les exigences de conformité et de marque nécessitent la présence de la marque sur chaque rendu. Pas une option.

« Graver le logo dans la vidéo source au moment de l'encodage. » Perd tout levier opérationnel — pas de changements de logo par campagne ou par région, et pas de mise à jour sans ré-encoder toute la bibliothèque.

« Utiliser une superposition globale avec des coordonnées manuelles par résolution. » L'action globale calcule la position par rapport à une référence fixe de 1920×1080, de sorte que les vidéos sources plus étroites produisent des coordonnées hors canevas — le logo dérive du coin ou est recadré.

Le vrai levier consistait à contourner entièrement le redimensionnement de la superposition de MediaLive : dimensionner nous-mêmes le logo selon le canevas de chaque rendu, avant même que l'encodeur ne le touche.

La solution

Le logo de chaque rendu est pré-rendu à ses dimensions exactes en pixels et stocké sous forme de PNG séparé. À chaque limite de programme, un orchestrateur Lambda émet quatre actions StaticImageOutputActivate — une par rendu — chacune pointant vers le PNG déjà dimensionné pour cette sortie spécifique. MediaLive n'effectue aucun redimensionnement sur la superposition.

GLOBAL (naïf)                    PAR SORTIE (ce que nous livrons)
master.png ──► composite sur      master.png ──► Redimensionnement Lanczos (hors ligne)
               canevas source                     en 4 PNGs de taille exacte
                    │                                  │
                    ▼                                  ▼
           scaler par rendu              scaler par rendu
           (redimensionne aussi           (la superposition n'est pas touchée —
            la superposition →             composée après, à la
            logo flou sur les              taille exacte en pixels)
            sorties SD)

Un script Python génère les quatre PNGs dimensionnés à partir d'une seule image maître en utilisant le rééchantillonnage de Lanczos, choisi pour son comportement prévisible et reproductible à de petites tailles plutôt que pour gagner un concours de qualité de pixels. Chaque logo représente environ 10% de la largeur de son canevas — visible sans être intrusif — et l'ajout d'un nouveau rendu se fait par une seule entrée de tableau et un nouveau PNG.

Décisions clés à souligner

Délai d'activation de 1,5 seconde. Les actions d'activation du filigrane se déclenchent 1,5 seconde après chaque changement d'entrée, et non au moment exact du changement — car une activation immédiate peut provoquer un scintillement sur des images pas encore stables. La valeur a été ajustée empiriquement et centralisée en une seule constante afin que tout ajustement futur ne nécessite qu'une modification d'une ligne.

Génération d'assets hors ligne, déclenchée manuellement — délibérément. Le pipeline de redimensionnement Lanczos n'est pas automatisé comme étape de build ou transformation côté CDN. Les assets de logo changent suffisamment rarement pour qu'une régénération en une seule commande soit le bon niveau d'automatisation ; le coût de la construction d'une automatisation supplémentaire l'emporte sur l'exécution d'un script deux fois par an.

Une variante « épaisse » existe mais n'est pas déployée. Le générateur produit également une variante avec alpha dilaté et des traits plus épais, destinée à survivre à la quantification H.264 à des faibles débits SD. Elle n'est pas en production — la variante standard est suffisante pour la plage de débits actuelle, et aucune mesure ne justifie encore le changement. Elle existe en tant que solution de secours testée par le code : peu coûteuse à maintenir disponible, prématurée à déployer.

Ce que nous surveillons encore

Aucun pipeline vidéo de production n'est jamais vraiment terminé, et il y a toujours des opportunités d'affiner cette approche au fil du temps.
L'implémentation actuelle garantit que chaque rendu reçoit un logo préparé spécifiquement pour sa propre résolution de sortie, éliminant le redimensionnement de la superposition en temps réel du pipeline MediaLive. L'apparence finale, cependant, reste naturellement limitée par la résolution et la compression vidéo de chaque rendu, en particulier aux débits inférieurs. À mesure que les profils de streaming évoluent, nous continuerons d'évaluer si différents traitements de logo offrent des avantages visuels mesurables dans ces conditions.
Le générateur d'assets prend déjà en charge la variante de logo standard et une variante plus épaisse. Si des tests futurs montrent que la version plus épaisse est plus performante pour les rendus à faible débit, nous rendrons la sélection de la variante de logo configurable afin qu'elle puisse être modifiée sans redéployer l'application.

Résultats

Chaque rendu reçoit désormais un logo dimensionné spécifiquement pour son propre canevas, MediaLive n'effectuant aucun redimensionnement de superposition en temps réel. Chaque sortie utilise une illustration préparée pour sa résolution cible, évitant l'adoucissement supplémentaire introduit par le redimensionnement de la superposition en temps réel tout en préservant la meilleure qualité visuelle pratique que ce rendu peut offrir.
Le bug de dérive des coordonnées de l'approche de superposition globale précédente, où les logos pouvaient se déplacer sur des vidéos sources plus étroites que 1920px, est structurellement éliminé car l'activation par sortie fonctionne entièrement dans les coordonnées de sortie.
Le remplacement du logo est désormais une tâche opérationnelle simple : régénérez les assets spécifiques au rendu avec un seul script et téléchargez-les. Aucun ré-encodage vidéo et aucune édition manuelle par rendu ne sont nécessaires.
Cette implémentation suit un principe d'ingénierie simple : résoudre les problèmes le plus tôt possible dans le pipeline, et concevoir en fonction des capacités de la plateforme au lieu de s'appuyer sur des solutions de contournement en aval. En préparant l'asset correct avant l'encodage, le pipeline en direct reste plus simple, plus prévisible et plus facile à maintenir.
Si vous rencontrez des problèmes similaires de qualité de rendu ou de superposition sur un pipeline vidéo en direct, contactez-nous.

Pile technologique : AWS MediaLive · AWS Lambda · AWS S3 · NestJS · TypeScript · Python (Pillow)