Documentation utilisateur¶
Planification et protocoles de transmission¶
Le logiciel Perfect Streamer est destiné à la transmission de flux MPEG-TS sur l’Internet public, sujet à pertes et latences, sur la base d’UDP.
Pour chaque flux MPEG-TS (Stream), on configure un serveur émetteur (Sender) et un ou plusieurs récepteurs (Receiver) ; l’ensemble est appelé Peer.
La configuration de l’émetteur et du récepteur consiste à saisir une liste de flux (Stream) et les paramètres de input et output pour chaque Stream. Plusieurs input dans la liste assurent la redondance des sources. Plusieurs output dans la liste permettent de transmettre les flux vers différents destinataires en même temps.
Pour l’émetteur, input désigne les sources des flux MPEG-TS, output la transmission des flux vers les récepteurs. Pour les récepteurs, input désigne la réception des flux depuis l’émetteur. Quatre protocoles Peer sont disponibles pour la transmission entre émetteur et récepteur :
Protocole Perfect Stream (PS1).
SRT.
Pro-MPEG / RTP+FEC.
RIST.
Protocole PS1¶
Le protocole PS1 fonctionne sur le principe Automatic Repeat reQuest (ARQ). Il est peu coûteux en ressources et permet de transmettre des flux à haut débit.
Sur l’émetteur — configuré dans output. Une seule instance est disponible par stream. Il faut inscrire dans Peer les logins des récepteurs. On définit le port UDP listen, qui doit être unique pour chaque stream.
Côté récepteur — configuré dans l’input. Indiquer l’hôte et le port de l’émetteur, ainsi que login et mot de passe.
Le chiffrement des flux (Crypto protection) est disponible, AES-128 est utilisé. Pour l’activer des deux côtés, saisir Crypt Passphrase comme clé partagée.
En fonctionnement, le récepteur (client) transmet ses statistiques à l’émetteur (serveur). On les consulte dans la section Peers en sélectionnant le client.
La latence du flux et la capacité de corriger les pertes dépendent des paramètres du récepteur (client) :
Round Trip Time — RTT en ms, par défaut 300. Latence estimée (ping) du canal. Après démarrage du flux, le RTT réel apparaît dans les statistiques (PS1 recovery delay).
Client Latency (RTT multiplexor) — multiplicateur du RTT (10 par défaut) déterminant la latence du flux dans le buffer émetteur. Par défaut, latence du buffer = 3000 ms.
Côté émetteur, on dispose du paramètre de latence (longueur du buffer) Latency (ms). Il doit être supérieur aux latences fixées chez les clients.
La capacité du protocole à compenser les pertes est déterminée par le nombre de demandes de retransmission et dépend de Client Latency (RTT multiplexor). Des pertes importantes entraînent un trafic réseau supplémentaire. Pour réduire la latence, il convient d’affiner ces paramètres.
Pour la bonne marche du protocole, voir les statistiques du client. PS1 recovery : Not found → augmenter le buffer émetteur ; Dublicates → augmenter le 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.
Protocole SRT¶
Protocole ouvert développé par Haivision. Basé sur UDT, il est largement répandu et offre de bonnes caractéristiques de compensation des pertes de paquets.
Cas d’usage :
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.
Fonctionnement en mode Listener : réception et émission du flux d’une chaîne avec indication du port d’écoute.
Les ports en mode listen doivent être uniques.
Le chiffrement des flux (Crypto protection) est disponible, AES-128 est utilisé. Pour l’activer des deux côtés, saisir Crypt Passphrase comme clé partagée.
Si l’émetteur utilise le mode listen (par défaut), l’initiation de la connexion provient du récepteur, l’émetteur exige une authentification et les récepteurs sont enregistrés dans peer. Login et mot de passe sont obligatoires.
Les options du protocole SRT correspondent à la description : 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, %) — Surdébit pour la récupération de la bande passante au-delà du débit d’entrée (voir SRTO_INPUTBW), en pourcentage du débit d’entrée. Effectif uniquement si SRTO_MAXBW est à 0. Émetteur : configurable par l’utilisateur ; par défaut : 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) — Cette option n’est effective que lorsque SRTO_MAXBW est égal à 0 (relatif). Elle contrôle la bande passante maximale conjointement avec SRTO_OHEADBW selon la formule : MAXBW = INPUTBW * (100 + OHEADBW) / 100. Si cette option est à 0 (automatique), la valeur réelle de INPUTBW sera estimée à partir du débit du flux d’entrée (cas où l’application appelle la fonction srt_send*) pendant la transmission. La valeur minimale admissible de l’estimation est limitée par SRTO_MININPUTBW, c’est-à-dire INPUTBW = MAX(INPUTBW_ESTIMATE; MININPUTBW).
Recommandations : définissez ce paramètre sur le bitrate attendu de votre diffusion et conservez la valeur par défaut de 25 % pour 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
Protocole Pro-MPEG / RTP+FEC (COP3 / SMPTE 2022-1/2)¶
Livraison MPEG-TS via RTP avec correction d’erreurs anticipée (FEC, Forward Error Correction). Le même protocole apparaît dans la littérature et les équipements sous différents noms :
Pro-MPEG / Pro-MPEG COP3 — Code of Practice #3 du forum Pro-MPEG, décrit dans la norme IEEE (https://ieeexplore.ieee.org/document/6738329) ;
RTP + FEC — nom fonctionnel (flux RTP plus canaux FEC) ;
SMPTE 2022-1 — Column FEC (même schéma, publié comme norme SMPTE) ;
SMPTE 2022-2 — Row + Column FEC (matrice bidimensionnelle, implémentée dans PSS).
Достоинства — низкая задержка. Его недостаток — высокий дополнительный трафик (overhead), и он плохо работает при больших потерях пакетов (более 0.2%).
Этот протокол основан на RTP с добавлением 2-х каналов для FEC (кода коррекции ошибок). Два канала FEC используют порты port+2 и port+4, что надо учитывать при добавлении нескольких потоков на один хост или мультикаст группу.
Côté émetteur, le flux de paquets RTP est groupé en une matrice de Cols colonnes et Rows lignes. Exemple pour cols=8 et rows=4 (valeurs par défaut) :
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 |
Les paquets Rx et Cx forment les données FEC par lignes et colonnes. Plus la matrice est petite, meilleure est la capacité de correction des pertes, mais plus le trafic supplémentaire est élevé. Dans cet exemple, il y a 12 paquets FEC pour 32 paquets RTP du flux.
Доступно шифрование потоков (Crypto protection), используется AES-128, но это не включено в стандарт, поэтому не гарантируется совместимость со сторонним ПО или оборудованием.
Des extensions de protocole non standard existent :
Multiplexing — мультиплексирование RTP каналов через один UDP порт. Может упростить настройку сети. Header XOR — обфускация RTP заголовка. Усложнит определение типа трафика в сети.
Protocole RIST¶
Nouveau protocole ouvert basé sur RTP/RTCP. Fonctionne sur le principe Automatic Repeat reQuest (ARQ) sans ACK, uniquement NACK, garantissant une grande efficacité.
Utilise unicast et multicast.
Les profils Simple et Main sont implémentés. Simple utilise deux ports UDP consécutifs ; le port configuré doit être pair. Main n’utilise qu’un seul port RTP avec multiplexage des données.
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.
Côté récepteur — configuré dans l’input. Pour l’unicast, on définit le port de réception (listen) et obligatoirement l’interface réseau. Pour le multicast, on indique uniquement le groupe multicast et le port.
RIST prend en charge plusieurs pairs (adresses). En définissant un poids supérieur à 1, on active la répartition de charge entre les pairs selon le poids.
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.
Autres protocoles¶
Outre les protocoles peer, d’autres sont disponibles pour recevoir et émettre des flux :
Protocol |
Input |
Output |
|---|---|---|
UDP |
Yes |
Yes |
RTP |
Yes |
Yes |
TCP |
Yes |
No |
HLS |
Yes |
Yes |
UDP (unicast ou multicast) — réception et émission de MPEG-TS dans un paquet UDP, jusqu’à 7 paquets TS par UDP.
RTP (unicast ou multicast) — protocole standard basé sur RFC. La récupération des paquets réordonnés est prise en charge.
TCP — réception de MPEG-TS via une connexion TCP, mode client TCP.
HLS — réception et émission de MPEG-TS over HTTP ou le protocole HLS standard d’Apple. À la réception d’une playlist adaptative, c’est le flux au bitrate le plus élevé qui est sélectionné.
Flux avec fichiers et périphériques¶
Pour input et output, le protocole file/device est disponible pour les fichiers et périphériques.
output file/device — enregistrement dans un fichier ou sortie vers un périphérique. L’enregistrement dans un fichier peut être nécessaire pour produire un fichier ts en vue d’un diagnostic ultérieur par d’autres analyseurs. Sortie vers un périphérique — tout périphérique (y compris SDI) enregistré dans /dev.
input file/device — lecture en boucle de la vidéo depuis un fichier TS.
- Pour travailler avec des fichiers, indiquer le chemin complet dans le champ File Path :
/catalog/stream.ts.
Pour les périphériques, l’indicateur Is Device est en plus activé.
Liste des flux autorisés et restriction du pair¶
Pour la restriction d’accès aux flux de chaînes TV côté client (Peer) en mode SRT Listen, PS1, HLS et HTTP, le programme implémente la fonctionnalité de liste des flux autorisés. Dans les paramètres du Peer sur l’émetteur, on définit la liste des chaînes disponibles. Pour cela, dans le champ Stream Access, ajoutez de la liste générale des chaînes du serveur uniquement celles destinées à ce Peer. Par défaut, avec une liste vide, toutes les chaînes sont accessibles.
Pour un Peer, des limites de temps et du nombre de connexions par protocole de transport sont disponibles.
Anonymous peer
Par défaut, le login du peer a la valeur anonymous. Le peer anonyme permet de distribuer des flux sans liaison à une IP ou login/mot de passe. S’appliquent les restrictions sur le nombre de flux distribués par protocoles de transport, sur la date limite et sur la liste des flux autorisés.
Il est possible de créer un pair individuel par login (nom) et mot de passe.
Pour autoriser un pair par IP, activer l’option « Login Is IP ».
Options d’autorisation :
Par IP unique
Par plage d’IP, par exemple : « 192.168.1.10-192.168.1.20 »
Variante combinée, syntaxe des listes IP : ip[-ip2][,…]
Intégration d’applications tierces¶
Pour prendre en charge d’autres protocoles non couverts par les moyens intégrés, il est possible de recevoir et transmettre un flux via des applications console externes. Pour cela, un protocole std distinct est disponible pour input et output. Le flux MPEG-TS est reçu et transmis via le flux d’entrée/sortie du système d’exploitation.
Dans les paramètres, on indique l’application console (chemin absolu) et la ligne de commande ; on peut également définir des variables d’environnement.
Pour un input s’appuyant sur une application externe, il faut éviter toute sortie sur stdout — uniquement sur stderr.
Pour l”output, on peut configurer le paquetage jusqu’à 7 paquets MPEG-TS.
Exigences sur le flux d’entrée¶
Conforme à ISO 13818-1, Single Program (SPTS) ou Multi Program Transport Stream (MPTS). Les particularités MPTS sont décrites plus loin ; les paramètres ci-dessous concernent le Single Program.
Au moins une piste audio est requise.
Les flux sans vidéo sont pris en charge, activés par le mode Radio.
Les flux chiffrés sont pris en charge ; pour cela, activez Scrambled Stream.
Pour la synchronisation, le flux doit contenir des marques PCR valides.
Paramètres du Stream¶
Définir un nom de flux unique en lettres latines, chiffres et caractères « _ », « - ». On peut aussi définir un nom d’affichage, prenant en charge le russe et d’autres langues.
Stream Timeout — délai global du flux. Si aucun flux d’entrée valide n’est reçu pendant cette durée, un redémarrage complet est effectué.
Pause — met le stream et l’ensemble des input et output en état inactif. À l’ajout d’un nouveau stream, input ou output, ils sont par défaut en pause et inactifs.
Le programme vérifie la validité du flux d’entrée sur l”input. En cas d’échec, l”input est considéré comme défaillant.
Check Interval — intervalle de re-vérification du flux.
Paramètres de filtrage MPEG-TS :
Remove All Unnecessary Data — supprime toutes les données inutiles à part PAT/PMT, vidéo et audio, sauf celles définies dans les filtres séparés (voir ci-dessous)
Remove SDT — suppression des données SDT (nom de chaîne, fournisseur, etc.).
Remove EIT/EPG — suppression des données EPG.
Remove Teletext — suppression du télétexte.
Remove Subtitles — suppression des sous-titres.
Gestion du bitrate du flux :
Bitrate mode — mode de gestion du bitrate.
Origin (default) — le flux est transmis tel quel.
VBR — supprime les paquets NULL pour minimiser le bitrate. À activer pour une diffusion OTT exclusive.
CBR auto — active l’alignement du bitrate par insertion de paquets NULL (stuffing). Le bitrate résultant est calé sur le bitrate maximal du flux d’entrée.
CBR set stuffing bitrate — définir explicitement le bitrate. Si la valeur est inférieure au flux d’entrée, l’alignement se fait comme en CBR Auto.
En mode CBR activé, la PCR Accuracy respecte TR 101 290 ; l’intervalle PCR reste celui du flux original.
Correction des flux :
Fix PAT/PMT interval — corrige l’intervalle pour respecter TR 101 290 en insérant des PAT/PMT supplémentaires.
Redondance des sources¶
On peut définir plusieurs input sous forme de liste, mais un seul est actif. En cas de défaillance, l”input suivant est essayé, et ainsi de suite en boucle.
Si Fallback Check est activé pour un stream, lorsqu’un input de secours (pas le premier de la liste) fonctionne, une revérification des entrées plus haut dans la liste est effectuée à l’intervalle Check Interval. Si lors de la revérification le flux est valide, le stream y bascule.
L’ordre des input étant significatif, il peut être modifié. Un input en pause n’est pas pris en compte pendant l’exécution.
Filtrage et modification MPEG-TS¶
Par défaut, le flux MPEG-TS est transmis tel quel.
Pour chaque input, les options de filtrage MPEG-TS suivantes sont disponibles :
PID Accept — liste des PID autorisés. Si vide, tout est autorisé sauf PID Reject.
PID Reject — liste des PID interdits. Prioritaire sur PID Accept.
Il est possible de changer les PID en saisissant les listes PID Old et PID New.
Mapping PID and Languages — réaffectation de la langue des pistes audio.
Default Language — définir la langue par défaut si la piste audio n’en a pas.
Pour le stream, on peut attribuer de nouvelles données MPEG-TS (SDT) :
MPEG-TS Network ID
Service Name
Provider Name
Language
Flux MPTS¶
Flux MPTS — flux MPEG-TS contenant plusieurs flux (services), chacun avec un numéro unique (PNR). Utilisé pour la diffusion DVB.
Les options de filtrage ne sont pas disponibles pour les flux MPTS. Les flux sont transmis tels quels.
La fonction mosaic est désactivée par défaut. Ne pas l’activer sur des CPU faibles — risque d’introduire du jitter.
Le diagnostic du flux affiche les données par programme ainsi que les statistiques globales.
Démultiplexeur¶
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.
Multiplexeur¶
Assemble un flux MPTS à partir de flux SPTS individuels. Pour le configurer :
Créer un flux MPTS.
- Ajouter un input de type muxer. Définir le bitrate pour aligner le flux en CBR (stuffing, conformité TR 101 290 et T-STD).
Si 0 est défini (par défaut), il n’y aura pas d’alignement — le bitrate correspondra aux flux d’entrée. Vous pouvez aussi y saisir certains paramètres du flux MPEG-TS ; pour la plupart des applications, les valeurs par défaut conviennent.
Dans le Stream source, ajouter un output de type muxer. Saisir le nom de service et, si besoin, le nom du fournisseur. Si l’écriture n’est pas latine, sélectionner la langue dans les paramètres MPEG-TS du flux.
Répéter pour toutes les sources.
Le multiplexeur génère pour le flux SDT, NIT et TDT/TOT (marques de temps). L’EIT (EPG) provient des flux source. De nouveaux PID sont assignés.
Flux de test¶
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.
Configuration via l’activation du type d’input correspondant sur le flux. On peut définir le format vidéo, la résolution, le bitrate, le volume et la fréquence audio, etc.
La liste des Test Streams disponibles se trouve dans le menu latéral gauche du programme.
Service OTT¶
Émet des flux via des protocoles HTTP — HLS, MPEG-DASH (depuis la version 1.12) et MPEG-TS over HTTP. HTTPS (SSL) est pris en charge. La diffusion s’active dans l’onglet OTT des paramètres Stream.
Les URL de connexion ont le format :
http://host:port/http/stream/login/password — autorisation par login et mot de passe
http://host:port/http/stream/login — autorisation par login (token)
http://host:port/http/stream/ — autorisation par IP
host et port se définissent dans les paramètres de http server.
stream — ID du stream. Ne pas confondre avec le numéro d’ordre dans la liste des streams. L”ID est affiché en haut de la page de statistiques du stream et dans la colonne ID de la liste des streams ; il est défini à la création du stream et ne change jamais.
De manière similaire pour HLS et DASH :
Sur la page de statistiques du flux s’affichent les URL des protocoles connectés (sous forme de modèle) et leur statut. L’accès non autorisé est interdit ; les clients doivent être déclarés dans Peers.
Pour HLS, des paramètres supplémentaires sont disponibles dans l’URL (optionnels) :
[URL]?a=1&s=40&m=40&v=5
a : 1 — chemins absolus dans la playlist (par défaut), 0 — chemins relatifs.
s : durée de la playlist dynamique (s), 40 s par défaut.
m : durée minimale de la playlist dynamique (s), 40 s par défaut. Taille maximale de la playlist dynamique 60 s. Si la taille actuelle du buffer de chunks est inférieure au minimum demandé, l’erreur 404 est renvoyée. Cela garantit que le HLS démarre depuis un buffer de chunks rempli sur le serveur.
v : version du protocole HLS annoncée dans la playlist. 5 par défaut ; un changement peut être nécessaire pour certains clients HLS.
Pour la compatibilité avec certains clients HLS, on peut ajouter le nom de fichier index.m3u8 à l’URL, par ex. http://host:port/hls/stream/login/password/index.m3u8.
Le serveur HLS dispose de deux modes — Peer mode et OTT mode.
Peer mode — mode avec découpage simple des segments (chunks). Recommandé pour le peering / la distribution.
OTT mode — mode avec un découpage des segments optimisé pour la diffusion OTT et un démarrage rapide des lecteurs. La charge CPU est plus élevée ; recommandé pour la diffusion.
SSL (HTTPS) peut être activé sur le serveur HTTP via ses paramètres.
Chunk Min Interval et 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
Depuis la version 1.10, prise en charge de HLS Adaptive Multistream et, depuis 1.12, de DASH Adaptive Multistream
Pour les flux adaptatifs, on configure une playlist HLS dédiée. Pour ce faire :
Pour les flux à inclure dans la playlist adaptative, activez HLS avec OTT Mode.
Dans le menu principal apparaît la section des flux adaptatifs. Y ajouter un flux et y inscrire tous les flux à inclure dans la playlist.
On peut affecter aux flux un paramètre de bitrate. Par défaut 0 signifie que le bitrate mesuré est utilisé ; sinon, on peut le fixer explicitement.
Pour les playlists adaptatives, l’URL diffère :
Des restrictions d’accès aux flux adaptatifs peuvent être imposées aux pairs (clients), comme aux flux ordinaires. L’autorisation d’un flux adaptatif englobe l’autorisation de tous les flux qu’il contient.
Modèle de mise en cache pour OTT HLS et DASH.¶
Le serveur produit trois catégories de réponses qui diffèrent par leur durée de vie et leur aptitude à la mise en cache par les nœuds intermédiaires (reverse proxy, CDN, cache client).
1. Modèle de mise en cache¶
1.1. Ressources et en-têtes HTTP¶
Ressource |
URL |
Content-Type |
Cache-Control |
|---|---|---|---|
Segment TS |
|
|
|
DASH MPD |
|
|
|
HLS master |
|
|
|
HLS media |
|
|
|
302 Redirect |
|
— |
|
Raw TS |
|
|
non défini ; non mis en cache |
1.2. Caractéristiques des segments TS¶
L’identifiant keyID est formé comme CRC64(startTime || streamID) et est globalement unique. L’URL d’un segment adresse un contenu immuable — sur des requêtes répétées de la même URL, un flux d’octets identique est renvoyé (tant que le segment reste dans la fenêtre glissante).
La directive immutable supprime la revalidation conditionnelle côté client (If-None-Match, If-Modified-Since). La valeur max-age=60 reste compatible avec un timeShiftBufferDepth=40s typique.
1.3. Caractéristiques des manifestes¶
max-age=1 limite la limite supérieure d’obsolescence du contenu en cache à une seconde. Combiné à proxy_cache_lock on (nginx), les pics de requêtes vers le manifeste sont coalescés en une seule requête vers l’origine par seconde.
1.4. Variabilité du contenu¶
Avec absPath=0 (par défaut, sans paramètre d’URL « a »), les manifestes HLS media et DASH MPD ne contiennent pas l’identifiant de session dans leur corps. Le contenu du manifeste est identique entre sessions appartenant à une même combinaison (stream, param). Cela permet au cache reverse-proxy de réutiliser une entrée entre sessions avec normalisation de la clé de cache.
Avec absPath=1 (paramètre d’URL « a=1 »), le corps du manifeste contient des URL absolues incluant schéma, host et identifiant de session. Le contenu devient spécifique à la session — la réutilisation cross-session du cache n’est plus possible.
2. Comportement des clients¶
Client |
URL de rafraîchissement du manifeste |
Impact sur le nombre de sessions |
|---|---|---|
VLC 3.x HLS |
|
Une session par lecture |
VLC 3.x DASH |
|
Traité par session reuse (voir 3.3) |
ffmpeg 5.x HLS |
|
Une session par lecture |
ffmpeg 5.x DASH |
|
Traité par session reuse (voir 3.3) |
dash.js, hls.js |
|
Une session par lecture |
3. Mécanismes spéciaux¶
3.1. HTTP 302 Redirect pour DASH¶
Une requête de la forme /dash/<stream>/<login>/<pass>/index.mpd renvoie une réponse 302 Found avec l’en-tête Location: /h<sess>/index.mpd. Le corps de la réponse est vide. L’authentification et l’allocation de la session ont lieu pendant le traitement de la redirection.
Les clients qui prennent en charge le caching de redirection accèdent directement à l’URL de session dans les requêtes suivantes. Les clients qui ne le prennent pas en charge réémettent la requête de redirection. Le coût du retraitement de la redirection se limite à la vérification d’authentification et aux opérations de session reuse.
3.2. Session reuse pour DASH¶
Lors du traitement de la requête /dash/.../index.mpd exécutée sous login-id L pour stream-id S et le drapeau adaptive=A, si _ottClientList contient déjà une session DASH avec les mêmes (L, S, A), son sessID est renvoyé. Aucune nouvelle session n’est créée, aucun slot maxConn n’est consommé.
Applicable uniquement à DASH. HLS n’a pas besoin d’un mécanisme de reuse distinct : les clients HLS rafraîchissent la media playlist via l’URL de session et ne déclenchent pas applyNewOTTSess à chaque rafraîchissement.
3.3. Réutilisation des segments entre sessions¶
Le chemin /h<sess>/<keyID>.ts est indépendant de sess lors de la résolution de keyID en contenu : keyID identifie de manière unique le segment dans la ChunkList enregistrée (voir _ottStreamList). Nginx avec une clé de cache normalisée (en supprimant le préfixe /h<sess>/) sert toutes les requêtes du même keyID depuis une unique entrée de cache.
4. Paramètres de requête¶
Paramètre |
Valeur par défaut |
Impact |
|---|---|---|
|
|
|
|
|
|
|
|
Longueur minimale de la fenêtre pour émettre le manifeste |
|
|
|
Modifier le paramètre via la query string met à jour les valeurs stockées dans la session lors du prochain appel à applyNewOTTSess.
5. Caractéristiques de charge¶
La charge sur l’origine évolue avec le nombre de streams distincts visionnés simultanément. L’augmentation du nombre de clients regardant le même stream n’augmente pas le nombre de requêtes vers l’origine en présence d’un cache reverse-proxy avec clé de cache normalisée.
Scénario |
Fréquence des requêtes origin (réf.) |
|---|---|
1 client par flux X |
MPD: 0.4 req/s, segment: 0.2 req/s |
N clients sur un même flux X (cache activé) |
MPD: 1 req/s, segment: 0.2 req/s |
N clients ffmpeg en mode replay sur un même flux |
MPD : 1 req/s (avec |
N clients sur N flux distincts |
MPD: 0.4·N req/s, segment: 0.2·N req/s |
6. Nginx en tant que reverse proxy avec cache¶
6.1. Configuration de base¶
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. Rôle des directives¶
Directive |
Objectif |
|---|---|
|
Sérialise l’exécution des requêtes upstream lors de cache miss simultanés sur la même clé |
|
Renvoie la copie périmée aux requêtes parallèles pendant le rafraîchissement du cache |
|
Utilise |
|
Interdit la mise en cache des erreurs d’autorisation et 404 |
|
Maintient un pool de connexions persistantes vers l’origin |
|
Pour les segments ; active la mise en buffer de la réponse dans nginx |
|
Pour la section |
6.3. Calcul de max_size pour le cache des segments¶
Valeur indicative : bitrate × timeShiftBufferDepth × distinct_streams × 2
Exemple : 10 flux × 8 Mbps × 40 s × 2 ≈ 800 Mo. Un facteur de sécurité de 10× est recommandé pour absorber la variabilité du bitrate.
6.4. Terminaison TLS¶
Le serveur Perfect Streamer accepte les connexions sur les ports HTTP et HTTPS. En cas de terminaison TLS sur nginx, l’upstream utilise le port HTTP. Le transfert des en-têtes X-Forwarded-Proto et X-Forwarded-Host est obligatoire pour la formation correcte des URL absolues lorsque 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;
}
En HTTPS entre nginx et l’origin, on applique proxy_ssl_verify et proxy_ssl_trusted_certificate. Pour les connexions loopback, le chiffrement est superflu.
6.5. Multi-host¶
Lorsque plusieurs server_name sont servis par un même processus nginx, $host est ajouté à la cache key pour isoler les contenus :
map $uri $pss_cache_key {
~^/h[0-9a-f]{16}(?<tail>/.+\.(ts|m3u8))$ "$host:stream:$tail";
default "$host:$uri";
}
La taille de keys_zone se calcule à 8000 clés/Mo. Pour des installations multi-hôtes avec des milliers de flux, il est recommandé keys_zone=...:300m ou plus.
7. Mise en cache côté client¶
Cache-Control: immutable est honoré par les navigateurs Chrome/Firefox/Safari. Le cache client renvoie le segment sans requête conditionnelle lors d’un nouvel accès (y compris seek arrière dans le buffer du lecteur).
Les Service Workers peuvent appliquer une stratégie cache-first basée sur le contenu de Cache-Control. Les lecteurs DASH (dash.js, Shaka) utilisent MSE via SourceBuffer ; un segment placé dans le buffer reste disponible sans nouvelle requête HTTP jusqu’à ce qu’il sorte de la fenêtre.
Pour les requêtes inter-domaines, l’en-tête Access-Control-Allow-Origin: * permet le caching dans les shared caches sans Vary: Origin. Le passage de l’ACAO à un Origin spécifique nécessite Vary: Origin, ce qui réduit l’efficacité du shared cache.
8. Déploiement via CDN¶
Perfect Streamer est compatible avec les CDN en mode pull-from-origin (Cloudflare, Akamai, Fastly, BunnyCDN, Amazon CloudFront).
Origin shield. Il est recommandé de placer un ou plusieurs nœuds shield entre l’edge du CDN et l’origin afin de réduire le taux de requêtes vers l’origin lorsque les clients sont répartis globalement.
Purge. Les segments adressés par contenu n’ont pas besoin de purge. Lors d’un changement de métadonnées du flux (codec, résolution), les manifestes se rafraîchissent dans la fenêtre max-age=1 sans purge explicite.
Cache warming. En cas de pic de charge attendu sur un flux donné, on peut préchauffer le CDN depuis plusieurs points géographiques avant le début de la diffusion.
Géo-distribution. Les segments (max-age=60) conviennent bien au caching géographiquement distribué. Les manifestes (max-age=1) tolèrent jusqu’à une seconde de retard de livraison — acceptable pour du live non low-latency.
9. Supervision¶
9.1. X-Cache-Status¶
Ajouter add_header X-Cache-Status $upstream_cache_status; dans chaque location avec cache. Valeurs :
Valeur |
Description |
|---|---|
|
Réponse depuis le cache |
|
Absent du cache ; récupéré depuis l’origin et stocké |
|
Expiré, rafraîchi |
|
Copie stale renvoyée à une requête parallèle pendant le rafraîchissement |
|
|
|
L’origin a renvoyé 304 Not Modified |
|
|
9.2. Format de l’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étriques¶
Le module nginx-vts exporte les métriques par zone au format Prometheus
GET /status/format/prometheus
Seuils recommandés pour les alertes :
Métrique |
Seuil |
Cause possible |
|---|---|---|
Segment HIT rate |
< 90 % sur 5 minutes |
Normalisation de la cache key cassée ; |
Manifest MISS rate |
> 50 % sur 1 minute |
|
Upstream response time p95 |
> 500 ms sur 1 minute |
Surcharge de l’origin |
Cache zone fill |
> 90 % sur 10 minutes |
Approche de |
10. Diagnostic¶
Symptôme |
Cause probable |
Solution |
|---|---|---|
Taux HIT segment faible |
|
Vérifier les en-têtes et le regex de la directive |
404 sur les segments sortis de la fenêtre |
404 mis en cache pour un segment sorti de la fenêtre glissante |
Ajouter |
Délai de démarrage de lecture 2–5 s |
|
Réduire à 1–2 s ; activer |
Le manifeste ne se rafraîchit pas |
|
Définir explicitement |
Augmentation de TIME_WAIT côté upstream |
|
Ajouter |
403 sur |
Le client résout les URL relatives par rapport à l’URL avant redirection |
Le serveur émet |
11. Sécurité¶
11.1. Session URL¶
Une URL au format /h<sess>/... joue le rôle de jeton de session — pas besoin de réauthentification. La durée de vie est bornée par l’idle timeout (valeur 30 s). En l’absence d’activité, la session est supprimée par la tâche cleaner.
Exigences :
HTTPS pour tous les chemins OTT (
/hls/,/dash/,/h<sess>/) en productionL’identifiant de session dans l’en-tête
Locationdu 302 n’est pas mis en cache (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;
}
}
Les URL de session (/h<sess>/) ne nécessitent pas de rate limiting — le traitement est peu coûteux, les réponses sont mises en cache.
11.3. Mise en cache des réponses d’erreur¶
proxy_cache_valid 200 60s;
proxy_cache_valid 301 302 0s;
proxy_cache_valid 404 403 0s;
proxy_cache_valid any 1s;
Interdit la mise en cache des redirections (sess unique dans Location) et des réponses d’erreur d’autorisation ou de ressource absente.
11.4. Restriction de l’accès réseau à l’origin¶
Le port 41972 (41982 pour HTTPS) doit être fermé au trafic externe. Configurations acceptables :
Lier Perfect Streamer à
127.0.0.1(si nginx est colocalisé)Règle de pare-feu :
iptables -A INPUT -p tcp --dport 41972 ! -s 10.0.0.0/8 -j DROP
12. Intégration avec un middleware¶
12.1. Le modèle prefix-login¶
Perfect Streamer peut déléguer l’identification utilisateur à un middleware/système de facturation via le mécanisme prefix-login. Un connecteur externe vers le système de facturation n’est pas inclus dans la version actuelle.
Configuration de l’utilisateur embedded :
{
"id": 9,
"login": "sub",
"password": "xxx",
"is-prefix": true,
"max-conn-http-hls": 1,
"accept-stream": [ ... ]
}
Avec is-prefix: true, le serveur accepte les URL dont le login suit <prefix><billing_user_id>
/dash/test1/sub42/xxx/index.mpd
/hls/test1/sub43/xxx/index.m3u8
12.2. Format des statistiques¶
<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>
Le champ login-id contient le hash du login URL. login est la valeur configurée. match-login est le login URL utilisé par le client.
12.3. Limitations de prefix-login¶
Mot de passe partagé. Tous les abonnés du pool prefix utilisent un même mot de passe. Sa compromission donne accès à tout
<prefix><string>.Granularité ACL.
accept-streams’applique à tout le pool prefix ; pas d’ACL par abonné sans facturation externe.Rotation du mot de passe. Le changement déconnecte tous les abonnés actifs. Pour un remplacement progressif, deux prefix-logins sont temporairement nécessaires.
13. Sous-titres WebVTT¶
La source des sous-titres est DVB Teletext / DVB Subtitling depuis le MPEG-TS d’entrée. Les pistes de sous-titres Teletext doivent être présentes dans les sections Media Information ou Original Media Information. La section Analyzer permet également de vérifier que les paquets des PID correspondants sont actifs.
Pour OTT HLS/DASH, le mode OTT doit être activé (en Peer mode, les sous-titres WebVTT ne sont pas disponibles). Dans la section Output # OTT, le compteur de chunks OTT WebVTT buffer chunk count doit devenir non nul.
Pour diagnostiquer les sous-titres, activer Analyze et Trace sur le stream. Au démarrage du flux, le journal du stream doit afficher :
Start Teletext subtitle decoder
[ttxsubdec] ttx: pid=331 magazine=8 page=0x88 lang=***
Le journal contient ensuite le texte décodé des sous-titres.
13.1. URL des segments VTT¶
Schéma |
URL |
Contenu |
|---|---|---|
HLS master |
|
|
HLS subtitle playlist |
|
liste |
Segment VTT HLS |
|
VTT avec X-TIMESTAMP-MAP de type HLS |
DASH MPD AdaptationSet |
dans |
|
Segment VTT DASH |
|
VTT avec X-TIMESTAMP-MAP de type DASH |
<keyHex> est l’hex 16 caractères de CRC64(startTime, streamID, pid). <seq> est le numéro décimal du chunk dans le subtitle storage (compteur distinct du video storage).
DVR / Archives¶
Depuis la version 1.13, Perfect Streamer intègre un DVR — une archive flux persistante sur disque, fonctionnant en parallèle avec la diffusion OTT normale (HLS / DASH). L’archive est écrite automatiquement, sans processus séparé, et lue via les mêmes URLs OTT que le live — seule différence : le paramètre query.
Fonctionnalités :
Enregistrement de chaque flux OTT dans l’archive sur le stockage choisi.
Lecture HLS et DASH de l’archive (VOD) sur les mêmes URLs que le live.
Sous-titres (WebVTT) — écrits avec les chunks TS.
Plusieurs stockages — un flux est lié à un seul ; différents flux peuvent écrire sur différents disques.
Nettoyage automatique par temps de rétention et utilisation disque.
EPG-aligned VOD — archive par référence à un événement EPG.
VOD adaptatif — pris en charge pour les groupes adaptatifs.
Le DVR ne requiert pas de licence séparée. Activé par flux en ajoutant une liaison stockage.
Le DVR ne remplace pas le live. Si un flux a une archive, le client reçoit une playlist live identique à celle sans DVR. L’archive ne joue que si le client demande explicitement le mode VOD via un paramètre query d’URL (voir ci-dessous).
Configuration du stockage¶
Un stockage est un enregistrement dans la section Configuration / DVR Storage. Chaque enregistrement décrit un répertoire sur disque où PSS écrit les fichiers d’archive. Un flux utilise un stockage.
À l’ajout d’un stockage, on configure :
Name — nom affiché.
Dir Path — chemin du répertoire sur disque. Après création, le chemin n’est pas modifiable — pour déplacer l’archive, supprimer l’enregistrement et en créer un nouveau. Les fichiers existants ne sont pas touchés sur disque à la suppression.
Max Usage, % — seuil d’utilisation disque (par défaut 90 %). Au-dessus, le nettoyage size-based démarre (voir ci-dessous). Min 1 %, max 100 %.
Cleanup Interval, sec — période de la tâche de nettoyage (par défaut 10 sec). À chaque tick, on coupe d’abord tout ce qui dépasse la profondeur de rétention ; puis, si Max Usage est dépassé, les anciens chunks.
Disk Pressure Grace, sec — durée pendant laquelle Used % doit dépasser Max Usage en continu avant le Size-based cleanup (par défaut 60 sec). Filtre les pics courts.
Disk Pressure Cut, sec — limite haute par tick de nettoyage : secondes vidéo par flux supprimables d’un coup (par défaut 300 sec). Le reste passe au tick suivant.
Disk Emergency Bytes — seuil d’espace libre sous lequel le stockage passe en Error et l’enregistrement s’arrête (par défaut 2 GiB). Reprise auto si espace libre ≥ 2 × cette valeur.
Alarm Disk-Full Hysteresis, % — largeur de la bande d’hystérésis à la sortie de DiskFullDegraded (par défaut 2 %).
La plupart des valeurs par défaut conviennent aux installations courantes ; seul Max Usage et Dir Path demandent généralement un ajustement.
Un stockage par disque est recommandé. Plusieurs enregistrements sur le même disque avec des sous-répertoires différents se disputent l’espace libre — statvfs donne la vue globale, mais le nettoyage est par enregistrement.
Liaison d’un flux à un stockage¶
Dans les paramètres Stream / OTT apparaît une section DVR :
Storage — liste déroulante des stockages ; 0 signifie « archive désactivée pour ce flux ».
Storage Hours — profondeur d’archive du flux, en heures. Les chunks plus anciens sont supprimés à chaque tick. 0 désactive le Rolling cleanup (seul Size-based cleanup via Max Usage tourne).
Storage Min Hour — seuil de protection bas (heures). Le nettoyage ne supprime jamais de chunks plus récents, même sous pression Max Usage. Utile si la logique métier exige un enregistrement récent garanti, ex. « les 2 dernières heures toujours présentes ».
Modification de Storage à la volée :
mettre 0 — désactive l’archive ; les chunks sur disque sont conservés, plus rien n’est écrit. Les sessions VOD renvoient 404 ;
choix d’un autre stockage — le flux se détache de l’ancien et écrit dans le nouveau. Les fichiers de l’ancien disque ne sont pas migrés.
Les modifications de Storage Hours et Storage Min Hour s’appliquent aussitôt — au tick suivant, le nettoyage utilise la nouvelle valeur.
Après configuration, le flux écrit automatiquement l’archive dès qu’il passe en Running.
VOD : lecture de l’archive¶
L’archive est lue via les mêmes URLs que le live HLS / DASH (voir section OTT service) — seul le paramètre query change.
URLs et paramètres¶
URLs pour HLS et DASH :
Sans paramètre query — live ordinaire à fenêtre glissante. Avec le paramètre t — mode VOD.
Paramètre |
Objectif |
|---|---|
|
Heure de début VOD (Unix epoch, sec). t=0 — depuis le début de l’archive. La présence de t (même t=0) active le mode VOD. |
|
Durée de la fenêtre VOD, sec. d=0 ou paramètre absent — « jusqu’à maintenant ». N’a de sens qu’avec t. |
|
EPG-aligned VOD : le serveur localise l’événement EPG actif au moment indiqué et prend ses start et duration comme bornes. Incompatible avec t et d (remplacement côté serveur). Voir ci-dessous. |
|
Paramètres live standard (voir OTT service) ; |
Comportement selon t et d :
t |
d |
Fenêtre |
Condition 404 |
|---|---|---|---|
non |
— |
live (fenêtre glissante) |
— |
0 |
aucun / 0 |
[début archive, maintenant] |
DVR non lié |
0 |
> 0 |
[début archive, +d] |
DVR non lié |
> 0 |
aucun / 0 |
[t, maintenant] |
DVR non lié |
> 0 |
> 0 |
[t, t+d] |
DVR non lié |
Normalisation des bornes :
t avant le début de l’archive — start est automatiquement aligné sur le premier chunk disponible (le nettoyage a pu rogner). Ce n’est pas un 404 — on sert ce qui reste.
t dans le futur ou fenêtre entièrement avant l’archive — playlist vide mais valide (HLS : header seul +
EXT-X-ENDLIST; DASH :@type="static",mediaPresentationDuration="PT0S").Les chunks sont choisis strictement par startTime ∈ [t, t+d) — pas de segments partiels.
VOD sur un flux sans archive (ou dont le stockage est en Error) — 404 immédiat sur master playlist / MPD. Aucune session créée.
Textes d’erreur dans le corps 404 (visibles dans les logs et le corps HTTP) :
VOD: stream not running— le flux est dans la config mais pas en Running.VOD: no DVR archive— aucun stockage défini sur le flux, ou stockage en Error.VOD: DVR detached— le flux a été détaché du stockage entre les requêtes.VOD: EPG event not found— aucun événement trouvé pour?epg=.
Playlist HLS VOD — fermée (le lecteur voit la durée et peut chercher) :
#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
Ces marqueurs sont absents de la playlist live — c’est la seule différence.
MPD DASH VOD — statique : @type="static", mediaPresentationDuration fixe, <SegmentURL> explicites. Le DASH live reste @type="dynamic".
Si l’intervalle choisi a des trous dans l’archive (ex. redémarrage d’enregistrement ou nettoyage au milieu), le MPD DASH est scindé automatiquement en plusieurs <Period> — un par piste contiguë. Les lecteurs (VLC, dashjs, Shaka) franchissent les frontières de période sans configuration.
EPG-aligned VOD¶
Si le flux est lié à une source EPG (champs EPG Source et EPG Channel des paramètres du flux), le client peut demander l’archive par un instant compris dans un événement EPG :
http://host:port/hls/stream/login/password/index.m3u8?epg=1778500000
http://host:port/dash/stream/login/password/index.mpd?epg=1778500000
Le serveur localise l’événement EPG actif à l”epoch donné et utilise ses start et duration comme bornes de la fenêtre VOD. Utile pour les catalogues : l’UI connaît l’heure de l’événement mais n’a pas à calculer les bornes exactes.
Si le flux n’est pas lié à l’EPG ou qu’aucun événement n’est actif — 404 ``VOD: EPG event not found``. t et d sont ignorés en présence de epg.
Flux adaptatifs¶
Les groupes adaptatifs (voir HLS Adaptive Multistream) acceptent les mêmes paramètres VOD :
http://host:port/hls/adaptive/group/login/password/index.m3u8?t=0
http://host:port/dash/adaptive/group/login/password/index.mpd?t=0
Seules les variantes avec un stockage DVR configuré entrent dans la master playlist (HLS). Celles sans DVR sont ignorées (VOD: variant N has no DVR apparaît au log) ; l’assemblage continue avec les autres.
En variante DASH, chaque qualité devient un <Representation> distinct dans des <Period> communs ; le lecteur peut changer de qualité sans rouvrir le manifeste.
Comportement du lecteur¶
Le VOD HLS / DASH de l’archive est lu par les lecteurs standards : VLC, hls.js, dashjs, Shaka, ffmpeg. La recherche timeline marche.
Si le lecteur demande un segment déjà supprimé par le nettoyage, le serveur renvoie 404 pour ce segment (pas 500). VLC, hls.js, dashjs sautent ce segment et continuent au suivant.
Fonctionnalités complémentaires :
Protection des sessions actives : tant qu’une session VOD est ouverte, le nettoyage ne supprime pas les chunks dans sa fenêtre (voir ci-dessous).
Live-edge bridge : si un client en session VOD demande un segment au-delà de vodEnd — ex. avance dans la timeline en atteignant la fin d’archive — le serveur sert le segment depuis la mémoire live. Aucune redirection ni ré-auth.
Cache playlist : sur des requêtes répétées du même VOD
index.m3u8/index.mpd, le serveur renvoie une réponse identique octet pour octet — sans reconstruction. Adapté à un CDN devant PSS.
Sous-titres dans l’archive¶
Si le flux porte des sous-titres (DVB Subtitling, Teletext ou WebVTT) et que l’option OTT WebVTT est active, les sous-titres sont archivés en parallèle des chunks TS — en fichiers .vtt à côté des .ts.
En live, la master playlist contient EXT-X-MEDIA:TYPE=SUBTITLES ; en VOD, le serveur renvoie une playlist VOD de sous-titres (avec ENDLIST) et des segments .vtt aux mêmes URLs.
Particularités :
HLS : l’en-tête
X-TIMESTAMP-MAPest conservé au début de chaque.vtt(requis par la spec HLS).DASH : l’en-tête
X-TIMESTAMP-MAPest retiré à la volée (lié au PCR absolu, en conflit avec l’ancre DASH ; sinon VLC affiche des sous-titres vides).En groupe adaptatif : si le sub-stream actif n’écrit pas de sous-titres, les segments VTT renvoient 404. Sur la variante suivante, le lecteur peut en recevoir à nouveau.
Les sous-titres se désactivent via l’option OTT WebVTT du flux, ou en n’activant pas HLS en mode OTT.
Nettoyage et rétention¶
PSS utilise deux stratégies de nettoyage, exécutées à chaque tick (par défaut toutes les 10 sec) :
Rolling cleanup (par flux) : pour chaque flux, les chunks plus vieux que Storage Hours sont supprimés. Tourne toujours, même disque à moitié vide.
Size-based cleanup (par stockage) : quand Used % dépasse en continu Max Usage pendant Disk Pressure Grace sec, les chunks les plus anciens sont coupés au prorata sur tous les flux liés au stockage. Par tick : Disk Pressure Cut sec vidéo par flux. Jamais de chunks plus jeunes que Storage Min Hour.
Emergency disk-full cut : si l’espace libre tombe sous Disk Emergency Bytes, le nettoyage devient agressif et peut supprimer même des chunks protégés. L’enregistrement s’arrête jusqu’à reprise de l’espace libre avec hystérésis × 2.
Orphan scan (horaire) : des fichiers non répertoriés dans l’index peuvent subsister sur disque (après arrêt brutal de PSS). Une fois par heure, le scanner parcourt les sous-répertoires des flux et supprime ces fichiers « oubliés ». Anti-race avec le writer — les fichiers de moins de 60 sec sont sautés.
Note. Les tâches de nettoyage tournent en arrière-plan ; l’utilisateur n’a normalement rien à faire. Si l’archive croît plus vite qu’elle n’est rognée, baisser Storage Hours sur les flux ou augmenter Disk Pressure Cut.
Protection des sessions VOD actives¶
À l’ouverture d’une session VOD, un « créneau de protection » avec l’heure de début de fenêtre est posé sur chaque stockage impliqué. Les nettoyages Rolling et size-based ne touchent pas les chunks dans la fenêtre de la session ouverte. Le créneau est libéré automatiquement à la fermeture (FIN, timeout).
Cela signifie :
Si un client garde une session VOD longtemps, il peut chercher tout instant dans sa fenêtre — les chunks ne « disparaissent pas sous lui ».
Le nettoyage Max Usage peut temporairement ne pas ramener Used % au seuil tant qu’une session est active ; dès le départ du client, le nettoyage rattrape.
Emergency disk-full cut et Storage Min Hour contournent la protection : si le disque est presque vide, les chunks sont supprimés et le client reçoit 404 sur les segments touchés (le lecteur les saute).
Après redémarrage de PSS, les créneaux de protection disparaissent — le nettoyage reprend aussitôt.
Plusieurs stockages¶
On peut créer un nombre quelconque d’enregistrements DVR Storage — un par répertoire / disque. Les flux sont liés indépendamment à différents stockages. Nettoyage et seuils (Max Usage, Disk Pressure) fonctionnent par stockage.
Cas d’usage :
Tiering par valeur : stockage SSD rapide pour chaînes premium avec grande profondeur, stockage HDD capacitif pour les autres.
Disque dédié à l’archive : pour que l’enregistrement DVR ne concurrence pas le disque système ou les fichiers temporaires.
Séparation par projet : un disque pour le lot de chaînes nº 1, un autre pour le nº 2 — simplifie migration et audit.
Changer la liaison du flux (champ Storage dans Stream / OTT) bascule l’enregistrement à la volée. Les anciens fichiers restent intacts sur le disque précédent — à supprimer à la main ou à réattacher en remettant le flux.
État du stockage et monitoring¶
La section Data / DVR Storage List (et l’API GET /data/dvr-storage-list) affiche par stockage :
State — Ready / DiskFullDegraded / Error.
Total / Free / Used Bytes — statistiques disque (statvfs).
Used % — pourcentage actuel d’utilisation.
Archived Bytes — taille totale des chunks indexés sur tous les flux liés (hors fichiers orphelins).
Attached Streams — nombre de flux liés à ce stockage.
Pressure Since Sec — moment (epoch) où Used % a d’abord dépassé Max Usage dans l’épisode courant ; 0 signifie « pas de pression ».
États :
Ready — fonctionnement normal.
DiskFullDegraded — espace libre < (Disk Emergency Bytes × 2) ; l’enregistrement continue mais peut basculer en Error à tout moment.
Error — espace libre < Disk Emergency Bytes ; enregistrement arrêté ; reprise par hystérésis.
Si le stockage est en Error, vérifier l’espace libre sur le disque ; PSS ne sort pas seul de cet état tant qu’il n’y a pas plus de place physiquement.
Protection contre la perte accidentelle¶
Plusieurs opérations admin entraînent une perte d’archive ou un arrêt de la diffusion VOD. Avant exécution, l’UI affiche une confirmation modale :
Suppression d’un DVR Storage — tous les flux liés perdent l’accès VOD ; les fichiers restent sur disque mais sont inaccessibles via PSS sans l’enregistrement.
Bascule du flux vers un autre stockage — le VOD sur l’ancienne archive cesse.
Détachement du flux du stockage (Storage = 0) — même effet.
Baisse de Max Usage — peut déclencher le nettoyage size-based et supprimer d’anciens chunks.
Baisse de Storage Hours / Storage Min Hour — peut sortir une partie de l’archive du rolling.
Décision produit assumée : opération autorisée mais avec confirmation, et les fichiers supprimés restent sur disque (restaurables depuis un backup). Placer l’archive sur un serveur de fichiers / RAID séparé réduit fortement le risque de perte irréversible.
Limites de la version actuelle¶
Une session VOD ouverte par un client ne suit pas le live edge — si de nouveaux chunks ont été ajoutés pendant la session, le client doit redemander la playlist (comportement standard HLS / DASH).
Un stockage par disque est recommandé — plusieurs enregistrements avec sous-répertoires différents se disputent l’espace libre.
Les segments sont adressés par hash (HLS) ou template
$Number$.ts(live DASH) /<SegmentURL>explicites (VOD DASH). Changer la taille de chunk entre live et VOD ne demande pas de rouvrir l’URL.Le scanner orphelin tourne chaque heure ; pour accélérer, redémarrer PSS.
Opérations sur les flux¶
Suppression. Pour supprimer un flux, ouvrez ses paramètres et cliquez sur Delete stream.
Clonage. Pour cloner un flux, ouvrez ses paramètres et cliquez sur Clone stream.
Tri. Pour configurer le tri des streams, cliquez sur le bouton Sort dans la fenêtre de la liste des streams. Indiquez ensuite l’ordre souhaité en faisant glisser les streams vers le haut ou le bas. Pour enregistrer l’ordre défini, cliquez sur Save order, ou sur Cancel pour annuler les modifications.
Filtrage de la liste. Pour filtrer la liste des flux, cliquez sur l’icône de recherche et saisissez la chaîne de filtre. Pour annuler, cliquez sur la flèche retour.
Opérations groupées. En mode de filtrage de la liste des streams, il est possible de sélectionner plusieurs streams en cochant les cases dans la colonne de gauche. Si des streams sont sélectionnés, les boutons Supprimer et Cloner deviennent disponibles pour les streams sélectionnés.
Export et import de flux via un script Python¶
L’export et l’import de configuration passent par une playlist .m3u via un script Python.
Python 3 doit être disponible à /usr/bin/python3.
Export et import de flux via l’interface web¶
Dans la liste des streams, en cliquant sur le bouton Playlist, la boîte de dialogue d’export des streams vers une playlist au format m3u8 s’ouvre. Seuls les streams actuellement affichés selon les filtres appliqués sont exportés.
Paramètres :
Host / IP — nom ou adresse du serveur utilisé pour construire les URL des flux.
Protocols — types de protocoles à exporter.
Login — sélection du compte utilisé pour construire les URL des flux.
Use Display Names — utiliser le Display name du flux à la place de Stream name dans le fichier m3u8.
La playlist est téléchargée sous forme de fichier m3u8 en cliquant sur le bouton Download.
En cliquant sur le bouton Import Playlist, la boîte de dialogue passe en mode d’importation des flux depuis une playlist au format m3u8. Lors de l’importation, les flux existants ne sont pas supprimés. Pour tous les flux importés, l’heure d’importation est inscrite dans le champ Note.
Paramètres :
Playlist — sélection du fichier de playlist à importer.
Create Outputs — choix du protocole pour générer automatiquement les sorties des flux importés.
Output Ports From — numéro de port de départ pour générer les sorties.
Output IP — sélection de l’interface à laquelle les flux de sortie sont liés.
Tags — étiquettes appliquées aux flux importés. Utiles pour les opérations groupées, par exemple supprimer tous les flux importés.
Si un fichier à importer est indiqué dans le champ Playlist, le bouton Load Playlist devient actif. En cliquant sur Load Playlist, la playlist est préchargée et le résultat de son parsing est affiché dans la table. Après le parsing, le bouton Import Streams devient actif — en cliquant dessus, les streams sont importés et des outputs sont générés pour eux.
Rapports et diagnostic¶
La section Streams affiche les données de tous les stream sous forme de tableau. Pause est accessible aux rôles admin et restricted admin.
Pour chaque stream, des statistiques et rapports détaillés sont disponibles.
Peers — liste des récepteurs actifs (clients). Chacun dispose de statistiques propres.
Analyse des flux¶
L’analyseur de flux du streamer mesure et analyse divers paramètres du flux MPEG-TS, ce qui permet d’en évaluer la qualité.
Input speed — débit (bitrate) du flux en kbps. Change après le filtrage par marques PCR. Affiché sous forme de graphique qui montre aussi le bitrate de sortie après le synchroniseur.
Raw data speed — débit de réception des données pour le protocole choisi. Overhead — supplément en % pour les frais du protocole.
CC errors — pertes de paquets (CC, discontinuity). On voit les compteurs par période et un compteur cumulé sur la durée de fonctionnement du flux ; un graphique d’historique est également affiché.
Scrambled — compteurs des paquets MPEG-TS ES chiffrés. Une valeur ≠ 0 indique des défaillances de décryptage des chaînes cryptées.
Sync by — source de synchronisation, par défaut PCR. En cas de PCR incorrect, on peut utiliser le PTS/DTS vidéo (voir le paramètre Force Sync by PTS de l’input).
PCR interval — intervalle entre les marques PCR. Recommandé : pas plus de 50 ms.
PCR jitter — caractérise la précision de synchronisation du flux de sortie ; mesuré comme l’écart entre le PCR et le temps réel.
Analyze PCR PMT Gap — activé par un paramètre séparé. La dispersion entre PCR et PTS/DTS est analysée pour chaque ES. L’historique est affiché sous forme de graphique. Une dispersion trop importante peut poser problème aux lecteurs avec un buffer de synchronisation réduit. L’analyse est activée par le paramètre Analyze PAT/PMT/KF.
PAT interval et PMT interval — modifient l’intervalle entre les tables PAT (PMT). Recommandé : pas plus de 500 ms. L’analyse s’active via Analyze PAT/PMT/KF.
Key Frame interval — mesure l’intervalle entre images-clés (KF). Pour les lecteurs qui se connectent au flux à un point arbitraire, on recommande au maximum 1 s. L’analyse est activée par le paramètre Analyze PAT/PMT/KF.
PAT/KF interval — mesure l’intervalle moyen entre le début et la fin de la séquence PAT/PMT/SPS/PPS/KF. Cela conditionne la vitesse de démarrage de la lecture pour les lecteurs qui se connectent au flux à un point arbitraire. La mesure est faite à partir du début du KF dans le flux ; le temps de démarrage réel du lecteur sera donc plus long. L’analyse est activée par le paramètre Analyze PAT/PMT/KF.
Activer Analyze PAT/PMT/KF lance l’analyseur de flux en continu, ce qui augmente la charge CPU.
Gestion du jitter¶
Plusieurs paramètres du flux permettent de gérer le jitter :
Jitter Compensation Delay (ms) — fonction de compensation du jitter réseau ; définit la taille du buffer. Description détaillée : https://forum.pstreamer.tv/viewtopic.php?t=25
Jitter Auto sync — applique 2000 ms pour les protocoles TCP (HTTP, HLS) ; pour les protocoles UDP, la valeur reste à 500 ms.
Limit PCR gap (ms) — vérifie le saut maximal du PCR ; au-delà, une resynchronisation est effectuée.
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¶
Surveillance des principaux paramètres du système d’exploitation.
Mosaic¶
Fonction de capture d’écran du flux d’entrée. Activée individuellement pour chaque stream.
Si non nécessaire, elle peut être totalement désactivée dans Settings/Server Settings pour économiser les ressources.
Administration¶
Dans Configuration/Administration/Administrators List, on ajoute les utilisateurs pour l’accès à l’interface web — serveur HTTP intégré.
Des rôles sont attribués aux utilisateurs :
admin — accès complet.
restricted admin — paramètres inaccessibles ; seule la valeur pause peut être modifiée.
viewer — accès en lecture seule.
Sauvegarde des paramètres¶
Pour sauvegarder la configuration, archiver le contenu du dossier /opt/pss/config.
Pour restaurer la configuration, arrêter le service et remplacer le contenu du dossier /opt/pss/config.
Intégration de systèmes de surveillance externes¶
pss-metrics — exportateur universel de métriques pour Perfect Streamer
Un unique script CLI en Python 3 qui récupère les statistiques depuis l’API HTTP du serveur web PSS et produit la sortie pour les systèmes de supervision les plus répandus :
Zabbix (UserParameter, Low-Level Discovery, zabbix_sender trapper)
Prometheus (format d’exposition texte pour le textfile collector)
InfluxDB / Telegraf (line protocol ou JSON pour l’input exec)
JSON universel pour des scripts arbitraires et les vérifications d’état façon Nagios
L’exportateur est un fichier unique et autonome, sans dépendance tierce, qui n’utilise que la bibliothèque standard de Python 3.6+ (urllib, xml.etree, json, argparse).
Fichiers¶
pss-metrics.py основной CLI (исполняемый)
userparameter_pss.conf.example шаблон UserParameter для Zabbix
Installation¶
L’exportateur est livré dans /opt/pss/monitoring/pss-metrics.py. Vérifiez que Python 3.6 ou ultérieur est installé
# RHEL / Rocky / AlmaLinux
yum install -y python3
# Debian / Ubuntu
apt-get install -y python3
Aucun paquet supplémentaire n’est requis.
Configuration¶
Par défaut, pss-metrics se connecte à http://127.0.0.1:43971 et détecte automatiquement le port depuis /opt/pss/config/pss.json (ou /opt/pss/config/pss_default.json). Les paramètres peuvent être remplacés via des variables d’environnement, le fichier /etc/pss-metrics.conf (format clé=valeur) ou des options de ligne de commande. Priorité : CLI > env > fichier > valeurs par défaut.
Variables prises en charge
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
Cache : chaque exécution effectue au plus un HTTP GET par endpoint dans la fenêtre TTL. Avec TTL=10 s, même des centaines de vérifications UserParameter par minute ne génèrent que ~6 requêtes HTTP par minute vers PSS.
Démarrage rapide¶
Vérification d’état (codes de sortie style Nagios)
pss-metrics.py health
# OK: total=42 running=15 stopped=27 unhealthy=0 version=1.12.2.430d
Découverte LLD Zabbix
pss-metrics.py discover streams
pss-metrics.py discover inputs --running-only
pss-metrics.py discover outputs
Récupération d’une métrique unique (à utiliser dans un UserParameter 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
Export complet
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
Chemins de métriques¶
pss-metrics get accepte un chemin séparé par des points. Une sortie vide signifie « valeur absente » (par exemple, la métrique n’existe que pour les flux en cours d’exécution).
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>
Attributs utiles par flux (depuis /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
Intégration avec Zabbix¶
Deux scénarios sont pris en charge ; choisissez celui qui correspond à votre environnement.
UserParameter statique + LLD (agent Zabbix v1 / v2)
Copiez userparameter_pss.conf.example dans /etc/zabbix/zabbix_agentd.d/pss.conf, redémarrez zabbix-agent, puis importez sur le serveur un modèle avec des prototypes LLD utilisant les clés pss.discover. Exemples de liaisons
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
Sur le serveur Zabbix :
Ключ правила обнаружения: pss.discover[streams] Ключи прототипов элементов: pss.get[input.{#STREAM_ID}.1.speed1] pss.get[stream.{#STREAM_ID}.bitrate] pss.get[summary.unhealthy]Trapper (push) avec zabbix_sender
Lancez via un timer (cron / systemd) et redirigez la sortie dans un pipe
/opt/pss/monitoring/pss-metrics.py dump --format=zabbix-trapper \ --zabbix-host="$(hostname)" \ | zabbix_sender -z zabbix.example.com -i -
Intégration avec Prometheus¶
Deux options.
Textfile collector (recommandé pour des environnements one-shot).
Exécutez un export périodique via systemd-timer ou 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.promnode_exporter exposera le fichier via –collector.textfile.directory.
Scrape direct via un petit wrapper (par exemple socat + pss-metrics dump) ou tout proxy HTTP tiers de votre choix.
Intégration avec Telegraf / InfluxDB¶
Telegraf inputs.exec:
[[inputs.exec]]
commands = ["/opt/pss/monitoring/pss-metrics.py dump --format=influx"]
interval = "10s"
timeout = "5s"
data_format = "influx"
Pour le parseur JSON, utilisez –format=json et configurez data_format = « json » avec les chemins des champs.
HTTPS et authentification¶
Si le serveur web PSS fonctionne derrière HTTPS ou est protégé par mot de passe
PSS_URL=https://streamer.example.com:8443 \
PSS_USER=monitor PSS_PASS=secret \
pss-metrics.py health
Certificats auto-signés : définissez PSS_INSECURE=1 (non recommandé) ou indiquez PSS_CA_BUNDLE=/path/to/ca.pem.
Codes de retour¶
pss-metrics suit la convention Nagios
0 OK
1 WARNING (например, у запущенных потоков unhealthy)
2 CRITICAL (PSS недоступен)
3 UNKNOWN (неверные аргументы / внутренняя ошибка)
get et dump produisent une ligne vide et se terminent avec le code 0 lorsque l’entité demandée est absente — ce comportement correspond à l’attente de Zabbix selon laquelle une valeur vide est interprétée comme « NOT_SUPPORTED » plutôt que comme une défaillance de l’agent.
Diagnostic¶
pss-metrics.py -v health # логировать каждый HTTP-запрос в stderr
pss-metrics.py --cache-ttl=0 … # обойти кеш при отладке
rm -rf /run/pss-metrics # очистить кеш
Let’s Encrypt et certbot pour HTTPS¶
Depuis la version 1.9.2.340, Perfect Streamer prend en charge le renouvellement automatique des certificats Let’s Encrypt pour HTTPS dans Web Server, HTTP Server et EPG Server.
Configuration de certbot pour RHEL.¶
Limitation :
Le port TCP/80 doit être libre et une IP publique avec un nom de domaine public doit être assignée.
Tous les serveurs HTTPS utilisent le même nom d’hôte (web server, http server, epg server).
Installation 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
Configuration de certbot :
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot certonly --standalone
Vérification de certbot :
sudo certbot renew --dry-run
Vérification du minuteur certbot :
systemctl list-timers | grep certbot
Dans l’admin de Perfect Streamer, activer HTTPS sur les serveurs (Web Server, HTTP Server, EPG Server).
Créer un script hook (https://pstreamer.tv/distrib/scripts/cert_update.zip) et le placer au chemin :
/opt/pss/scripts/cert_update.sh
Y indiquer si besoin le nom de domaine de l’hôte ; par défaut, il est lu depuis /etc/hostname.
Rendre le fichier exécutable.
chmod +x /opt/pss/scripts/cert_update.sh
Vérifier l’exécution du script, il ne doit pas y avoir d’erreurs :
/opt/conf/scripts/cert_update.sh
Les paramètres HTTPS doivent s’appliquer ; le changement de statut apparaît dans les logs.
Ajouter un fichier hook à certbot :
certbot renew --deploy-hook "/opt/conf/scripts/cert_update.sh"
Revérifier certbot :
sudo certbot renew --dry-run
Configuration de certbot pour Debian/Ubuntu.¶
La configuration pour Debian est analogue à celle pour RHEL ; description courte à l’exemple d’Ubuntu 24.04.2 LTS.
Installation de certbot :
apt install certbot
certbot certonly
Rendre le script exécutable :
chmod +x /opt/pss/scripts/cert_update.sh
Exécution du script :
/opt/pss/scripts/cert_update.sh
Émet :
Select domain name (your domain name)
Vérifier si les certificats ont été renouvelés :
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 date doit être à jour.
Adaptateurs DVB¶
Perfect Streamer prend en charge tout adaptateur DVB installé dans le système. Standards pris en charge : DVB-S, DVB-S2, DVB-T, DVB-T2, DVB-C, ATSC. Implémentés en outre : la décapsulation T2-MI (ETSI TS 102 773) et le désembrouillage BISS-1 / BISS-E.
La condition principale est un pilote d’adaptateur correctement installé et fonctionnel dans le système.
La section DVB n’apparaît que si le système comporte des adaptateurs DVB valides. La reconfiguration à la volée n’est pas prise en charge ; un redémarrage du streamer est nécessaire.
Connexion de l’adaptateur¶
Pour ajouter un nouvel adaptateur DVB, accédez à la section correspondante et ajoutez l’adaptateur :
Définir le nom de l’adaptateur.
Sélectionner un adaptateur dans la liste de ceux disponibles dans le système.
Sélectionner le mode Stream.
Spécifier le type de système de transmission : DVB-S, DVB-S2, DVB-T, DVB-T2, DVB-C.
Spécifier les paramètres de réception : Fréquence porteuse, Polarisation, Débit symbole, FEC, Modulation, ID du flux DVB, Fréquence de l’oscillateur, Oscillateur bande haute, Limite bande haute, Mode DiSEqC 1.0 et d’autres paramètres selon le type.
L’enregistrement EIT dans la base EPG peut être activé en option (Enregistrer EIT dans la base EPG).
Répéter l’ajout pour chaque adaptateur présent dans le système.
Balayage DVB¶
Pour éviter de saisir manuellement les paramètres de réception (fréquence, polarisation, débit symbole, FEC, modulation), Perfect Streamer intègre un scanner de transpondeurs. Le scanner parcourt les transpondeurs du satellite sélectionné (DVB-S/S2) ou de la bande régionale (DVB-C, DVB-T/T2), effectue l’accord et la capture de chacun, collecte les tables PSI/SI (PAT, PMT, SDT) et constitue la liste finale des multiplex avec leurs programmes. Tout multiplex trouvé peut être ajouté à la liste des adaptateurs DVB d’un seul clic.
Le scanner mobilise l’adaptateur physique en totalité ; pour le démarrer, il faut un adaptateur qui n’est utilisé ni par le noyau du système d’exploitation ni par une entrée d’adaptateur DVB active dans Perfect Streamer.
Свободные адаптеры¶
À l’ouverture de l’écran de balayage dans l’interface d’administration, une liste des adaptateurs DVB physiques du système est affichée avec leur état d’occupation :
free — l’adaptateur est disponible pour le balayage.
kernel — le périphérique est détenu par un autre processus du système d’exploitation.
pss-id-N — l’adaptateur est déjà utilisé par une entrée d’adaptateur DVB dans Perfect Streamer portant l’identifiant indiqué. Le scanner ne peut pas y être lancé tant que cette entrée est active. Pour libérer temporairement l’adaptateur, l’entrée d’adaptateur DVB existante doit être suspendue (l’indicateur Pause dans ses paramètres).
Listes de transpondeurs¶
Le scanner s’appuie sur des listes de référence au format Enigma2 : la liste des satellites satellites.xml et les listes régionales cables.xml / terrestrial.xml. Chaque fichier contient un ensemble de transpondeurs pour une position orbitale connue ou pour une bande régionale DVB-T/C (pour plus de détails, voir le site du projet oe-alliance-tuxbox-common).
Les fichiers se trouvent dans le répertoire sat/ relatif à pss.json (par défaut /etc/pss/sat/). Ils sont fournis avec la distribution Perfect Streamer et sont chargés à l’ouverture de l’écran de balayage. Ils peuvent être mis à jour en cas de besoin en remplaçant le fichier XML correspondant.
Dans l’interface d’administration, les listes de référence sont présentées sous la forme de trois listes :
Satellite — positions orbitales (par exemple Hot Bird 13.0°E, Astra 19.2°E).
Région câble — pays ou fournisseur DVB-C.
Région terrestre — région DVB-T/T2.
Si le satellite ou la région requis n’est pas présent dans les listes de référence, le fichier XML peut être mis à jour ou le balayage aveugle peut être utilisé à la place (voir ci-dessous).
Démarrage¶
Dans la boîte de dialogue de balayage, les éléments suivants sont définis dans l’ordre :
Un adaptateur physique libre.
Тип delivery system: DVB-S, DVB-S2, DVB-T, DVB-T2 или DVB-C.
Source :
pour DVB-S/S2 — une position orbitale dans la liste des satellites et les paramètres LNB (fréquences d’oscillateur local LO1 et LO2, limite de la bande supérieure, port DiSEqC) ;
pour DVB-C — une région câble ;
pour DVB-T/T2 — une région terrestre.
Après avoir appuyé sur Démarrer, le balayage s’exécute en arrière-plan. La progression est affichée dans l’interface d’administration :
le pourcentage d’avancement basé sur le nombre de transpondeurs traités ;
la fréquence et la polarisation actuelles ;
les compteurs Multiplex trouvés et Programmes trouvés ;
un arbre des multiplex déjà trouvés, déployable jusqu’aux programmes.
Le scanner est une ressource partagée au niveau du streamer : au plus un balayage s’exécute à la fois. Si un nouveau balayage est lancé alors qu’un autre est déjà en cours, le précédent est automatiquement annulé. Le bouton Annuler interrompt le balayage et vide la liste accumulée.
La durée du balayage dépend du nombre de transpondeurs dans la liste de référence sélectionnée (typiquement jusqu’à 5 secondes par transpondeur : jusqu’à 2 secondes pour le verrouillage du signal et jusqu’à 5 secondes pour la collecte des PSI). Valeurs typiques :
DVB-S Hot Bird 13.0°E — environ 2 minutes (44 transpondeurs).
DVB-S Astra 19.2°E — environ 1,5 minute.
DVB-T région européenne — moins d’une minute.
Résultat¶
Le résultat du balayage est affiché sous la forme d’un arbre multiplex → programmes.
Paramètres du multiplex :
fréquence, polarisation, débit symbole ;
FEC, modulation, delivery system ;
identifiant du flux de transport (TSID) ;
les relevés du frontend au moment de la fin de la collecte des PSI — SNR, Signal, BER ;
les compteurs pmt-total / pmt-recv — le nombre de tables PMT annoncées par la PAT et le nombre de tables effectivement collectées dans le délai imparti.
Параметры программы:
PNR (program_number) — l’identifiant du service au sein du multiplex ;
Nom et Fournisseur — issus de la table SDT, en UTF-8 ;
scrambled — l’indicateur d’embrouillage. Sa source est déterminée dans l’ordre suivant : le bit
free_CA_modeissu de la SDT (déclaration du broadcaster) → les drapeaux d’embrouillage de transport issus de la PMT. Si ni la SDT ni la PMT ne sont reçues dans le délai imparti, la valeur par défaut est 0 (« non embrouillé ») ; l’état réel est déterminé lors de la tentative de réception ;video-pid, audio-pid, pcr-pid — les principaux flux élémentaires du service.
Application du résultat¶
Le multiplex sélectionné dans l’arbre est ajouté à la liste des adaptateurs DVB par un seul bouton. Une nouvelle entrée est créée avec les paramètres issus du résultat du balayage (fréquence, polarisation, débit symbole, FEC, modulation, delivery system) ainsi que les paramètres LNB et le couple adapter/device spécifiés au démarrage du balayage. Le nom de l’adaptateur est défini par l’utilisateur ; les paramètres complémentaires (clés BISS pour les chaînes embrouillées, T2-MI, LNB partagé, etc.) sont renseignés une fois l’entrée créée, via ses paramètres.
Les programmes issus des multiplex trouvés sont appliqués séparément — en créant un flux (Stream) avec une source d’entrée demuxer désignée par la PNR (voir la section Connexion d’un flux SPTS à un service de multiplex DVB).
Balayage aveugle¶
Le mode aveugle est utilisé lorsque :
le satellite requis ne figure pas dans les listes de référence (position orbitale non standard, liaison montante locale) ;
les listes de référence régionales DVB-T/C sont insuffisantes ou obsolètes pour un site donné ;
un segment de la bande doit être revérifié indépendamment de la liste des transpondeurs connus.
Dans ce mode, le scanner ne consulte pas les listes de référence ; il synthétise une liste de transpondeurs à partir d’une grille de fréquences. Par défaut, les plages typiques suivantes sont utilisées :
DVB-S/S2 Ku — 10700..12750 MHz, pas de 4 MHz, les deux polarisations (H et V), débits symbole typiques 22000 / 27500 / 30000 ksym/s.
DVB-C — 47000..862000 kHz, pas de 8000 kHz, QAM-64 et QAM-256, débits symbole typiques 6875 / 6900 / 6952 ksym/s.
DVB-T/T2 — 174000..862000 kHz, pas de 8000 kHz.
Un balayage aveugle complet de la bande Ku prend de l’ordre de 100 minutes (plusieurs milliers de points d’accord). En pratique, la plage est restreinte manuellement dans l’interface d’administration — fréquence minimale/maximale et pas de la grille. Par exemple, un balayage de 11700..11800 MHz au pas de 4 MHz pour une seule bande LNB dure environ 5 minutes.
Le format du résultat d’un balayage aveugle est identique à celui d’un balayage normal. Particularités :
les champs FEC et Modulation des multiplex trouvés sont fixés à la valeur AUTO — le scanner ne détermine pas leurs valeurs exactes ;
le delivery system est égal à celui demandé (DVB-S, DVB-S2, …). Pour les réseaux mixtes, il est recommandé d’effectuer deux passages — DVB-S et DVB-S2 séparément.
L’application d’un multiplex issu d’un balayage aveugle s’effectue de la même manière que pour un balayage normal — via le bouton qui l’ajoute à la liste des adaptateurs DVB. Les champs FEC et Modulation sont généralement laissés à AUTO et, si nécessaire, affinés après un verrouillage stable du signal sur le transpondeur concerné.
Taille du tampon de réception kernel¶
Le paramètre buffer-size (entier, valeur par défaut 512) définit la taille du tampon circulaire DVB demux du kernel en blocs de 65536 octets.
512(32 Mo) — valeur par défaut recommandée. Couvre les scénarios DVB-S/S2 sur transpondeur entier (>= 33 Mbit/s) avec un ou plusieurs consommateurs MPTS. Choisi sur la base des tests sur banc avec un adaptateur TBS à pleine charge du transpondeur.8...64(512 Ko … 4 Mo) — acceptable pour les systèmes embarqués à RAM limitée ou pour les adaptateurs en modes Scanner / Femon avec un trafic faible.0— conserver la valeur par défaut du pilote (en général 8…32 Ko). Convient uniquement aux scénarios très peu chargés. Au-delà de 10 Mbit/s des pertes apparaîtront.
Lorsqu’un message du type suivant apparaît dans le journal :
DVB adapter X/Y dvr buffer overflow (NN so far, KK pids);
raise 'buffer-size' or reduce pid filter
augmenter buffer-size ou réduire le nombre de PIDs traversant le filtre (par exemple, abandonner la sortie MPTS si elle n’est pas nécessaire).
Coût mémoire : la valeur N consomme N × 64 Ko de mémoire kernel par adaptateur. Avec beaucoup d’adaptateurs (8 et plus) il convient d’en tenir compte (8 × 32 Mo = 256 Mo).
Connexion d’un flux SPTS à un service de multiplex DVB¶
Lors de l’ajout d’un nouveau canal SPTS à l”input du flux, sélectionner :
Type : demuxer.
Source : adaptateur DVB.
Multiplex créé sur l’adaptateur DVB, par nom d’adaptateur.
PNR — sélectionné dans la liste contextuelle des services détectés dans le multiplex ou saisi manuellement.
Droits d’accès aux périphériques DVB¶
Si les adaptateurs DVB ne sont pas affichés dans Perfect Streamer, effectuer les actions suivantes :
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
Décapsulation T2-MI¶
T2-MI (T2-Modulator Interface, ETSI TS 102 773) est un format de transport des flux DVB-T2 sur DVB-S2 multistream. Le transpondeur externe DVB-S/S2 porte un ou plusieurs T2-MI carrier-PIDs, chacun encapsulant des BBFRAMEs avec un ou plusieurs PLPs (Physical Layer Pipe). Après décapsulation, le MPEG-TS interne contenant les programmes et les tables PSI/SI est extrait du BBFRAME.
L’implémentation Perfect Streamer fonctionne en mode multi-carrier : un seul adaptateur physique fournit simultanément le multiplex DVB-S/S2 externe et tous les carriers T2-MI décapsulés (un par carrier-PID trouvé dans le PMT du flux externe).
Paramètres de configuration¶
t2mi-mode (Int, 0..2, valeur par défaut 0) — mode de décapsulation :
0— Désactivé. Le MPEG-TS externe est transmis sans traitement. Si un descripteur T2-MI (tag 0x51) est détecté dans le PMT, un indice unique est journalisé.1— Manuel. La décapsulation est toujours active. Sit2mi-pidest non nul, un carrier est pré-créé sur ce PID au démarrage. Les carriers supplémentaires continuent d’être détectés automatiquement à partir du PMT.2— Auto. Les carriers sont détectés automatiquement à partir du PMT du multiplex externe pour tous les ES qui ressemblent à du T2-MI (descripteur 0x51 ou unique ES avec stream_type=0x06 sur un service sans autres ES A/V). Si aucun carrier n’est trouvé, l’adaptateur fonctionne comme un multiplex DVB ordinaire.
t2mi-pid (Int, 0..8191, valeur par défaut 0) — PID pour la pré-création d’un carrier au démarrage, avant l’arrivée du PMT :
0— pas de pré-création. Les carriers sont détectés à partir du PMT (recommandé pour le mode auto2).1..8191— pré-créer un carrier sur ce PID. Les T2-MI ES supplémentaires trouvés dans le PMT obtiennent quand même leurs propres carriers.
En mode multi-carrier, le paramètre t2mi-pid n’est pas un sélecteur de carrier unique — chaque ES T2-MI détecté obtient son propre carrier avec son propre décapsulateur. Le paramètre fournit une initialisation précoce pour un PID connu.
t2mi-plp (Int, 0..255, valeur par défaut 0) — identifiant du PLP extrait de chaque carrier T2-MI sur l’adaptateur. Appliqué à tous les carriers — la surcharge par carrier n’est pas prise en charge dans la version actuelle. Si en production différents carriers portent des PLPs différents, il faut :
spécifier un PLP commun à tous les carriers, ou
configurer des adaptateurs séparés pour différents PLPs à l’aide de
lnb-sharing.
Il s’agit de l’identifiant du champ plp_id du BBFRAME, non du ISI multistream DVB-S2 (défini par le paramètre dvb-stream-id). Ce sont des identifiants différents à des couches différentes.
Diagnostic de sélection PLP :
Cinq secondes après le démarrage d’un carrier, si aucun BBFrame n’a été reçu pour le PLP configuré mais que d’autres PLPs sont visibles, un avertissement est journalisé avec la liste des
plp_idobservés.
t2mi-tsid (Int, -1..255, valeur par défaut -1) — réservé pour un usage futur. Sélecteur de l’identifiant de flux T2-MI lorsque plusieurs flux T2-MI partagent un même carrier-PID. Ignoré dans la version actuelle.
PNR composite — connexion SPTS depuis T2-MI¶
Un adaptateur peut exposer plusieurs multiplex logiques :
carrier-id = 0— multiplex DVB-S/S2 externe (services A/V ordinaires).carrier-id = 1..N— carriers T2-MI décapsulés (un par ES T2-MI externe).
Désembrouillage BISS¶
Le désembrouillage des flux DVB chiffrés selon BISS-1 (mode E1) et BISS-E (mode E2) est pris en charge. Applicable aux systèmes de transmission DVB-S, DVB-S2, DVB-T, DVB-T2.
L’implémentation permet de garder plusieurs désembrouilleurs actifs simultanément sur un même adaptateur :
Par PNR dans le multiplex externe (service ordinaire).
Par
plp_idpour décrypter le carrier-PID T2-MI avant décapsulation (requis pour les fluxmultistreamchiffrés — sinon le décapsulateur rejette chaque paquet chiffré, voir le compteur<t2mi scrambledDropped>).
EPG¶
Import EPG/XMLTV¶
Les données EPG sont collectées dans la EPG Database depuis diverses sources :
EIT issus des flux reçus (SPTS et MPTS). Activé via 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.
La durée de conservation des événements EPG est définie par le paramètre EPG storage period (days).
Auto-clean database — les programmes sans événements sont supprimés.
La section EPG affiche les sources EPG et les données associées. Pour chaque chaîne (EPG Channels List), on peut définir :
Channel Name — nom utilisé lors de l’export sur le serveur XMLTV.
Time Zone — possibilité d’ajuster le fuseau horaire si l’import n’a pas calé sur l’UTC.
EPG Channel Sets — lier la chaîne à un Channel Set (voir plus bas).
Icon — URL de l’icône de chaîne (http://example.com/mychannel/myicon.png).
Générateur 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 ce Stream est utilisé dans un multiplexeur, le Service Name peut être redéfini séparément dans le paramètre output/muxer.
Serveur EPG (XMLTV)¶
Un serveur HTTP intégré distinct de Perfect Streamer délivre le XMLTV complet pour un ensemble de chaînes donné. L’endpoint est destiné aux middleware et lecteurs qui stockent le guide localement et ne le rafraîchissent que rarement, en bloc — généralement une à deux fois par jour.
Le serveur et ses clients se configurent dans la section Configuration/EPG/EPG Server.
URL et authentification¶
Le service est assuré par un serveur HTTP distinct epg-server (pas celui de /data/*). Par défaut, il écoute sur les ports 10444 (HTTP) et 10445 (HTTPS) ; les ports et SSL se configurent sous /config/epg-server.
Routes :
URL |
Content-Type |
Comportement |
|---|---|---|
|
|
Avec |
|
|
Renvoie toujours un flux gzip avec |
Trois méthodes d’authentification sont prises en charge :
HTTP Digest (recommandé) — compte issu de
/config/epg-server/login.Paramètres dans l’URL —
?l=<login>&p=<password>(synonymes :login=…,password=…).Loopback — une requête depuis
127.0.0.1est traitée anonymement. Pratique pour les scripts déployés sur la même machine.
Avertissement
Un login et un mot de passe dans l’URL finissent dans les logs d’accès du reverse-proxy et dans l’historique du navigateur. Pour la distribution publique du XMLTV, utilisez HTTP Digest ou n’acceptez les requêtes que depuis des adresses privées.
Accès par channel-set¶
Chaque compte epg-server/login est lié à un seul channel-set issu de /config/epg-channel-set. L’EPG renvoyé ne contient que les chaînes appartenant à ce groupe. Cela permet à une même installation PSS de fournir des XMLTV différents à différents opérateurs/middleware.
Configuration de base dans l’IU :
Dans Configuration/EPG/EPG Channel Sets, créez un groupe de chaînes et affectez-y les chaînes voulues au niveau des sources EPG.
Dans Configuration/EPG/EPG Server Clients, créez un compte et liez-y le groupe de chaînes créé. Sans liaison channel-set, le client reçoit un XMLTV vide.
Restrictions supplémentaires pour un login :
ip-addr— si défini et non joker, une requête depuis une autre IP reçoit403 Forbidden.limit-day— Unix epoch en s, après lequel le compte cesse d’être servi (403 Forbidden). Pratique pour un modèle d’abonnement.pause— désactiver temporairement un login sans le supprimer.
Format de la réponse¶
Le corps de la réponse est un document XMLTV avec la racine <tv>. La structure suit le schéma XMLTV DTD communément utilisé :
<?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>
Remarques sur les champs :
Les attributs
source-info-nameetsource-info-urlde la racine<tv>sont alimentés depuis les champs EPG Source Name et EPG Source URL dans Configuration/EPG/EPG Server.Les attributs
startetstopsont au formatYYYYMMDDhhmmss ±zone(le fuseau horaire est tiré du champtime_zonede la chaîne).Un
<programme>peut contenir plusieurs<title>/<desc>pour différentes langues. L’attributlangest vide quand l’identifiant de langue dans les données EPG sources n’a pas pu être mappé au dictionnaire (l’entrée apparaît tout de même dans la sortie).Les chaînes avec un
channel_iden conflit (lorsque le même id provient de plusieurs sources) sont listées une seule fois, les sources restantes sont ignorées avec un avertissement dans le journal du serveur.Seuls les événements avec
stop_time >= nowsont inclus dans la sortie.
En-têtes HTTP¶
Le serveur envoie toujours :
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Connection: close
Pour /xmltv en plus — Content-Encoding: gzip lorsque Accept-Encoding: gzip est présent dans la requête. Pour /xmltv.gz — Content-Disposition: inline; filename="xmltv.xml.gz".
L’interdiction du cache côté client est intentionnelle : le XMLTV change à chaque import EIT ou rafraîchissement de source XMLTV externe, et le lecteur ne doit pas conserver des données obsolètes indéfiniment. Un cache edge (nginx) reste tout à fait admissible — voir la section performance ci-dessous.
Cache serveur et sa purge¶
Le XMLTV prêt est mis en cache dans la mémoire du processus PSS :
Une entrée par
channel-set; les deux variantes du corps (brute et gzip) sont stockées — les requêtes répétées avecAccept-Encoding: gzipou/xmltv.gzne recompressent pas les données.Chaque entrée est étiquetée avec un compteur
update-time. Toute mise à jour EPG (import EIT, rafraîchissement de source XMLTV) incrémente le compteur, et le cache est reconstruit à la requête suivante.
Purge forcée du cache :
POST /xmltv/reset-cache
La route est servie par le serveur admin (port 43971/43981), pas par epg-server. Corps vide ; la réponse est 200 OK avec une enveloppe JSON.
Codes de réponse HTTP¶
Code |
Condition |
|---|---|
|
Requête traitée. Le corps est un document XMLTV (éventuellement un |
|
Ni Digest ni les paramètres |
|
Le login existe mais la requête ne vient pas d’une IP autorisée, ou |
|
Toute URL autre que |
|
Méthode autre que GET. |
Le corps de l’erreur est une enveloppe JSON de format fixe :
{"status": 401, "message": "Unauthorized"}
Performance et mise à l’échelle¶
Cache serveur¶
Le cache serveur sert les requêtes répétées sur un même channel-set sans accéder à SQLite — en copiant le corps déjà prêt.
Construire le XMLTV « depuis zéro » (cache miss) est plus coûteux : un SELECT distinct sur channel_name par chaîne, et sur event_text et event_rating par événement. Temps de construction indicatifs :
Taille de la sortie |
Cache hit |
Cache miss (build) |
|---|---|---|
100 chaînes / jour |
dizaines de ms |
~0,5–1 s |
500 chaînes / jour |
~50 ms |
2–5 s |
1000+ chaînes / semaine |
~100–300 ms |
5–15 s |
Pour la plupart des middleware, il est acceptable de récupérer le XMLTV toutes les quelques heures ou une fois par jour.
Quand un reverse-proxy externe (nginx) est nécessaire¶
Contrairement à /data/epg/channel (réponses JSON courtes), le XMLTV est un seul gros document par channel-set, idéal pour un cache edge :
Des dizaines à des centaines de clients par channel-set — le cache interne de PSS suffit généralement s’ils interrogent le XMLTV toutes les heures à toutes les 24 h.
Milliers de clients simultanés — un reverse-proxy avec cache est recommandé. Servir un fichier XMLTV à des centaines/milliers de requêtes est avant tout une charge réseau (centaines de Ko à quelques Mo par réponse) qu’il est préférable de retirer à PSS.
Distribution géographiquement répartie — un CDN/cache edge est indispensable quel que soit le nombre de clients.
PSS renvoie Cache-Control: no-cache ; il faut donc indiquer explicitement à nginx d’ignorer l’en-tête upstream et de tenir son propre TTL.
Exemple de configuration 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;
}
}
Explications et recommandations¶
TTL ``proxy_cache_valid 200 30m`` — le XMLTV change rarement plus souvent que toutes les 30 minutes. Si la synchronisation avec les sources est horaire ou moins fréquente, on peut monter à 1 heure et plus ; si la fraîcheur après
POST /xmltv/reset-cacheimporte, baissez-le.``proxy_cache_lock_timeout 60s`` — augmenté par rapport à
/data/epg/channel(où 5 s est habituel), car la construction du XMLTV pour un grand channel-set est plus longue.Une ``keys_zone`` dédiée — même sur une grande installation, les clés XMLTV uniques se comptent sur les doigts (nombre de comptes ×
channel-set) ; 8 Mo suffisent largement.max_sizese dimensionne selon le volume XMLTV, pas selon le nombre de clés.inutile d’activer gzip côté nginx : pour
/xmltv.gzla réponse est déjà compressée et pour/xmltvPSS répond lui-même en gzip siAccept-Encoding: gzipest présent.Terminaison HTTPS sur nginx offre de meilleures performances en cas de nombreux handshakes TLS simultanés.
Endpoints associés¶
POST /xmltv/reset-cache— purge forcée du cache XMLTV côté serveur (sur le serveur admin43971/43981).POST /data/epg/update?s=<src_id>— actualisation forcée d’une source XMLTV externe ; après un succès, le cache XMLTV côté serveur est purgé automatiquement.GET /data/epg/channel?…— sortie EPG JSON pour une chaîne sur la journée ; voir la section dédiée.
La liste complète et la description détaillée de l’API HTTP figurent dans manual/http_data_api.txt.
EPG pour middleware OTT¶
Le serveur fournit les données du guide des programmes (EPG) pour la journée sélectionnée pour une chaîne, au format JSON. L’endpoint est destiné aux back-ends de middleware OTT qui agrègent la grille depuis Perfect Streamer pour construire le programme côté client final.
URL et authentification¶
L’endpoint est servi par le serveur admin intégré. Par défaut, il est disponible sur les ports 43971 (HTTP) et 43981 (HTTPS) ; les ports se configurent dans Settings/Server Settings.
GET /data/epg/channel?src=<src_id>&ch=<channel_id>&lang=<lang>&t=<time>
L’authentification est HTTP Digest, comme pour le reste de /data/*. Pour le middleware, un compte avec le rôle viewer (lecture seule) suffit.
Note
Les requêtes depuis l’adresse loopback (127.0.0.1) sont exécutées sans contrôle HTTP Digest — le serveur les considère comme anonymes. Pratique pour les scripts locaux et les health-checks d’un middleware déployé sur la même machine que Perfect Streamer ; pour les accès distants, des identifiants sont obligatoires.
Paramètres de la requête¶
Paramètre |
Type |
Obligatoire |
Par défaut |
Description |
|---|---|---|---|---|
|
entier non signé |
non |
|
Source EPG. |
|
chaîne |
oui |
— |
Identifiant de la chaîne dans la base EPG : valeur du champ |
|
entier ou ISO 639 |
non |
langue système par défaut |
|
|
entier non signé (Unix epoch, s) |
non |
heure actuelle du serveur |
Tout point à l’intérieur de la journée concernée. Le serveur renvoie les événements de la journée UTC à laquelle appartient |
Note
La journée est prise en UTC, pas dans le fuseau local. Si le middleware construit la grille selon le jour calendaire local, la frontière de la journée UTC peut ne pas coïncider avec minuit local ; il faut alors lancer deux requêtes (pour deux jours UTC adjacents) et recoller les résultats par le champ start.
Format de la réponse¶
Content-Type:application/json.Les en-têtes HTTP interdisent la mise en cache côté client et sur les proxys intermédiaires :
Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: 0
Le corps de la réponse est un JSON avec la liste des événements du jour :
{
"event": [
{"start": 1715000000, "end": 1715003400, "title": "Утренние новости", "desc": "Обзор событий за сутки"},
{"start": 1715003400, "end": 1715007000, "title": "Прогноз погоды", "desc": ""}
]
}
Champs de l’événement :
start,end— début et fin de l’émission en Unix epoch (s), UTC.title— titre de l’émission dans la langue choisie. Si le titre n’existe pas dans la langue demandée pour l’événement, le serveur prend l’entrée dans la langue système par défaut, puis dans toute autre langue disponible.desc— description étendue. Peut être une chaîne vide si la base ne contenait pas de description séparée pour l’événement.
Particularités de la sortie :
Les événements avec un titre vide et sans description, ainsi que ceux avec des horodatages incorrects, sont exclus de la sortie.
Les doublons par
startsont éliminés : pour un même instant de début, une seule entrée est renvoyée avec la meilleure priorité de langue (demandée → défaut système → autres).L’ordre des événements dans le tableau n’est pas garanti — si nécessaire, le middleware trie lui-même la liste par le champ
start.Si la chaîne est introuvable, si la source n’existe pas ou s’il n’y a aucun événement pour la journée choisie, le serveur renvoie
200 OKavec le tableau vide{"event":[]}ou, dans le rare cas d’une source absente, avec un corps vide. Le middleware doit gérer correctement les deux variantes.
Mise en cache sur le serveur¶
Le JSON prêt est mis en cache par le serveur avec la clé (channel_id, date UTC, langue) ; les requêtes répétées pour les mêmes jour et chaîne sont donc servies sans accéder à la base de données. Le middleware n’a rien à faire pour gérer le cache.
Le cache est purgé automatiquement :
à l’arrivée de nouveaux événements depuis l’EIT MPEG-TS des flux d’entrée (
src=0) ;lors d’une actualisation réussie d’une source XMLTV externe (
src > 0— planifiée ou forcée viaPOST /data/epg/update?s=<src_id>) ;lorsqu’un jour sort de la fenêtre de conservation EPG.
Un endpoint dédié pour la purge forcée du cache n’est ni prévu ni nécessaire.
Codes de réponse HTTP¶
Code |
Condition |
|---|---|
|
Requête traitée. Le corps est un JSON avec la liste des événements (éventuellement vide). |
|
Le paramètre |
|
L’authentification HTTP Digest est absente ou invalide (pour les requêtes ne provenant pas d’une adresse loopback). |
Les autres situations (src inconnu, chaîne absente, pas d’événements ce jour-là) ne produisent pas de 4xx — le middleware reçoit 200 OK avec le tableau vide {"event":[]}.
En cas d’erreur, le corps de la réponse est une enveloppe JSON de format fixe :
{"status": 400, "message": "Bad Request"}
Le champ status reprend le code HTTP ; le champ message contient une cause d’erreur précisée en anglais (ou le texte standard du statut HTTP s’il n’y a pas d’information supplémentaire). Le Content-Type de la réponse d’erreur est application/json.
Exemple¶
curl -u middleware:secret --digest \
'http://pss.example.com:43971/data/epg/channel?src=0&ch=12.0.1&lang=rus&t=1715000000'
Exemple de réponse :
{
"event": [
{"start": 1715000000, "end": 1715003400, "title": "Утренние новости", "desc": "Обзор событий за сутки"},
{"start": 1715003400, "end": 1715007000, "title": "Прогноз погоды", "desc": ""}
]
}
Performance et mise à l’échelle¶
Cache serveur Perfect Streamer¶
Au sein du processus PSS, il existe un cache LRU en mémoire des réponses, indexé par (channel_id, date UTC, langue), avec un plafond strict de 1024 entrées par source EPG. Avec une charge typique (dizaines à centaines de chaînes × 1–3 langues × keep-day jours), toutes les entrées actuelles tiennent intégralement en cache ; les requêtes répétées sont servies sans accéder à SQLite.
Ordre de grandeur (build de débogage, loopback local, sans HTTPS) :
Scénario |
Latence (requête unique) |
Débit (P=8) |
|---|---|---|
Cache hit |
~0,3 ms |
~1100 requêtes/s |
Cache miss (SQL + JSON) |
~1,0–1,5 ms |
~1000 requêtes/s |
En build release et sans journalisation de debug, les chiffres sont environ 2 à 3 fois meilleurs. Bande passante — environ 14 Ko par réponse pour une chaîne typique sur la journée.
Quand un reverse-proxy externe (nginx) est nécessaire¶
Le cache serveur accélère les requêtes répétées pour le même (chaîne, jour, langue), mais chaque requête passe tout de même par le serveur HTTP intégré de PSS et consomme un thread de son pool. Avec beaucoup de clients, il est judicieux de déplacer la mise en cache au edge :
jusqu’à ~1 000 clients en ligne — le cache interne suffit généralement, un reverse-proxy n’est pas obligatoire.
dizaines de milliers et plus — un reverse-proxy avec cache (par exemple nginx) est recommandé. Un cache edge traite 99 % des requêtes sans PSS, amortit les pics (démarrage de middleware, rafraîchissement massif des lecteurs) et permet de placer la terminaison SSL sur un nœud séparé.
distribution géographiquement répartie — un CDN/proxy externe est nécessaire avant même de compter les clients.
PSS envoie son propre en-tête Cache-Control: no-cache, no-store, must-revalidate pour que les clients finaux ne mettent pas l’EPG en cache durablement. Le reverse-proxy peut (et doit) mettre la réponse en cache lui-même — on montre plus bas comment indiquer explicitement à nginx d’ignorer le Cache-Control upstream et de tenir son propre TTL.
Exemple de configuration nginx¶
Une configuration minimale pour un cache edge EPG dimensionnée pour des dizaines de milliers de clients avec un intervalle d’interrogation de 1 à 5 minutes :
# /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;
}
}
Explications et recommandations¶
TTL ``proxy_cache_valid 200 60s`` — compromis entre fraîcheur de l’EPG et charge sur l’upstream. La grille ne change pas en temps réel, 30 à 300 s sont donc raisonnables. Après l’import de nouveaux événements, PSS purge son propre cache instantanément, et le cache edge rattrape au prochain TTL.
``proxy_cache_lock on`` est obligatoire pour un grand nombre de clients : lors d’un cache miss, il coalesce les requêtes parallèles sur la même clé en une seule requête upstream, protégeant SQLite des pics de
BUSYsous charge.``keys_zone`` et ``max_size`` sont dimensionnés selon le nombre
(chaîne × jour × langue): 32 Mo dekeys_zonecouvrent des centaines de milliers de clés ; 2 Go demax_sizecouvrent un mois d’historique pour des centaines de chaînes, avec marge.gzip réduit nettement le trafic : les réponses se compressent bien (clés JSON répétées, cyrillique en UTF-8).
``X-Cache-Status`` dans la réponse permet au middleware de voir
HIT/MISS/EXPIREDet d’évaluer l’efficacité du cache.Si nginx et PSS résident sur la même machine, le serveur admin n’exige pas HTTP Digest pour le loopback ; le bloc upstream peut donc rester sans
proxy_set_header Authorization …. Pour un déploiement à travers les réseaux, créez un compteviewerdédié et ajoutez l’authentification Digest dansproxy_pass.HTTPS se termine de préférence sur nginx : PSS prend HTTPS directement en charge, mais un serveur edge est généralement plus efficace pour gérer les handshakes TLS avec des milliers de clients simultanés.
Endpoints associés¶
POST /data/epg/sql?s=<src_id>— requête SQL arbitraire sur la base EPG (notamment pour obtenir la liste deschannel_id).POST /data/epg/update?s=<src_id>— actualisation forcée d’une source XMLTV externe.
La liste complète et la description détaillée de l’API HTTP figurent dans manual/http_data_api.txt.
Optimisation du fonctionnement du programme¶
Si avec un grand nombre de stream, des problèmes de charge CPU ou de manque de mémoire surviennent, les paramètres peuvent être optimisés.
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.
Désactiver complètement ou modifier les paramètres de Mosaic. La désactivation complète se fait dans les paramètres du serveur. Vous pouvez la désactiver individuellement pour chaque stream ou modifier l’intervalle de mise à jour avec le paramètre Check Interval.
Erreurs queue overload pour les bases DBStat et DBEPG¶
Apparaissent en cas de performances insuffisantes des bases de données — disque lent ou système surchargé.
L’emplacement des bases de données est défini par le paramètre data-dir du fichier pss.properties
Solutions possibles :
Déplacement des fichiers de base de données vers /tmp. La mémoire système sera utilisée — cela nécessite une estimation de la mémoire disponible et le réglage du temps de stockage des statistiques (voir paramètres du serveur). Au redémarrage du système, les données seront perdues.
Réduire le niveau de détail des statistiques — voir le paramètre dbstat-detail. Valeur par défaut 5 s, peut être portée à 20.
Placer la base EPG en mémoire — définir dbepg-memory=true.
Transcodeurs¶
Les transcodeurs sont implémentés comme des binaires exécutables distincts, lancés depuis pstreamer en tant que processus séparés.
Les configurations 1toN sont prises en charge : un seul decoder peut alimenter plusieurs flux avec des réglages d’encoder différents.
Le flux source doit contenir vidéo et audio ; les variantes sans vidéo ou sans son ne sont pas prises en charge.
Codecs implémentés :
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)
Les flux entrelacés sont pris en charge en entrée et en sortie.
Pour les décodeurs H.264 et HEVC, le format interlace alternate (deux champs séparés dans le flux) est pris en charge ; il est converti en interlace interleaved.
Le décodeur HEVC prend en charge le profil Main10 avec bt.709 (SDR) et bt.2020 (HDR). L’encodeur HEVC utilise toujours le profil Main avec bt.709.
Pour les décodeurs H.264 et HEVC, le format VBR (Variable Frame Rate) est pris en charge ; il est converti en framerate constant.
Audio decoder - mpeg (layer 1,2,3), aac, ac3
Audio encoder - mpeg (layer 2), aac
Il existe un mode de transcodage Video Passthrough — la vidéo n’est pas transcodée, seul l’audio l’est ; le transcodeur SW est utilisé.
Note
Pour le transcodage, configurer deux flux ou plus, avec output (decoder) et input (encoder).
Pour configurer une instance de transcodeur, il faut :
Source — ajouter dans le stream output transcoder (decoder). Dans les paramètres, choisir le type : SW, NV ou Video Passthrough.
Flux de sortie — ajouter dans le stream input transcoder (encoder) ; sélectionner la source-decoder dans les paramètres.
Répéter si plusieurs flux de sortie sont nécessaires pour un même decoder.
Paramètres du transcodeur de sortie (decoder)¶
Convert colors to BT.709 — conversion des formats SD BT.470-2 (PAL) et SMPTE 170M (NTSC) en BT.709
Trace — activer pour le diagnostic le journal détaillé du transcodeur.
Pour le bon fonctionnement du transcodeur, le flux source doit répondre à certaines exigences ; dans certains cas, cela peut être corrigé. Ces paramètres ne convertissent pas le flux — ils servent d’indices pour le bon fonctionnement du transcodeur.
Pour corriger les données du flux d’entrée, les paramètres suivants existent :
Fix PAR — corriger le Pixel Aspect Ratio. Donné sous forme de fraction N/D ; par exemple 16/9 pour le Wide SD.
Fix Framerate — spécifier explicitement le framerate. Dans certains flux, le framerate peut être absent du SPS, et l’erreur correspondante apparaîtra dans le log du transcodeur. Dans ces cas, il faut indiquer manuellement le framerate. Indiqué sous forme de fraction au format N/D.
Exemples de valeurs de framerate :
PAL - 25/1
NTSC — 30/1 ou 30000/1001
Cinéma — 24/1 ou 24000/1001
Paramètres du transcodeur d’entrée (encoder)¶
Encoder Type — codec vidéo.
Align Total Bitrate — bitrate du stuffing du flux (remplissage par paquets null). Important si le flux sera utilisé pour la diffusion DVB. Le bitrate doit être garanti supérieur à celui de la vidéo et de toutes les pistes audio.
Video Profile — pour H.264, on peut sélectionner le profil d’encodage.
Video Bitrate — bitrate du flux vidéo en kbps. L’encodage est toujours en CBR ; le bitrate total sera plus élevé à cause des pistes audio.
Speed Preset — préréglages d’encodage, valeurs de 1 à 7. Plus bas = meilleure qualité et plus de ressources. Par défaut 4.
GOP Interval — intervalle en images pour le GOP (équivaut au Key Frame Interval). Par défaut 25 (1 seconde à 25p) ; recommandé lorsque les lecteurs démarrent en aléatoire.
BFrame — activer pour améliorer la qualité. Valeur recommandée : 3.
Lookahead — activer pour améliorer la qualité. Valeur recommandée : 20 à 50 images.
Resize — redimensionnement de l’image.
Deinterlace — convertit l’entrelacé en progressif.
L’insertion d’un crop (bandes vides en bordure) n’est pas prise en charge. Toute taille d’image arbitraire est refusée pour éviter de fausser les proportions.
Pour resize, les options suivantes sont disponibles :
Réduire proportionnellement la taille de 2 et 4.
Choisir le format Wide SD 16:9, l’Aspect Ratio approprié sera défini.
Upscale SD→HD. S’applique aux sources SD PAL/NTSC. L’entrelacement n’est pas pris en charge ; effectuer un désentrelacement préalable si besoin.
Définir la largeur. La hauteur sera recalculée proportionnellement.
Définir la hauteur. La largeur sera recalculée proportionnellement.
Certains paramètres peuvent être incompatibles avec le transcodeur choisi ; les erreurs apparaissent dans son log.
Traitement audio¶
Par défaut, toutes les pistes audio passent de l’entrée à la sortie sans traitement. Les pistes superflues peuvent être supprimées via les filtres PID du stream.
Pour transcoder l’audio, on configure des règles distinctes par codec audio. L’option skip — supprimer la piste audio de ce codec.
Si le flux de sortie ne contient aucune piste audio, une erreur se produit — voir les logs du transcodeur.
Génération PCR et TR 101 290.¶
Le multiplexeur MPEG-TS génère un nouveau PCR. Avec Align Total Bitrate correctement réglé (supérieur à la somme des bitrates vidéo et audio), le PCR doit passer la conformité TR 101 290.
État des transcodeurs¶
En cas de problèmes de fonctionnement du transcodeur (pas de flux depuis l’encoder), consultez les logs dans la section Transcoders — la liste des instances y est affichée (chaque ligne est une instance distincte, decoder + N encoders) ; en cliquant sur l’instance souhaitée, la fenêtre de statut des logs s’ouvre. Sont affichés le log courant et celui de l’exécution précédente. Pour un log détaillé, activez trace dans les paramètres output (decoder).
