Transcodificación ABR con Flussonic: perfiles de bitrate y cuándo no transcodificar

El transcoder no es gratis

En los posts anteriores sobre esta cabecera hablamos de la captación (TVHeadend con tarjetas TBS) y de la arquitectura de dos nodos con Flussonic principal en el Caribe y secundario en Francia. Ese nivel es sobre todo I/O: recibir señal, entregarla, tener un plan B si una fuente cae. Este post está un piso más arriba, en la parte donde Flussonic deja de mover bytes y empieza a gastar ciclos de CPU: la transcodificación adaptativa (ABR, adaptive bitrate).

La tentación con ABR es tratarlo como un interruptor: "actívalo y ya el stream se adapta a cualquier red". En la práctica es al revés — cada perfil adicional en la escalera es un proceso de codificación corriendo en tiempo real, consumiendo CPU (o GPU) de forma sostenida mientras el canal esté al aire. Diseñar mal la escalera no rompe nada visiblemente el primer día; simplemente satura el servidor tres meses después, cuando ya hay quince canales transcodificando a la vez y nadie recuerda por qué el perfil de 360p sigue ahí.

Qué resuelve ABR y qué no

Adaptive bitrate streaming (HLS o DASH) le da al reproductor del lado del cliente varias versiones del mismo contenido —distintas combinaciones de resolución y bitrate— para que elija cuál pedir según el ancho de banda disponible en ese momento, y cambie entre ellas sin cortar la reproducción. Resuelve un problema real: una red que fluctúa, un dispositivo con pantalla pequeña que no necesita 1080p, un STB conectado por Wi-Fi en una esquina de la casa con señal débil.

Lo que ABR no resuelve es un origen mal dimensionado o una red backbone saturada. Si el enlace entre el nodo de captación y el servidor de salida ya está al límite, agregar perfiles no alivia esa saturación — la CPU adicional dedicada a transcodificar compite por los mismos recursos que el sistema necesita para servir el stream principal con estabilidad. Ahí el problema no se resuelve con más perfiles, se resuelve con mejor red o menos carga.

Cuándo sí conviene transcodificar

• El parque de dispositivos es heterogéneo. Un portal Stalker sirviendo STBs MAG de generaciones distintas —algunos con decodificación de hardware limitada, otros sobre Wi-Fi doméstico— se beneficia de tener una versión más liviana disponible, en vez de forzar a todos a recibir el bitrate del origen.
• El origen llega en un bitrate que no es viable para la última milla. Una captación satelital en alta definición puede entrar a 8-15 Mbps; eso es razonable en un backbone dedicado, pero no en una conexión residencial compartida por el resto de la casa.
• El codec de origen no es compatible con todos los STBs. Algunos decodificadores más antiguos no soportan HEVC; si el origen llega en HEVC y hay que servir a esos dispositivos, hace falta al menos un perfil transcodificado a H.264.

Cuándo no conviene

• Tráfico entre nodos propios sobre backbone dedicado. El enlace entre el Flussonic principal y el secundario no necesita ABR — es infraestructura interna con ancho de banda conocido y previsible, no un cliente final con red variable. Ahí lo correcto es passthrough: relay del stream tal cual llega, sin gastar CPU en recodificarlo.
• Perfiles que nadie consume. Es fácil heredar una escalera de cinco perfiles de un canal a otro "por si acaso", sin revisar qué bitrates realmente están pidiendo los reproductores en producción. Cada perfil sin demanda real es CPU regalada.
• Contenido de bajo movimiento en baja resolución de origen. Un canal que ya entra en definición estándar y bitrate modesto rara vez necesita una escalera completa — con el original más, a lo sumo, un perfil bajo para redes muy limitadas, suele bastar.

Diseñar la escalera: resolución, bitrate y codec

Una escalera ABR razonable no es simétrica en resolución y bitrate — cada escalón debe representar una mejora perceptible, no un salto arbitrario. Los criterios que usamos para decidir cuántos escalones tiene un canal y dónde van:

1. El origen siempre es un perfil. Nunca recodificar lo que ya llega en buena calidad si lo que se necesita es justamente entregarlo tal cual a los dispositivos que sí lo soportan.
2. Cada escalón hacia abajo reduce resolución y bitrate juntos. Bajar solo el bitrate manteniendo la resolución produce bloques y artefactos visibles mucho antes que si se reduce también la resolución — el ojo tolera mejor una imagen más pequeña y nítida que una del mismo tamaño con macro-bloques.
3. El codec se decide por el dispositivo más limitado que hay que soportar, no por el más nuevo. Si el portal todavía tiene STBs MAG que solo decodifican H.264, ese es el codec del perfil bajo, aunque el origen y el perfil alto vayan en HEVC.
4. El audio no se toca a la ligera. AAC es la opción más compatible entre decodificadores; cambiar de codec de audio entre perfiles agrega una variable más a la hora de depurar un STB que "no reproduce" un canal específico.

El detalle que rompe el cambio de perfil: alineación de GOP

Esto es lo que más tickets genera y menos se explica: para que un reproductor cambie de un perfil a otro sin que se vea un corte o un congelamiento, los keyframes (los fotogramas de referencia completos, no diferenciales) de todos los perfiles tienen que caer exactamente en los mismos instantes de tiempo. Si el perfil de 1080p tiene un keyframe cada 2 segundos y el de 480p cada 3, el reproductor no tiene un punto limpio donde saltar de uno a otro — el resultado es un freeze de medio segundo o un salto visible cada vez que la red obliga a cambiar de calidad.

