Aller au contenu

live-common: Module NGINX Commun de Kaltura Media Framework

Installation

Vous pouvez installer ce module dans n'importe quelle distribution basée sur RHEL, y compris, mais sans s'y limiter :

  • RedHat Enterprise Linux 7, 8, 9 et 10
  • CentOS 7, 8, 9
  • AlmaLinux 8, 9
  • Rocky Linux 8, 9
  • Amazon Linux 2 et Amazon Linux 2023
dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-live-common

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-live-common

Activez le module en ajoutant ce qui suit en haut de /etc/nginx/nginx.conf :

load_module modules/ngx_http_api_module.so;

Ce document décrit nginx-module-live-common v2.0.6 publié le 13 novembre 2025.

Statut de construction

Un cadre distribué pour le streaming vidéo en direct. Le système est composé de plusieurs composants, chacun responsable d'une fonction spécifique.

Les composants peuvent être déployés sur un seul serveur pour des déploiements/tests à petite échelle, mais il est recommandé de les déployer séparément pour une utilisation plus optimale des ressources. Par exemple, le transcoder peut utiliser le GPU, il serait donc plus rentable de déployer les transcodeurs sur des serveurs équipés de GPU, tandis que les autres composants fonctionneraient sur des serveurs sans GPU.

Les médias sont transmis entre les différents composants en interne en utilisant des protocoles personnalisés - 1. Kaltura Media Protocol (KMP) - un protocole basé sur TCP pour la diffusion de médias en streaming, conceptuellement, similaire à une seule piste de fMP4/MPEG-TS 2. Kaltura Segmented Media Protocol (KSMP) - un protocole basé sur HTTP pour la diffusion de médias en segments, conceptuellement, un super-ensemble de LLHLS/DASH

L'orchestration des différents composants médiatiques est effectuée par un "contrôleur". La principale responsabilité du contrôleur est de construire la topologie du pipeline médiatique et de la mettre à jour en cas de défaillances. Le contrôleur reçoit des événements JSON des composants médiatiques envoyés sous forme de HTTP-POST. De plus, tous les composants de traitement des médias exposent une API REST basée sur JSON, qui est utilisée par le contrôleur pour obtenir le dernier statut et prendre des mesures. Une implémentation d'exemple de contrôleur pour un serveur tout-en-un est fournie dans le dossier conf.

Principales caractéristiques

  • Protocoles de publication : RTMP, MPEGTS (sur SRT/HTTP/TCP)
  • Protocoles de lecture : HLS/LLHLS, DASH
  • Protocoles de push/relais en direct : RTMP
  • Transcodage vidéo/audio - y compris le support GPU, basé sur l'API ffmpeg
  • Persistance - dans le stockage d'objets S3 (ou compatible)
  • Livraison à débit binaire adaptatif
  • Support des sous-titres - y compris la conversion de 608/708 en WebVTT
  • Audio alternatif
  • Chiffrement des médias et DRM
  • Capture d'images vidéo

Prise en main

Le dossier conf contient un code d'exemple et une configuration pour exécuter un serveur tout-en-un.

Glossaire

  • Canal - un conteneur qui représente un flux en direct, peut contenir des pistes, des variantes, des chronologies, etc.
  • Piste - une seule version de vidéo/audio/sous-titre. Par exemple, un canal peut avoir 3 pistes vidéo : 1080p, 720p, 540p.
  • Variante - un regroupement de pistes utilisé pour l'emballage. Les variantes déterminent quelle piste audio sera associée à chaque piste vidéo, lorsque des segments muxés sont utilisés. Une variante peut pointer vers plusieurs pistes, mais pas plus d'une piste par type de média. Les pistes doivent être associées à des variantes afin d'être livrées via HLS/DASH.
  • Segment - un groupe d'images d'une piste spécifique. Les segments sont toujours indépendants - les segments vidéo commenceront toujours par une image clé/IDR.
  • Index de segment - un nombre qui identifie les segments des différentes pistes qui sont associés à un intervalle de temps spécifique.
  • Période - un ensemble d'index de segments qui peuvent être joués de manière continue.
  • Chronologie - un ensemble de périodes. Plusieurs chronologies peuvent être créées, chacune avec son propre ensemble de périodes. Les chronologies peuvent être utilisées, par exemple, pour implémenter le "mode aperçu" - le diffuseur consomme une chronologie, tandis que les spectateurs consomment une autre. La chronologie du diffuseur est toujours active, tandis que la chronologie des spectateurs est activée à la discrétion du diffuseur.

