Documentación de usuario¶

Planificación y protocolos de transmisión de datos¶

El programa Perfect Streamer está pensado para transmitir flujos MPEG-TS por la red pública de Internet con pérdidas y latencias, sobre UDP.

Para cada flujo MPEG-TS (Stream) se configura un transmisor (Sender) y uno o varios receptores (Receiver); el conjunto se denomina Peer.

La configuración del transmisor y del receptor se reduce a introducir una lista de flujos (Stream) y los ajustes de input y output para cada Stream. Varios input en la lista proporcionan redundancia de fuentes. Varios output en la lista permiten transmitir los flujos a distintos destinatarios al mismo tiempo.

Para el transmisor, input son las fuentes de flujos MPEG-TS, output la transmisión de los flujos a los receptores. Para los receptores, input es la recepción de los flujos del transmisor. Hay cuatro protocolos Peer disponibles para la transmisión entre transmisor y receptor:

Protocolo Perfect Stream (PS1).
SRT.
Pro-MPEG / RTP+FEC.
RIST.

Protocolo PS1¶

El protocolo PS1 funciona según Automatic Repeat reQuest (ARQ). Es de bajo consumo de recursos y permite transmitir flujos con bitrate alto.

En el transmisor — se configura en output. Solo está disponible una instancia por stream. Es necesario registrar en Peer los logins de los receptores. Se establece el UDP listen port, que debe ser único para cada stream.

En el receptor — se configura en input. Se indica el host y puerto del transmisor, además del login y contraseña.

Hay cifrado de flujos disponible (Crypto protection) con AES-128. Para activarlo en ambos lados, introduzca Crypt Passphrase como clave compartida.

Durante el funcionamiento, el receptor (cliente) envía sus estadísticas al transmisor (servidor). Se consultan en la sección Peers al elegir el cliente.

El retardo del flujo y la capacidad de corregir pérdidas dependen de los ajustes del receptor (cliente):

Round Trip Time — RTT en ms, por defecto 300. Latencia estimada (ping) del canal. Tras iniciar el flujo, el RTT real aparece en las estadísticas (PS1 recovery delay).

Client Latency (RTT multiplexor) — multiplicador del RTT (por defecto 10) que define la latencia del flujo en el buffer del emisor; con el valor por defecto resultan 3000 ms.

En el lado del emisor existe el ajuste de latencia (longitud del buffer) Latency (ms). Debe ser mayor que las latencias fijadas en los clientes.

La capacidad del protocolo para compensar pérdidas se determina por el número de solicitudes de retransmisión y depende de Client Latency (RTT multiplexor). Las grandes pérdidas generan tráfico de red adicional. Para reducir la latencia conviene afinar estos parámetros.

Para verificar el correcto funcionamiento del protocolo, ver las estadísticas del cliente. PS1 recovery: Not found → aumentar el buffer del emisor; Dublicates → aumentar el RTT.

Since the connection is initiated from the side of the receiver, the transmitter requires authentication, the receivers are registered in the peers section. Login and password required.

Protocolo SRT¶

Protocolo abierto desarrollado por Haivision. Basado en UDT; está ampliamente extendido y ofrece buenas características de compensación de pérdidas de paquetes.

Casos de uso:

Peer between two Perfect Streamer instances. On transmitter - endpoint is configured as output, listen mode (default). For one stream only one such output can be configured. Multiple receivers can be connected in this mode. For authorization, it is required to register receivers logins in Peer. On receiver - endpoint is configured as input. The host and port of the transmitter, have to be set up as well as login and password. Streamer uses stream ID in format «login|password» to transmit login and password in SRT.
Peer between Perfect Streamer and third-part SRT streamer. On transmitter you can set up srt client mode, switching off listen. SRT stream ID is entered in login field, if needed. For listen mode, the IP-address authorization is available - entered in login field in Peer. On receiver it is available to turn on listen mode, enter the SRT stream ID in the login field, also you can specify the host from which the connection is allowed.

Trabajo en modo Listener: recepción y transmisión del flujo del canal indicando el puerto de recepción.

Los puertos en modo listen deben ser únicos.

Hay cifrado de flujos disponible (Crypto protection) con AES-128. Para activarlo en ambos lados, introduzca Crypt Passphrase como clave compartida.

Si el transmisor usa el modo listen (predeterminado), la conexión la inicia el receptor, el transmisor exige autenticación y los receptores se registran en peer. Login y contraseña son obligatorios.

Las opciones del protocolo SRT siguen la descripción de https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md

Reorder (SRTO_LOSSMAXTTL) - Value up to which the reordering allowance can increase. Reordering allowance is the number of packets that must follow the detected «gap» in the order numbers of incoming packets, to send a report on loss (in the hope that the gap is caused by reordering of packets, not by loss). The reordering allowance starts at 0 and increases when reordering of packets is detected. This happens when a «late» packet with a sequence number older than the last received, but without the retransmission flag is received. At such detection, the reordering allowance is set to the value of the interval between the last number and the sequence number of this packet, but not more than the value set by the SRTO_LOSSMAXTTL parameter. By default, this value is 0, which means that this mechanism is disabled. https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#SRTO_LOSSMAXTTL

Overhead (SRTO_OHEADBW, %) — Sobrecarga para la recuperación de ancho de banda por encima de la tasa de entrada (ver SRTO_INPUTBW), en porcentaje de la tasa de entrada. Efectivo solo si SRTO_MAXBW está en 0. Emisor: configurable por el usuario; predeterminado: 25 %.

Recommendations: Overhead is intended to provide additional bandwidth capacity in case a packet has taken up some bandwidth but is then lost and needs to be retransmitted. Therefore, the effective maximum bandwidth should be sufficiently higher than the bitrate of your stream to leave room for retransmissions, while being limited so that retransmitted packets do not lead to a sharp increase in bandwidth usage when large groups of packets are lost. Do not set too low a value and avoid 0 if the SRTO_INPUTBW parameter is set to 0 (automatic). Otherwise, your stream will quickly interrupt with any increase in packet loss. https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#SRTO_OHEADBW

Max Band (SRTO_MAXBW, bps) — Esta opción es efectiva solo cuando SRTO_MAXBW está en 0 (relativo). Controla el ancho de banda máximo junto con SRTO_OHEADBW según la fórmula: MAXBW = INPUTBW * (100 + OHEADBW) / 100. Si esta opción está en 0 (automático), el valor real de INPUTBW se estimará a partir de la tasa del flujo de entrada (casos en los que la aplicación llama a la función srt_send*) durante la transmisión. El valor mínimo admisible de la estimación está limitado por SRTO_MININPUTBW, es decir, INPUTBW = MAX(INPUTBW_ESTIMATE; MININPUTBW).

Recomendaciones: establezca este parámetro en el bitrate esperado de su transmisión y mantenga el valor predeterminado de 25 % para SRTO_OHEADBW. https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#srto_inputbw

Timeout (SRTO_CONNTIMEO, ms) - Value of the connection timeout in milliseconds. This is the time during which the connecting object will try to connect and wait for a response from the remote endpoint, before terminating the connection with an error code. https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md#SRTO_CONNTIMEO

Protocolo Pro-MPEG / RTP+FEC (COP3 / SMPTE 2022-1/2)¶

Entrega de MPEG-TS sobre RTP con corrección anticipada de errores (FEC, Forward Error Correction). El mismo protocolo aparece en la literatura y los equipos bajo diferentes nombres:

Pro-MPEG / Pro-MPEG COP3 — Code of Practice #3 del foro Pro-MPEG, descrito en el estándar IEEE (https://ieeexplore.ieee.org/document/6738329);
RTP + FEC — nombre funcional (flujo RTP más canales FEC);
SMPTE 2022-1 — Column FEC (mismo esquema, publicado como estándar SMPTE);
SMPTE 2022-2 — Row + Column FEC (matriz bidimensional, implementada en PSS).

Достоинства — низкая задержка. Его недостаток — высокий дополнительный трафик (overhead), и он плохо работает при больших потерях пакетов (более 0.2%).

Этот протокол основан на RTP с добавлением 2-х каналов для FEC (кода коррекции ошибок). Два канала FEC используют порты port+2 и port+4, что надо учитывать при добавлении нескольких потоков на один хост или мультикаст группу.

En el emisor, el flujo de paquetes RTP se agrupa en una matriz de Cols columnas y Rows filas. Ejemplo para cols=8 y rows=4 (por defecto):

RTP01	RTP02	RTP03	RTP04	RTP05	RTP06	RTP07	RTP08	R1
RTP11	RTP12	RTP13	RTP14	RTP15	RTP16	RTP17	RTP18	R2
RTP21	RTP22	RTP23	RTP24	RTP25	RTP26	RTP27	RTP28	R3
RTP31	RTP32	RTP33	RTP34	RTP35	RTP36	RTP37	RTP38	R4
C1	C2	C3	C4	C5	C6	C7	C8

Los paquetes Rx y Cx forman los datos FEC por filas y columnas. Cuanto menor sea la matriz, mejor la capacidad de corregir pérdidas, pero mayor el tráfico adicional. En este ejemplo hay 12 paquetes FEC por cada 32 paquetes RTP del flujo.

Доступно шифрование потоков (Crypto protection), используется AES-128, но это не включено в стандарт, поэтому не гарантируется совместимость со сторонним ПО или оборудованием.

Existen extensiones no estándar del protocolo:

Multiplexing — мультиплексирование RTP каналов через один UDP порт. Может упростить настройку сети. Header XOR — обфускация RTP заголовка. Усложнит определение типа трафика в сети.

Protocolo RIST¶

Nuevo protocolo abierto basado en RTP/RTCP. Funciona según Automatic Repeat reQuest (ARQ) sin ACK, solo NACK, lo que asegura alta eficiencia.

Utiliza unicast y multicast.

Se implementan los perfiles Simple y Main. Simple usa dos puertos UDP consecutivos — el puerto configurado debe ser par. Main usa un único puerto RTP con multiplexación de datos.

On the transmitter - configured in output. For unicast, the address and port of the receiver are set. For multicast, the network interface through which the data will be transmitted must be set. Also, for multicast, authorization of receivers via IP address can be set if login is written in Peer.

En el receptor — se configura en input. Para unicast se define el puerto de recepción (listen) y obligatoriamente la interfaz de red. Para multicast solo se indica el grupo multicast y el puerto.

RIST admite varios peers (direcciones) separados. Con un peso superior a 1 se activa el balanceo de carga entre peers según ese peso.

If the transmitter uses multicast, there may be many receivers. In this case, authentication of receivers by IP address is possible. To do this, enable authentication in the transmitter settings (by default disabled) and add the client to the peer list, in the login field write the IP address.

Otros protocolos¶

Además de los protocolos peer, hay otros para recibir y transmitir flujos:

Protocol	Input	Output
UDP	Yes	Yes
RTP	Yes	Yes
TCP	Yes	No
HLS	Yes	Yes

UDP (unicast o multicast) — recepción y transmisión de MPEG-TS en paquete UDP, hasta 7 paquetes TS por UDP.

RTP (unicast o multicast) — protocolo estándar basado en RFC. Se admite la recuperación de paquetes reordenados.

TCP — recepción de MPEG-TS en conexión TCP, modo cliente TCP.

HLS — recepción y transmisión de MPEG-TS over HTTP o el protocolo HLS estándar de Apple. Al recibir una playlist adaptativa se elige el flujo con mayor bitrate.

Flujos con archivos y dispositivos¶

Para input y output está disponible el protocolo file/device para archivos y dispositivos.

output file/device — grabación en archivo o salida a dispositivo. La grabación en archivo puede requerirse para grabar en un archivo ts y posterior diagnóstico con otros analizadores. Salida a dispositivo — cualquier dispositivo (incluido SDI) registrado en /dev.

input file/device — reproducción cíclica del vídeo desde un archivo TS.

Al trabajar con archivos se indica la ruta completa al archivo en el campo File Path:: /catalog/stream.ts.

Al trabajar con dispositivos se activa además el indicador Is Device.

Lista de flujos permitidos y restricción del peer¶

Para poder limitar el acceso a los flujos de canales de TV por parte del cliente (Peer) en los modos SRT Listen, PS1, HLS y HTTP, el programa implementa la funcionalidad de lista de flujos permitidos. En los ajustes de Peer del transmisor se define la lista de canales disponibles. Para ello, en el campo Stream Access añada de la lista general de canales del servidor solo aquellos destinados a este Peer. Por defecto, con la lista vacía, todos los canales están disponibles.

Para un Peer se pueden definir límites de tiempo y de número de conexiones por protocolo de transporte.

Anonymous peer

Por defecto, el login del peer tiene el valor anonymous. El peer anónimo permite distribuir flujos sin vinculación a IP o login/contraseña. Aplican restricciones sobre el número de flujos entregados por protocolos de transporte, fecha límite y lista de flujos permitidos.

Es posible crear un peer individual por login (nombre) y contraseña.

Para autorizar peer por IP, active la opción «Login Is IP».

Opciones de autorización:

Por IP único
Por rango de IP, por ejemplo: «192.168.1.10-192.168.1.20»
Variante combinada, sintaxis de listas IP: ip[-ip2][,…]

Integración de aplicaciones de terceros¶

Para admitir otros protocolos no cubiertos por los medios integrados, es posible recibir y transmitir flujos a través de aplicaciones de consola externas. Para ello existe un protocolo std separado para input y output. El flujo MPEG-TS se recibe y transmite a través del flujo de entrada/salida del sistema operativo.

En el ajuste se indica la aplicación de consola (ruta absoluta) y la línea de comandos; también se pueden definir variables de entorno.

Para un input con aplicación externa hay que evitar mensajes en stdout: solo en stderr.

Para el output se puede configurar el empaquetado hasta 7 paquetes MPEG-TS.

Requisitos del flujo de entrada¶

Cumple ISO 13818-1, Single Program (SPTS) o Multi Program Transport Stream (MPTS). Las particularidades de MPTS se describen más abajo; los siguientes ajustes son para SPTS.

Se requiere al menos una pista de audio.

Se admiten flujos sin vídeo, se activan con el modo Radio.

Se soportan flujos codificados; para ello hay que activar Scrambled Stream.

Para la sincronización el flujo debe contener marcas PCR válidas.

Ajustes del Stream¶

Asigne un nombre único al stream usando letras latinas, dígitos y «_»/«-». Además se puede definir un nombre de visualización que admite ruso y otros idiomas.

Stream Timeout — tiempo de espera global del stream. Si no llega flujo de entrada válido en ese tiempo, se reinicia por completo.

Pause — pone el stream y todos los input y output en estado inactivo. Por defecto, los stream, input y output recién añadidos quedan en pausa e inactivos.

El programa comprueba la validez del flujo de entrada en el input. Si no pasa la comprobación, el input se considera averiado.

Check Interval — intervalo de re-verificación del flujo.

Ajustes de filtrado MPEG-TS:

Remove All Unnecessary Data — elimina todos los datos innecesarios excepto PAT/PMT, vídeo y audio, salvo lo definido en los filtros aparte (ver abajo)

Remove SDT — eliminar los datos SDT (nombre de canal, proveedor, etc.).

Remove EIT/EPG — eliminar los datos EPG.

Remove Teletext — eliminar el teletexto.

Remove Subtitles — eliminar los subtítulos.

Control de bitrate del flujo:

Bitrate mode — modo de control del bitrate.

Origin (default) — el flujo se transmite sin cambios.
VBR — elimina paquetes NULL para minimizar el bitrate. Active si los flujos se usan solo para difusión OTT.
CBR auto — activa el alineado de bitrate insertando paquetes NULL (stuffing). El bitrate resultante se ajusta al bitrate máximo del flujo de entrada.
CBR set stuffing bitrate — fijar explícitamente el bitrate deseado. Si es menor que el del flujo de entrada, se ajusta como en CBR Auto.

Con el modo CBR activado, la PCR Accuracy cumple TR 101 290; el intervalo PCR queda como en el flujo original.

Corrección de flujos:

Fix PAT/PMT interval — corrige el intervalo para cumplir con TR 101 290 insertando PAT/PMT adicionales.

Redundancia de fuentes¶

Se puede definir una lista de varios input, pero solo uno está activo. Si falla, se intenta el siguiente de la lista, y así sucesivamente de forma cíclica.

Si en stream se activa Fallback Check, durante el funcionamiento de un input de respaldo (no el primero de la lista) se realizará una recomprobación de los superiores en la lista en el intervalo Check Interval. Si en la recomprobación el flujo es válido, stream cambia a él.

El orden de los input importa, por lo que puede cambiarse. Un input en pausa no se tiene en cuenta durante el funcionamiento.

Filtrado y modificación de MPEG-TS¶

Por defecto el flujo MPEG-TS se transmite sin cambios.

Para cada input están disponibles las siguientes opciones de filtrado MPEG-TS:

PID Accept — lista de PIDs permitidos. Si está vacía, se permite todo excepto PID Reject.

PID Reject — lista de PIDs prohibidos. Tiene prioridad sobre PID Accept.

Es posible cambiar los PIDs introduciendo las listas PID Old y PID New.

Mapping PID and Languages — reasignación del idioma de las pistas de audio.

Default Language — asignar el idioma por defecto cuando la pista de audio no tenga uno.

Para el stream se pueden asignar nuevos datos MPEG-TS (tabla SDT):

MPEG-TS Network ID
Service Name
Provider Name
Language

Flujos MPTS¶

Flujo MPTS — flujo MPEG-TS con varios flujos (servicios); cada servicio tiene un número único (PNR). Se usa para emisión DVB.

Para los flujos MPTS no hay opciones de filtrado. Los flujos se transmiten sin cambios.

La función mosaic está desactivada por defecto. No se recomienda activarla en CPUs débiles: puede añadir jitter.

En el diagnóstico del flujo se muestran los datos de cada programa por separado y la estadística global.

Demultiplexor¶

Extracts individual streams from MTPS stream. To do this, add input of demux type to the SPTS stream, select a source and a PNR service. If the source MPTS is active, then a list will be available when selecting the PNR, otherwise you need to set the PNR manually.

Multiplexor¶

Compone un flujo MPTS a partir de flujos SPTS individuales. Para configurarlo:

Crear un stream MPTS.
Añadir un input de tipo muxer. Definir el bitrate para alinear el flujo CBR (stuffing, conformidad TR 101 290 y T-STD).
Si se establece 0 (predeterminado), no habrá alineación — el bitrate corresponderá a los flujos de entrada. Allí también pueden indicarse algunos parámetros del flujo MPEG-TS; para la mayoría de aplicaciones los valores predeterminados son adecuados.
En el Stream de origen añada un output de tipo muxer. Indique el nombre del servicio y, si procede, del proveedor. Si no usa alfabeto latino, seleccione el idioma en los ajustes MPEG-TS del stream.
Repetir para todas las fuentes.

El multiplexor genera para el flujo SDT, NIT y TDT/TOT (marcas de tiempo). El EIT (EPG) se toma de los flujos de origen. Se asignan PIDs nuevos.

Flujos de prueba¶

Test Stream generator - test stream (test card). It allows to create generated video streams as plugs for broadcasting or failures on main streams. It is possible to set the type of image, sound, overlay text and time.

Se configura activando el tipo de input correspondiente en el stream. Se puede definir el tipo de formato de vídeo, resolución, bitrate, volumen y frecuencia de audio, etc.

La lista de Test Streams disponibles está en el menú lateral izquierdo del programa.

Servicio OTT¶

Emite flujos por protocolos basados en HTTP — HLS, MPEG-DASH (desde la versión 1.12) y MPEG-TS over HTTP. Soporta HTTPS (SSL). La emisión se activa en la pestaña OTT de los ajustes Stream.

Las URL de conexión tienen el formato:

http://host:port/http/stream/login/password — autorización por login y contraseña
http://host:port/http/stream/login — autorización por login (token)
http://host:port/http/stream/ — autorización por IP

host y port se configuran en los ajustes de http server.

stream — ID del stream. No confundir con el número de orden en la lista de streams. El ID se muestra en la parte superior de la página de estadísticas del stream y en la columna ID de la lista de streams; se establece al crear el stream y nunca cambia.

De forma similar para HLS y DASH:

En la página de estadísticas del stream se muestran las URLs de los protocolos conectados (como plantilla) y su estado actual. El acceso no autorizado está prohibido; los clientes deben estar declarados en Peers.

Para HLS la URL admite parámetros adicionales (opcionales):

[URL]?a=1&s=40&m=40&v=5

a: 1 — rutas absolutas en la playlist (por defecto), 0 — rutas relativas.
s: duración de la playlist dinámica (s), 40 s por defecto.
m: duración mínima de la playlist dinámica (s), 40 s por defecto. Tamaño máximo de la playlist dinámica 60 s. Si el tamaño actual del búfer de chunks es menor que el mínimo solicitado, se devolverá el error 404. Esto se hace para que HLS arranque desde un búfer de chunks ya lleno en el servidor.
v: versión del protocolo HLS indicada en la playlist. Por defecto 5; algunos clientes HLS pueden requerir cambiarla.

Para compatibilidad con algunos clientes HLS se puede añadir el nombre de archivo index.m3u8 a la URL, p. ej. http://host:port/hls/stream/login/password/index.m3u8.

Hay 2 modos de funcionamiento del servidor HLS — Peer mode y OTT mode.

Peer mode — modo con segmentación (chunks) simple. Recomendado para peering / distribución de flujos.

OTT mode — modo con una segmentación optimizada para emisión OTT y arranque rápido de los reproductores. La carga de CPU es mayor; recomendado para emisión.

Se puede habilitar SSL (HTTPS) en el servidor HTTP desde sus ajustes.

Chunk Min Interval y Chunk Max Interval

In OTT mode, the stream is analyzed on PAT/PMT/SPS/PPS/IFrame and chunks are cut by the fast start players criterion. Analysis starts with min interval and if for some reason the data is not found, the chunk is forcibly cut by max interval.

HLS Adaptive Multistream

Desde la versión 1.10 se soporta HLS Adaptive Multistream y desde la 1.12 DASH Adaptive Multistream

Para los flujos adaptativos se configura una playlist HLS dedicada. Para ello:

En los flujos que se incluirán en la playlist adaptativa, activar HLS con OTT Mode.
En el menú principal aparecerá la sección de flujos adaptativos. Allí hay que añadir un flujo e indicar todos los flujos que deben incluirse en esa playlist.
A los flujos se les puede asignar un parámetro de bitrate. Por defecto 0 significa que se usa el valor medido; en caso contrario se puede fijar explícitamente.

Para playlists adaptativas la URL es distinta:

A los peers (clientes) se les pueden imponer restricciones de acceso a los flujos adaptativos, igual que a los normales. El permiso para un flujo adaptativo incluye el permiso para todos los flujos que lo componen.

Modelo de caché para OTT HLS y DASH.¶

El servidor genera respuestas en tres categorías, que difieren en la vida útil del contenido y en su idoneidad para cacheo en nodos intermedios (reverse proxy, CDN, caché del cliente).

1. Modelo de caché¶

1.1. Recursos y cabeceras HTTP¶

Recurso	URL	Content-Type	Cache-Control
Segmento TS	`/h<sess>/<keyID>.ts`, `/h<sess>/<subID>/<keyID>.ts`	`video/mp2t`	`public, max-age=60, immutable`
DASH MPD	`/h<sess>/index.mpd`	`application/dash+xml; charset=utf-8`	`public, max-age=1`
HLS master	`/hls/<stream>/<login>/<pass>/index.m3u8`	`application/vnd.apple.mpegurl`	`public, max-age=1`
HLS media	`/h<sess>/index.m3u8`, `/h<sess>/<subID>/index.m3u8`	`application/vnd.apple.mpegurl`	`public, max-age=1`
302 Redirect	`/dash/<stream>/<login>/<pass>/index.mpd`	—	`no-cache, no-store`
Raw TS	`/http/<stream>/<login>/<pass>`	`video/mp2t`	no establecido; no se cachea

1.2. Características de los segmentos TS¶

El identificador keyID se forma como CRC64(startTime || streamID) y es globalmente único. La URL de un segmento direcciona contenido inmutable — ante solicitudes repetidas de la misma URL se devuelve un flujo de bytes idéntico (mientras el segmento permanezca dentro de la ventana deslizante).

La directiva immutable suprime la revalidación condicional del cliente (If-None-Match, If-Modified-Since). El valor max-age=60 es compatible con un timeShiftBufferDepth=40s típico.

1.3. Características de los manifiestos¶

max-age=1 limita el límite superior de obsolescencia del contenido en caché a un segundo. Junto con proxy_cache_lock on (nginx), los picos de solicitudes al manifiesto se coalescen en una única solicitud al origen por segundo.

1.4. Variabilidad del contenido¶

Con absPath=0 (por defecto, sin el parámetro de URL «a»), los manifiestos HLS media y DASH MPD no contienen el identificador de sesión en el cuerpo. El contenido del manifiesto es idéntico entre sesiones pertenecientes a una misma combinación (stream, param). Esto permite que el caché del reverse-proxy reutilice una entrada entre sesiones con normalización de la clave de caché.

Con absPath=1 (parámetro de URL «a=1»), el cuerpo del manifiesto contiene URL absolutas que incluyen esquema, host e identificador de sesión. El contenido se vuelve específico de la sesión — la reutilización del caché entre sesiones deja de ser posible.

2. Comportamiento de los clientes¶

Cliente	URL de actualización del manifest	Impacto en el número de sesiones
VLC 3.x HLS	`/h<sess>/index.m3u8`	Una sesión por reproducción
VLC 3.x DASH	`/dash/<stream>/.../index.mpd`	Se gestiona mediante session reuse (ver 3.3)
ffmpeg 5.x HLS	`/h<sess>/index.m3u8`	Una sesión por reproducción
ffmpeg 5.x DASH	`/dash/<stream>/.../index.mpd` (bucle de repetición)	Se gestiona mediante session reuse (ver 3.3)
dash.js, hls.js	`/h<sess>/...` a través de `<Location>` / URL de sesión	Una sesión por reproducción

3. Mecanismos especiales¶

3.1. HTTP 302 Redirect para DASH¶

Una solicitud de la forma /dash/<stream>/<login>/<pass>/index.mpd devuelve la respuesta 302 Found con la cabecera Location: /h<sess>/index.mpd. El cuerpo de la respuesta es vacío. La autenticación y la asignación de la sesión ocurren durante el procesamiento de la redirección.

Los clientes que admiten caché de redirecciones acceden directamente a la URL de la sesión en las solicitudes posteriores. Los clientes que no la admiten repiten la solicitud de redirección. El coste del reprocesamiento de la redirección se limita a la verificación de autenticación y a las operaciones de session reuse.

3.2. Session reuse para DASH¶

En el procesamiento de la solicitud /dash/.../index.mpd ejecutada bajo login-id L para stream-id S y la flag adaptive=A, si en _ottClientList ya existe una sesión DASH con los mismos (L, S, A), se devuelve su sessID. No se crea una nueva sesión y no se consume ningún slot maxConn.

Solo se aplica a DASH. HLS no necesita un mecanismo de reuse separado: los clientes HLS actualizan la media playlist mediante la URL de sesión y no disparan applyNewOTTSess en cada refresh.

3.3. Reutilización de segmentos entre sesiones¶

La ruta /h<sess>/<keyID>.ts es independiente de sess al resolver keyID en contenido: keyID identifica de forma unívoca el segmento dentro de las ChunkList registradas (ver _ottStreamList). Nginx con clave de caché normalizada (eliminando el prefijo /h<sess>/) sirve todas las solicitudes del mismo keyID desde una única entrada de caché.

4. Parámetros de solicitud¶

Parámetro	Valor por defecto	Impacto
`a`	`0`	`1` — URL absolutas en los manifest; `0` — relativas
`s`	`40`	`timeShiftBufferDepth` en segundos
`m`	`40`	Longitud mínima de ventana para emitir el manifest
`v`	`3`	`#EXT-X-VERSION` en HLS (DASH lo ignora)

Cambiar el parámetro mediante query string actualiza los valores guardados en la sesión al próximo applyNewOTTSess.

5. Características de carga¶

La carga sobre el origen escala con el número de streams distintos vistos simultáneamente. El aumento del número de clientes que ven el mismo stream no incrementa el número de solicitudes al origen cuando hay un caché reverse-proxy con clave de caché normalizada.

Escenario	Frecuencia de peticiones origin (ref.)
1 cliente por flujo X	MPD: 0.4 req/s, segment: 0.2 req/s
N clientes en un mismo flujo X (caché activada)	MPD: 1 req/s, segment: 0.2 req/s
N clientes ffmpeg en modo de reproducción sobre un mismo flujo	MPD: 1 req/s (con `proxy_cache_lock`)
N clientes en N flujos distintos	MPD: 0.4·N req/s, segment: 0.2·N req/s

6. Nginx como reverse proxy con caché¶

6.1. Configuración básica¶

proxy_cache_path /var/cache/nginx/pss_segments
    levels=1:2 keys_zone=pss_segments:100m
    max_size=20g inactive=30m use_temp_path=off;

proxy_cache_path /var/cache/nginx/pss_manifests
    levels=1:2 keys_zone=pss_manifests:10m
    max_size=256m inactive=5m use_temp_path=off;

upstream pss_backend {
    server 127.0.0.1:41972;
    keepalive 64;
}

map $uri $pss_cache_key {
    ~^/h[0-9a-f]{16}(?<tail>/.+\.(ts|m3u8))$  "stream:$tail";
    default                                     $uri;
}

server {
    listen 80;
    server_name stream.example.com;

    location ~* "^/h[0-9a-f]{16}(/[0-9]+)?/[0-9a-f]+\.ts$" {
        proxy_cache               pss_segments;
        proxy_cache_key           $pss_cache_key;
        proxy_cache_valid         200 60s;
        proxy_cache_valid         404 403 0s;
        proxy_cache_lock          on;
        proxy_cache_use_stale     updating error timeout;
        proxy_cache_revalidate    on;
        add_header                X-Cache-Status $upstream_cache_status;

        proxy_pass                http://pss_backend;
        proxy_http_version        1.1;
        proxy_set_header          Connection "";
        proxy_buffering           on;
    }

    location ~* "(^/h[0-9a-f]{16}(/[0-9]+)?/index\.(m3u8|mpd)$|^/(hls|dash)/.*\.(m3u8|mpd)$)" {
        proxy_cache               pss_manifests;
        proxy_cache_key           $pss_cache_key;
        proxy_cache_valid         200 1s;
        proxy_cache_valid         404 403 0s;
        proxy_cache_lock          on;
        proxy_cache_lock_timeout  2s;
        proxy_cache_use_stale     updating;
        add_header                X-Cache-Status $upstream_cache_status;

        proxy_pass                http://pss_backend;
        proxy_http_version        1.1;
        proxy_set_header          Connection "";
    }

    location / {
        proxy_pass                http://pss_backend;
        proxy_http_version        1.1;
        proxy_set_header          Connection "";
        proxy_set_header          X-Forwarded-Proto $scheme;
        proxy_set_header          X-Forwarded-Host  $host;
        proxy_buffering           off;
        proxy_read_timeout        3600s;
    }
}

6.2. Propósito de las directivas¶

Directiva	Propósito
`proxy_cache_lock on`	Serializa las peticiones upstream cuando hay cache miss simultáneos para la misma clave
`proxy_cache_use_stale updating`	Devuelve la copia obsoleta a peticiones paralelas durante la actualización de la caché
`proxy_cache_revalidate on`	Usa `If-Modified-Since` en cache miss con copia guardada
`proxy_cache_valid 404 403 0s`	Prohíbe la caché de errores de autorización y 404
`keepalive 64` en upstream	Mantiene un pool de conexiones persistentes al origin
`proxy_buffering on`	Para los segmentos; activa el bufferizado de la respuesta en nginx
`proxy_buffering off`	Para la sección `/`; desactiva el buffering (raw streaming)

