Overlays HTML5: cómo llegan los gráficos a tu directo
Casi todos los sistemas modernos de gráficos en vivo dibujan hoy en un motor de navegador. Esta página explica qué es un overlay HTML5, cómo sobrevive la transparencia hasta tu codificador, cómo se mantienen sincronizados los gráficos con un panel de control y dónde se acaba la técnica.
Qué es un overlay HTML5
Es una página web normal cuyo fondo nunca se pinta. Cada gráfico —rótulo, bug, ticker— es un elemento del DOM colocado en un lienzo de 1920×1080. Como la página no pinta nada detrás, todos los demás píxeles son transparentes.
Tu codificador abre esa página en un navegador embebido (OBS usa CEF, Chromium Embedded Framework) y compone el resultado sobre tu escena respetando el canal alfa. Para el codificador es una fuente con transparencia más, como un PNG que se mueve.
Cómo cambian los gráficos en antena
La página se abre una vez y se queda abierta. Cuando el operador pulsa TAKE, un comando viaja por WebSocket hasta la página, que añade una clase o actualiza un valor, y CSS anima el elemento. No se recarga nada ni se escribe ningún archivo.
Eso es lo que hace posibles los datos en vivo: un marcador puede avanzar, un reloj correr y un nombre cambiar mientras el gráfico sigue en pantalla, porque la página es una aplicación en ejecución y no un archivo renderizado.
Reglas de rendimiento que importan
- Anima solo transform y opacity. Se componen en la GPU. Animar width, height, top o left fuerza cálculo de diseño en cada fotograma.
- Evita box-shadow y filter animados. Repintan áreas grandes y son la causa más común de un overlay a tirones.
- Mantén el DOM pequeño. Unas decenas de elementos es normal. Unos miles es un directo que pierde fotogramas.
- No hagas polling. Un temporizador que redibuja cada 100 ms cuesta igual haya cambios o no; empuja las actualizaciones por el socket.
- Coincide con el lienzo. Construye a la resolución del codificador para que el browser source nunca se reescale, lo que suavizaría todos los bordes del texto.
Dónde no basta HTML5
Un browser source lo compone tu codificador, así que los gráficos solo existen dentro de él. Si necesitas alimentar un mezclador de realización, un keyer por hardware o una segunda instalación, necesitas señal de vídeo: SDI key y fill, o NDI con canal alfa. Gráficos por NDI →
La otra frontera es la precisión de fotograma. Un navegador dibuja cuando dibuja; en streaming eso es invisible, pero una cadena que cuenta fotogramas querrá un servidor de playout real.
Por qué lo construimos así
La página de salida de LowerThird Software es HTML5 deliberadamente aburrido: fondo transparente, animaciones CSS, estado por SignalR. Eso significa que tu codificador compone en hardware que ya está usando y que un diseñador que sepa CSS puede cambiar el aspecto sin recompilar nada. Verlo funcionando en OBS →
Gráficos HTML5 ya hechos Plantillas, panel y salida transparente en una instalación: sin proyecto de plantillas desde cero.
Solicitar acceso anticipado