Topologies d'exemple

Les diagrammes ci-dessous montrent quelques topologies d'exemple qui peuvent être créées en utilisant les composants du Media-Framework.

Simple RTMP Passthrough

flowchart LR;
    enc(Encodeur);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Joueur);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Passthrough + Persistance S3

flowchart LR;
    enc(Encodeur);
    ingest(nginx-rtmp-kmp-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    s3(Amazon S3);
    play(Joueur);
    enc-->|RTMP|ingest;
    ingest-->|KMP|live;
    live-->|HTTP|s3;
    s3-->|HTTP|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Entrée SRT + Transcodage Vidéo

flowchart LR;
    enc(Encodeur);
    ingest(nginx-mpegts-kmp-module);
    srt(nginx-srt-module);
    trans(transcodeur);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Joueur);
    enc-->|SRT|srt;
    srt-->|MPEG-TS|ingest;
    ingest-->|KMP vidéo|trans;
    trans-->|KMP vidéo|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Décodage de sous-titres

flowchart LR;
    enc(Encodeur);
    ingest(nginx-rtmp-kmp-module);
    cc(nginx-cc-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Joueur);
    enc-->|RTMP|ingest;
    ingest-->|KMP vidéo|cc;
    cc-->|KMP sous-titre|live;
    ingest-->|KMP vidéo|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Transcodage + Push RTMP

flowchart LR;
    enc(Encodeur);
    ingest(nginx-mpegts-kmp-module);
    trans(transcodeur);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    push(nginx-kmp-rtmp-module);
    yt(YouTube);
    play(Joueur);
    enc-->|MPEG-TS/HTTP|ingest;
    ingest-->|KMP|trans;
    trans-->|KMP|live;
    trans-->|KMP|push;
    push-->|RTMP|yt;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Vue d'ensemble des composants

Composants médiatiques

  • nginx-rtmp-kmp-module - ingestion de médias en direct, entrée : RTMP, sortie : KMP x N

  • nginx-mpegts-kmp-module - ingestion de médias en direct, entrée : MPEG-TS sur TCP/HTTP, sortie : KMP x N

  • transcodeur - transcodage vidéo/audio, entrée : KMP, sortie : KMP x N

  • nginx-live-module - segmentateur de médias en direct, entrée : KMP x N, sortie : KSMP

    Fonctionnalités supplémentaires : persistance, remplisseur, support de chronologie.

  • nginx-pckg-module - empaqueteur de médias en direct (sans état), entrée : KSMP, sortie : HLS/LLHLS, DASH

    Fonctionnalités supplémentaires : débit binaire adaptatif, sous-titres, audio alternatif, chiffrement des médias / DRM, capture d'images vidéo

  • nginx-kmp-cc-module - décodeur de sous-titres, entrée : KMP vidéo (h264/5), sortie : KMP sous-titre (WebVTT) x N

  • nginx-kmp-rtmp-module - relais de médias en direct, entrée : KMP x N, sortie : RTMP

Important : Tous les composants basés sur nginx avec état (= tous sauf nginx-pckg-module), doivent être déployés sur un serveur nginx à processus unique (worker_processes 1;). L'état du module est conservé par processus, et lorsque plusieurs processus sont utilisés, il n'est pas possible de contrôler quel processus recevra la requête. Par exemple, la requête pour créer un canal sur le segmentateur peut arriver au worker 1, tandis que la connexion KMP avec le média réel, atteindra le worker 2. Dans les déploiements qui utilisent des conteneurs, cela ne devrait pas poser de problème - plusieurs conteneurs peuvent être déployés sur un seul serveur, au lieu d'utiliser plusieurs processus nginx. Une autre possibilité est d'utiliser un patch comme le listener par worker d'arut, mais il devra probablement être mis à jour pour s'appliquer également aux connexions stream.