La regla es fijar el mismo intervalo de GOP (keyframe interval) en todos los perfiles de un mismo canal, y que ese intervalo coincida con la duración del segmento HLS. Si los segmentos HLS son de 4 segundos, el GOP también debería ser de 4 segundos (o un divisor exacto) en cada perfil — así cada segmento arranca exactamente en un keyframe, en todos los perfiles, y el cambio de calidad es invisible.

Ejemplo simplificado de configuración

Un perfil de transcodificación en Flussonic se define especificando codec, resolución, bitrate objetivo y el intervalo de keyframe explícito, en vez de dejarlo a discreción del encoder. Simplificado, la idea de un stream con tres perfiles se ve así:

stream canal-ejemplo {
  input rtsp://origen-tvheadend/canal-ejemplo;

  # Passthrough: el original se sirve tal cual, sin recodificar
  hls;

  # Perfil transcodificado 720p — dispositivos de gama media
  transcode {
    video_codec h264;
    size 1280x720;
    video_bitrate 2500k;
    gop 4s;
  }

  # Perfil transcodificado 480p — redes limitadas, STBs antiguos
  transcode {
    video_codec h264;
    size 854x480;
    video_bitrate 1000k;
    gop 4s;
    audio_codec aac;
  }
}

La sintaxis real de Flussonic tiene más matices (perfiles reutilizables, hardware acceleration, control de calidad por CRF o VBR), pero la estructura conceptual es esta: cada perfil declara explícitamente su GOP, y ese valor coincide entre todos.

CPU vs GPU: la decisión que más pesa en el presupuesto

Transcodificar por software (x264/x265 sobre CPU) da más control fino sobre calidad, pero escala mal — cada perfil adicional de cada canal es más núcleos ocupados de forma sostenida, y en una cabecera con varios canales al aire simultáneamente eso se convierte rápido en el cuello de botella del servidor. Transcodificar con aceleración por hardware (NVENC en GPUs NVIDIA, o los encoders integrados de algunas CPU) reduce drásticamente el costo por stream, a cambio de menos margen de ajuste fino sobre la calidad resultante y de la necesidad de tener ese hardware disponible en el servidor.

Para un equipo chico operando varios nodos, la decisión práctica suele ser: servidores de captación y passthrough sin GPU (no la necesitan, solo mueven bytes), y GPU concentrada en los nodos que sí transcodifican activamente, dimensionada según cuántos canales con cuántos perfiles van a correr en paralelo — no comprada de antemano "por si acaso" ni añadida canal por canal sin proyectar el total.

Monitoreo: lo que hay que vigilar además del stream

Con captación, lo que se monitorea es señal y bitrate por canal. Con transcodificación, se suma una capa: carga de CPU o de GPU por proceso de transcode, y latencia de encoding (cuánto tarda en producirse cada segmento respecto al tiempo real). Dos alertas que vale la pena tener activas:

• CPU/GPU sostenida cerca del límite en el nodo transcodificador — no como pico puntual, sino como tendencia; es la señal de que hace falta redistribuir canales entre nodos o reducir perfiles antes de que un canal nuevo tire todo al piso.
• Segmentos HLS que se generan más lento que la duración real del contenido — si un segmento de 4 segundos tarda más de 4 segundos en producirse, el buffer del reproductor se va vaciando y termina en rebuffering, aunque el canal "se vea bien" en el momento de revisarlo manualmente.

Errores que más tiempo cuestan en producción

1. GOP distinto entre perfiles

Ya descrito arriba, pero vale repetirlo porque es la causa más común de "el canal se congela un segundo cuando cambia de calidad" — un síntoma que se reporta como bug de reproductor cuando en realidad es un error de configuración del origen.

2. Escalera heredada sin revisar

Copiar la configuración de perfiles de un canal a otro sin ajustar por el contenido real (un canal de noticias con poco movimiento no necesita el mismo bitrate que uno de deportes) desperdicia CPU de forma sistemática en toda la cabecera, no solo en un canal.

3. Transcodificar tráfico interno entre nodos propios

El enlace entre Flussonic principal y secundario debe ser relay, no transcode — recodificar ahí no mejora nada para el usuario final y solo agrega latencia y carga a un tramo que no lo necesita.

4. Cambiar de codec de audio entre perfiles sin necesidad

Cuando un STB específico "no reproduce" un perfil pero sí otros, casi siempre la primera sospecha debería ser una diferencia de audio codec entre perfiles, no un problema de red — es más fácil de descartar de lo que parece y se pasa por alto seguido.

Checklist antes de dar por lista una escalera ABR

• Cada perfil responde a un dispositivo o condición de red real del portal, no a "por si acaso".
• El GOP es idéntico en todos los perfiles de un mismo canal y coincide con la duración del segmento HLS.
• El codec de video del perfil más bajo es compatible con el STB más limitado que hay que soportar.
• El tráfico entre nodos propios (backbone) usa passthrough, no transcodificación.
• Hay monitoreo de CPU/GPU por nodo transcodificador y de tiempo de generación de segmentos, no solo de bitrate del canal.
• La capacidad de GPU o CPU está dimensionada contra el total de canales y perfiles esperados, no añadida canal por canal sin proyección.

Cierre

ABR bien diseñado es invisible: el usuario nunca nota que su STB cambió de perfil, solo nota que el video no se congela. ABR mal diseñado también es invisible al principio — hasta que el servidor se queda sin CPU un día de mucho tráfico y el problema aparece en todos los canales a la vez, no solo en el que se configuró mal. La disciplina está en no transcodificar lo que no hace falta, y en tratar cada perfil adicional como el costo recurrente que realmente es.

Si estás diseñando o auditando la capa de transcodificación de una plataforma de streaming, hablemos.