Cómo emitir un evento en YouTube: configuración, latencia y pruebas

YouTube tiene una ventaja difícil de discutir para un evento: reproduce en cualquier dispositivo, aguanta picos de audiencia sin que nadie dimensione nada y no cobra por espectador. A cambio impone sus reglas, y casi todos los sustos que hemos visto en directos ajenos vienen de haber descubierto una de esas reglas el mismo día. Esto es la configuración real de una emisión, en el orden en que conviene resolverla.

Lo que hay que resolver días antes, no el mismo día

El canal necesita estar verificado y tener el directo habilitado, y la habilitación no es inmediata: la plataforma aplica un periodo de espera antes de permitir la primera emisión. Si el evento sale por el canal del cliente, se comprueba con semanas de margen. Hay dos condicionantes más:

• Restricciones activas. Una reclamación de derechos o una incidencia previa puede dejar la cuenta sin acceso al directo durante un periodo largo. Si el canal ha tenido problemas, se comprueba en el panel de la propia cuenta antes de contar con él.
• Música con derechos. Es el motivo número uno de que un directo se silencie o se bloquee a mitad. El sistema de identificación de contenido actúa sobre el audio en tiempo real: una sintonía de vídeo corporativo, un tema de fondo en el cóctel o una versión tocada en directo pueden disparar una reclamación. Con música en juego conviene decidir de antemano si esa parte se emite, se sustituye el audio o se corta el programa hacia una cortinilla.

Crear la emisión: programada, nunca improvisada

Una emisión creada con antelación en el estudio de directo de YouTube da tres cosas que no se consiguen improvisando: una URL estable que se puede repartir en invitaciones, en la web del evento y en firmas de correo días antes; una página de espera con cuenta atrás donde el público aterriza antes de la hora; y tiempo para preparar título, descripción, miniatura y categoría con calma.

La creamos en cuanto hay fecha y hora confirmadas. Si el acto tiene sesiones separadas por horas, conviene una emisión por sesión en lugar de dejar una sola abierta en negro durante el descanso.

Clave de emisión y servidor RTMP

El codificador —en nuestro caso el máster de la unidad móvil— necesita dos datos: la URL del servidor de ingesta y la clave de emisión. YouTube ofrece una URL principal y una de respaldo; si el equipo permite enviar a las dos a la vez, se envía, porque es la forma más barata de sobrevivir a un problema puntual en un nodo de ingesta.

Una clave persistente se carga en el codificador durante el montaje y se prueba el día anterior sin tocar nada más; es lo que usamos casi siempre. Una clave de un solo uso es más limpia cuando el canal es del cliente, pero obliga a copiarla el mismo día. En cualquier caso se trata como una contraseña: quien la tiene puede emitir en ese canal.

Del lado del codificador dejamos fijados H.264, audio AAC, GOP cerrado con keyframe cada 2 segundos —lo que pide la plataforma para generar sus calidades adaptativas— y bitrate constante. El caudal sale del formato y del movimiento de la imagen; los valores con los que trabajamos están en qué bitrate usar para Full HD, y la subida que hay que reservar para sostenerlo, en qué conexión necesita un streaming profesional.

Latencia: normal, baja o ultrabaja

Es el ajuste peor entendido, porque suena a que menos siempre es mejor. No lo es: el retardo de emisión es el colchón que absorbe los baches de la red, y cuanto más lo reduces, menos margen tiene el reproductor del espectador para disimular un microcorte. Nuestra regla es elegir la latencia más alta que el evento tolere: normal en directos de consumo pasivo, baja si hay preguntas del público remoto, y ultrabaja solo cuando una dinámica lo exige de verdad, sabiendo que se emite con menos red de seguridad.

Pública, oculta o privada

Las tres opciones responden a necesidades distintas y se confunden a menudo:

• Pública. Aparece en el canal, en búsquedas y en recomendaciones. Es lo que se quiere en un evento abierto.
• Oculta o no listada. Solo accede quien tiene el enlace, pero cualquiera con ese enlace entra. Es la opción habitual en actos corporativos abiertos a invitados.
• Privada. Solo cuentas invitadas explícitamente, que deben iniciar sesión. Da control real, añade fricción y no escala bien a listas grandes.

Cuando el requisito real es restringir quién ve el contenido —una junta, una presentación de resultados—, YouTube no suele ser la herramienta adecuada y la emisión se lleva a una plataforma con control de acceso y registro, como explicamos en webcast profesional. Emitir en oculto y confiar en que nadie comparta el enlace no es una política de acceso.

Miniatura, DVR y chat

La miniatura personalizada se sube antes: es lo único que ve quien llega a la página de espera. El título debe describir el acto y no solo la marca. El DVR —poder rebobinar durante la emisión— se deja activo en sesiones largas, porque quien entra a mitad puede volver al principio. Y el chat es una decisión de producción: si no habrá nadie moderando, mejor desactivarlo.

Las pruebas que evitan el susto

Ninguna configuración vale nada sin una prueba real contra la ingesta de YouTube, hecha desde el sitio del evento, con la misma conexión y a una hora parecida a la del directo. No se mira solo que «se ve»: se vigila si el codificador reporta pérdida o cola de envío, si el bitrate se mantiene plano, si el audio llega al nivel correcto y sincronizado y si la plataforma marca la emisión como correcta. Media hora sostenida dice mucho más que dos minutos.

Si el directo se corta

El comportamiento a conocer: si el codificador deja de enviar y vuelve con la misma clave en un margen breve, la emisión continúa en la misma URL y el público que esperaba recupera la imagen. Si se supera ese margen, la plataforma da por terminada la retransmisión y hay que abrir otra, con enlace nuevo y con el público disperso. Por eso el plan de contingencia se ordena así:

1. Grabación local siempre en marcha. Pase lo que pase en la red, el evento existe y se publica íntegro después.
2. Salida redundante. Dos caminos a internet de tecnologías distintas, para que un fallo de uno no llegue a ser un corte. El detalle, en conectividad.
3. Protocolo tolerante en el tramo frágil. Cuando el enlace no es una fibra estable, la señal viaja con SRT hasta un punto fiable y desde ahí se entrega en RTMP.
4. Cortinilla preparada. Un «continuamos en unos instantes» cargado en el mezclador es la diferencia entre una incidencia y una pantalla en negro.