Options de débogage

Certains des composants du Media-Framework prennent en charge des macros de préprocesseur optionnelles à des fins de débogage - - NGX_LBA_SKIP (nginx-common) - Ignore l'utilisation du module "Large Buffer Array" (LBA). Lorsqu'il est activé, les allocations LBA sont routées vers ngx_alloc / ngx_free. - NGX_RTMP_VERBOSE (nginx-rtmp-module) - Active des messages de log de débogage supplémentaires - NGX_LIVE_VALIDATIONS (nginx-live-module) - Active les vérifications de cohérence à l'exécution sur les structures de données internes, activé par défaut lors de l'utilisation de --with-debug - NGX_BLOCK_POOL_SKIP (nginx-live-module) - Ignore l'utilisation des pools de blocs. Lorsqu'il est activé, les allocations de pools de blocs sont routées vers ngx_palloc / ngx_pfree.

Pour tester les modules avec valgrind, il est recommandé d'appliquer le patch no-pool-nginx, et de configurer nginx avec --with-cc-opt="-O0 -DNGX_BLOCK_POOL_SKIP -DNGX_LBA_SKIP" et --with-debug.

Kaltura Media Protocol (KMP)

Kaltura Media Protocol est un protocole simple basé sur des paquets pour le streaming de médias sur TCP. Une connexion KMP peut livrer le média d'une seule piste vidéo/audio/sous-titre - lorsque plusieurs pistes sont nécessaires, plusieurs connexions TCP sont établies.

Chaque paquet commence par un en-tête qui contient les champs suivants (32 bits chacun) - - Type - le type du paquet. Les types de paquets sont des codes de quatre caractères, voir ci-dessous la liste des types actuellement définis. - Taille de l'en-tête - la taille de l'en-tête du paquet, doit être comprise entre sizeof(kmp_packet_header_t) et 64 Ko. Les analyseurs doivent utiliser la taille de l'en-tête pour accéder aux données du paquet, cela permet d'ajouter de nouveaux champs aux en-têtes de paquet sans casser les analyseurs existants. - Taille des données - la taille des données du paquet, doit être comprise entre 0 et 16 Mo. - Réservé - réservé à un usage futur, doit être fixé à 0.

Les structures et constantes utilisées dans KMP peuvent être trouvées dans ngx_live_kmp.h.

Identifiants de cadre KMP

Un identifiant de cadre est un entier de 64 bits qui identifie de manière unique un cadre d'entrée. Les modules d'ingestion (nginx-rtmp-kmp-module / nginx-mpegts-kmp-module) allouent l'identifiant de cadre initial en fonction de l'horloge du serveur (en unités de temps), lorsqu'une piste de sortie est créée. Afin d'éviter la nécessité d'envoyer l'identifiant de cadre à chaque cadre envoyé, les identifiants de cadre dans KMP sont séquentiels - l'identifiant du N-ième cadre envoyé sur une connexion KMP est initial_frame_id + N.

Si la connexion d'entrée (par exemple, RTMP) se coupe et se rétablit, de nouveaux identifiants de cadre KMP seront alloués. Étant donné que l'échelle de temps par défaut est élevée (90 kHz), et que le taux d'images est peu susceptible de dépasser 60 fps, même en cas de reconnexion après une courte période de streaming, l'identifiant de cadre initial sera significativement plus élevé que l'identifiant de cadre qui a été envoyé en dernier sur la connexion précédente. Il est donc extrêmement peu probable qu'il y ait un conflit avec des identifiants de cadre précédemment utilisés en raison de la reconnexion.

