Por qué se corta una transmisión en vivo

Cuando una transmisión en vivo se congela o pixela, casi siempre pensamos «se cayó el internet». Pero detrás hay al menos tres problemas distintos, y cada uno se arregla de una forma diferente.

1. Pérdida de paquetes

Los datos viajan en paquetes y algunos se pierden en el camino, por ejemplo por mala señal o interferencia. La red sigue disponible, pero faltan piezas. Aquí la solución es recuperar lo perdido: pedir de nuevo el paquete (ARQ) o enviar corrección por adelantado (FEC).

2. Congestión

La red no da abasto para el caudal que le pedimos, así que todo se atrasa. Aquí bajar la calidad un poco es lo correcto: menos bitrate, y si hace falta menos cuadros por segundo. Insistir con reenvíos solo empeora el problema.

3. Corte de un enlace

El enlace simplemente desaparece. Ni recuperar paquetes ni bajar la calidad sirven: se necesita otro camino. Por eso se usan varios enlaces a la vez y un respaldo listo.

El protocolo también cuenta: RTMP

Muchas transmisiones en terreno todavía salen por RTMP, el protocolo clásico para enviar video a YouTube, Facebook o Twitch. Funciona bien en una conexión estable de oficina, pero no fue diseñado para salir desde un estadio, una calle o un cerro con señal móvil.

RTMP viaja sobre TCP, que interpreta cualquier pérdida como congestión: frena el envío y reenvía todo en orden, así que lo que viene detrás tiene que esperar. Con una señal móvil inestable, el codificador acumula atraso, la imagen se congela y al final la conexión se cae. Además usa un solo camino: si el enlace cambia o se corta, se corta la transmisión. No tiene bonding ni corrección de errores.

Protocolos más modernos, como SRT o RIST, trabajan sobre UDP y suman recuperación de paquetes (ARQ y FEC), pensados justamente para redes imperfectas. Algunas plataformas aún solo aceptan RTMP; ahí lo sensato es enviar una señal robusta desde terreno hasta un servidor y que sea el servidor quien entregue a cada plataforma. Es la idea detrás de «un envío, varios destinos».

Otros errores comunes en terreno

• Depender de un solo enlace u operador. Si cae o se satura, no hay plan B.
• Medir la velocidad una sola vez. Un test de diez segundos no dice cuánta subida habrá durante dos horas, ni cuánto cae cuando llega el público.
• Mirar la bajada en vez de la subida. En un en vivo lo que cuenta es la velocidad de subida.
• Configurar el bitrate al límite. Sin margen, cualquier bajón se convierte en corte. Conviene dejar holgura bajo lo que el enlace sostiene.
• No probar en el lugar y a la hora del evento. En eventos masivos la red celular se satura cuando llega la gente.
• No mirar las estadísticas. Pérdida, latencia y bitrate en tiempo real avisan antes de que se corte.

Qué viene en esta serie

Esta es la primera nota. Siguen bonding y redundancia, y después ARQ y FEC, los métodos para recuperar lo que se pierde.