Por qué el video es distinto de todo lo demás que sirves
Una página web pesa un par de megabytes. Diez minutos de video 1080p pesan del orden de un gigabyte por espectador. Esa brecha de tres órdenes de magnitud es la razón por la que un video que sería un error de redondeo como vista de página puede saturar un servidor de origen el día que se hace popular: cien espectadores simultáneos de un fichero son cien streams sostenidos de alto ancho de banda saliendo de una sola máquina.
La economía sigue la misma curva. En proveedores que facturan la salida por gigabyte, un video con éxito modesto es una factura notable; uno viral es una llamada de finanzas. Ambos problemas — el techo de ancho de banda y la factura — tienen la misma forma que cualquier otro problema de contenido estático, lo que significa que tienen la misma solución: responder las peticiones repetidas desde una caché cercana al espectador en vez de desde el origen, todas y cada una de las veces.
HLS desmitificado: es una playlist y una carpeta de ficheros
HLS (HTTP Live Streaming) parece exótico hasta que abres los ficheros. El codificador corta el video en segmentos cortos — de unos pocos segundos cada uno — y escribe una playlist en texto plano (.m3u8) que los lista en orden. El reproductor descarga la playlist y luego va pidiendo los segmentos uno a uno por HTTP normal, unos segundos por delante de lo que está mostrando. La calidad adaptativa es el mismo truco dos veces: una playlist maestra apunta a varias playlists de variante (1080p, 720p, 480p) y el reproductor salta entre ellas según cambia el ancho de banda.
La consecuencia merece decirse sin rodeos: no hay ningún protocolo especial de video en la ruta de entrega. Ni sockets, ni servidor de streaming, ni infraestructura exótica. Cada petición que hace el reproductor es un GET a un fichero estático pequeño — y ficheros estáticos pequeños servidos millones de veces es exactamente la carga de trabajo para la que existe el edge de una CDN.
Una playlist de variante — texto plano que apunta a ficheros normales
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment_000.ts
#EXTINF:6.000,
segment_001.ts
#EXTINF:6.000,
segment_002.ts
#EXT-X-ENDLISTEl pipeline VOD: codifica una vez, guarda una vez, sirve desde el edge
Para el video bajo demanda el pipeline tiene tres estaciones. Codifica una vez, en tu máquina o en tu build — ffmpeg convierte un video fuente en la carpeta de playlist más segmentos con un solo comando. Guarda una vez, en object storage compatible con S3, que existe precisamente para ficheros que se escriben una vez y se leen muchas, como estos. Sirve desde el edge: con el bucket detrás de la CDN, el primer espectador de cada segmento llena la caché y todos los que vienen después reciben la respuesta cerca de donde están, mientras tu almacenamiento responde cada fichero único aproximadamente una vez.
En cdn.com.tr el almacenamiento y el edge son una sola plataforma, así que esto no es un proyecto de integración: crea un bucket, sube la carpeta, y el edge de la misma cuenta — con WAF y protección DDoS incluidos — se pone delante.
Del fichero fuente al stream servido por la CDN
# 1) encode into HLS (6-second segments, one quality for brevity)
ffmpeg -i talk.mp4 -c:v h264 -c:a aac \
-hls_time 6 -hls_playlist_type vod \
-hls_segment_filename 'talk/segment_%03d.ts' talk/playlist.m3u8
# 2) create the bucket and an access key (panel works too)
cdnctl object-storage buckets create --account <uuid> --name videos
cdnctl object-storage access-keys create --account <uuid> --bucket <bucket_uuid>
# 3) upload the folder with the standard AWS CLI
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./talk s3://videos/talk
# the player now points at the playlist behind your CDN hostname:
# https://video.example.com/talk/playlist.m3u8Las reglas de caché que hacen o rompen la entrega de video
El video premia la disciplina con las cabeceras de caché que otros contenidos simplemente agradecen, porque los dos tipos de fichero de un stream HLS quieren tratos opuestos.
Los segmentos son inmutables por construcción — segment_042.ts nunca contendrá bytes distintos, porque una recodificación escribe una carpeta nueva. Cachéalos tanto como quieras; un año no es una imprudencia, es lo correcto. Cada segmento cacheado a largo plazo es ancho de banda que tu origen no vuelve a servir jamás.
Las playlists son la parte que se mueve. Para un VOD terminado solo cambian cuando reemplazas el video, así que una hora está bien. En el momento en que a una playlist se le van añadiendo entradas — que es como funciona el casi-directo — debe cachearse en segundos, porque el reproductor la relee para descubrir segmentos nuevos. Equivocarse en esa única cabecera es el bug clásico del video: espectadores congelados en segmentos viejos mientras la playlist les dice que no existe nada nuevo.
En cdn.com.tr configuras exactamente esta separación como reglas de entrega en el panel: una regla que coincide con la ruta de los segmentos con un tiempo largo, y otra que coincide con *.m3u8 con uno corto.
Detalles que muerden: rangos, CORS y compresión
Tres notas prácticas ahorran la mayoría de los tickets de soporte de video. Primero, las peticiones de rango: los reproductores y navegadores piden habitualmente rangos de bytes de los ficheros de media, y el edge sirve contenido parcial desde caché — esto es también lo que permite a un espectador saltar al minuto seis sin descargar los minutos uno a cinco de un MP4.
Segundo, CORS: si el reproductor corre en un hostname distinto al de los ficheros de video, el navegador exigirá cabeceras Access-Control-Allow-Origin en segmentos y playlists, y el síntoma de olvidarlo es un reproductor que funciona en una pestaña suelta pero no incrustado en tu página.
Tercero, la compresión: déjala apagada para el media. El video y el audio ya vienen comprimidos por el códec; hacer gzip a un segmento .ts gasta CPU para no ahorrar nada. Comprime las playlists si quieres — son texto — pero la ganancia es microscópica. El edge ya sabe que no debe recomprimir tipos de media; la nota importa para la configuración de tu propio origen.
¿Y el streaming en directo? Una respuesta honesta
El directo es la misma historia de entrega con una cadena de suministro más dura. La mitad de la entrega es idéntica: un stream HLS en directo sigue siendo una playlist y segmentos, solo que la playlist crece cada pocos segundos y se cachea muy brevemente. Un edge sirve eso de maravilla — miles de espectadores leyendo ficheros con segundos de antigüedad siguen siendo simples aciertos de caché.
Lo que el directo añade es todo lo que pasa antes de que existan los ficheros: la ingesta (recibir la señal de la cámara por RTMP o SRT), la transcodificación en tiempo real a la escalera de calidades, y el empaquetado — un pipeline en marcha con sus propios modos de fallo, no una carpeta que subes una vez. Ese pipeline no se monta a la ligera, y no es lo que hace el producto autoservicio de esta plataforma: cdn.com.tr es la mitad de almacenamiento y entrega de la historia. Si tu proyecto necesita la cadena de directo completa, háblalo con nosotros directamente en lugar de forzarlo en un flujo con forma de VOD — y desconfía de cualquier proveedor que venda "streaming en directo" sin decir quién opera el codificador.
Preguntas frecuentes
¿Puedo servir un fichero MP4 directamente en vez de HLS?
Para clips cortos, sí — un MP4 detrás de la CDN con peticiones de rango funciona y los reproductores lo navegan sin problema. HLS se gana su complejidad cuando los videos se alargan o la audiencia varía: calidad adaptativa, arranques más rápidos y segmentos pequeños que se cachean y reanudan mejor que un fichero grande.
¿cdn.com.tr codifica mis videos?
No — la codificación es tu lado del pipeline (ffmpeg en local o en CI es la ruta estándar, y el comando de arriba es un punto de partida completo). La plataforma guarda la salida codificada en object storage y la entrega a través del edge.
¿Qué pasa cuando un video se hace viral?
Ese es el escenario para el que existe esta arquitectura: después del primer espectador por ubicación edge, los segmentos se responden desde caché, así que la carga del origen apenas se mueve mientras la entrega escala con el edge. Lo que hay que vigilar son tus cabeceras de caché — segmentos inmutables cacheados a largo plazo es lo que hace que las cuentas salgan.
¿Cómo reemplazo un video sin que los espectadores vean una mezcla rota de viejo y nuevo?
Codifica en una carpeta NUEVA (talk-v2/) y apunta el reproductor a la nueva URL de playlist — los segmentos viejos cacheados se vuelven irrelevantes en lugar de incorrectos, sin necesidad de purga. Sobrescribir ficheros en su sitio y purgar funciona, pero las rutas versionadas son el patrón más tranquilo, exactamente igual que con cualquier asset estático.