Les identifiants de cadre sont utilisés : - Pour identifier quels cadres sont accusés dans les paquets d'accusé de réception KMP - Pour ignorer les cadres déjà traités si une connexion KMP est rétablie

Le transcoder ajoute quelques complexités à la gestion des identifiants de cadre - - Étant donné que le transcoder peut changer le taux d'images d'entrée ou supprimer des cadres, les identifiants de cadre dans l'entrée du transcoder, ne sont pas nécessairement les mêmes que les identifiants de cadre dans la sortie du transcoder. Si le transcoder est redémarré, il doit savoir quelle valeur envoyer comme initial_frame_id de son serveur en amont (généralement nginx-live-module). Le champ upstream_frame_id est utilisé à cette fin. - Le transcoder peut être configuré pour changer le taux d'échantillonnage d'une piste audio, et, dans ce cas, les cadres transcodés ne s'alignent pas avec les cadres d'entrée. Pour gérer ce scénario, le transcoder doit avoir la capacité d'accuser seulement une partie d'un cadre d'entrée. C'est le but du champ offset - il peut stocker, par exemple, le nombre d'échantillons audio qui doivent être accusés dans le cadre. La signification exacte du champ offset est déterminée par le récepteur KMP - le récepteur définit l'offset dans les trames d'accusé de réception qu'il renvoie, et le récupère dans le champ initial_offset du paquet de connexion, en cas de reconnexion.

Paquets KMP du diffuseur

Les sections ci-dessous listent les paquets KMP qui peuvent être envoyés par un diffuseur KMP.

Connecter (cnct)

Envoyé immédiatement après l'établissement de la connexion TCP KMP.

L'en-tête contient les champs suivants : - channel_id - chaîne, l'identifiant du canal qui est publié. La longueur maximale autorisée est de 32 caractères. - track_id - chaîne, l'identifiant de la piste qui est publiée. La longueur maximale autorisée est de 32 caractères. - initial_frame_id - entier, l'identifiant du premier cadre envoyé. - initial_upstream_frame_id - entier, l'identifiant de cadre initial qui doit être envoyé au serveur en amont (utilisé par le transcoder) - initial_offset - entier, l'offset à partir duquel commencer, dans le cadre initial. - flags - entier, un masque de bits de flags, actuellement un seul flag est défini - consistent - ce flag est défini lorsque le diffuseur KMP génère une sortie cohérente (exacte en bits), donnée la même entrée. nginx-rtmp-kmp-module et nginx-mpegts-kmp-module sont des exemples de diffuseurs qui sont cohérents. Le transcoder, en revanche, ne l'est pas. Le flag consistent est utilisé par le segmentateur LL en cas de reconnexion. Lorsque le diffuseur est cohérent, le segmentateur LL peut continuer à partir du point où il s'est arrêté. Lorsque le diffuseur est incohérent, le segmentateur LL peut continuer uniquement à partir du prochain GOP - il ne doit pas mélanger un GOP partiel d'avant la déconnexion, avec le GOP reçu après la déconnexion.

Les données du paquet de connexion sont optionnelles, le format attendu des données est défini par le récepteur KMP spécifique.

Info Média (minf)

Contient les paramètres des médias. Certains des champs de l'en-tête sont partagés par tous les types de médias, tandis que les autres sont définis uniquement pour un type spécifique (union).

Les champs d'en-tête partagés sont : - media_type - entier, le type de média - video / audio / subtitle, utilise les constantes KMP_MEDIA_XXX. - codec_id - entier, l'identifiant du codec, utilise les constantes KMP_CODEC_XXX. - timescale - entier, les unités utilisées dans les champs dts / pts_delay / created des paquets de cadre, en Hz. - bitrate - entier, le débit binaire, en bits par seconde.

Les champs d'en-tête spécifiques à la vidéo sont : - width - entier, la largeur de la vidéo, en pixels. - height - entier, la hauteur de la vidéo, en pixels. - frame_rate - rationnel, le taux d'images de la vidéo, en images par seconde. - cea_captions - booléen, défini à 1 lorsque la piste vidéo contient des sous-titres EIA-608 / CTA-708.