6.3. Cálculo de `max_size` de la caché de segmentos¶

Valor orientativo: bitrate × timeShiftBufferDepth × distinct_streams × 2

Ejemplo: 10 flujos × 8 Mbps × 40 s × 2 ≈ 800 MB. Se recomienda un margen 10× para absorber la variabilidad del bitrate.

6.4. Terminación TLS¶

El servidor Perfect Streamer acepta conexiones en los puertos HTTP y HTTPS. Con terminación TLS en nginx, el upstream usa el puerto HTTP. El reenvío de las cabeceras X-Forwarded-Proto y X-Forwarded-Host es obligatorio para la formación correcta de URL absolutas cuando absPath=1.

server {
    listen 443 ssl http2;
    server_name stream.example.com;

    ssl_certificate           /etc/letsencrypt/live/stream.example.com/fullchain.pem;
    ssl_certificate_key       /etc/letsencrypt/live/stream.example.com/privkey.pem;
    ssl_protocols             TLSv1.2 TLSv1.3;
    ssl_session_cache         shared:SSL:10m;
    ssl_session_timeout       1d;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    location ... {
        proxy_pass                http://pss_backend;
        proxy_set_header          X-Forwarded-Proto https;
        proxy_set_header          X-Forwarded-Host  $host;
        proxy_set_header          Host              $host;
        # + директивы кеширования из 6.1
    }
}

server {
    listen 80;
    server_name stream.example.com;
    return 301 https://$host$request_uri;
}

Para HTTPS entre nginx y origin se usan proxy_ssl_verify y proxy_ssl_trusted_certificate. Para conexiones loopback el cifrado es redundante.

6.5. Multi-host¶

Si un mismo proceso nginx atiende varios server_name, se añade $host a la cache key para aislar el contenido:

map $uri $pss_cache_key {
    ~^/h[0-9a-f]{16}(?<tail>/.+\.(ts|m3u8))$  "$host:stream:$tail";
    default                                     "$host:$uri";
}

El tamaño de keys_zone se calcula como 8000 claves/MB. Para instalaciones multi-host con miles de flujos se recomienda keys_zone=...:300m o superior.

7. Caché en el cliente¶

Cache-Control: immutable lo respetan los navegadores Chrome/Firefox/Safari. El caché del cliente devuelve el segmento sin solicitud condicional al volver a acceder (incluido seek hacia atrás dentro del búfer del reproductor).

Los Service Workers pueden aplicar una estrategia cache-first basada en el contenido de Cache-Control. Los reproductores DASH (dash.js, Shaka) usan MSE a través de SourceBuffer; un segmento colocado en el búfer permanece disponible sin nueva solicitud HTTP hasta que sale de la ventana.

Para solicitudes entre dominios, la cabecera Access-Control-Allow-Origin: * permite el caché en shared caches sin Vary: Origin. Cambiar el valor de ACAO a un Origin específico requiere Vary: Origin, lo que reduce la eficiencia del shared cache.

8. Despliegue mediante CDN¶

Perfect Streamer es compatible con CDNs en modo pull-from-origin (Cloudflare, Akamai, Fastly, BunnyCDN, Amazon CloudFront).

Origin shield. Se recomienda colocar uno o varios nodos shield entre el edge del CDN y el origin para reducir la frecuencia de peticiones al origin cuando los clientes están distribuidos globalmente.

Purge. Los segmentos content-addressed no necesitan purge. Si cambian los metadatos del stream (códec, resolución), los manifiestos se actualizan dentro de max-age=1 sin purge explícito.

Cache warming. Ante un aumento previsto de carga en un stream, se puede precalentar la CDN desde varios puntos geográficos antes del inicio de la emisión.

Distribución geográfica. Los segmentos (max-age=60) son adecuados para caché distribuido geográficamente. Los manifiestos (max-age=1) toleran hasta un segundo de retardo de entrega — aceptable para live no low-latency.

9. Monitorización¶

9.1. `X-Cache-Status`¶

Añadir add_header X-Cache-Status $upstream_cache_status; en cada location con caché. Valores:

Valor	Descripción
`HIT`	Respuesta desde caché
`MISS`	No estaba en caché; obtenido del origin y almacenado
`EXPIRED`	Caducado, actualizado
`UPDATING`	Copia stale devuelta a una solicitud paralela durante la actualización
`STALE`	`use_stale` devolvió la copia caducada (origin no disponible)
`REVALIDATED`	Origin devolvió 304 Not Modified
`BYPASS`	Se activó `proxy_cache_bypass`

9.2. Formato del access-log¶

log_format pss_cache '$remote_addr $status $request_method "$request" '
                     '$body_bytes_sent rt=$request_time ut=$upstream_response_time '
                     'cache=$upstream_cache_status key=$pss_cache_key';

server {
    access_log /var/log/nginx/pss.log pss_cache;
}

9.3. Métricas¶

El módulo nginx-vts exporta métricas por zona en formato Prometheus:

GET /status/format/prometheus

Umbrales recomendados para alertas:

Métrica	Umbral	Causa posible
Segment HIT rate	< 90 % en 5 minutos	Normalización de cache key rota; `max_size` pequeño
Manifest MISS rate	> 50 % en 1 minuto	`proxy_cache_lock` no serializa las peticiones
Upstream response time p95	> 500 ms en 1 minuto	Sobrecarga del origin
Cache zone fill	> 90 % en 10 minutos	Aproximándose a `max_size`; se prevé desalojo LRU

10. Diagnóstico¶

Síntoma	Causa probable	Solución
Tasa HIT de segmento baja	`Vary: Origin` con alta variabilidad de Origin; normalización rota en `map`	Comprobar las cabeceras y la regex en la directiva `map`
404 en segmentos tras salir de la ventana	404 cacheado para un segmento que salió de la ventana deslizante	Añadir `proxy_cache_valid 404 0s` en la location segments
Retraso del inicio de reproducción 2–5 s	`proxy_cache_lock_timeout` supera la latencia objetivo	Reducir a 1–2 s; activar `proxy_cache_use_stale updating`
El manifest no se actualiza	`proxy_cache_valid` sobrescribe `max-age`	Establecer explícitamente `proxy_cache_valid 200 1s`
Aumento de TIME_WAIT en upstream	Falta `keepalive` en el bloque upstream	Añadir `keepalive 64`, `proxy_http_version 1.1`, `proxy_set_header Connection ""`
403 en `/dash/.../<segment>.ts` desde ffmpeg	El cliente resuelve URLs relativas frente a la URL previa al redirect	El servidor emite `<BaseURL>/h<sess>/</BaseURL>` (ruta absoluta); compatible en la build actual

11. Seguridad¶

11.1. Session URL¶

Una URL en el formato /h<sess>/... cumple la función de token de sesión — no requiere reautenticación. La duración está acotada por el idle timeout (valor 30 s). En caso de inactividad, la sesión es eliminada por la tarea cleaner.

Requisitos:

HTTPS en todas las rutas OTT (/hls/, /dash/, /h<sess>/) en producción
El Session ID en la cabecera Location del 302 no se cachea (no-cache, no-store)

11.2. Rate limiting¶

limit_req_zone $binary_remote_addr zone=dash_top:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=hls_top:10m  rate=5r/s;

server {
    location /dash/ {
        limit_req zone=dash_top burst=20 nodelay;
        proxy_pass http://pss_backend;
    }
    location /hls/ {
        limit_req zone=hls_top burst=20 nodelay;
        proxy_pass http://pss_backend;
    }
}

Las URLs de sesión (/h<sess>/) no requieren rate limiting — su procesamiento es barato y las respuestas se cachean.

11.3. Caché de respuestas de error¶

proxy_cache_valid 200 60s;
proxy_cache_valid 301 302 0s;
proxy_cache_valid 404 403 0s;
proxy_cache_valid any 1s;

Prohíbe la caché de redirecciones (sess único en Location) y de respuestas con errores de autorización o recurso inexistente.

11.4. Restricción del acceso de red al origin¶

El puerto 41972 (41982 para HTTPS) debe estar cerrado al tráfico externo. Configuraciones admitidas:

Bindear Perfect Streamer a 127.0.0.1 (con nginx local)
Regla de firewall:

iptables -A INPUT -p tcp --dport 41972 ! -s 10.0.0.0/8 -j DROP

12. Integración con middleware¶

12.1. Modelo prefix-login¶

Perfect Streamer permite delegar la identificación de usuarios a middleware/sistema de facturación mediante el mecanismo prefix-login. El conector externo al sistema de facturación no se incluye en la versión actual.

Configuración del usuario embedded:

{
  "id": 9,
  "login": "sub",
  "password": "xxx",
  "is-prefix": true,
  "max-conn-http-hls": 1,
  "accept-stream": [ ... ]
}

Con is-prefix: true el servidor acepta URLs cuyo login tiene la forma <prefix><billing_user_id>:

/dash/test1/sub42/xxx/index.mpd
/hls/test1/sub43/xxx/index.m3u8

12.2. Formato de estadísticas¶

<clients>
  <client login-id="-1974387287" login="sub" match-login="sub42"
          sess-id="11331..." ott-type="dash" stream-id="10000" .../>
  <client login-id="-2147031294" login="sub" match-login="sub43"
          sess-id="11132..." ott-type="dash" stream-id="10000" .../>
</clients>

El campo login-id contiene el hash del login URL. login es el valor configurado. match-login es el login URL usado por el cliente.

12.3. Limitaciones de prefix-login¶

Contraseña compartida. Todos los subscribers del pool prefix usan una sola contraseña. Su compromiso da acceso a cualquier <prefix><string>.
Granularidad de ACL. accept-stream se aplica a todo el pool prefix; no hay ACL por suscriptor sin facturación externa.
Rotación de contraseña. El cambio desconecta a todos los subscribers activos. Para una sustitución progresiva se requieren dos prefix-logins temporalmente.

13. Subtítulos WebVTT¶

La fuente de subtítulos es DVB Teletext / DVB Subtitling del MPEG-TS de entrada. Las pistas de subtítulos Teletext deben estar presentes en las secciones Media Information o Original Media Information. La sección Analyzer también permite verificar que los paquetes de los PID correspondientes están activos.

Para OTT HLS/DASH debe activarse el modo OTT (en Peer mode los subtítulos WebVTT no están disponibles). En la sección Output # OTT el contador de chunks OTT WebVTT buffer chunk count debe ser distinto de cero.

Para diagnosticar los subtítulos, activar Analyze y Trace en el stream. Al iniciar el flujo, el log del stream debe mostrar:

Start Teletext subtitle decoder
[ttxsubdec] ttx: pid=331 magazine=8 page=0x88 lang=***

A continuación, el log registra el texto decodificado de los subtítulos.

13.1. URL de los segmentos VTT¶

Esquema	URL	Contenido
HLS master	`/hls/.../index.m3u8`	`#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs",...,URI="/h<sess>/sub/<pid>/index.m3u8"`
HLS subtitle playlist	`/h<sess>/sub/<pid>/index.m3u8`	lista `<keyHex>.vtt` con `#EXTINF`
Segmento VTT HLS	`/h<sess>/sub/<pid>/<keyHex>.vtt`	VTT con X-TIMESTAMP-MAP estilo HLS
DASH MPD AdaptationSet	en `index.mpd`	`contentType="text" mimeType="text/vtt"` + `<SegmentTemplate media="$Number$.vtt">`
Segmento VTT DASH	`/h<sess>/sub/<pid>/<seq>.vtt`	VTT con X-TIMESTAMP-MAP estilo DASH

<keyHex> es el hex de 16 caracteres de CRC64(startTime, streamID, pid). <seq> es el número decimal del chunk en el subtitle storage (contador independiente del video storage).

DVR / Archivo¶

Desde la versión 1.13, Perfect Streamer incluye un DVR integrado — un archivo de flujo persistente en disco, paralelo a la salida OTT normal (HLS / DASH). El archivo se escribe automáticamente, sin proceso aparte, y se reproduce por las mismas URLs OTT que el live — única diferencia: el parámetro query.

Funcionalidades:

Grabación de cada flujo OTT al archivo en el almacenamiento elegido.
Reproducción HLS y DASH del archivo (VOD) en las mismas URLs que el live.
Subtítulos (WebVTT) — escritos junto con chunks TS.
Varios almacenamientos — un flujo se vincula a uno; flujos distintos pueden escribir a discos distintos.
Limpieza automática por tiempo de retención y uso del disco.
EPG-aligned VOD — archivo según evento EPG referenciado.
VOD adaptativo — soportado para grupos adaptativos.

El DVR no requiere licencia aparte. Se activa por flujo añadiendo una vinculación al almacenamiento.

El DVR no reemplaza el live. Si un flujo tiene archivo, el cliente recibe una playlist live idéntica a la sin DVR. El archivo solo se reproduce si el cliente solicita modo VOD vía parámetro query de URL (ver abajo).

Configuración del almacenamiento¶

Un almacenamiento es un registro en la sección Configuration / DVR Storage. Cada registro describe un directorio en disco donde PSS escribe ficheros del archivo. Un flujo usa un almacenamiento.

Al añadir un almacenamiento se configuran:

Name — nombre mostrado.

Dir Path — ruta al directorio en disco. Tras crear el registro, la ruta no se puede cambiar — para mover el archivo, eliminar el registro y añadir uno nuevo. Los ficheros existentes no se tocan en disco al eliminar el registro.

Max Usage, % — umbral de uso del disco (por defecto 90 %). Al superarlo, arranca la limpieza size-based (ver abajo). Mín 1 %, máx 100 %.

Cleanup Interval, seg — periodo de la tarea de limpieza (por defecto 10 seg). En cada tick se corta primero lo más antiguo que la profundidad de retención; luego, si supera Max Usage, chunks viejos.

Disk Pressure Grace, seg — segundos que Used % debe superar Max Usage continuamente antes de Size-based cleanup (por defecto 60 seg). Filtra picos cortos.

Disk Pressure Cut, seg — límite superior por tick de limpieza: segundos de vídeo por flujo borrables de una vez (por defecto 300 seg). El resto pasa al siguiente tick.

Disk Emergency Bytes — umbral de espacio libre bajo el cual el almacenamiento pasa a Error y la grabación para (por defecto 2 GiB). Recuperación auto si espacio libre ≥ 2 × este valor.

Alarm Disk-Full Hysteresis, % — ancho de la banda de histéresis al salir de DiskFullDegraded (por defecto 2 %).

La mayoría de valores por defecto sirven para instalaciones típicas; suele bastar ajustar Max Usage y Dir Path.

Un almacenamiento por disco es lo recomendado. Varios registros en el mismo disco con subdirectorios distintos compiten por el espacio libre — statvfs da la vista global, pero la limpieza es por registro.

Vinculación de un flujo al almacenamiento¶

En los ajustes Stream / OTT aparece una sección DVR:

Storage — lista desplegable de almacenamientos; 0 significa «archivo desactivado para este flujo».

Storage Hours — profundidad del archivo para este flujo, en horas. Chunks más viejos se borran en cada tick. 0 desactiva Rolling cleanup (sólo corre Size-based cleanup por Max Usage).

Storage Min Hour — umbral de protección inferior (horas). La limpieza nunca borra chunks más jóvenes, ni bajo presión Max Usage. Útil si la lógica de negocio exige una grabación reciente garantizada, p. ej. «las últimas 2 horas siempre presentes».

Cambio de Storage en caliente:

poner 0 — desactiva el archivo; los chunks en disco se conservan, no se escriben nuevos. Las sesiones VOD empiezan a devolver 404;
elegir otro almacenamiento — el flujo se desvincula del antiguo y empieza a escribir en el nuevo. Los ficheros del antiguo no se migran.

Los cambios en Storage Hours y Storage Min Hour se aplican al instante — la limpieza usa el nuevo valor en el siguiente tick.

Tras la configuración, el flujo escribe el archivo automáticamente al entrar en Running.

