Perfiles de resolución

El problema que resuelve

Una lista de reproducción maestra enumera varios escalones —por ejemplo 1080p, 720p y 480p— y un reproductor normal elige entre ellos midiendo su propio caudal. Cuando es una cabecera la que consume esa lista, esa adaptación no tiene sentido: el flujo va a un grupo multicast fijo que sirve a un conjunto fijo de televisores, con la calidad que resulte tener el primer escalón que acepte el motor.

En la práctica decide el orden del servidor de origen, y los servidores de origen enumeran primero su mejor escalón. El resultado habitual es que se descarga de forma continua un escalón de 1080p para alimentar pantallas de definición estándar en las habitaciones. No es un desperdicio menor: supone varias veces el ancho de banda para una imagen cuya mejora nadie puede apreciar, multiplicado por cada canal del equipo, precisamente en los enlaces ascendentes limitados donde más daño hace.

Configurar un perfil de resolución en el canal le quita esa decisión al servidor de origen.

Los perfiles

Perfil	Altura objetivo	También se acepta
4k	2160	`uhd`, `2160p`
fullhd	1080	`1080p`
hd	720	`720p`
sd	576	`576p`, `480p`
mobile	360	`360p`, `low`
(vacío)	—	Predeterminado. La lista de reproducción maestra se entrega al motor sin cambios.

Vacío es el valor predeterminado y el que tienen todos los canales preexistentes. Esto es importante: añadir esta función no cambió nada en ningún canal ya configurado. Un perfil es algo que se activa canal por canal, no un comportamiento que llegó y empezó a reinterpretar sus listas de reproducción.

Cómo se selecciona una variante

Gana la altura más cercana. En caso de empate, gana el bitrate más alto.

Castmux lee la lista de reproducción maestra, toma el RESOLUTION declarado de cada variante y elige aquella cuya altura esté más cerca del objetivo del perfil. Si dos variantes están a la misma distancia, se elige la que anuncia mayor ancho de banda.

Deliberadamente, no se trata de «coincidencia exacta o fallo». Los servidores de origen publican la escalera que les parece, y 576p en particular es poco habitual en la práctica: la mayoría publica 480p en su lugar. Un canal que se niega a arrancar porque nadie sirve exactamente 576 líneas es estrictamente peor que un canal que emite en 480p y le informa de ello. No encontrar una coincidencia perfecta no es una condición de error; es el caso normal.

La insignia de coincidencia

La cabecera de la tarjeta del canal muestra las dos mitades de la decisión: lo que usted pidió y lo que realmente tenía el servidor de origen.

Insignia	Significado
HD	Se pidió 720p y existe un escalón de 720p. Coincidencia exacta.
4K (1080p)	Se pidió 4K; lo mejor que ofrece el servidor de origen es 1080p, y eso es lo que se está emitiendo. Se muestra en ámbar.
SD (480p)	Se pidieron 576 líneas; 480p era el escalón más cercano. Se muestra en ámbar.

El ámbar es información, no una avería. Indica que el perfil no pudo cumplirse exactamente y le dice qué se usó en su lugar. Un canal con una insignia ámbar funciona correctamente. Tratar el ámbar como una alarma genera un aluvión de falsos positivos con cualquier conjunto realista de servidores de origen, porque la mayoría de las escaleras no coincidirán exactamente con ningún conjunto fijo de alturas de perfil.

Cuando no se ha podido completar la consulta en absoluto, la insignia muestra el motivo en su tooltip. Es el primer sitio donde mirar cuando un canal no emite el escalón que esperaba.

La sustitución se hace en cada arranque y nunca se guarda

La configuración siempre contiene la URL de la lista de reproducción maestra que usted introdujo. Cuando un canal arranca, Castmux resuelve la variante y entrega esa URL al motor solo para esa ejecución. No se escribe nada de vuelta.

Conviene ser tajante en esto, porque escribir la URL de la variante en la configuración parece una optimización obvia y es una trampa por dos motivos distintos:

Fijaría el canal a un escalón que el servidor de origen puede retirar. Las escaleras cambian. Un servidor de origen que elimine su escalón de 480p el mes que viene deja a un canal fijado descargando una URL que ahora devuelve 404, para siempre, sin forma de volver a la lista de reproducción maestra salvo que un operador la vuelva a escribir.
Sería indistinguible de una elección del propio operador. Una vez que la URL de una variante está en el archivo de configuración, nada registra si una persona la puso ahí deliberadamente o si la sustituyó el software. Cualquier intento posterior de volver a resolverla correría el riesgo de sobrescribir una decisión deliberada.

Resolver en cada arranque cuesta una lectura de la lista de reproducción en caché y mantiene el canal siguiendo la escalera del servidor de origen, vaya adonde vaya.

Falla en modo abierto