Les champs d'en-tête spécifiques à l'audio sont : - channels - entier, le nombre de canaux audio. - bits_per_sample - entier, la taille des échantillons audio, en bits. - sample_rate - entier, le taux d'échantillonnage de l'audio, en échantillons par seconde. - channel_layout - entier, un masque de bits des positions des canaux, utilise les constantes KMP_CH_XXX.

Les données du paquet d'info média contiennent les données privées/extra du codec. Par exemple, lors de l'utilisation du codec h264, les données contiennent le corps d'une boîte MP4 avcC.

Les récepteurs KMP doivent gérer les changements d'info média, par exemple, un changement de résolution vidéo. Cependant, le type de média (vidéo/audio/sous-titre) qui est envoyé dans une connexion KMP, ne doit pas changer.

Les récepteurs KMP doivent ignorer les paquets d'info média, lorsqu'ils sont identiques au paquet d'info média précédemment reçu.

Cadre (fram)

Représente un seul cadre vidéo / cadre audio / indice de sous-titre.

L'en-tête du cadre contient les champs suivants : - created - entier, le temps auquel le cadre a été reçu par le premier module du Media-Framework dans le pipeline, en unités de temps. - dts - entier, le timestamp de décodage du cadre, en unités de temps. Lorsque le type de média est subtitle, contient le timestamp de début de l'indice. - flags - entier, actuellement un seul flag est défini - key - activé sur les images clés vidéo. - pts_delay - entier, la différence entre le timestamp de présentation du cadre et le timestamp de décodage, en unités de temps. Lorsque le type de média est subtitle, contient la durée de l'indice - end_pts - start_pts.

Lorsque le type de média est vidéo / audio, les données du paquet de cadre contiennent le média compressé. Lorsque le type de média est sous-titre et que le codec est WebVTT, les données du cadre suivent le format d'échantillon WebVTT, tel que spécifié dans ISO/IEC 14496-30 (généralement, dans ce cas, un échantillon est une boîte vttc, qui contient une boîte payl).

Null (null)

Envoyé pour signaler la "vivacité", et empêcher les minuteries d'inactivité d'expirer. Les paquets nuls ne transportent aucune donnée autre que l'en-tête KMP de base. Les analyseurs doivent ignorer les paquets nuls.

Fin de flux (eost)

Utilisé pour signaler une terminaison gracieuse de la session de publication. Les paquets de fin de flux ne transportent aucune donnée autre que l'en-tête KMP de base.

Paquets KMP du récepteur

Les sections ci-dessous listent les paquets KMP qui peuvent être envoyés par un récepteur KMP.

Cadres d'accusé (ackf)

Accusent la réception des cadres.

Le récepteur KMP décide du moment approprié pour envoyer un paquet d'accusé. Par exemple, lorsque la persistance est activée, le segmentateur envoie un accusé uniquement après qu'un segment contenant le cadre a été enregistré dans le stockage.

Certains récepteurs n'envoient pas d'accusés du tout, dans ce cas, le producteur KMP doit être configuré pour rejeter les cadres après leur envoi (en utilisant le paramètre resume_from)

L'en-tête du paquet contient les champs suivants : - frame_id - entier, l'identifiant du premier cadre qui doit être renvoyé si la connexion est perdue. En d'autres termes, un paquet de cadres d'accusé, accuse tous les cadres ayant un identifiant inférieur à frame_id. Si la connexion KMP est rétablie, cette valeur sera envoyée dans le champ initial_frame_id. - upstream_frame_id - entier, l'identifiant du cadre qui a été envoyé au serveur en amont. Si la connexion KMP est rétablie, cette valeur sera envoyée dans le champ initial_upstream_frame_id. - offset - entier, l'offset à accuser dans le cadre. Si la connexion KMP est rétablie, cette valeur sera envoyée dans le champ initial_offset. - padding - entier, réservé à un usage futur, doit être fixé à zéro.

