Overlays HTML5 : comment les graphiques arrivent sur votre direct
Presque tous les systèmes graphiques modernes dessinent aujourd’hui dans un moteur de navigateur. Cette page explique ce qu’est un overlay HTML5, comment la transparence survit jusqu’à votre encodeur, comment les graphiques restent synchronisés avec un pupitre, et où la technique s’arrête.
Ce qu’est un overlay HTML5
C’est une page web ordinaire dont le fond n’est jamais peint. Chaque graphique — synthé, bug, défilant — est un élément du DOM positionné sur un canevas de 1920×1080. Comme la page ne peint rien derrière, tous les autres pixels sont transparents.
Votre encodeur ouvre cette page dans un navigateur embarqué (OBS utilise CEF, le Chromium Embedded Framework) et compose le résultat sur votre scène en respectant la couche alpha. Pour l’encodeur, c’est une source transparente de plus, comme un PNG qui bouge.
Comment les graphiques changent à l’antenne
La page s’ouvre une fois et reste ouverte. Quand l’opérateur appuie sur TAKE, une commande passe par WebSocket jusqu’à la page, qui ajoute une classe ou met à jour une valeur, et le CSS anime l’élément. Rien n’est rechargé, aucun fichier n’est écrit.
C’est ce qui rend les données vivantes possibles : un score peut avancer, un chronomètre tourner et un nom changer alors que le graphique est encore à l’antenne, parce que la page est une application en cours d’exécution et non un fichier rendu.
Les règles de performance qui comptent
- N’animez que transform et opacity. Ils sont composés sur le GPU. Animer width, height, top ou left force un calcul de mise en page à chaque image.
- Évitez box-shadow et filter animés. Ils repeignent de grandes zones et sont la première cause d’un habillage qui saccade.
- Gardez un DOM léger. Quelques dizaines d’éléments, c’est normal. Quelques milliers, c’est un direct qui perd des images.
- Pas de polling. Un minuteur qui redessine toutes les 100 ms coûte pareil qu’il y ait un changement ou non ; poussez les mises à jour par la socket.
- Alignez-vous sur le canevas. Construisez à la résolution de l’encodeur pour que la source ne soit jamais redimensionnée, ce qui adoucirait tous les bords du texte.
Là où le HTML5 ne suffit pas
Une source navigateur est composée par votre encodeur : les graphiques n’existent donc qu’à l’intérieur de celui-ci. S’il faut alimenter un mélangeur de régie, un incrustateur matériel ou un second site, il faut un signal vidéo : SDI key et fill, ou NDI avec couche alpha. Graphiques NDI →
La précision à l’image est l’autre limite. Un navigateur dessine quand il dessine ; en streaming c’est invisible, mais une chaîne qui compte les images voudra un vrai serveur de diffusion.
Pourquoi nous construisons ainsi
La page de sortie de LowerThird Software est du HTML5 volontairement ennuyeux : fond transparent, animations CSS, état via SignalR. Cela signifie que votre encodeur compose sur du matériel qu’il utilise déjà et qu’un graphiste qui connaît le CSS peut changer l’apparence sans recompiler. Le voir tourner dans OBS →
Des graphiques HTML5 déjà prêts Modèles, pupitre et sortie transparente en une installation — pas de projet de modèles à démarrer de zéro.
Demander un accès anticipé