VOD: reproducción del archivo¶

El archivo se reproduce por las mismas URLs que el live HLS / DASH (ver sección OTT service) — sólo cambia el parámetro query.

URLs y parámetros¶

URLs para HLS y DASH:

Sin parámetros query — live normal con ventana deslizante. Con el parámetro t — modo VOD.

Parámetro	Propósito
`t=<epoch>`	Hora de inicio VOD (Unix epoch, seg). t=0 — desde el inicio del archivo. La presencia de t (incluso t=0) activa el modo VOD.
`d=<sec>`	Duración de la ventana VOD, seg. d=0 o ausente — «hasta el momento actual». Sólo tiene sentido con t.
`epg=<epoch>`	EPG-aligned VOD: el servidor localiza el evento EPG activo en el momento dado y toma sus start y duration como bordes de la ventana. Incompatible con t y d (sustitución server-side). Ver abajo.
`a`, `s`, `m`, `v`	Parámetros live estándar (ver OTT service); `s` y `m` se ignoran en modo VOD.

Comportamiento según t y d:

t	d	Ventana	Condición 404
no	—	live (ventana deslizante)	—
0	ninguno / 0	[inicio archivo, ahora]	DVR no vinculado
0	> 0	[inicio archivo, +d]	DVR no vinculado
> 0	ninguno / 0	[t, ahora]	DVR no vinculado
> 0	> 0	[t, t+d]	DVR no vinculado

Normalización de bordes:

t anterior al inicio del archivo — start se alinea automáticamente al primer chunk disponible (la limpieza pudo recortarlo). No es 404 — se sirve lo que queda.
t en el futuro o ventana totalmente anterior al archivo — playlist vacía pero válida (HLS: sólo header + EXT-X-ENDLIST; DASH: @type="static", mediaPresentationDuration="PT0S").
Los chunks se eligen estrictamente por startTime ∈ [t, t+d) — sin segmentos parciales.

VOD en un flujo sin archivo (o cuyo almacenamiento está en Error) — 404 inmediato sobre master playlist / MPD. No se crea sesión.

Texto de error en el cuerpo 404 (visible en logs del servidor y HTTP body):

VOD: stream not running — el flujo está en la config pero no en Running.
VOD: no DVR archive — el flujo no tiene almacenamiento o está en Error.
VOD: DVR detached — el flujo se desvinculó del almacenamiento entre peticiones.
VOD: EPG event not found — sin evento para ?epg=.

Playlist HLS VOD — cerrada (el reproductor ve la duración y puede buscar):

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:5.000,
...
#EXT-X-ENDLIST

Estos marcadores no están en la playlist live — esa es la única diferencia.

MPD DASH VOD — estático: @type="static", mediaPresentationDuration fijo, <SegmentURL> explícitos. El DASH live sigue @type="dynamic".

Si el intervalo elegido tiene huecos en el archivo (p. ej. reinicio de grabación o limpieza en medio), el MPD DASH se divide automáticamente en varios <Period> — uno por pista contigua. Los reproductores (VLC, dashjs, Shaka) cruzan los bordes de periodo sin configuración especial.

EPG-aligned VOD¶

Si el flujo está vinculado a una fuente EPG (campos EPG Source y EPG Channel en los ajustes), el cliente puede solicitar el archivo por un momento contenido en un evento EPG:

El servidor localiza el evento EPG activo en el epoch dado y usa sus start y duration como bordes de la ventana VOD. Útil para catálogos: la UI conoce la hora del evento pero no debe calcular bordes exactos.

Si el flujo no está vinculado a EPG o no hay evento activo — 404 ``VOD: EPG event not found``. t y d se ignoran si está epg.

Flujos adaptativos¶

Los grupos adaptativos (ver HLS Adaptive Multistream) admiten los mismos parámetros VOD:

En la master playlist (HLS) sólo entran las variantes con almacenamiento DVR configurado. Las variantes sin DVR se omiten (en el log aparece VOD: variant N has no DVR); el ensamblado sigue con las demás.

En la variante DASH, cada calidad se vuelve un <Representation> distinto en <Period> comunes; el reproductor cambia de calidad sin reabrir el manifiesto.

Comportamiento del reproductor¶

El VOD HLS / DASH del archivo se reproduce en reproductores estándar: VLC, hls.js, dashjs, Shaka, ffmpeg. La búsqueda en timeline funciona.

Si el reproductor pide un segmento ya borrado por la limpieza, el servidor devuelve 404 para ese segmento (no 500). VLC, hls.js, dashjs lo saltan y siguen con el siguiente.

Capacidades adicionales:

Protección de sesiones activas: con sesión VOD abierta, la limpieza no borra chunks dentro de su ventana (ver abajo).
Live-edge bridge: si un cliente en sesión VOD pide un segmento más allá de vodEnd — p. ej. avanza en la timeline al final del archivo — el servidor sirve el segmento desde la memoria live. Sin redirecciones ni reautenticación.
Caché de playlist: ante peticiones repetidas del mismo VOD index.m3u8 / index.mpd, el servidor devuelve respuesta idéntica byte a byte — sin reconstruir. Apto para CDN delante de PSS.

Subtítulos en el archivo¶

Si el flujo lleva subtítulos (DVB Subtitling, Teletext o WebVTT) y la opción OTT WebVTT está activa, los subtítulos se archivan en paralelo con los chunks TS — en ficheros .vtt junto a .ts.

En modo live, la master playlist contiene EXT-X-MEDIA:TYPE=SUBTITLES; en modo VOD, el servidor devuelve una playlist VOD de subtítulos (con ENDLIST) y segmentos .vtt en las mismas URLs.

Particularidades:

HLS: la cabecera X-TIMESTAMP-MAP se conserva al inicio de cada .vtt (requerida por la spec HLS).
DASH: la cabecera X-TIMESTAMP-MAP se elimina al vuelo (ligada al PCR absoluto, choca con el anclaje DASH; si no, VLC muestra subtítulos vacíos).
En grupo adaptativo: si el sub-stream activo no escribe subtítulos, los segmentos VTT devuelven 404. En la siguiente variante, el reproductor podrá recibirlos otra vez.

Los subtítulos se desactivan vía OTT WebVTT en el flujo, o no activando HLS en modo OTT.

Limpieza y retención¶

PSS usa dos estrategias de limpieza que corren en cada tick (por defecto cada 10 seg):

Rolling cleanup (por flujo): por cada flujo se borran chunks más viejos que Storage Hours. Corre siempre, aun con disco a medias.
Size-based cleanup (por almacenamiento): cuando Used % supera Max Usage continuamente durante Disk Pressure Grace seg, los chunks más viejos se cortan proporcionalmente entre los flujos vinculados. Por tick: Disk Pressure Cut seg de vídeo por flujo. Nunca chunks más jóvenes que Storage Min Hour.
Emergency disk-full cut: si el espacio libre cae bajo Disk Emergency Bytes, la limpieza es agresiva y puede borrar incluso chunks protegidos por sesión. La grabación para hasta que el espacio libre se recupere con histéresis × 2.
Orphan scan (cada hora): pueden quedar ficheros no contabilizados en el índice (tras parada abrupta de PSS). Una vez por hora, el scanner recorre los subdirectorios de los flujos y borra estos ficheros «olvidados». Anti-race con el writer — se saltan ficheros menores de 60 seg.

Nota. Las tareas de limpieza corren en segundo plano; el usuario normalmente no actúa. Si el archivo crece más rápido de lo que se corta, bajar Storage Hours en los flujos o subir Disk Pressure Cut.

Protección de sesiones VOD activas¶

Al abrir una sesión VOD, en cada almacenamiento implicado se registra un «slot de protección» con la hora de inicio de la ventana. Las limpiezas Rolling y size-based no tocan chunks dentro de la ventana de la sesión abierta. El slot se libera automáticamente al cerrar (FIN, timeout).

Esto significa:

Si un cliente mantiene una sesión VOD largo tiempo, puede buscar a cualquier instante de su ventana — los chunks no «desaparecen bajo él».
La limpieza por Max Usage puede no llevar Used % al umbral mientras la sesión está activa; al irse el cliente, la limpieza alcanza.
Emergency disk-full cut y Storage Min Hour saltan la protección: si el disco está casi sin libre, los chunks se borran y el cliente recibe 404 en los segmentos afectados (el reproductor los salta).
Tras reiniciar PSS, los slots de protección desaparecen — la limpieza reanuda al instante.

Varios almacenamientos¶

Se puede crear cualquier número de registros DVR Storage — uno por directorio / disco. Los flujos se vinculan a distintos almacenamientos de forma independiente. La limpieza y umbrales (Max Usage, Disk Pressure) operan por almacenamiento.

Casos de uso:

Tiering por valor: almacenamiento SSD rápido para canales premium con gran profundidad, HDD capacitivo para el resto.
Disco dedicado al archivo: para que la grabación DVR no compita con el disco del sistema o ficheros temporales.
Separación por proyecto: un disco para el lote nº 1, otro para el nº 2 — simplifica migración y auditoría.

Cambiar la vinculación del flujo (campo Storage en Stream / OTT) conmuta la grabación al vuelo. Los ficheros antiguos quedan intactos en el disco previo — pueden borrarse a mano o reanudar la grabación devolviendo el flujo.

Estado del almacenamiento y monitorización¶

La sección Data / DVR Storage List (y la API GET /data/dvr-storage-list) muestra por almacenamiento:

State — Ready / DiskFullDegraded / Error.
Total / Free / Used Bytes — estadísticas disco (statvfs).
Used % — porcentaje actual de uso.
Archived Bytes — tamaño total de chunks indexados de todos los flujos vinculados (sin orphans).
Attached Streams — número de flujos vinculados a este almacenamiento.
Pressure Since Sec — momento (epoch) en que Used % superó por primera vez Max Usage en este episodio; 0 significa «sin presión».

Estados:

Ready — operación normal.
DiskFullDegraded — espacio libre < (Disk Emergency Bytes × 2); la grabación sigue pero puede pasar a Error en cualquier momento.
Error — espacio libre < Disk Emergency Bytes; grabación parada; reinicio por histéresis.

Si el almacenamiento está en Error, comprueba el espacio libre; PSS no sale solo de este estado hasta que haya más espacio físico.

Protección contra pérdida accidental¶

Varias operaciones del admin causan pérdida del archivo o cese de la entrega VOD. Antes de ejecutarlas, el UI muestra confirmación modal:

Eliminar DVR Storage — todos los flujos vinculados pierden acceso VOD; los ficheros quedan en disco pero son inalcanzables vía PSS sin el registro.
Cambiar el flujo a otro almacenamiento — el VOD sobre el archivo antiguo deja de funcionar.
Desvincular el flujo del almacenamiento (Storage = 0) — el mismo efecto.
Bajar Max Usage — puede disparar la limpieza size-based y borrar chunks viejos.
Bajar Storage Hours / Storage Min Hour — puede sacar parte del archivo del rolling-window.

Decisión deliberada del producto: la operación es posible pero con confirmación, y los ficheros borrados quedan en disco (recuperables de backup). Ubicar el archivo en un servidor de ficheros / RAID aparte reduce mucho el riesgo de pérdida irreversible.

Limitaciones de la versión actual¶

Una sesión VOD abierta por el cliente no sigue el live edge — si se añadieron chunks durante la sesión, el cliente debe volver a pedir la playlist (comportamiento estándar HLS / DASH).
Asignar un almacenamiento por disco es lo recomendable — varios registros con subdirectorios distintos compiten por el espacio.
Los segmentos se direccionan por hash (HLS) o plantilla $Number$.ts (live DASH) / <SegmentURL> explícitos (VOD DASH). Cambiar el tamaño de chunk entre live y VOD no requiere reabrir la URL.
El orphan scanner corre cada hora; para acelerar, reiniciar PSS.

Operaciones con flujos¶

Eliminación. Para eliminar un flujo, abra sus ajustes y pulse el botón Delete stream.

Clonación. Para clonar un flujo, abra sus ajustes y pulse el botón Clone stream.

Ordenación. Para configurar la ordenación de streams haga clic en el botón Sort en la ventana de la lista de streams. A continuación indique el orden deseado arrastrando los streams hacia arriba o hacia abajo. Para guardar el orden definido haga clic en Save order, o en Cancel para descartar los cambios.

Filtrado de la lista. Para filtrar la lista de flujos pulse el icono de búsqueda e introduzca la cadena de filtro. Para anularlo, pulse la flecha atrás.

Operaciones de grupo. En modo de filtrado de la lista de streams es posible seleccionar varios streams marcando las casillas en la columna izquierda. Si hay streams seleccionados, los botones Eliminar y Clonar quedan disponibles para los streams seleccionados.

Exportación e importación de flujos mediante un script en Python¶

La exportación e importación de la configuración se realiza mediante una playlist .m3u y un script en Python.

Se requiere Python 3 en la ruta /usr/bin/python3.

Exportación e importación de flujos por la interfaz web¶

En la lista de streams, al hacer clic en el botón Playlist, se abre el diálogo de exportación de streams a una playlist en formato m3u8. Solo se exportan los streams actualmente mostrados según los filtros aplicados.

Ajustes:

Host / IP — nombre o dirección del servidor que se usará para formar las URL de los flujos.
Protocols — tipos de protocolos a exportar.
Login — se selecciona la cuenta que se usará para formar las URL de los flujos.
Use Display Names — usar el Display name del flujo en lugar del Stream name en el archivo m3u8.

La playlist se descarga como archivo m3u8 al pulsar el botón Download.

Al hacer clic en el botón Import Playlist, el diálogo cambia al modo de importación de flujos desde una playlist en formato m3u8. Durante la importación, los flujos existentes no se eliminan. En todos los flujos importados la hora de importación se registra en el campo Note.

Ajustes:

Playlist — selección del archivo de playlist a importar.
Create Outputs — elección del protocolo para generar automáticamente salidas de los flujos importados.
Output Ports From — puerto inicial para generar las salidas.
Output IP — selección de la interfaz a la que se enlazan los flujos de salida.
Tags — etiquetas con las que se marcan los flujos importados. Útiles para operaciones grupales, p. ej. eliminar todos los flujos importados.

Si en el campo Playlist se indica un archivo a importar, el botón Load Playlist se activa. Al hacer clic en Load Playlist se precarga la playlist y se muestra el resultado del parsing en una tabla. Tras el parsing, se activa el botón Import Streams: al hacer clic, los streams se importan y se generan outputs para ellos.

Informes y diagnóstico¶

La sección Streams muestra los datos de todos los stream en forma de tabla. Pausa está disponible para los roles admin y restricted admin.

Para cada stream hay estadísticas detalladas e informes disponibles.

Peers — lista de receptores (clientes) activos. Cada uno tiene estadísticas independientes.

Análisis de flujos¶

El analizador de flujos del streamer mide y analiza distintos parámetros del flujo MPEG-TS, lo que permite evaluar su calidad.

Input speed — tasa (bitrate) del flujo en kbps. Cambia tras filtrar por las marcas PCR. Se muestra como un gráfico que también incluye el bitrate de salida tras el sincronizador.

Raw data speed — velocidad de recepción por el protocolo elegido. Overhead — incremento en % por la sobrecarga del protocolo.

CC errors — pérdidas de paquetes (CC, discontinuity). Se muestran contadores por periodos y un contador acumulado durante el uptime del stream; también se ve el historial en gráfico.

Scrambled — contadores de paquetes MPEG-TS ES codificados. Si es ≠ 0 hay fallos de descodificación de canales cifrados.

Sync by — fuente de sincronización, por defecto PCR. Si el PCR es incorrecto, se puede usar el PTS/DTS del vídeo (ver el ajuste Force Sync by PTS del input).

PCR interval — intervalo entre marcas PCR. Recomendado: no superior a 50 ms.

PCR jitter — caracteriza la precisión de sincronización del flujo de salida; se mide como la diferencia entre el PCR y el tiempo real.