La resolución del perfil está en la ruta de emisión, así que se degrada al comportamiento configurado y no a una pantalla en negro. En todos los casos siguientes se deja intacta la URL configurada, se registra el motivo y se arranca el canal:

No se puede acceder al servidor de origen o la descarga agota el tiempo de espera.
Resulta que la URL es una lista de reproducción de medios, no una maestra: no hay escalera entre la que elegir.
La maestra no incluye atributos RESOLUTION, así que no hay alturas que comparar.
La lista de reproducción tiene algún defecto de formato que impide leer las variantes.

En cada caso, el canal emite exactamente igual que lo haría sin un perfil configurado. El motivo no queda oculto: se registra y aparece en el tooltip de la insignia, para que pueda ver desde el panel por qué no se está aplicando un perfil.

Las consultas nunca bloquean la carga de una página

Los resultados se almacenan en caché —unos diez minutos si la consulta tiene éxito, un minuto tras un error— y se actualizan en segundo plano. Al cargar una página o responder a un sondeo de estado se lee la caché y se programa una actualización si la entrada está obsoleta; nunca se espera. El único lugar que espera una consulta en directo es un arranque del motor completamente en frío, donde de todos modos no hay nada que emitir.

El cálculo lo explica. Veinticinco canales, cada uno con un tiempo de espera de descarga de ocho segundos, en cada carga de página y cada sondeo, dan una interfaz que se queda colgada durante minutos cada vez que un servidor de origen va lento; y los servidores de origen van lentos justo cuando un operador intenta consultar el panel. La vida más corta de la caché tras un error existe para que un servidor de origen temporalmente averiado se reintente pronto en lugar de descartarse durante diez minutos.

Dos salvaguardas que conviene conocer

Ambas existen porque la implementación ingenua pone en el aire un canal averiado mientras informa de éxito.

Se omiten las variantes solo de audio

Muchas escaleras incluyen una variante solo de audio. No lleva atributo RESOLUTION, así que su altura se lee como cero, y una comparación ingenua de altura más cercana con el objetivo de 360 del perfil mobile la convierte en ganadora frente a todos los escalones de vídeo reales. El canal arranca entonces, informa de que está sano, genera paquetes y pone en el aire una lista de reproducción sin vídeo.

Por eso, las variantes sin atributo RESOLUTION quedan totalmente excluidas de la selección.

Se rechaza una escalera con audio separado

Si la maestra declara audio con #EXT-X-MEDIA:TYPE=AUDIO y esa declaración tiene su propio URI=, el audio no está dentro de los segmentos de vídeo. Es una variante independiente que se espera que el cliente descargue junto con el vídeo y combine por su cuenta.

Seleccionar una variante de vídeo de una escalera así entregaría al motor una lista de reproducción con vídeo y nada más. El resultado es vídeo sin sonido en el aire: un canal que parece perfecto en todos los indicadores y no tiene audio.

Por eso Castmux lo rechaza. Un canal cuya maestra anuncia una escalera de audio separado conserva su URL maestra, se sigue aplicando la gestión de audio de la propia maestra y la insignia indica el motivo. No hay solución parcial: un motor que recibe una sola URL no puede volver a unir dos variantes, y conseguirlo requiere una segunda entrada y un mapeo explícito de flujos, lo que cambia por completo la estructura del canal.

Solo HLS

Los perfiles de resolución se aplican a fuentes HLS y a nada más. SRT y RTMP entregan una única codificación fija sin escalera entre la que elegir, así que no hay nada que consultar.

No se trata solo de que «se ignore el ajuste». Para un canal que no sea HLS no se realiza ninguna petición HTTP. Esa distinción importa porque, cuando se hace mal, el modo de fallo es desagradable y silencioso: lanzar un HTTP GET a una URL srt:// en cada carga de página y cada sondeo de estado, para cada canal SRT del equipo, lo que genera latencia y ruido en los registros que parecen salir de la nada.

Ejemplo práctico

Un servidor de origen publica esta escalera:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5200000,RESOLUTION=1920x1080
v1080.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
v720.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
v480.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=96000,CODECS="mp4a.40.2"
audio.m3u8

El canal está configurado con resolution_profile: sd, cuyo objetivo es 576 líneas.

Primero se descarta la variante solo de audio: no tiene atributo RESOLUTION. Sin ese paso obtendría una altura de cero y ganaría directamente con el perfil mobile.
Se calculan las distancias a 576 para el resto: 1080p está a 504, 720p a 144 y 480p a 96.
480p es el más cercano, así que se entrega v480.m3u8 al motor para esta ejecución. La configuración sigue conteniendo la URL maestra.

La cabecera de la tarjeta muestra SD (480p) en ámbar: se pidió 576, 480p era lo más cercano que tenía el servidor de origen y el canal lo está emitiendo correctamente.