Les données des paquets d'accusé ne sont pas utilisées.

Kaltura Segmented Media Protocol (KSMP)

Kaltura Segmented Media Protocol est un protocole basé sur HTTP pour la diffusion de médias en segments, de manière similaire à HLS/DASH.

Une requête KSMP est une requête HTTP GET, les paramètres de requête suivants sont définis - - channel_id - chaîne requise, l'identifiant du canal - timeline_id - chaîne requise, l'identifiant de la chronologie - flags - entier hexadécimal requis, les flags : - Sélectionner le sous-ensemble de données requis (comme la liste des colonnes dans une instruction SQL SELECT) - Contrôler divers comportements lors du traitement de la requête. Par exemple, le flag 'closest key', ne renvoie que l'image clé la plus proche du timestamp de la requête, au lieu de renvoyer tout le segment. - variant_ids - chaîne optionnelle, sélectionne un sous-ensemble des variantes qui doivent être renvoyées, par défaut, toutes les variantes sont renvoyées. Si plusieurs variantes sont spécifiées, elles doivent être délimitées par un tiret (-). - media_type_mask - entier hexadécimal optionnel, définit les types de médias qui doivent être renvoyés, par défaut, tous les types de médias sont renvoyés. - time - entier optionnel, le timestamp demandé. Le timestamp est utilisé, par exemple, pour capturer une image vidéo à un moment spécifique. - segment_index - entier optionnel, l'index du segment - max_segment_index - entier optionnel, utilisé pour limiter la portée des segments renvoyés dans la réponse. Ce paramètre peut être utilisé pour rejouer un flux persistant à des fins de débogage. - part_index - entier optionnel, l'index basé sur zéro du segment partiel dans le segment. Une requête utilisant part_index doit également envoyer segment_index. - skip_boundary_percent - entier optionnel, définit la valeur de skip boundary en pourcentage de la durée cible (voir la définition de l'attribut CAN-SKIP-UNTIL dans la spécification HLS pour plus de détails) - padding - entier optionnel, ajoute des octets nuls supplémentaires à la fin de la réponse. Utilisé pour se conformer aux exigences de remplissage de ffmpeg sans engager d'opérations de copie supplémentaires.

Une réponse KSMP utilise le format KLPF (voir ci-dessous), avec le type Serve (serv). Les définitions spécifiques à KSMP peuvent être trouvées dans ngx_ksmp.h

Kaltura Live Persist File (KLPF)

Kaltura Live Persist File est un schéma de sérialisation utilisé dans les réponses KSMP et dans les objets S3 créés par nginx-live-module.

Un KLPF est composé de blocs, similaires aux atomes/boîtes MP4. Chaque bloc a l'en-tête suivant - - id - un code de quatre caractères identifiant le bloc - size - uint32, la taille totale du bloc (en-tête & données) - flags - 4 bits, les flags suivants sont définis : - container (0x1) - le bloc contient d'autres blocs - index (0x2) - le bloc est un index vers un autre bloc, la taille de l'en-tête ne doit pas être utilisée - compressed (0x4) - les données du bloc sont compressées avec zlib - header_size - 28 bits, la taille de l'en-tête du bloc. Les analyseurs doivent utiliser la taille de l'en-tête pour accéder aux données du bloc, afin que des champs puissent être ajoutés à l'en-tête sans casser la compatibilité

Un fichier KLPF est un bloc dont l'id est fixé à klpf. Après les champs d'en-tête de bloc génériques (énumérés ci-dessus), un fichier KLPF a les champs suivants dans son en-tête - - uncomp_size - uint32, contient la taille non compressée des données, lorsque les données KLPF sont compressées - version - uint32, la version du format de fichier. La version utilisée pour les nouveaux fichiers est mise à jour à chaque changement de format, le code sera mis à jour pour soit - prendre en charge la lecture à la fois du nouveau format et de l'ancien format, ou - ignorer les fichiers utilisant l'ancien format - type - un code de quatre caractères qui identifie le type de données stockées dans le KLPF. Le type détermine quels identifiants de bloc sont pris en charge, et leur structure interne. Le type serv (Serve) est utilisé pour les réponses KSMP, dans la communication entre l'empaqueteur et le segmentateur. Des types supplémentaires sont utilisés en interne par le segmentateur. - created - uint64, le timestamp unix lorsque le KLPF a été créé