Analyze PCR PMT Gap — se activa con un ajuste separado. Se analiza la dispersión entre PCR y PTS/DTS para cada ES. El historial se muestra como gráfico. Una dispersión excesiva puede causar problemas en reproductores con búfer de sincronización pequeño. El análisis se activa con el ajuste Analyze PAT/PMT/KF.

PAT interval y PMT interval — cambian el intervalo entre tablas PAT (PMT). Recomendado: no superior a 500 ms. El análisis se activa con Analyze PAT/PMT/KF.

Key Frame interval — mide el intervalo entre fotogramas clave (KF). Para reproductores que se conectan al flujo en un punto aleatorio, se recomienda un máximo de 1 s. El análisis se activa con el ajuste Analyze PAT/PMT/KF.

PAT/KF interval — mide el intervalo medio entre el comienzo y el final de la secuencia PAT/PMT/SPS/PPS/KF. De esto depende la velocidad de inicio de la reproducción en reproductores que se conectan al flujo en un punto aleatorio. Se mide desde el inicio del KF en el flujo, por lo que el tiempo real de inicio del reproductor será mayor. El análisis se activa con el ajuste Analyze PAT/PMT/KF.

Activar Analyze PAT/PMT/KF pone el analizador del flujo en modo permanente, lo que aumenta la carga de CPU.

Control del jitter¶

Para gestionar el jitter existen varios ajustes en el stream:

Jitter Compensation Delay (ms) — función de compensación del jitter de red; fija el tamaño del buffer. Descripción ampliada: https://forum.pstreamer.tv/viewtopic.php?t=25
Jitter Auto sync — activa 2000 ms para protocolos basados en TCP (HTTP, HLS); para los UDP el valor sigue siendo 500 ms.
Limit PCR gap (ms) — comprueba cuánto puede saltar el PCR; si lo supera, se realiza una resincronización.

If PCR Accuracy errors appear after the transcoder, you need to set an even bitrate using stuffing for the encoded stream along the followingpath: «input - transcoder - Align Total Bitrate». The speed must be guaranteed to be greater than the bitrate of video and audio.

System Monitor¶

Control de los parámetros principales del sistema operativo.

Mosaic¶

Función de captura del flujo de entrada. Se activa individualmente por cada stream.

Si no se necesita, se puede desactivar por completo en Settings/Server Settings para ahorrar recursos.

Administración¶

En Configuration/Administration/Administrators List se añaden usuarios para acceder a la interfaz web — servidor HTTP integrado.

A los usuarios se les asignan roles:

admin — acceso completo.

restricted admin — los ajustes no están disponibles; solo se puede cambiar el valor pause.

viewer — acceso solo en modo lectura.

Copia de seguridad de los ajustes¶

Para hacer una copia de seguridad de los ajustes, guarde el contenido de la carpeta /opt/pss/config.

Para restaurar los ajustes, detenga el servicio y reemplace el contenido de la carpeta /opt/pss/config.

Integración de sistemas de monitorización externos¶

pss-metrics — exportador universal de métricas para Perfect Streamer

Un único script CLI en Python 3 que obtiene estadísticas de la API HTTP del servidor web de PSS y produce salida para los sistemas de monitorización más comunes:

Zabbix (UserParameter, Low-Level Discovery, zabbix_sender trapper)

Prometheus (formato de exposición de texto para el textfile collector)

InfluxDB / Telegraf (line protocol o JSON para el input exec)

JSON universal para scripts arbitrarios y comprobaciones de estado tipo Nagios

El exportador es un único archivo autocontenido sin dependencias de terceros y utiliza solamente la biblioteca estándar de Python 3.6+ (urllib, xml.etree, json, argparse).

Archivos¶

pss-metrics.py                    основной CLI (исполняемый)
userparameter_pss.conf.example    шаблон UserParameter для Zabbix

Instalación¶

El exportador se entrega en /opt/pss/monitoring/pss-metrics.py. Asegúrese de tener instalado Python 3.6 o posterior:

# RHEL / Rocky / AlmaLinux
yum install -y python3

# Debian / Ubuntu
apt-get install -y python3

No se requieren paquetes adicionales.

Configuración¶

Por defecto, pss-metrics se conecta a http://127.0.0.1:43971 y detecta automáticamente el puerto desde /opt/pss/config/pss.json (o /opt/pss/config/pss_default.json). Los parámetros se pueden sobrescribir mediante variables de entorno, el archivo /etc/pss-metrics.conf (formato clave=valor) o banderas de línea de comandos. Prioridad: CLI > env > archivo > valores por defecto.

Variables admitidas:

PSS_URL          полный URL, например http://10.0.0.1:43971  (по умолчанию авто)
PSS_USER         логин веб-сервера (если включена авторизация)
PSS_PASS         пароль веб-сервера
PSS_TIMEOUT      таймаут HTTP, в секундах                    (по умолчанию 5)
PSS_CACHE_DIR    каталог кеша                                (по умолчанию /run/pss-metrics)
PSS_CACHE_TTL    время жизни кеша, в секундах                (по умолчанию 10)
PSS_CA_BUNDLE    путь к CA bundle для HTTPS
PSS_INSECURE     1 — отключить проверку TLS-сертификата
PSS_VERBOSE      1 — логировать запросы в stderr

Caché: cada ejecución realiza como mucho un HTTP GET por endpoint dentro de la ventana TTL. Con TTL=10 s incluso cientos de comprobaciones de UserParameter por minuto resultan en ~6 peticiones HTTP por minuto a PSS.

Inicio rápido¶

Comprobación de estado (códigos de salida estilo Nagios):

pss-metrics.py health
# OK: total=42 running=15 stopped=27 unhealthy=0 version=1.12.2.430d

Descubrimiento LLD de Zabbix:

pss-metrics.py discover streams
pss-metrics.py discover inputs --running-only
pss-metrics.py discover outputs

Obtención de una sola métrica (para usar en UserParameter de Zabbix):

pss-metrics.py get summary.running
pss-metrics.py get stream.10031.bitrate
pss-metrics.py get input.10031.1.speed1
pss-metrics.py get output.10031.1.speed
pss-metrics.py get sysmon.cpu.self-usage
pss-metrics.py get server.server-version

Exportación completa:

pss-metrics.py dump --format=json
pss-metrics.py dump --format=prometheus
pss-metrics.py dump --format=influx
pss-metrics.py dump --format=zabbix-trapper --zabbix-host=streamer-01

Rutas de métricas¶

pss-metrics get acepta una ruta separada por puntos. Una salida vacía significa «valor ausente» (por ejemplo, la métrica solo existe para flujos en ejecución).

server.<attr>                например server.server-version, server.uptime
summary.<key>                total | running | stopped | unhealthy |
                             input_bitrate_kbps | output_bitrate_kbps
sysmon.cpu.<attr>            self-usage | total-usage | cores
sysmon.memory.<attr>         self-usage-kb | available-kb | total-kb
sysmon.netbw.<iface>.<attr>  rx-bw | tx-bw  (имя интерфейса как в XML)
stream.<id>.<attr>           любой атрибут <stream>
input.<sid>.<iid>.<attr>     любой атрибут <input>
output.<sid>.<oid>.<attr>    любой атрибут <output>

Atributos útiles por flujo (de /data/stream/detail):

stream:  state, state-str, bitrate, thread-usage, mpts
input:   speed1, recv-bytes, recv-packets, recv-err,
         stat-disc, stat-disc1, stat-scrambled, stat-scrambled1,
         health-state-good, health-status, check-status
output:  speed, sent-bytes, sent-packets, sent-err, uri, type

Integración con Zabbix¶

Se admiten dos escenarios: elija el que se adapte a su entorno.

UserParameter estático + LLD (agente Zabbix v1 / v2)

Copie userparameter_pss.conf.example a /etc/zabbix/zabbix_agentd.d/pss.conf, reinicie zabbix-agent e importe en el servidor una plantilla con prototipos LLD que usen las claves pss.discover. Ejemplos de asignaciones:

UserParameter=pss.discover[*],/opt/pss/monitoring/pss-metrics.py discover $1
UserParameter=pss.get[*],/opt/pss/monitoring/pss-metrics.py get $1
UserParameter=pss.health,/opt/pss/monitoring/pss-metrics.py health

En el servidor Zabbix:

Ключ правила обнаружения:  pss.discover[streams]
Ключи прототипов элементов: pss.get[input.{#STREAM_ID}.1.speed1]
                            pss.get[stream.{#STREAM_ID}.bitrate]
                            pss.get[summary.unhealthy]

Trapper (push) mediante zabbix_sender

Ejecútelo por temporizador (cron / systemd) y canalice la salida:

/opt/pss/monitoring/pss-metrics.py dump --format=zabbix-trapper \
    --zabbix-host="$(hostname)" \
  | zabbix_sender -z zabbix.example.com -i -

Integración con Prometheus¶

Dos opciones.

Textfile collector (recomendado para entornos one-shot).

Ejecute una exportación periódica mediante systemd-timer o cron:

*/1 * * * * /opt/pss/monitoring/pss-metrics.py dump --format=prometheus \
    > /var/lib/node_exporter/textfile_collector/pss.prom.$$ \
    && mv /var/lib/node_exporter/textfile_collector/pss.prom.$$ \
          /var/lib/node_exporter/textfile_collector/pss.prom

node_exporter servirá el archivo mediante –collector.textfile.directory.

Scrape directo mediante un pequeño wrapper (por ejemplo socat + pss-metrics dump) o cualquier proxy HTTP de terceros que prefiera.

Integración con Telegraf / InfluxDB¶

Telegraf inputs.exec:

[[inputs.exec]]
  commands = ["/opt/pss/monitoring/pss-metrics.py dump --format=influx"]
  interval = "10s"
  timeout  = "5s"
  data_format = "influx"

Para el parser JSON, utilice –format=json y configure data_format = «json» con las rutas de los campos.

HTTPS y autenticación¶

Si el servidor web de PSS opera detrás de HTTPS o está protegido con contraseña:

PSS_URL=https://streamer.example.com:8443 \
PSS_USER=monitor PSS_PASS=secret \
pss-metrics.py health

Certificados autofirmados: establezca PSS_INSECURE=1 (no recomendado) o indique PSS_CA_BUNDLE=/path/to/ca.pem.

Códigos de salida¶

pss-metrics sigue la convención de Nagios:

OK
WARNING       (например, у запущенных потоков unhealthy)
CRITICAL      (PSS недоступен)
UNKNOWN       (неверные аргументы / внутренняя ошибка)

get y dump muestran una cadena vacía y terminan con código 0 cuando la entidad solicitada no existe — esto se corresponde con la expectativa de Zabbix de que un valor vacío se interpreta como «NOT_SUPPORTED» en lugar de como un fallo del agente.

Diagnóstico¶

pss-metrics.py -v health        # логировать каждый HTTP-запрос в stderr
pss-metrics.py --cache-ttl=0 …  # обойти кеш при отладке
rm -rf /run/pss-metrics         # очистить кеш

Let’s Encrypt y certbot para HTTPS¶

Desde la versión 1.9.2.340, Perfect Streamer soporta la renovación automática de certificados Let’s Encrypt para HTTPS en Web Server, HTTP Server y EPG Server.

Configuración de certbot para RHEL.¶

Limitación:

El puerto TCP/80 debe estar libre y debe haber asignada una IP pública con nombre de dominio público.
Todos los servidores HTTPS usan el mismo nombre de host (web server, http server, epg server).

Instalación de certbot (https://certbot.eff.org/instructions?ws=other&os=snap):

sudo yum install snapd
sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install certbot --classic

Configuración de certbot:

sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot certonly --standalone

Comprobación de certbot:

sudo certbot renew --dry-run

Comprobación del temporizador de certbot:

systemctl list-timers | grep certbot

En el panel admin de Perfect Streamer activar HTTPS en los servidores (Web Server, HTTP Server, EPG Server).

Crear el script hook (https://pstreamer.tv/distrib/scripts/cert_update.zip) y colocarlo en la ruta:

/opt/pss/scripts/cert_update.sh

Allí se puede indicar el nombre de dominio del host; por defecto se toma de /etc/hostname.

Hacer el archivo ejecutable.

chmod +x /opt/pss/scripts/cert_update.sh

Comprobar la ejecución del script, no debe haber errores:

/opt/conf/scripts/cert_update.sh

Los ajustes HTTPS deben aplicarse; el cambio de estado se reflejará en los logs.

Añadir archivo hook a certbot:

certbot renew --deploy-hook "/opt/conf/scripts/cert_update.sh"

Volver a comprobar certbot:

sudo certbot renew --dry-run

Configuración de certbot para Debian/Ubuntu.¶

La configuración para Debian es análoga a RHEL; descripción breve con el ejemplo de Ubuntu 24.04.2 LTS.

Instalación de certbot:

apt install certbot
certbot certonly

Hacer el script ejecutable:

chmod +x /opt/pss/scripts/cert_update.sh

Ejecutar el script:

/opt/pss/scripts/cert_update.sh

Emite:

Select domain name (your domain name)

Comprobar si los certificados se han renovado:

ls -lat /opt/pss/config/cert/
total 44
-rw------- 1 root root  241 May 26 07:52 epgserver.key
-rw------- 1 root root  241 May 26 07:52 httpserver.key
-rw------- 1 root root  241 May 26 07:52 webserver.key
-rw-r--r-- 1 root root 1338 May 26 07:52 epgserver.crt
-rw-r--r-- 1 root root 1338 May 26 07:52 httpserver.crt
-rw-r--r-- 1 root root 1338 May 26 07:52 webserver.crt

La fecha debe ser actual.

Adaptadores DVB¶

Perfect Streamer admite cualquier adaptador DVB instalado en el sistema. Estándares soportados: DVB-S, DVB-S2, DVB-T, DVB-T2, DVB-C, ATSC. Además se implementan: la desencapsulación T2-MI (ETSI TS 102 773) y el descifrado BISS-1 / BISS-E.

La condición principal es un controlador de adaptador correctamente instalado y en funcionamiento en el sistema.

La sección DVB aparece únicamente si el sistema dispone de adaptadores DVB válidos. La reconfiguración en caliente no está soportada; se requiere reiniciar el streamer.

Conexión del adaptador¶

Para añadir un nuevo adaptador DVB, vaya a la sección correspondiente y añada el adaptador:

Establecer el nombre del adaptador.
Seleccionar un adaptador de la lista de los disponibles en el sistema.
Seleccionar el modo Stream.
Especificar el tipo de sistema de transmisión: DVB-S, DVB-S2, DVB-T, DVB-T2, DVB-C.
Especificar los parámetros de recepción: Frecuencia portadora, Polarización, Tasa de símbolo, FEC, Modulación, ID del flujo DVB, Frecuencia del oscilador, Oscilador banda alta, Límite banda alta, Modo DiSEqC 1.0 y otros parámetros según el tipo.

Opcionalmente puede habilitarse el registro de EIT en la base de datos EPG (Registrar EIT en la BD EPG).

Repetir la incorporación para cada adaptador presente en el sistema.

Escaneo DVB¶

Para evitar introducir manualmente los parámetros de recepción (frecuencia, polarización, tasa de símbolo, FEC, modulación), Perfect Streamer incluye un escáner de transpondedores integrado. El escáner recorre los transpondedores del satélite seleccionado (DVB-S/S2) o de la banda regional (DVB-C, DVB-T/T2), realiza la sintonización y la captura de cada uno, recopila las tablas PSI/SI (PAT, PMT, SDT) y elabora la lista final de multiplex con sus programas. Cualquier multiplex encontrado se añade a la lista de adaptadores DVB con un solo botón.

El escáner ocupa el adaptador físico por completo; para iniciarlo se requiere un adaptador que no esté siendo utilizado ni por el núcleo del sistema operativo ni por ninguna entrada de adaptador DVB activa en Perfect Streamer.

Свободные адаптеры¶

Al abrir la pantalla de escaneo en el panel de administración, se muestra una lista de los adaptadores DVB físicos del sistema junto con su estado de ocupación:

free — el adaptador está disponible para el escaneo.
kernel — el dispositivo está retenido por otro proceso del sistema operativo.
pss-id-N — el adaptador ya está siendo utilizado por una entrada de adaptador DVB en Perfect Streamer con el identificador indicado. No es posible iniciar el escáner en él mientras dicha entrada esté activa. Para liberar el adaptador temporalmente, la entrada de adaptador DVB existente debe ponerse en pausa (el indicador Pause en sus ajustes).

Listas de transpondedores¶

El escáner se basa en listas de referencia en formato Enigma2: la lista de satélites satellites.xml y las listas regionales cables.xml / terrestrial.xml. Cada archivo contiene un conjunto de transpondedores para una posición orbital conocida o para una banda regional DVB-T/C (para más detalles, consulte el sitio del proyecto oe-alliance-tuxbox-common).

Los archivos se ubican en el directorio sat/ relativo a pss.json (por defecto /etc/pss/sat/). Se incluyen con la distribución de Perfect Streamer y se cargan al abrir la pantalla de escaneo. Si es necesario, pueden actualizarse sustituyendo el archivo XML correspondiente.

En el panel de administración, las listas de referencia se presentan como tres listas:

Satélite — posiciones orbitales (por ejemplo, Hot Bird 13.0°E, Astra 19.2°E).
Región de cable — país o proveedor DVB-C.
Región terrestre — región DVB-T/T2.

Si el satélite o la región requeridos no están presentes en las listas de referencia, se puede actualizar el XML o utilizar en su lugar el escaneo ciego (véase más abajo).

Inicio¶

En el diálogo de escaneo se especifican en orden los siguientes elementos:

Un adaptador físico libre.
Тип delivery system: DVB-S, DVB-S2, DVB-T, DVB-T2 или DVB-C.
Fuente:
- para DVB-S/S2 — una posición orbital de la lista de satélites y los parámetros LNB (frecuencias del oscilador local LO1 y LO2, límite de la banda superior, puerto DiSEqC);
- para DVB-C — una región de cable;
- para DVB-T/T2 — una región terrestre.

Tras pulsar Iniciar, el escaneo se ejecuta en segundo plano. El progreso se muestra en el panel de administración:

el porcentaje de avance basado en el número de transpondedores procesados;
la frecuencia y la polarización actuales;
los contadores Multiplex encontrados y Programas encontrados;
un árbol de los multiplex ya encontrados, desplegable hasta los programas.

El escáner es un recurso compartido para todo el streamer: solo se ejecuta un escaneo a la vez. Si se inicia un nuevo escaneo mientras hay otro en curso, el anterior se cancela automáticamente. El botón Cancelar interrumpe el escaneo y borra la lista acumulada.

La duración del escaneo depende del número de transpondedores en la lista de referencia seleccionada (típicamente hasta 5 segundos por transpondedor: hasta 2 segundos para el enganche de la señal y hasta 5 segundos para la recopilación de las PSI). Valores típicos:

DVB-S Hot Bird 13.0°E — alrededor de 2 minutos (44 transpondedores).
DVB-S Astra 19.2°E — alrededor de 1,5 minutos.
DVB-T región europea — menos de un minuto.

Resultado¶

El resultado del escaneo se muestra como un árbol multiplex → programas.

Parámetros del multiplex:

frecuencia, polarización, tasa de símbolo;
FEC, modulación, delivery system;
identificador del flujo de transporte (TSID);
las lecturas del frontend en el momento de finalización de la recopilación de PSI — SNR, Signal, BER;
los contadores pmt-total / pmt-recv — cuántas tablas PMT declaró la PAT y cuántas se recopilaron realmente dentro del tiempo de espera.

Параметры программы:

PNR (program_number) — el identificador del servicio dentro del multiplex;
Nombre y Proveedor — obtenidos de la tabla SDT, en UTF-8;
scrambled — el indicador de cifrado. Su origen se determina en el siguiente orden: el bit free_CA_mode de la SDT (declaración del broadcaster) → los indicadores de cifrado de transporte de la PMT. Si ni la SDT ni la PMT llegan dentro del tiempo de espera, el valor por defecto es 0 («no cifrado»); el estado real se determina al intentar la recepción;
video-pid, audio-pid, pcr-pid — los principales flujos elementales del servicio.

Aplicación del resultado¶

El multiplex seleccionado en el árbol se añade a la lista de adaptadores DVB con un solo botón. Se crea una nueva entrada con los parámetros del resultado del escaneo (frecuencia, polarización, tasa de símbolo, FEC, modulación, delivery system) junto con los parámetros LNB y el par adapter/device especificados al iniciar el escaneo. El nombre del adaptador lo establece el usuario; los parámetros adicionales (claves BISS para canales cifrados, T2-MI, LNB compartido, etc.) se rellenan una vez creada la entrada, en sus ajustes.

Los programas de los multiplex encontrados se aplican por separado — creando un flujo (Stream) con una fuente de entrada demuxer direccionada por el PNR (véase la sección Conexión de un flujo SPTS a un servicio de multiplex DVB).

Escaneo ciego¶

El modo ciego se utiliza cuando:

el satélite requerido no está en las listas de referencia (posición orbital no estándar, uplink local);
las listas de referencia regionales DVB-T/C son insuficientes o están desactualizadas para una ubicación concreta;
es necesario reverificar un tramo de la banda con independencia de la lista de transpondedores conocidos.

En este modo, el escáner no consulta las listas de referencia, sino que sintetiza una lista de transpondedores a partir de una rejilla de frecuencias. Por defecto se utilizan los siguientes rangos típicos:

DVB-S/S2 Ku — 10700..12750 MHz, paso de 4 MHz, ambas polarizaciones (H y V), tasas de símbolo típicas 22000 / 27500 / 30000 ksym/s.
DVB-C — 47000..862000 kHz, paso de 8000 kHz, QAM-64 y QAM-256, tasas de símbolo típicas 6875 / 6900 / 6952 ksym/s.
DVB-T/T2 — 174000..862000 kHz, paso de 8000 kHz.

Un barrido ciego completo de la banda Ku tarda del orden de 100 minutos (varios miles de puntos de sintonización). En la práctica, el rango se acota manualmente en el panel de administración — frecuencia mínima/máxima y paso de rejilla. Por ejemplo, un barrido de 11700..11800 MHz con paso de 4 MHz para una sola banda LNB dura unos 5 minutos.

El formato del resultado de un escaneo ciego es idéntico al de uno normal. Particularidades:

los campos FEC y Modulación de los multiplex encontrados se fijan en el valor AUTO — el escáner no determina sus valores exactos;
el delivery system es igual al solicitado (DVB-S, DVB-S2, …). Para redes mixtas se recomienda realizar dos pasadas — DVB-S y DVB-S2 por separado.

La aplicación de un multiplex procedente de un escaneo ciego se realiza igual que la de uno normal — mediante el botón que lo añade a la lista de adaptadores DVB. Los campos FEC y Modulación suelen dejarse en AUTO y, si es necesario, se afinan tras conseguir un enganche estable de la señal en el transpondedor concreto.

Tamaño del búfer de recepción del kernel¶

El parámetro buffer-size (entero, valor por defecto 512) establece el tamaño del búfer circular DVB demux del kernel en bloques de 65536 bytes.

512 (32 MB) — valor por defecto recomendado. Cubre escenarios DVB-S/S2 de transpondedor completo (>= 33 Mbit/s) con uno o varios consumidores MPTS. Seleccionado a partir de pruebas en banco con un adaptador TBS bajo carga completa del transpondedor.
8...64 (512 KB … 4 MB) — aceptable para sistemas embebidos con RAM limitada o para adaptadores en modos Scanner / Femon donde el tráfico es bajo.
0 — mantener el valor por defecto del controlador (normalmente 8…32 KB). Adecuado solo para escenarios con muy poca carga. Por encima de 10 Mbit/s habrá pérdidas.

Cuando aparezca un mensaje de la forma siguiente en el registro:

DVB adapter X/Y dvr buffer overflow (NN so far, KK pids);
raise 'buffer-size' or reduce pid filter

aumentar buffer-size o reducir el número de PIDs que pasan por el filtro (por ejemplo, eliminar la salida MPTS si no es necesaria).

Coste de memoria: el valor N consume N × 64 KB de memoria del kernel por adaptador. Con muchos adaptadores (8 o más) conviene tenerlo en cuenta (8 × 32 MB = 256 MB).

Conexión de un flujo SPTS a un servicio de multiplex DVB¶

Al añadir un nuevo canal SPTS al input del flujo, seleccionar:

Tipo: demuxer.
Fuente: adaptador DVB.
Multiplex creado en el adaptador DVB, por nombre del adaptador.
PNR — se selecciona de la lista emergente de servicios detectados en el multiplex o se introduce manualmente.

Permisos de acceso a dispositivos DVB¶

Si los adaptadores DVB no aparecen en Perfect Streamer, realizar las siguientes acciones:

sudo nano /etc/udev/rules.d/99-dvb-permissions.rules
SUBSYSTEM=="dvb", GROUP="video", MODE="0660"

sudo usermod -aG video pss
sudo chown -R root:video /dev/dvb/*
sudo reboot

Desencapsulación T2-MI¶

T2-MI (T2-Modulator Interface, ETSI TS 102 773) es un formato para transportar flujos DVB-T2 sobre DVB-S2 multistream. El transpondedor externo DVB-S/S2 transporta uno o más T2-MI carrier-PID, cada uno encapsulando BBFRAMEs con uno o más PLP (Physical Layer Pipe). Tras la desencapsulación, se extrae del BBFRAME el MPEG-TS interno que contiene los programas y las tablas PSI/SI.

La implementación de Perfect Streamer funciona en modo multi-carrier: un único adaptador físico entrega simultáneamente el multiplex DVB-S/S2 externo y todos los carriers T2-MI desencapsulados (uno por cada carrier-PID encontrado en el PMT del flujo externo).

Parámetros de configuración¶

t2mi-mode (Int, 0..2, valor por defecto 0) — modo de desencapsulación:

0 — Desactivado. El MPEG-TS externo se transmite sin procesar. Si se detecta un descriptor T2-MI (tag 0x51) en el PMT, se registra una pista única.
1 — Manual. La desencapsulación está siempre activa. Si t2mi-pid no es 0, al iniciar se pre-crea un carrier en ese PID. Los carriers adicionales se siguen detectando automáticamente a partir del PMT.
2 — Auto. Los carriers se detectan automáticamente desde el PMT del multiplex externo para todos los ES que parezcan T2-MI (descriptor 0x51 o único ES con stream_type=0x06 en un servicio sin otros ES A/V). Si no se encuentran carriers, el adaptador funciona como un multiplex DVB normal.

t2mi-pid (Int, 0..8191, valor por defecto 0) — PID para pre-crear un carrier al inicio, antes de la llegada del PMT:

0 — sin pre-creación. Los carriers se detectan a partir del PMT (recomendado para el modo auto 2).
1..8191 — pre-crear un carrier en este PID. Los T2-MI ES adicionales encontrados en el PMT obtienen igualmente sus propios carriers.

En modo multi-carrier el parámetro t2mi-pid no es un selector de un único carrier — cada ES T2-MI detectado obtiene su propio carrier con su propio desencapsulador. El parámetro proporciona inicialización temprana para un PID conocido.

t2mi-plp (Int, 0..255, valor por defecto 0) — identificador del PLP extraído de cada carrier T2-MI en el adaptador. Se aplica a todos los carriers — la anulación por carrier no se admite en la versión actual. Si en producción distintos carriers transportan distintos PLP, conviene:

especificar un PLP común a todos los carriers, o
configurar adaptadores independientes para distintos PLP mediante lnb-sharing.

Este es el identificador del campo plp_id del BBFRAME, no el ISI multistream DVB-S2 (que se establece con el parámetro dvb-stream-id). Son identificadores distintos en capas distintas.

Diagnóstico de selección PLP:

Cinco segundos después de iniciar un carrier, si no se ha recibido ningún BBFrame para el PLP configurado pero se ven otros PLPs, se registra una advertencia con la lista de plp_id observados.

t2mi-tsid (Int, -1..255, valor por defecto -1) — reservado para uso futuro. Selector del identificador de flujo T2-MI cuando varios flujos T2-MI comparten un mismo carrier-PID. Se ignora en la versión actual.

PNR compuesto — conexión SPTS desde T2-MI¶

Un adaptador puede exponer varios multiplex lógicos:

carrier-id = 0 — multiplex DVB-S/S2 externo (servicios A/V normales).
carrier-id = 1..N — carriers T2-MI desencapsulados (uno por cada ES T2-MI externo).

Descifrado BISS¶

Se admite el descifrado de flujos DVB cifrados con BISS-1 (modo E1) y BISS-E (modo E2). Aplicable a los sistemas de transmisión DVB-S, DVB-S2, DVB-T, DVB-T2.

La implementación permite mantener varios descifradores activos simultáneamente en un mismo adaptador:

Por PNR en el multiplex externo (servicio normal).
Por plp_id para descifrar el carrier-PID T2-MI antes de la desencapsulación (requerido para flujos multistream cifrados — de lo contrario el desencapsulador descarta cada paquete cifrado, véase el contador <t2mi scrambledDropped>).

EPG¶

Importación EPG/XMLTV¶

Los datos del EPG se recogen en la EPG Database desde varias fuentes:

EIT de los flujos recibidos (SPTS y MPTS). Se activa con Stream: Extract EIT to EPG Database.
Import in XMLTV format from different external sources. Set in Configuration/EPG/EPG Sources. Supported sources EPG in the form of a link to a web resource and a local file, with the full path specified.

El tiempo de almacenamiento de eventos EPG se define con EPG storage period (days).

Auto-clean database — se eliminan los programas sin eventos.

En la sección EPG se muestran las fuentes de EPG y los datos asociados. Para cada canal (EPG Channels List) se puede definir:

Channel Name — nombre que se usará al exportar al servidor XMLTV.
Time Zone — se puede corregir la zona horaria si al importar no quedó vinculada a UTC.
EPG Channel Sets — vincular el canal a un Channel Set (ver abajo).
Icon — URL del icono del canal (http://example.com/mychannel/myicon.png).

Generador EIT¶

EIT data from EPG Database can be generated in SPTS Stream. To do this, set EPG Source ID and select EPG Channel ID in the Stream settings. In this case, SDT will be generated anyway, even if it is not in the source. Set the correct SDT Data.

Si este Stream se usa en un multiplexor, el Service Name puede redefinirse aparte en el ajuste output/muxer.

Servidor EPG (XMLTV)¶

Un servidor HTTP integrado e independiente de Perfect Streamer devuelve el XMLTV completo para un conjunto dado de canales. El endpoint está pensado para middleware y reproductores que guardan la guía localmente y la actualizan con poca frecuencia, como archivo completo — normalmente una o dos veces al día.

El servidor y sus clientes se configuran en Configuration/EPG/EPG Server.

URL y autenticación¶

El servicio lo ofrece un servidor HTTP independiente epg-server (no el que atiende /data/*). Por defecto escucha en los puertos 10444 (HTTP) y 10445 (HTTPS); los puertos y SSL se configuran en /config/epg-server.

Rutas:

URL	Content-Type	Comportamiento
`GET /xmltv`	`text/xml`	Con `Accept-Encoding: gzip` la respuesta se comprime al vuelo (`Content-Encoding: gzip`); en caso contrario, se entrega como XML sin comprimir.
`GET /xmltv.gz`	`application/octet-stream`	Siempre devuelve un flujo gzip con `Content-Disposition: inline; filename="xmltv.xml.gz"` — práctico para guardarlo como archivo.

Se admiten tres métodos de autenticación:

HTTP Digest (preferido) — cuenta de /config/epg-server/login.
Parámetros en la URL — ?l=<login>&p=<password> (sinónimos: login=…, password=…).
Loopback — una solicitud desde 127.0.0.1 se trata como anónima. Útil para scripts implantados en la misma máquina.

Advertencia

Un login y una contraseña en la URL acaban en los access-logs del reverse-proxy y en el historial del navegador. Para distribución pública de XMLTV utilice HTTP Digest o acepte solicitudes únicamente desde direcciones privadas.

Acceso por channel-set¶

Cada cuenta epg-server/login está vinculada a un único channel-set de /config/epg-channel-set. El EPG devuelto contiene solo los canales del grupo indicado. Esto permite que una misma instalación de PSS sirva XMLTV distintos a distintos operadores/middleware.

Configuración básica en la UI:

En Configuration/EPG/EPG Channel Sets cree un grupo de canales y asigne los canales deseados en las fuentes EPG.
En Configuration/EPG/EPG Server Clients cree una cuenta y vincúlela al grupo creado. Sin vincular un channel-set, el cliente recibe un XMLTV vacío.

Restricciones adicionales para un login:

ip-addr — si está definido y no es un comodín, una solicitud desde otra IP recibe 403 Forbidden.
limit-day — Unix epoch en s, después del cual la cuenta deja de ser atendida (403 Forbidden). Útil para un modelo de suscripción.
pause — desactivar temporalmente un login sin eliminarlo.

Formato de la respuesta¶

El cuerpo de la respuesta es un documento XMLTV con raíz <tv>. La estructura sigue el esquema XMLTV DTD habitual:

<?xml version="1.0" encoding="utf-8"?>
<tv source-info-name="..." source-info-url="...">
  <channel id="ru.first">
    <display-name lang="ru">Первый</display-name>
    <icon src="https://.../first.png"/>
  </channel>
  ...
  <programme start="20260504060000 +0300"
             stop ="20260504070000 +0300"
             channel="ru.first">
    <title lang="ru">Утренние новости</title>
    <desc  lang="ru">Обзор событий за сутки</desc>
    <rating system="RU"><value>12+</value></rating>
  </programme>
  ...
</tv>

Notas sobre los campos:

Los atributos source-info-name y source-info-url de la raíz <tv> se completan con los campos EPG Source Name y EPG Source URL de Configuration/EPG/EPG Server.
Los atributos start y stop siguen el formato YYYYMMDDhhmmss ±zone (la zona horaria se toma del campo time_zone del canal).
Un <programme> puede contener varios <title>/<desc> en distintos idiomas. El atributo lang queda vacío cuando el identificador de idioma del EPG original no se pudo asignar al diccionario (la entrada igualmente aparece en la salida).
Los canales con un channel_id en conflicto (si el mismo id procede de varias fuentes) se muestran una sola vez; las fuentes restantes se omiten con una advertencia en el log del servidor.
Solo se incluyen en la salida los eventos con stop_time >= now.

Encabezados HTTP¶

El servidor siempre envía:

Cache-Control: no-cache, no-store, must-revalidate
Pragma:        no-cache
Expires:       0
Connection:    close

Para /xmltv adicionalmente — Content-Encoding: gzip cuando Accept-Encoding: gzip está presente en la solicitud. Para /xmltv.gz — Content-Disposition: inline; filename="xmltv.xml.gz".

El veto al caché del cliente es intencional: el XMLTV cambia con cada importación EIT o refresco de fuentes XMLTV externas, y el reproductor no debe conservar datos obsoletos de forma indefinida. Una caché edge (nginx), sin embargo, es perfectamente aceptable — véase la sección sobre rendimiento más abajo.

Caché del servidor y su vaciado¶

El XMLTV listo se almacena en la memoria del proceso PSS:

Una entrada por cada channel-set; se guardan ambas variantes del cuerpo (cruda y gzip) — las solicitudes repetidas con Accept-Encoding: gzip o /xmltv.gz no recomprimen los datos.
Cada entrada lleva un contador update-time. Cualquier actualización de EPG (importación EIT, refresco de fuente XMLTV) incrementa el contador y la caché se reconstruye en la siguiente solicitud.

Vaciado forzado de la caché:

POST /xmltv/reset-cache

La ruta la atiende el servidor admin (puerto 43971/43981), no el epg-server. Cuerpo vacío; la respuesta es 200 OK con un envoltorio JSON.

Códigos de respuesta HTTP¶

Código	Condición
`200 OK`	Solicitud procesada. El cuerpo es un documento XMLTV (posiblemente un `<tv></tv>` vacío ante un fallo transitorio de la BD).
`401 Unauthorized`	Ni Digest ni los parámetros `l/p` superaron la validación (para solicitudes no loopback).
`403 Forbidden`	El login existe pero la solicitud no proviene de una IP permitida, o ha expirado `limit-day`.
`404 Not Found`	Cualquier URL distinta de `/xmltv` y `/xmltv.gz`.
`405 Method Not Allowed`	Método distinto de GET.

El cuerpo del error es un envoltorio JSON de formato fijo:

{"status": 401, "message": "Unauthorized"}

Rendimiento y escalado¶

Caché del servidor¶

La caché del servidor atiende las solicitudes repetidas sobre un mismo channel-set sin acceder a SQLite — copiando el cuerpo ya preparado.

Construir XMLTV «desde cero» (cache miss) es más costoso: por cada canal se hace un SELECT aparte por channel_name, y por cada evento por event_text y event_rating. Tiempos de construcción aproximados:

Tamaño de salida	Cache hit	Cache miss (build)
100 canales / día	decenas de ms	~0,5–1 s
500 canales / día	~50 ms	2–5 s
1000+ canales / semana	~100–300 ms	5–15 s

Para la mayoría de los middleware es aceptable solicitar XMLTV cada pocas horas o una vez al día.

Cuándo se necesita un reverse-proxy externo (nginx)¶

A diferencia de /data/epg/channel (respuestas JSON cortas), XMLTV es un único documento grande por channel-set, ideal para una caché edge:

Decenas o cientos de clientes por channel-set — la caché interna de PSS suele bastar si consultan el XMLTV cada hora o cada día.
Miles de clientes simultáneos — se recomienda un reverse-proxy con caché. Servir un archivo XMLTV a cientos/miles de solicitudes es, ante todo, una carga de red (cientos de KB a unos pocos MB por respuesta) que conviene quitar de PSS.
Distribución geográficamente repartida — un CDN/caché edge es ineludible sin importar el número de clientes.

PSS devuelve Cache-Control: no-cache, por lo que hay que indicarle explícitamente a nginx que ignore la cabecera del upstream y mantenga su propio TTL.

Ejemplo de configuración nginx¶

# /etc/nginx/conf.d/pss-xmltv.conf

proxy_cache_path /var/cache/nginx/pss-xmltv
                 levels=1:2
                 keys_zone=pss_xmltv:8m
                 max_size=4g
                 inactive=2h
                 use_temp_path=off;

upstream pss_epg {
    server 127.0.0.1:10444;
    keepalive 16;
}

server {
    listen 80;
    # listen 443 ssl http2;     # SSL termination разумно держать здесь
    server_name epg-files.example.com;

    # Не включаем gzip on: /xmltv.gz уже сжат, /xmltv получит
    # gzip-encoding от PSS, повторное сжатие бесполезно.

    location ~ ^/xmltv(\.gz)?$ {
        proxy_pass http://pss_epg;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # PSS отдаёт no-cache; кешируем на edge принудительно.
        proxy_ignore_headers Cache-Control Expires Set-Cookie;
        proxy_hide_header   Cache-Control;
        proxy_hide_header   Pragma;
        proxy_hide_header   Expires;

        # Ключ кеша = весь URL включая query (login/password в /xmltv?l=...&p=...)
        # дают разные ключи для разных учёток с разным channel-set.
        proxy_cache_key     "$scheme$host$request_uri";

        proxy_cache         pss_xmltv;
        proxy_cache_valid   200      30m;       # XMLTV меняется не часто
        proxy_cache_valid   401 403  1m;
        proxy_cache_lock           on;          # коалесцируем cache miss
        proxy_cache_lock_timeout   60s;         # build XMLTV может занимать секунды
        proxy_cache_use_stale      error timeout updating
                                   http_500 http_502 http_503;

        # Большой буфер: XMLTV для крупного channel-set может
        # достигать нескольких мегабайт.
        proxy_buffering      on;
        proxy_buffers        16 256k;
        proxy_buffer_size    256k;
        proxy_busy_buffers_size 1m;

        # Клиенту разрешим закешировать на короткий срок.
        add_header Cache-Control "public, max-age=600";
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

Explicaciones y recomendaciones¶

TTL ``proxy_cache_valid 200 30m`` — el XMLTV rara vez cambia con mayor frecuencia que cada media hora. Si la sincronización con las fuentes es horaria o menos frecuente, puede subirse a 1 hora o más; si importa la frescura tras POST /xmltv/reset-cache, redúzcalo.
``proxy_cache_lock_timeout 60s`` — incrementado respecto a /data/epg/channel (donde lo habitual son 5 segundos), porque construir el XMLTV de un channel-set grande lleva más tiempo.
Una ``keys_zone`` dedicada — incluso en una instalación grande, las claves XMLTV únicas son pocas (número de cuentas × channel-set); 8 MB sobran. max_size se dimensiona por el volumen de XMLTV, no por el número de claves.
gzip en el lado de nginx no hace falta: para /xmltv.gz la respuesta ya está comprimida y para /xmltv PSS responde directamente con gzip-encoded si está presente Accept-Encoding: gzip.
Terminación HTTPS en nginx ofrece mejor rendimiento ante muchos handshakes TLS simultáneos.

Endpoints relacionados¶

POST /xmltv/reset-cache — vaciado forzado de la caché XMLTV del servidor (en el servidor admin 43971/43981).
POST /data/epg/update?s=<src_id> — actualización forzada de una fuente XMLTV externa; tras un refresco exitoso, la caché XMLTV del servidor se vacía automáticamente.
GET /data/epg/channel?… — salida EPG en JSON para un canal durante un día; véase la sección aparte.

La lista completa y la descripción detallada de la API HTTP se encuentran en manual/http_data_api.txt.

EPG para middleware OTT¶

El servidor entrega los datos de la guía electrónica de programación (EPG) para el día elegido y un único canal en formato JSON. El endpoint está pensado para back-ends de middleware OTT que agregan la programación desde Perfect Streamer para construir la guía del cliente final.

URL y autenticación¶

El endpoint lo atiende el servidor admin integrado. Por defecto está disponible en los puertos 43971 (HTTP) y 43981 (HTTPS); los puertos se configuran en Settings/Server Settings.

GET /data/epg/channel?src=<src_id>&ch=<channel_id>&lang=<lang>&t=<time>

La autenticación es HTTP Digest, igual que para el resto de /data/*. Para el middleware basta con una cuenta con rol viewer (solo lectura).

Nota

Las solicitudes desde la dirección loopback (127.0.0.1) se ejecutan sin verificar HTTP Digest — el servidor las trata como anónimas. Es útil para scripts locales y comprobaciones de salud del middleware desplegado en la misma máquina que Perfect Streamer; para accesos remotos las credenciales son obligatorias.

Parámetros de la solicitud¶

Parámetro	Tipo	Obligatorio	Por defecto	Descripción
`src`	entero sin signo	no	`0`	Fuente EPG. `0` — datos importados desde el EIT MPEG-TS de los flujos de entrada. `1, 2, …` — identificador de entrada en `/config/epg/epg-source` (fuente XMLTV externa).
`ch`	cadena	sí	—	Identificador del canal en la base EPG: valor del campo `channel_id` de la tabla `channel`. La lista de identificadores disponibles puede obtenerse mediante una consulta SQL por `POST /data/epg/sql`.
`lang`	entero o ISO 639	no	idioma por defecto del sistema	`0` — idioma predeterminado del sistema; un entero > 0 — identificador interno de idioma (véase `GET /schema/lang`); una cadena — código ISO 639 de dos o tres letras, p. ej. `eng`, `rus`, `fra`.
`t`	entero sin signo (época Unix, s)	no	hora actual del servidor	Cualquier instante dentro del día de interés. El servidor devuelve los eventos del día UTC al que pertenece `t`: intervalo `[t / 86400 · 86400, (t / 86400 + 1) · 86400)`. Para los datos del «día siguiente» basta con sumar `86400` a la hora actual.

Nota

El día se toma en UTC, no en la zona horaria local. Si el middleware arma la programación por el día natural local, la frontera del día UTC puede no coincidir con la medianoche local; en tal caso hay que hacer dos solicitudes (para días UTC adyacentes) y unir los resultados por el campo start.

Formato de la respuesta¶

Content-Type: application/json.
Los encabezados HTTP prohíben el almacenamiento en caché en el cliente y en proxies intermedios:
```
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
```
El cuerpo de la respuesta es un JSON con la lista de eventos del día:

{
  "event": [
    {"start": 1715000000, "end": 1715003400, "title": "Утренние новости", "desc": "Обзор событий за сутки"},
    {"start": 1715003400, "end": 1715007000, "title": "Прогноз погоды",   "desc": ""}
  ]
}

Campos del evento:

start, end — inicio y fin del programa en época Unix (s), UTC.
title — título del programa en el idioma elegido. Si no existe el título en el idioma solicitado para el evento, el servidor toma la entrada en el idioma predeterminado del sistema y, después, en cualquier otro disponible.
desc — descripción ampliada. Puede ser una cadena vacía si la base no tenía una descripción aparte para el evento.

Particularidades de la salida:

Los eventos con título vacío y sin descripción, así como aquellos con marcas de tiempo incorrectas, quedan excluidos de la salida.
Los duplicados por start se descartan: para un mismo momento de inicio se devuelve una sola entrada con la mejor prioridad de idioma (solicitado → predeterminado del sistema → resto).
El orden de los eventos en el array no está garantizado — si es necesario, el middleware ordena la lista por el campo start por su cuenta.
Si el canal no se encuentra, la fuente no existe o no hay eventos para el día elegido, el servidor devuelve 200 OK con el array vacío {"event":[]} o, en el raro caso de una fuente ausente, con cuerpo vacío. El middleware debe manejar correctamente ambas variantes.

Almacenamiento en caché en el servidor¶

El JSON listo lo almacena el servidor en caché con la clave (channel_id, fecha UTC, idioma), por lo que las solicitudes repetidas del mismo día y canal se sirven sin acceder a la base de datos. El middleware no necesita gestionar la caché.

La caché se vacía automáticamente:

cuando llegan nuevos eventos desde EIT MPEG-TS de los flujos de entrada (src=0);
al actualizar correctamente una fuente XMLTV externa (src > 0 — programada o forzada vía POST /data/epg/update?s=<src_id>);
cuando un día sale de la ventana de retención EPG.

No se proporciona ni es necesario un endpoint dedicado para el vaciado forzado de la caché.

Códigos de respuesta HTTP¶

Código	Condición
`200 OK`	Solicitud procesada. El cuerpo es un JSON con la lista de eventos (posiblemente vacía).
`400 Bad Request`	El parámetro `ch` falta o está vacío; o `src`, `t` no se analizan como entero sin signo; o un `lang` numérico apunta a un identificador de idioma inexistente.
`401 Unauthorized`	Falta la autenticación HTTP Digest o es incorrecta (para solicitudes no procedentes de una dirección loopback).

Otras situaciones (src desconocido, canal ausente, sin eventos en el día) no devuelven 4xx — el middleware recibe 200 OK con el array vacío {"event":[]}.

En caso de error, el cuerpo de la respuesta es un envoltorio JSON de formato fijo:

{"status": 400, "message": "Bad Request"}

El campo status duplica el código HTTP; el campo message contiene la causa concreta del error en inglés (o el texto estándar del estado HTTP si no hay información adicional). El Content-Type de la respuesta de error es application/json.

Ejemplo¶

curl -u middleware:secret --digest \
  'http://pss.example.com:43971/data/epg/channel?src=0&ch=12.0.1&lang=rus&t=1715000000'

Ejemplo de respuesta:

{
  "event": [
    {"start": 1715000000, "end": 1715003400, "title": "Утренние новости", "desc": "Обзор событий за сутки"},
    {"start": 1715003400, "end": 1715007000, "title": "Прогноз погоды",   "desc": ""}
  ]
}

Rendimiento y escalado¶

Caché del servidor Perfect Streamer¶

Dentro del proceso PSS hay una caché LRU de respuestas en memoria con clave (channel_id, fecha UTC, idioma) y un tope duro de 1024 entradas por fuente EPG. Con la carga típica (decenas a cientos de canales × 1–3 idiomas × keep-day días) todas las entradas actuales caben completas en la caché; las solicitudes repetidas se atienden sin tocar SQLite.

Orden de magnitud (build debug, loopback local, sin HTTPS):

Escenario	Latencia (solicitud única)	Rendimiento (P=8)
Cache hit	~0,3 ms	~1100 solicitudes/s
Cache miss (SQL + JSON)	~1,0–1,5 ms	~1000 solicitudes/s

En build release y sin logging de depuración las cifras son aproximadamente 2–3× mejores. Ancho de banda — unos 14 KB por respuesta para un canal-día típico.

Cuándo se necesita un reverse-proxy externo (nginx)¶

La caché del servidor acelera las solicitudes repetidas para el mismo (canal, día, idioma), pero cada solicitud pasa igualmente por el servidor HTTP integrado de PSS y consume un hilo de su pool. Con muchos clientes conviene trasladar el almacenamiento en caché al edge:

hasta ~1.000 clientes en línea — el caché interno suele bastar, no se requiere reverse-proxy.
decenas de miles o más — se recomienda un reverse-proxy con caché (por ejemplo, nginx). Una caché edge atiende el 99 % de las solicitudes sin PSS, amortigua los picos (arranque de middleware, refresco masivo de reproductores) y permite trasladar la terminación SSL a un nodo aparte.
distribución geográficamente repartida — se necesita un CDN/proxy externo incluso antes de contar clientes.

PSS envía su propia cabecera Cache-Control: no-cache, no-store, must-revalidate para que los clientes finales no almacenen el EPG durante mucho tiempo. El reverse-proxy, sin embargo, puede (y debe) cachear la respuesta por su cuenta — más abajo se muestra cómo indicarle explícitamente a nginx que ignore el Cache-Control del upstream y mantenga su propio TTL.

Ejemplo de configuración nginx¶

Configuración mínima para un caché edge de EPG dimensionada para decenas de miles de clientes con intervalo de sondeo de 1–5 minutos:

# /etc/nginx/conf.d/pss-epg.conf

proxy_cache_path /var/cache/nginx/pss-epg
                 levels=1:2
                 keys_zone=pss_epg:32m
                 max_size=2g
                 inactive=30m
                 use_temp_path=off;

upstream pss_admin {
    server 127.0.0.1:43971;
    keepalive 64;
}

server {
    listen 80;
    # listen 443 ssl http2;  # рекомендовано: SSL termination здесь
    server_name epg.example.com;

    # gzip помогает: типовой EPG-JSON жмётся ~5–8x.
    gzip on;
    gzip_types application/json;
    gzip_min_length 512;
    gzip_proxied any;

    location = /data/epg/channel {
        proxy_pass http://pss_admin;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # PSS отдаёт no-cache; кешируем на edge принудительно.
        proxy_ignore_headers Cache-Control Expires Set-Cookie;
        proxy_hide_header   Cache-Control;
        proxy_hide_header   Pragma;
        proxy_hide_header   Expires;

        # Ключ кеша = весь URL с query string. Параметры src/ch/lang/t
        # уже определяют уникальность ответа.
        proxy_cache_key     "$scheme$host$request_uri";

        proxy_cache         pss_epg;
        proxy_cache_valid   200 60s;          # время устаревания
        proxy_cache_valid   400 404 10s;
        proxy_cache_lock           on;        # коалесцируем cache miss
        proxy_cache_lock_timeout   5s;
        proxy_cache_use_stale      error timeout updating
                                   http_500 http_502 http_503;

        # Отдадим клиенту результат в JSON, но с собственным TTL
        # (плеер пересмотрит EPG не раньше этого срока).
        add_header Cache-Control "public, max-age=60";
        add_header X-Cache-Status $upstream_cache_status always;
    }
}

Explicaciones y recomendaciones¶

TTL ``proxy_cache_valid 200 60s`` — compromiso entre frescura del EPG y carga en el upstream. La programación no cambia en tiempo real, por lo que 30–300 segundos es razonable. Tras importar nuevos eventos PSS vacía su caché al instante y la caché edge se pone al día en el siguiente TTL.
``proxy_cache_lock on`` es obligatorio con muchos clientes: ante un cache miss, fusiona las solicitudes paralelas sobre la misma clave en una sola solicitud upstream, protegiendo a SQLite de picos de BUSY bajo carga.
``keys_zone`` y ``max_size`` se dimensionan por el número de (canal × día × idioma): 32 MB de keys_zone bastan para cientos de miles de claves; 2 GB de max_size cubren un mes de historia para cientos de canales con margen.
gzip reduce notablemente el tráfico: las respuestas se comprimen bien (claves JSON repetidas, cirílico en UTF-8).
``X-Cache-Status`` en la respuesta permite al middleware ver HIT/MISS/EXPIRED y evaluar la eficacia de la caché.
Si nginx y PSS conviven en la misma máquina, el servidor admin no exige HTTP Digest para loopback, así que el bloque upstream puede quedarse sin proxy_set_header Authorization …. Para separarlos por redes, cree una cuenta viewer aparte y añada la autenticación Digest en proxy_pass.
HTTPS conviene terminarlo en nginx: PSS admite HTTPS directamente, pero un servidor edge suele ser más eficiente al gestionar handshakes TLS con miles de clientes simultáneos.

Endpoints relacionados¶

POST /data/epg/sql?s=<src_id> — consulta SQL arbitraria contra la base EPG (en particular, para obtener una lista de channel_id).
POST /data/epg/update?s=<src_id> — actualización forzada de una fuente XMLTV externa.

La lista completa y la descripción detallada de la API HTTP se encuentran en manual/http_data_api.txt.

Optimización del funcionamiento del programa¶

Si con muchos stream aparecen problemas de carga de CPU o falta de memoria, se pueden optimizar los ajustes.

You can disable the MPEG-TS filtering and processing features if you don’t need to.By default, the stream has the Clean All Unnecessary Data function enabled, disable it if there is no unwanted data in the stream. Disabling these features completely will remove the Original Media Information section of the Report.

Desactivar completamente o modificar los ajustes de Mosaic. La desactivación completa se realiza en los ajustes del servidor. Puede desactivarlo individualmente para cada stream o cambiar el intervalo de actualización con el ajuste Check Interval.

Errores de queue overload para las bases DBStat y DBEPG¶

Aparecen cuando el rendimiento de las bases de datos es insuficiente — disco lento o sistema sobrecargado.

La ubicación de las bases de datos se define con el parámetro data-dir del archivo pss.properties

Posibles soluciones:

Mover los archivos de base de datos a /tmp. Se utilizará la memoria del sistema — requiere una estimación de la memoria libre y el ajuste del tiempo de almacenamiento de las estadísticas (ver ajustes del servidor). Al reiniciar el sistema, los datos se perderán.
Reducir el detalle de las estadísticas — ver el parámetro dbstat-detail. Por defecto 5 s; se puede aumentar hasta 20.
Mantener la base de datos EPG en memoria — establecer dbepg-memory=true.

Transcodificadores¶

Los transcoders se implementan como binarios ejecutables independientes, lanzados desde pstreamer como procesos separados.

Se admiten configuraciones 1toN: a partir de un decoder se pueden generar varios flujos con distintos ajustes de encoder.

El flujo origen debe contener vídeo y audio; las variantes sin vídeo o sin sonido no se admiten.

Codecs implementados:

Video SW decoder: mpeg2, h.264, hevc (h.265)
Video NW decoder: mpeg2, h.264, hevc (h.265)
Video SW encoder: mpeg2, h.264, hevc (h.265)
Video NW encoder: h.264, hevc (h.265)

Se soportan flujos entrelazados en entrada y salida.

Para los decoders H.264 y HEVC se admite interlace alternate (dos campos separados en el flujo); se convierte a interlace interleaved.

El decodificador HEVC admite el perfil Main10 con bt.709 (SDR) y bt.2020 (HDR). El codificador HEVC siempre usa el perfil Main con bt.709.

Para los decodificadores H.264 y HEVC se admite VBR (Variable Frame Rate); se convierte a frame rate constante.

Audio decoder - mpeg (layer 1,2,3), aac, ac3
Audio encoder - mpeg (layer 2), aac

Existe el modo de transcodificación Video Passthrough — el vídeo no se transcodifica, solo el audio; se usa el transcoder SW.

Nota

Para la transcodificación se configuran dos o más streams, con output (decoder) e input (encoder).

Para configurar una instancia del transcoder se requiere:

Fuente — añadir en el stream output transcoder (decoder). En los ajustes elija el tipo: SW, NV o Video Passthrough.
Flujo de salida — añadir en el stream input transcoder (encoder); en los ajustes seleccionar la fuente-decoder.
Repetir si se requieren varios flujos de salida para un mismo decoder.

Ajustes del transcoder de salida (decoder)¶

Convert colors to BT.709 — conversión de los formatos SD BT.470-2 (PAL) y SMPTE 170M (NTSC) a BT.709
Trace — activar para diagnóstico el log detallado del transcoder.

Para el funcionamiento correcto del transcodificador, el flujo de origen debe cumplir ciertos requisitos; en algunos casos esto puede corregirse. Estos ajustes no convierten el flujo — actúan como pistas para el funcionamiento correcto del transcodificador.

Para corregir los datos del flujo de entrada existen los siguientes ajustes:

Fix PAR — corregir el Pixel Aspect Ratio. Se indica como fracción N/D; por ejemplo, 16/9 para Wide SD.
Fix Framerate — especificar explícitamente el framerate. En algunos flujos el framerate puede faltar en el SPS, y aparecerá el error correspondiente en el log del transcodificador. En estos casos hay que indicar el framerate manualmente. Se indica como fracción en formato N/D.

Ejemplos de valores de framerate:

PAL - 25/1
NTSC — 30/1 o 30000/1001
Cinema — 24/1 o 24000/1001

Ajustes del transcoder de entrada (encoder)¶

Encoder Type — códec de vídeo.
Align Total Bitrate — bitrate del stuffing del flujo (relleno con paquetes null). Importante si el flujo se usa para transmisión DVB. El bitrate debe ser garantizadamente mayor que el del vídeo y el de todas las pistas de audio.
Video Profile — para H.264 se puede elegir el perfil de codificación.
Video Bitrate — bitrate del flujo de vídeo en kbps. La codificación es siempre CBR; el bitrate total será mayor por las pistas de audio.
Speed Preset — preajustes de codificación, valores de 1 a 7. Menor valor = mayor calidad y más recursos necesarios. Por defecto 4.
GOP Interval — intervalo en frames para el GOP (equivale al Key Frame Interval). Por defecto 25 (1 segundo a 25p); recomendado cuando los reproductores arrancan en aleatorio.
BFrame — activar para mejorar la calidad. Valor recomendado: 3.
Lookahead — activar para mejorar la calidad. Valor recomendado: 20–50 frames.
Resize — cambio del tamaño de la imagen.
Deinterlace — convierte interlace en progressive.

No se admite la inserción de crop (franjas vacías en los bordes). Tampoco se permite un tamaño de imagen arbitrario porque distorsionaría las proporciones.

Para resize están disponibles las opciones:

Reducir proporcionalmente el tamaño en 2 y 4.
Establecer formato Wide SD 16:9, se asignará el Aspect Ratio correspondiente.
Upscale SD→HD. Se aplica a fuentes SD PAL/NTSC. No se admite interlace; aplique deinterlace previo si es necesario.
Definir el ancho. La altura se recalculará proporcionalmente.
Definir la altura. El ancho se recalculará proporcionalmente.

Algunos parámetros pueden ser incompatibles con el transcoder elegido; los errores aparecen en sus logs.

Procesamiento de audio¶

Por defecto todas las pistas de audio pasan del input al output sin procesar. Las pistas innecesarias se pueden eliminar con los filtros PID del stream.

Para transcodificar el audio se configuran reglas independientes por cada códec de audio. La opción skip — eliminar la pista de audio con ese códec.

Si en el flujo de salida no hay pistas de audio se generará un error; consulte los logs del transcoder.

Generación de PCR y TR 101 290.¶

El multiplexor MPEG-TS genera un nuevo PCR. Si se ajusta correctamente Align Total Bitrate (mayor que la suma de los bitrates de vídeo y audio), el PCR debe superar la comprobación TR 101 290.

Estado de los transcoders¶

Ante problemas en el funcionamiento del transcodificador (no hay flujo del encoder), consulte los logs en la sección Transcoders — allí se muestra la lista de instancias (cada línea es una instancia separada, decoder + N encoders); al hacer clic en la instancia deseada se abre el diálogo de estado de los logs. Se muestran el log actual y el de la ejecución anterior. Para log detallado active trace en los ajustes de output (decoder).

Documentación de usuario¶

Planificación y protocolos de transmisión de datos¶

Protocolo PS1¶

Protocolo SRT¶

Protocolo Pro-MPEG / RTP+FEC (COP3 / SMPTE 2022-1/2)¶

Protocolo RIST¶

Otros protocolos¶

Flujos con archivos y dispositivos¶

Lista de flujos permitidos y restricción del peer¶

Integración de aplicaciones de terceros¶

Requisitos del flujo de entrada¶

Ajustes del Stream¶

Redundancia de fuentes¶

Filtrado y modificación de MPEG-TS¶

Flujos MPTS¶

Demultiplexor¶

Multiplexor¶

Flujos de prueba¶

Servicio OTT¶

Modelo de caché para OTT HLS y DASH.¶

1. Modelo de caché¶

1.1. Recursos y cabeceras HTTP¶

1.2. Características de los segmentos TS¶

1.3. Características de los manifiestos¶

1.4. Variabilidad del contenido¶

2. Comportamiento de los clientes¶

3. Mecanismos especiales¶

3.1. HTTP 302 Redirect para DASH¶

3.2. Session reuse para DASH¶

3.3. Reutilización de segmentos entre sesiones¶

4. Parámetros de solicitud¶

5. Características de carga¶

6. Nginx como reverse proxy con caché¶

6.1. Configuración básica¶

6.2. Propósito de las directivas¶

6.3. Cálculo de max_size de la caché de segmentos¶

6.4. Terminación TLS¶

6.5. Multi-host¶

7. Caché en el cliente¶

8. Despliegue mediante CDN¶

9. Monitorización¶

9.1. X-Cache-Status¶

9.2. Formato del access-log¶

9.3. Métricas¶

10. Diagnóstico¶

11. Seguridad¶

11.1. Session URL¶

11.2. Rate limiting¶

11.3. Caché de respuestas de error¶

11.4. Restricción del acceso de red al origin¶

12. Integración con middleware¶

12.1. Modelo prefix-login¶

12.2. Formato de estadísticas¶

12.3. Limitaciones de prefix-login¶

13. Subtítulos WebVTT¶

13.1. URL de los segmentos VTT¶

DVR / Archivo¶

Configuración del almacenamiento¶

Vinculación de un flujo al almacenamiento¶

VOD: reproducción del archivo¶

URLs y parámetros¶

EPG-aligned VOD¶

Flujos adaptativos¶

Comportamiento del reproductor¶

Subtítulos en el archivo¶

Limpieza y retención¶

Protección de sesiones VOD activas¶

Varios almacenamientos¶

Estado del almacenamiento y monitorización¶

Protección contra pérdida accidental¶

Limitaciones de la versión actual¶

Operaciones con flujos¶

Exportación e importación de flujos mediante un script en Python¶

Exportación e importación de flujos por la interfaz web¶

Informes y diagnóstico¶

Análisis de flujos¶

Control del jitter¶

System Monitor¶

Mosaic¶

Administración¶

6.3. Cálculo de `max_size` de la caché de segmentos¶

9.1. `X-Cache-Status`¶