Cuando 4.000 empleados se conectan a la misma reunión all-hands al mismo tiempo, alguien le está pagando a alguien por esos bytes. Por lo general, ese alguien es una suscripción a Microsoft Stream, Zoom Webinar, Vimeo Enterprise o Brightcove: los bytes salen brevemente de la red corporativa, rebotan en un datacenter de un tercero y vuelven a entrar a la misma red por una conexión distinta. El CEO está en una sala de reuniones a dos puertas, y el video de él va hasta Frankfurt y regresa.
Esto funciona bien hasta que alguien hace la pregunta que no tiene una buena respuesta. “¿Por qué el tráfico de nuestro town hall interno transita por un SaaS de un tercero?” Compliance lo pregunta antes de una auditoría de una industria regulada. Seguridad lo pregunta después de cada divulgación de brecha que menciona a un proveedor de streaming. El CFO lo pregunta cuando se renueva la factura SaaS por espectador. IT lo pregunta la primera vez que el enlace WAN del edificio se satura porque el all-hands tuvo asistencia récord.
La respuesta honesta es que el streaming corporativo en vivo evolucionó alrededor de codificadores RTMP y plataformas SaaS porque las alternativas eran caras (Cisco enterprise video, appliances eCDN de Kollective y Hive, equipo de CDN interno) o caseras de una manera que nadie en un equipo de IT típico tenía el ancho de banda para mantener. Las empresas eligieron SaaS porque nada más estaba a su alcance.
Eso ha cambiado. El codificador, el transcodificador, el empaquetador y el publicador se han colapsado en una única pieza de software corriendo en una Mac. El destino no tiene que ser un proveedor. Apuntado a un servidor web dentro de tu firewall, el mismo software produce HLS de calidad broadcast que tus empleados consumen por la LAN corporativa, y nada sale de la red.
Este artículo trata exactamente de eso.
Cómo se ve realmente el “corporate live interno”
La mayor parte del video interno en una empresa típica cae en una lista corta de casos de uso recurrentes.
All-hands trimestrales y town halls del CEO. Audiencias grandes (a menudo toda la compañía), baja frecuencia (cuatro a doce veces al año), valores de producción modestos. Las tolerancias de latencia son flexibles: quince a treinta segundos está bien porque no hay interacción bidireccional durante el discurso y las preguntas y respuestas se gestionan por un canal aparte.
Sesiones de capacitación y cursos de certificación. A veces en vivo, a menudo revisitadas después. Pocos cientos de espectadores concurrentes como máximo. La producción es de una cámara, un presentador y diapositivas compartidas desde una laptop.
Lanzamientos de producto y anuncios de ingeniería. Solo internos porque el anuncio es para el personal antes de llegar a la prensa. Sensibles ante filtraciones.
Briefings de compliance y RR. HH. Capacitaciones anuales de ética, actualizaciones regulatorias, salud y seguridad. La trazabilidad para auditoría importa más que el pulido de producción.
Actualizaciones sobre incidentes de seguridad. Solo internos por defecto porque el contenido son detalles del incidente. Tienen que quedarse adentro.
En cada uno de esos casos de uso, la audiencia son empleados internos en la red corporativa o en la VPN corporativa. El contenido es interno por política. Mandar los bytes a un SaaS, hacer que el SaaS se los devuelva a tus empleados, pagar por minuto y pedirle al equipo legal que agregue otro acuerdo de procesamiento de datos es el camino de menor resistencia, no la arquitectura correcta.
Cómo se ve una alternativa on-prem en 2025
La arquitectura es lo bastante pequeña como para dibujarla en un post-it.
Una Mac en la sala de reuniones. La MacBook del orador, una cámara USB, el sistema AV del edificio enviando audio a la Mac, o cualquier combinación de eso. Apple silicon tiene un codificador por hardware de H.264, HEVC y AV1 idéntico al que Final Cut Pro usa para exportar. Codificar 1080p a 5 Mbps, 720p a 3 Mbps y 540p a 1,8 Mbps simultáneamente, en tiempo real, es para lo que el chip está diseñado.
Un servidor web dentro del firewall. Cualquier cosa
que acepte HTTPS PUT y sirva archivos. Un servidor de archivos
reutilizado, una pequeña VM Linux, un IIS o nginx interno que ya sirva
contenido de intranet. El endpoint recibe pequeños segmentos de
fragmented MP4 (seis segundos cada uno) y diminutos archivos de playlist
.m3u8. El almacenamiento es trivial: una transmisión de una
hora a tres niveles de calidad usa unos 4 GB. El servidor no
transcodifica, no reempaqueta, solo almacena y sirve.
Un reproductor HLS embebido en la página de intranet. Cualquier reproductor HLS moderno funciona: hls.js para navegadores sin HLS nativo, el soporte integrado del navegador en Safari, el Apple TV de la cafetería, los sistemas de display de las salas de reuniones que la mayoría de las empresas ya tienen.
Esa es la arquitectura completa. Los bytes nunca salen de la red. No hay servidor de streaming que licenciar, ni transcodificador en la nube que facturar, ni agente eCDN que instalar en cada laptop de empleado, ni suscripción SaaS. La Mac corre My Live TV Channel, que codifica el stream y lo sube. El servidor web que ya tienes hace el resto.
Por qué esto funciona a escala en una LAN corporativa
La primera reacción de la gente de infraestructura suele ser que un solo servidor web no puede soportar la audiencia de un town hall. En la internet pública, esa intuición es correcta. En una LAN corporativa, no lo es.
Una variante HLS de 1080p a 5 Mbps sobre un uplink de 1 Gbps satura el enlace con unos 200 espectadores concurrentes (1000 ÷ 5). El mismo uplink a 10 Gbps soporta aproximadamente 2.000 espectadores concurrentes en 1080p. La variante de 720p a 3 Mbps lleva esos números a unos 333 y 3.300 respectivamente. En una escalera de bitrate adaptativo donde los espectadores se reparten entre múltiples peldaños, la mayoría de las laptops corporativas terminan en 720p una vez que la lógica adaptativa de HLS encuentra el peldaño cómodo, así que la capacidad concurrente realista en un único servidor de 10 Gbps son varios miles de empleados.
Si tu audiencia es mayor que eso, el siguiente paso no es un SaaS. Es un segundo servidor interno, o tu CDN interno existente (la mayoría de las grandes empresas ya tienen infraestructura de caché para actualizaciones de software y contenido de intranet), o una sola capa de caché nginx delante del servidor de subida. Nada de esto requiere un proveedor, y todo es más barato que la facturación SaaS por espectador.
Cuando la audiencia es demasiado grande para unicast
La matemática unicast por LAN de arriba se topa con un techo de varios miles de espectadores concurrentes por servidor. Si un all-hands global pone a 50.000 empleados sobre la red del mismo edificio en el mismo minuto, o estás transmitiendo a un recinto del tamaño de un estadio lleno de laptops corporativas, unicast choca con un muro y apilar más servidores se vuelve un desperdicio.
La respuesta tradicional es multidifusión: una copia de cada segmento viaja a un grupo multicast, cada espectador se suscribe, y la red duplica los paquetes en switches y routers según haga falta. Un solo stream de 5 Mbps alimenta todo el campus desde una sola fuente, sin multiplicación de ancho de banda por espectador.
En la práctica, multicast en una red corporativa es una situación de “sí, pero”:
- Solo funciona dentro de una red habilitada para multicast. La mayoría de las redes corporativas tiene IGMP y PIM deshabilitados por defecto por motivos de seguridad. Activarlos es un proyecto de ingeniería de red, no un ajuste.
- No cruza la mayoría de las conexiones VPN. Los trabajadores remotos vuelven a unicast.
- No cruza enlaces WAN entre oficinas sin MPLS multicast explícito o equivalente.
- Es útil sobre todo dentro de un mismo campus o un mismo edificio donde IT ha construido los árboles multicast deliberadamente.
Si tu red lo soporta, la forma de usarlo con esta arquitectura es dejar que la Mac codificadora siga haciendo lo suyo (HLS por HTTPS PUT al servidor web interno) y agregar un traductor multicast aguas abajo. Herramientas open-source como tsduck y appliances comerciales de proveedores de red leen la salida HLS, construyen un feed multicast MPEG-TS y lo anuncian vía SAP o SDP. Los endpoints que soportan multicast (VLC, set-top boxes en salas de reuniones, smart TVs de la cafetería) se unen al grupo en lugar de tirar HLS unicast. Los endpoints que no (la mayoría de las laptops en un navegador) siguen usando el reproductor HLS unicast servido desde el mismo servidor web. Una Mac, un destino de subida, más un único traductor multicast cubren ambos tipos de espectador.
Para la mayoría de las empresas esta sección es teórica: unicast resuelve el all-hands sin dificultad. Para las pocas grandes empresas donde no es teórica, la arquitectura se extiende sin cambiar el codificador.
Configurándolo por primera vez
La primera puesta en marcha lleva más o menos una tarde para un equipo de IT que no ha hecho streaming interno antes. El orden aproximado:
Elige el servidor web destino. Sirve cualquier servidor web interno con HTTPS. Configura un directorio como
/intranet-broadcasts/town-hall-2025-q4/con HTTPS PUT habilitado, sin autenticación si está detrás del firewall, o basic auth si lo prefieres. nginx con eldav_modulelo logra en aproximadamente diez líneas de configuración. Elmod_davde Apache es el equivalente.Prueba el endpoint. Desde cualquier máquina interna,
curl -X PUT https://intranet.corp/intranet-broadcasts/test/index.m3u8 --data "test"debería devolver un 201. Si lo hace, el destino está listo.Configura My Live TV Channel en la Mac del presentador. Agrega un destino HTTP PUT que apunte al directorio. Guárdalo. Prueba la conexión. Crea un Stream Profile con la escalera de bitrate que quieras.
Embebe un reproductor HLS en la página de intranet. Una etiqueta
<video controls>apuntando a la URL de reproducción alcanza en Safari. Para Chrome y Edge, agrega hls.js (un script tag, una línea de JavaScript). El reproductor entero ocupa menos de treinta líneas de HTML.Ensayo con el equipo técnico. Transmite desde la Mac durante diez minutos. Que algunos espectadores internos se sintonicen. Mira el dashboard. Confirma que los segmentos aparecen en el servidor destino, que el reproductor los toma y que la latencia es aceptable.
Esa es toda la configuración. Las transmisiones siguientes reutilizan el mismo destino, el mismo perfil y el mismo embed del reproductor.
Y las preguntas y respuestas, encuestas y demás
La arquitectura de arriba resuelve la transmisión, no la capa interactiva. Para Q&A, encuestas y reacciones durante el town hall, las empresas internas suelen tener ya un canal de Slack o Microsoft Teams que cumple perfectamente, corre con latencia subsegundo sobre la misma red interna y se integra con el directorio que el resto de la compañía usa. Tratar de convertir un SaaS de streaming también en herramienta de chat es lo que vuelve caros a esos productos. Separar la transmisión y la interacción en las herramientas que tu compañía ya usa es lo que vuelve barata a la arquitectura.
Si quieres un canal de información interna 24/7 (“CorpTV”), la app de playout My TV Channel llena el tiempo entre transmisiones en vivo con contenido programado (archivos grabados de all-hands, videos de capacitación, noticias internas, actualizaciones de los gerentes). Mismo servidor destino, mismo embed del reproductor. Los empleados que entran a la página del canal un martes por la tarde se encuentran con algo en pantalla en lugar de un cartel de “stream offline”.
Lo que sigue siendo problema tuyo
Auto-hospedar video interno tiene compromisos sobre los que conviene ser honesto.
Grabación y retención. El servidor destino guarda cada transmisión indefinidamente a menos que configures un job de limpieza. Eso es bueno para los archivos y malo para el almacenamiento si lo olvidas. La mayoría de las empresas quiere una política de retención sobre las transmisiones internas (típicamente alineada con requisitos regulatorios o legales). Configúrala una vez, en cron, y olvídate.
Subtítulos y accesibilidad. El subtitulado en vivo no viene integrado en la app codificadora, y resulta ser menos problema de lo que parece. Los navegadores y sistemas operativos modernos generan subtítulos en vivo del lado del cliente, on-device, sin intervención del servidor: la función Live Caption de Chrome funciona en cualquier video que se reproduzca en el navegador, macOS Live Captions hace lo mismo a nivel sistema en Safari, y Edge tiene su propio equivalente. Cada espectador activa o desactiva los subtítulos en su propio navegador. Si necesitas subtitulado del lado del servidor por motivos de compliance (los subtítulos deben formar parte de la grabación, o no puedes confiar en el navegador del espectador), enruta el audio a través de un servicio de subtitulado (los subtítulos integrados de Microsoft, AWS Transcribe, herramientas internas) y superpón los subtítulos en el reproductor. La capa HLS no cambia en ninguno de los dos casos.
Autenticación. Dentro del firewall, “cualquiera en la red corporativa puede mirar” suele ser aceptable. Si necesitas garantías más fuertes (briefings ejecutivos, anuncios de M&A), pon la URL de reproducción detrás de tu SSO existente o de chequeos de postura de VPN. Auth web estándar, no específica de video.
Oficinas en distintas regiones. Si tienes oficinas en varios continentes uniéndose a una sola transmisión, vas a querer o un servidor de caché regional en cada región, o la decisión deliberada de usar la WAN corporativa. Las WAN suelen estar limitadas en ancho de banda, así que la matemática LAN de arriba no aplica. Planifica en consecuencia.
El veredicto honesto
La cuestión del costo es la más fácil de exagerar. Las facturas SaaS por streaming interno existen, pero rara vez son el factor decisivo por sí solas. El factor decisivo para la mayoría de las empresas que se mudan a una arquitectura on-prem es que el video interno debe seguir siendo interno. La voz del CEO, el anuncio de ingeniería, el briefing de M&A, el debrief de un incidente de seguridad, la capacitación de compliance: ninguno de esos necesita salir de la red corporativa para llegar a la audiencia corporativa que está sentada sobre ella. Una vez que ese es el marco, “mandamos una copia por el datacenter de un proveedor y pagamos el viaje de ida y vuelta” es la parte que necesita justificarse, no la alternativa on-prem.
Los equipos de compliance hacen la misma pregunta en industrias reguladas: ¿qué terceros tienen acceso a las grabaciones de las reuniones internas con empleados? Los equipos de seguridad la hacen después de cada divulgación de brecha que menciona a un proveedor de streaming. Las reglas de residencia de datos en algunas regiones la hacen incluso antes de que la transmisión ocurra. Una arquitectura donde los bytes nunca salen de la red elimina la pregunta.
Si tienes esas preocupaciones y tu equipo de IT está cansado de provisionar otro agente eCDN de un proveedor en cada laptop, la respuesta práctica ahora es lo bastante chica como para montarla en una tarde. Una Mac en la sala de reuniones, un servidor web que ya tienes y una app que puedes probar gratis durante una semana. El diagrama de arquitectura cabe en un post-it. La cantidad de proveedores con acceso a la voz de tu CEO pasa de “varios” a “cero”.
Prueba My Live TV Channel gratis durante 7 días en el Mac App Store →