Pour plus de détails sur la structure interne des blocs KLPF, voir KLFP-SPEC.md.

Pour inspecter le contenu des objets KLPF/réponses KSMP, utilisez klpf_parse.py. Le script peut montrer la structure des blocs sans aucune info supplémentaire, cependant, pour analyser les champs à l'intérieur des blocs : - exécutez generate_persist_spec.py, et enregistrez la sortie dans un fichier - fournissez le nom du fichier à klpf_parse.py en utilisant l'option -s / --spec-file

Vue d'ensemble de l'API

Tous les composants de traitement des médias exposent une API REST basée sur JSON. Cette section explique les propriétés générales des API du Media-Framework. Pour une référence détaillée des points de terminaison API disponibles, voir la documentation des modules spécifiques.

Types de requêtes

Les verbes HTTP suivants sont utilisés dans l'API : - GET - obtenir le statut complet du module, ou un sous-ensemble de celui-ci. L'argument ?pretty=1 peut être ajouté à la requête, afin de renvoyer la réponse dans un format "beau" / indenté. - GET avec ?list=1 - renvoie les noms des "dossiers" sous un certain chemin dans l'API. Peut être utilisé pour parcourir l'arbre des routes API possibles. - POST - créer un objet. - PUT - mettre à jour un objet, l'identifiant de l'objet à mettre à jour est passé dans l'URI. - DELETE - supprimer un objet, l'identifiant de l'objet à supprimer est passé dans l'URI.

Le corps de la requête dans les requêtes POST / PUT doit être un JSON (généralement un objet), et la requête doit utiliser l'en-tête Content-Type: application/json.

Lorsque la taille du corps de la requête dépasse un certain seuil, nginx l'écrit dans un fichier temporaire. Cependant, l'implémentation de l'API du Media-Framework exige que le corps de la requête des requêtes POST / PUT soit disponible en mémoire. Si nécessaire, la directive client_body_buffer_size de nginx peut être utilisée pour augmenter la taille du tampon alloué pour le corps de la requête.

Requête Multi

La configuration d'un canal dans nginx-live-module peut nécessiter plusieurs appels API - créer le canal, créer une chronologie, créer une variante, etc. Afin d'éviter la pénalité de plusieurs allers-retours, la couche API prend en charge les requêtes "multi". Une requête multi regroupe plusieurs requêtes API en une seule requête HTTP.

Les requêtes multi doivent utiliser le verbe POST, et leur URI doit être définie sur /multi. Le corps de la requête doit être un tableau JSON d'objets, chaque objet représentant une seule requête API.

Les objets contiennent les champs suivants : - uri - chaîne, requise, le chemin API relatif. - method - chaîne, requise, le verbe HTTP de la requête - GET / POST / PUT / DELETE. - body - tout (généralement objet), optionnel, le corps des requêtes POST / PUT.

La réponse des requêtes multi est également un tableau JSON d'objets. Le nombre d'éléments dans le tableau de réponse correspond toujours au nombre d'éléments dans le tableau de requête, et l'ordre des objets dans le tableau de réponse correspond à l'ordre dans le tableau de requête. En d'autres termes, le N-ième élément du tableau de réponse est la réponse de la N-ième requête dans le tableau de requête.

Chaque objet de réponse contient les champs suivants : - code - entier, requis, le code de statut HTTP - body - tout (généralement objet / tableau), optionnel, le corps de la réponse

GitHub

Vous pouvez trouver des conseils de configuration supplémentaires et de la documentation pour ce module dans le dépôt GitHub pour nginx-module-live-common.