live-common: Kaltura Media Framework Gemeinsames NGINX-Modul

Installation

Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:

RedHat Enterprise Linux 7, 8, 9 und 10
CentOS 7, 8, 9
AlmaLinux 8, 9
Rocky Linux 8, 9
Amazon Linux 2 und Amazon Linux 2023

CentOS/RHEL 8+, Fedora Linux, Amazon Linux 2023+CentOS/RHEL 7 und Amazon Linux 2

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

Aktivieren Sie das Modul, indem Sie Folgendes an den Anfang von /etc/nginx/nginx.conf hinzufügen:

load_module modules/ngx_http_api_module.so;

Dieses Dokument beschreibt nginx-module-live-common v2.0.6 veröffentlicht am 13. November 2025.

Ein verteiltes Framework für Live-Video-Streaming. Das System besteht aus mehreren Komponenten, von denen jede für eine spezifische Funktion verantwortlich ist.

Die Komponenten können auf einem einzelnen Server für kleine Bereitstellungen/Tests bereitgestellt werden, es wird jedoch empfohlen, sie separat bereitzustellen, um eine optimalere Ressourcennutzung zu erreichen. Zum Beispiel kann der Transcoder die GPU nutzen, daher wäre es kosteneffizienter, die Transcoder auf GPU-fähigen Servern bereitzustellen, während die anderen Komponenten auf Servern ohne GPU laufen.

Medien werden zwischen den verschiedenen Komponenten intern unter Verwendung benutzerdefinierter Protokolle übertragen - 1. Kaltura Media Protocol (KMP) - ein TCP-basiertes Protokoll zur Bereitstellung von Streaming-Medien, konzeptionell ähnlich zu einem einzelnen Track von fMP4/MPEG-TS 2. Kaltura Segmented Media Protocol (KSMP) - ein HTTP-basiertes Protokoll zur Bereitstellung von Medien in Segmenten, konzeptionell ein Superset von LLHLS/DASH

Die Orchestrierung der verschiedenen Medienkomponenten erfolgt durch einen "Controller". Die Hauptverantwortung des Controllers besteht darin, die Topologie der Medienpipeline zu erstellen und sie im Falle von Fehlern zu aktualisieren. Der Controller erhält JSON-Ereignisse von den Medienkomponenten, die als HTTP-POSTs gesendet werden. Darüber hinaus stellen alle Medienverarbeitungs-Komponenten eine JSON-basierte REST-API bereit, die vom Controller verwendet wird, um den aktuellen Status abzurufen und Maßnahmen zu ergreifen. Eine Beispielimplementierung des Controllers für einen All-in-One-Server ist im conf Ordner enthalten.

Hauptmerkmale

Veröffentlichungsprotokolle: RTMP, MPEGTS (über SRT/HTTP/TCP)
Wiedergabeprotokolle: HLS/LLHLS, DASH
Live-Push/Relay-Protokolle: RTMP
Video-/Audio-Transcodierung - einschließlich GPU-Unterstützung, basierend auf der ffmpeg-API
Persistenz - in S3 (oder kompatibler) Objektspeicherung
Adaptive Bitrate-Auslieferung
Untertitelunterstützung - einschließlich Konvertierung von 608/708 zu WebVTT
Alternative Audiospuren
Medienverschlüsselung und DRM
Video-Frame-Erfassung

Erste Schritte

Der conf Ordner enthält Beispielcode und Konfiguration für den Betrieb eines All-in-One-Servers.

Glossar

Channel - ein Container, der einen Live-Stream darstellt, kann Tracks, Varianten, Zeitlinien usw. enthalten.
Track - eine einzelne Wiedergabe von Video/Audios/Untertitel. Zum Beispiel kann ein Kanal 3 Video-Tracks haben: 1080p, 720p, 540p.
Variant - eine Gruppierung von Tracks, die für das Packaging verwendet wird. Varianten bestimmen, welcher Audiotrack mit jedem Videotrack gekoppelt wird, wenn muxed Segmente verwendet werden. Eine Variante kann auf mehrere Tracks verweisen, jedoch nicht mehr als einen Track pro Medientyp. Tracks müssen Varianten zugeordnet sein, um über HLS/DASH bereitgestellt zu werden.
Segment - eine Gruppe von Frames eines bestimmten Tracks. Segmente sind immer unabhängig - Video-Segmente beginnen immer mit einem Key/IDR-Frame.
Segmentindex - eine Nummer, die die Segmente der verschiedenen Tracks identifiziert, die mit einem bestimmten Zeitintervall verbunden sind.
Periode - eine Menge von Segmentindizes, die kontinuierlich abgespielt werden können.
Timeline - eine Menge von Perioden. Es können mehrere Zeitlinien erstellt werden, jede mit ihrem eigenen Satz von Perioden. Zeitlinien können beispielsweise verwendet werden, um einen "Vorschau-Modus" zu implementieren - der Publisher konsumiert eine Zeitlinie, während die Zuschauer eine andere konsumieren. Die Zeitlinie des Publishers ist immer aktiv, während die Zeitlinie der Zuschauer nach Ermessen des Publishers aktiviert wird.

Beispieltopologien

Die folgenden Diagramme zeigen einige Beispieltopologien, die mit den Komponenten des Media-Frameworks erstellt werden können.

Einfacher RTMP-Passthrough

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

Passthrough + S3-Persistenz

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

SRT-Eingang + Video-Transcodierung

flowchart LR;
    enc(Encoder);
    ingest(nginx-mpegts-kmp-module);
    srt(nginx-srt-module);
    trans(transcoder);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|SRT|srt;
    srt-->|MPEG-TS|ingest;
    ingest-->|KMP video|trans;
    trans-->|KMP video|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Dekodierung von Untertiteln

flowchart LR;
    enc(Encoder);
    ingest(nginx-rtmp-kmp-module);
    cc(nginx-cc-module);
    live(nginx-live-module);
    pckg(nginx-pckg-module);
    play(Player);
    enc-->|RTMP|ingest;
    ingest-->|KMP video|cc;
    cc-->|KMP subtitle|live;
    ingest-->|KMP video|live;
    ingest-->|KMP audio|live;
    live-->|KSMP|pckg;
    pckg-->|LLHLS/DASH|play;

Transcodierung + RTMP-Push

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

Komponentenübersicht

Medienkomponenten

nginx-rtmp-kmp-module - Live-Medienaufnahme, Eingabe: RTMP, Ausgabe: KMP x N
nginx-mpegts-kmp-module - Live-Medienaufnahme, Eingabe: MPEG-TS über TCP/HTTP, Ausgabe: KMP x N
transcoder - Video-/Audio-Transcodierung, Eingabe: KMP, Ausgabe: KMP x N
nginx-live-module - Live-Medien-Segmentierer, Eingabe: KMP x N, Ausgabe: KSMP

Zusätzliche Funktionen: Persistenz, Füller, Unterstützung für Zeitlinien.
nginx-pckg-module - Live-Medienpackager (zustandslos), Eingabe: KSMP, Ausgabe: HLS/LLHLS, DASH

Zusätzliche Funktionen: adaptive Bitrate, Untertitel, alternative Audiospuren, Medienverschlüsselung / DRM, Video-Frame-Erfassung
nginx-kmp-cc-module - Decoder für Closed-Captions, Eingabe: KMP video (h264/5), Ausgabe: KMP subtitle (WebVTT) x N
nginx-kmp-rtmp-module - Live-Medien-Relay, Eingabe: KMP x N, Ausgabe: RTMP

Wichtig: Alle zustandsbehafteten nginx-basierten Komponenten (=alle außer nginx-pckg-module) müssen auf einem einzelnen Prozess-nginx-Server bereitgestellt werden (worker_processes 1;). Der Modulstatus wird pro Prozess gespeichert, und wenn mehrere Prozesse verwendet werden, ist es nicht möglich zu steuern, welcher Prozess die Anfrage erhält. Zum Beispiel kann die Anfrage zur Erstellung eines Kanals auf dem Segmentierer bei Worker 1 ankommen, während die KMP-Verbindung mit den tatsächlichen Medien Worker 2 trifft. In Bereitstellungen, die Container verwenden, sollte dies kein Problem sein - mehrere Container können auf einem einzelnen Server bereitgestellt werden, anstatt mehrere nginx-Prozesse zu verwenden. Eine andere Möglichkeit besteht darin, einen Patch wie arut's per-worker listener zu verwenden, aber es wird wahrscheinlich aktualisiert werden müssen, um auch auf stream-Verbindungen anzuwenden.

Debug-Optionen

Einige der Media-Framework-Komponenten unterstützen optionale Präprozessor-Makros zu Debugging-Zwecken - - NGX_LBA_SKIP (nginx-common) - Überspringt die Verwendung des "Large Buffer Array" (LBA) Moduls. Wenn aktiviert, werden LBA-Zuweisungen an ngx_alloc / ngx_free weitergeleitet. - NGX_RTMP_VERBOSE (nginx-rtmp-module) - Aktiviert zusätzliche Debug-Protokollnachrichten - NGX_LIVE_VALIDATIONS (nginx-live-module) - Aktiviert Laufzeit-Konsistenzprüfungen auf internen Datenstrukturen, standardmäßig aktiviert, wenn --with-debug verwendet wird - NGX_BLOCK_POOL_SKIP (nginx-live-module) - Überspringt die Verwendung von Block-Pools. Wenn aktiviert, werden Block-Pool-Zuweisungen an ngx_palloc / ngx_pfree weitergeleitet.

Um die Module mit valgrind zu testen, wird empfohlen, den no-pool-nginx Patch anzuwenden, und nginx mit --with-cc-opt="-O0 -DNGX_BLOCK_POOL_SKIP -DNGX_LBA_SKIP" und --with-debug zu konfigurieren.

Kaltura Media Protocol (KMP)

Kaltura Media Protocol ist ein einfaches paketbasiertes Protokoll zum Streaming von Medien über TCP. Eine KMP-Verbindung kann die Medien eines einzelnen Video-/Audio-/Untertitel-Tracks bereitstellen - wenn mehrere Tracks benötigt werden, werden mehrere TCP-Verbindungen hergestellt.

Jedes Paket beginnt mit einem Header, der die folgenden Felder enthält (jeweils 32 Bit) - - Type - der Typ des Pakets. Die Pakettypen sind vierstellige Codes, siehe unten die Liste der derzeit definierten Typen. - Header size - die Größe des Paket-Headers, muss zwischen sizeof(kmp_packet_header_t) und 64KB liegen. Parser müssen die Headergröße verwenden, um auf die Daten des Pakets zuzugreifen, dies ermöglicht die Hinzufügung neuer Felder zu Paket-Headern, ohne bestehende Parser zu brechen. - Data size - die Größe der Paketdaten, muss zwischen 0 und 16MB liegen. - Reserved - für zukünftige Verwendung reserviert, muss auf 0 gesetzt werden.

Die in KMP verwendeten Strukturen und Konstanten finden Sie in ngx_live_kmp.h.

KMP Frame-IDs

Eine Frame-ID ist eine 64-Bit-Ganzzahl, die ein Eingangsframe eindeutig identifiziert. Die Eingangs-Module (nginx-rtmp-kmp-module / nginx-mpegts-kmp-module) weisen die anfängliche Frame-ID gemäß der Serveruhr (in Zeitskalen-Einheiten) zu, wenn ein Ausgangs-Track erstellt wird. Um die Notwendigkeit zu vermeiden, die Frame-ID für jedes gesendete Frame zu senden, sind die Frame-IDs in KMP sequenziell - die ID des N-ten Frames, der über eine KMP-Verbindung gesendet wird, ist initial_frame_id + N.

Wenn die Eingangsverbindung (z. B. RTMP) abbricht und wiederhergestellt wird, werden neue KMP-Frame-IDs zugewiesen. Da die Standard-Zeitskala hoch ist (90 kHz) und die Bildrate wahrscheinlich 60 fps nicht überschreiten wird, wird die anfängliche Frame-ID deutlich höher sein als die Frame-ID, die in der vorherigen Verbindung zuletzt gesendet wurde. Es ist also äußerst unwahrscheinlich, dass es zu Konflikten mit zuvor verwendeten Frame-IDs aufgrund einer Wiederverbindung kommt.

Frame-IDs werden verwendet: - Um zu identifizieren, welche Frames in KMP-Ack-Paketen bestätigt werden - Um zuvor verarbeitete Frames zu überspringen, wenn eine KMP-Verbindung wiederhergestellt wird

Der Transcoder fügt einige Komplexitäten zur Verwaltung von Frame-IDs hinzu - - Da der Transcoder die Eingangsbildrate ändern oder Frames verwerfen kann, sind die Frame-IDs im Transcoder-Eingang nicht unbedingt die gleichen wie die Frame-IDs im Transcoder-Ausgang. Wenn der Transcoder neu gestartet wird, muss er wissen, welchen Wert er als initial_frame_id seines Upstream-Servers (normalerweise nginx-live-module) senden soll. Das Feld upstream_frame_id wird für diesen Zweck verwendet. - Der Transcoder kann so konfiguriert werden, dass er die Abtastrate eines Audiotracks ändert, und in diesem Fall stimmen die transcodierten Frames nicht mit den Eingangsframes überein. Um dieses Szenario zu handhaben, muss der Transcoder die Fähigkeit haben, nur einen Teil eines Eingangsframes zu bestätigen. Dies ist der Zweck des Feldes offset - es kann beispielsweise die Anzahl der Audio-Samples speichern, die innerhalb des Frames bestätigt werden sollen. Die genaue Bedeutung des Feldes offset wird vom KMP-Empfänger bestimmt - der Empfänger setzt das offset in den Ack-Frames, die er zurückgibt, und erhält es im initial_offset-Feld des Verbindungs-Pakets zurück, im Falle einer Wiederverbindung.

Publisher KMP-Pakete

Die folgenden Abschnitte listen die KMP-Pakete auf, die von einem KMP-Publisher gesendet werden können.

Connect (`cnct`)

Wird sofort nach dem Herstellen der KMP-TCP-Verbindung gesendet.

Der Header enthält die folgenden Felder: - channel_id - Zeichenfolge, die Kanal-ID, die veröffentlicht wird. Die maximal erlaubte Länge beträgt 32 Zeichen. - track_id - Zeichenfolge, die Track-ID, die veröffentlicht wird. Die maximal erlaubte Länge beträgt 32 Zeichen. - initial_frame_id - Ganzzahl, die ID des ersten gesendeten Frames. - initial_upstream_frame_id - Ganzzahl, die anfängliche Frame-ID, die an den Upstream-Server gesendet werden soll (verwendet vom Transcoder) - initial_offset - Ganzzahl, der Offset, von dem aus innerhalb des anfänglichen Frames gestartet werden soll. - flags - Ganzzahl, eine Bitmaske von Flags, derzeit ist ein einzelnes Flag definiert - consistent - dieses Flag wird gesetzt, wenn der KMP-Publisher konsistente (bitgenaue) Ausgaben erzeugt, bei denselben Eingaben. nginx-rtmp-kmp-module und nginx-mpegts-kmp-module sind Beispiele für Publisher, die konsistent sind. Der Transcoder hingegen ist es nicht. Das consistent-Flag wird vom LL-Segmentierer im Falle einer Wiederverbindung verwendet. Wenn der Publisher konsistent ist, kann der LL-Segmentierer an dem Punkt fortfahren, an dem er aufgehört hat. Wenn der Publisher inkonsistent ist, kann der LL-Segmentierer nur vom nächsten GOP fortfahren - er darf kein partielles GOP von vor der Trennung mit dem GOP mischen, das nach der Trennung empfangen wurde.

Die Daten des Connect-Pakets sind optional, das erwartete Format der Daten wird vom spezifischen KMP-Empfänger definiert.

Media Info (`minf`)

Enthält die Parameter der Medien. Einige der Felder im Header werden von allen Medientypen gemeinsam genutzt, während die anderen nur für einen bestimmten Typ definiert sind (Union).

Die gemeinsamen Headerfelder sind: - media_type - Ganzzahl, der Typ der Medien - video / audio / subtitle, verwendet die KMP_MEDIA_XXX-Konstanten. - codec_id - Ganzzahl, die Codec-ID, verwendet die KMP_CODEC_XXX-Konstanten. - timescale - Ganzzahl, die Einheiten, die in den Feldern dts / pts_delay / created von Frame-Paketen verwendet werden, in Hz. - bitrate - Ganzzahl, die Bitrate, in Bits pro Sekunde.

Die videospezifischen Headerfelder sind: - width - Ganzzahl, die Breite des Videos, in Pixeln. - height - Ganzzahl, die Höhe des Videos, in Pixeln. - frame_rate - rational, die Bildrate des Videos, in Bildern pro Sekunde. - cea_captions - boolean, auf 1 gesetzt, wenn der Video-Track EIA-608 / CTA-708-Untertitel enthält.

Die audiobezogenen Headerfelder sind: - channels - Ganzzahl, die Anzahl der Audiokanäle. - bits_per_sample - Ganzzahl, die Größe der Audio-Samples, in Bits. - sample_rate - Ganzzahl, die Abtastrate des Audios, in Samples pro Sekunde. - channel_layout - Ganzzahl, eine Bitmaske von Kanalpositionen, verwendet die KMP_CH_XXX-Konstanten.

Die Daten des Media Info-Pakets enthalten die Codec-privaten/zusätzlichen Daten. Zum Beispiel, wenn der h264-Codec verwendet wird, enthalten die Daten den Körper eines avcC MP4-Box.

KMP-Empfänger sollten Änderungen an den Medieninformationen behandeln, z. B. eine Änderung der Videoauflösung. Der Typ der Medien (Video/Audio/Untertitel), die in einer KMP-Verbindung gesendet werden, darf sich jedoch nicht ändern.

KMP-Empfänger sollten Media Info-Pakete ignorieren, wenn sie identisch mit dem zuvor empfangenen Media Info-Paket sind.

Frame (`fram`)

Stellt ein einzelnes Video-Frame / Audio-Frame / Untertitel-Cue dar.

Der Frame-Header enthält die folgenden Felder: - created - Ganzzahl, die Zeit, zu der das Frame vom ersten Media-Framework-Modul in der Pipeline empfangen wurde, in Zeitskalen-Einheiten. - dts - Ganzzahl, der Decodierungszeitstempel des Frames, in Zeitskalen-Einheiten. Wenn der Medientyp subtitle ist, enthält er den Startzeitstempel des Cues. - flags - Ganzzahl, derzeit ist nur ein Flag definiert - key - aktiviert bei Video-Keyframes. - pts_delay - Ganzzahl, der Unterschied zwischen dem Präsentationszeitstempel des Frames und dem Decodierungszeitstempel, in Zeitskalen-Einheiten. Wenn der Medientyp subtitle ist, enthält er die Dauer des Cues - end_pts - start_pts.

Wenn der Medientyp Video / Audio ist, enthält die Daten des Frame-Pakets die komprimierten Medien. Wenn der Medientyp Untertitel ist und der Codec WebVTT ist, folgt die Daten des Frames dem WebVTT Sample Format, wie in ISO/IEC 14496-30 angegeben (gewöhnlich ist in diesem Fall ein Sample eine vttc-Box, die eine payl-Box enthält).

Null (`null`)

Wird gesendet, um "Lebendigkeit" zu signalisieren und zu verhindern, dass Leerlauf-Timer ablaufen. Null-Pakete tragen keine Daten außer dem grundlegenden KMP-Header. Parser müssen Null-Pakete ignorieren.

End Of Stream (`eost`)

Wird verwendet, um ein sanftes Ende der Veröffentlichungssitzung zu signalisieren. End-of-Stream-Pakete tragen keine Daten außer dem grundlegenden KMP-Header.

Receiver KMP-Pakete

Die folgenden Abschnitte listen die KMP-Pakete auf, die von einem KMP-Empfänger gesendet werden können.

Ack Frames (`ackf`)

Bestätigen den Empfang von Frames.

Der KMP-Empfänger entscheidet über den geeigneten Zeitpunkt, um ein Ack-Paket zu senden. Zum Beispiel, wenn die Persistenz aktiviert ist, sendet der Segmentierer ein Ack nur, nachdem ein Segment, das den Frame enthält, in den Speicher gespeichert wurde.

Einige Empfänger senden überhaupt keine Acks, in diesem Fall muss der KMP-Produzent so konfiguriert werden, dass die Frames nach dem Senden verworfen werden (unter Verwendung der resume_from-Einstellung).

Der Paket-Header enthält die folgenden Felder: - frame_id - Ganzzahl, die ID des ersten Frames, der erneut gesendet werden soll, wenn die Verbindung abbricht. Mit anderen Worten, ein Ack-Frames-Paket bestätigt alle Frames, die eine ID haben, die kleiner ist als frame_id. Wenn die KMP-Verbindung wiederhergestellt wird, wird dieser Wert im Feld initial_frame_id gesendet. - upstream_frame_id - Ganzzahl, die ID des Frames, der an den Upstream-Server gesendet wurde. Wenn die KMP-Verbindung wiederhergestellt wird, wird dieser Wert im Feld initial_upstream_frame_id gesendet. - offset - Ganzzahl, der Offset, der innerhalb des Frames bestätigt werden soll. Wenn die KMP-Verbindung wiederhergestellt wird, wird dieser Wert im Feld initial_offset gesendet. - padding - Ganzzahl, reserviert für zukünftige Verwendung, muss auf null gesetzt werden.

Die Daten der Ack-Pakete werden nicht verwendet.

Kaltura Segmented Media Protocol (KSMP)

Kaltura Segmented Media Protocol ist ein HTTP-basiertes Protokoll zur Bereitstellung von Medien in Segmenten, ähnlich wie HLS/DASH.

Eine KSMP-Anfrage ist eine HTTP GET-Anfrage, die folgenden Abfrageparameter sind definiert - - channel_id - erforderliche Zeichenfolge, die ID des Kanals - timeline_id - erforderliche Zeichenfolge, die ID der Zeitlinie - flags - erforderliche hexadezimale Ganzzahl, die Flags: - Wählt die Teilmenge der benötigten Daten aus (wie die Spaltenliste in einer SQL SELECT-Anweisung) - Steuert verschiedene Verhaltensweisen bei der Bearbeitung der Anfrage. Zum Beispiel gibt das 'nächste Schlüssel'-Flag nur den Schlüssel-Frame zurück, der dem Anfrage-Zeitstempel am nächsten ist, anstatt das gesamte Segment zurückzugeben. - variant_ids - optionale Zeichenfolge, wählt eine Teilmenge der Varianten aus, die zurückgegeben werden sollen, standardmäßig werden alle Varianten zurückgegeben. Wenn mehrere Varianten angegeben sind, sollten sie mit einem Bindestrich (-) getrennt werden. - media_type_mask - optionale hexadezimale Ganzzahl, legt die Medientypen fest, die zurückgegeben werden sollen, standardmäßig werden alle Medientypen zurückgegeben. - time - optionale Ganzzahl, der angeforderte Zeitstempel. Der Zeitstempel wird beispielsweise verwendet, um einen Video-Frame zu einem bestimmten Zeitpunkt zu erfassen. - segment_index - optionale Ganzzahl, der Index des Segments - max_segment_index - optionale Ganzzahl, die verwendet wird, um den Umfang der in der Antwort zurückgegebenen Segmente zu begrenzen. Dieses Parameter kann verwendet werden, um einen persistierten Stream zur Fehlersuche abzuspielen. - part_index - optionale Ganzzahl, der nullbasierte Index des Teilsegments innerhalb des Segments. Eine Anfrage, die part_index verwendet, muss auch segment_index senden. - skip_boundary_percent - optionale Ganzzahl, legt den Skip Boundary-Wert als Prozentsatz der Ziel-Dauer fest (siehe die Definition des Attributs CAN-SKIP-UNTIL in der HLS-Spezifikation für weitere Details) - padding - optionale Ganzzahl, fügt zusätzliche Nullbytes am Ende der Antwort hinzu. Wird verwendet, um den Anforderungen an die Auffüllung von ffmpeg zu entsprechen, ohne zusätzliche Kopieroperationen zu verursachen.

Eine KSMP-Antwort verwendet das KLPF-Format (siehe unten), mit dem Typ Serve (serv). Die KSMP-spezifischen Definitionen finden Sie in ngx_ksmp.h.

Kaltura Live Persist File (KLPF)

Kaltura Live Persist File ist ein Serialisierungs-Schema, das in KSMP-Antworten und in den von nginx-live-module erstellten S3-Objekten verwendet wird.

Ein KLPF besteht aus Blöcken, ähnlich wie MP4-Atome/Boxen. Jeder Block hat den folgenden Header - - id - ein vierstelliger Code, der den Block identifiziert - size - uint32, die vollständige Größe des Blocks (Header & Daten) - flags - 4 Bits, die folgenden Flags sind definiert: - container (0x1) - der Block enthält andere Blöcke - index (0x2) - der Block ist ein Index zu einem anderen Block, die Headergröße sollte nicht verwendet werden - compressed (0x4) - die Daten des Blocks sind zlib-komprimiert - header_size - 28 Bits, die Größe des Block-Headers. Parser müssen die Headergröße verwenden, um auf die Daten des Blocks zuzugreifen, sodass Felder zum Header hinzugefügt werden können, ohne die Kompatibilität zu brechen.

Eine KLPF-Datei ist ein Block, dessen ID auf klpf gesetzt ist. Nach den generischen Headerfeldern (die oben aufgeführt sind) hat eine KLPF-Datei die folgenden Felder in ihrem Header - - uncomp_size - uint32, hält die unkomprimierte Größe der Daten, wenn die KLPF-Daten komprimiert sind - version - uint32, die Version des Dateiformats. Die für neue Dateien verwendete Version wird bei jeder brechenden Änderung am Format aktualisiert, der Code wird aktualisiert, um entweder - sowohl das Lesen des neuen Formats als auch des alten Formats zu unterstützen oder - Dateien, die das alte Format verwenden, zu ignorieren - type - ein vierstelliger Code, der den Typ der in der KLPF gespeicherten Daten identifiziert. Der Typ bestimmt, welche Block-IDs unterstützt werden und deren interne Struktur. Der Typ serv (Serve) wird für KSMP-Antworten in der Kommunikation zwischen dem Packager und dem Segmentierer verwendet. Zusätzliche Typen werden intern vom Segmentierer verwendet. - created - uint64, der Unix-Zeitstempel, wann die KLPF erstellt wurde.

Für weitere Details zur internen Struktur von KLPF-Blöcken siehe KLFP-SPEC.md.

Um den Inhalt von KLPF-Objekten/KSMP-Antworten zu inspizieren, verwenden Sie klpf_parse.py. Das Skript kann die Blockstruktur ohne zusätzliche Informationen anzeigen, jedoch, um die Felder innerhalb der Blöcke zu parsen: - führen Sie generate_persist_spec.py aus und speichern Sie die Ausgabe in einer Datei - geben Sie den Dateinamen an klpf_parse.py unter Verwendung der Option -s / --spec-file an

API-Übersicht

Alle Medienverarbeitungs-Komponenten stellen eine JSON-basierte REST-API bereit. Dieser Abschnitt erklärt die allgemeinen Eigenschaften der Media-Framework-APIs. Für eine detaillierte Referenz der verfügbaren API-Endpunkte siehe die Dokumentation der spezifischen Module.

Anfragetypen

Die folgenden HTTP-Methoden werden in der API verwendet: - GET - den vollständigen Status des Moduls oder einen Teil davon abrufen. Das Argument ?pretty=1 kann zur Anfrage hinzugefügt werden, um die Antwort in einem "schönen" / eingerückten Format zurückzugeben. - GET mit ?list=1 - gibt die Namen der "Ordner" unter einem bestimmten Pfad in der API zurück. Kann verwendet werden, um den Baum möglicher API-Routen zu durchlaufen. - POST - ein Objekt erstellen. - PUT - ein Objekt aktualisieren, die ID des zu aktualisierenden Objekts wird in der URI übergeben. - DELETE - ein Objekt löschen, die ID des zu löschenden Objekts wird in der URI übergeben.

Der Anfragekörper in POST / PUT-Anfragen muss ein JSON (normalerweise ein Objekt) sein, und die Anfrage muss den Header Content-Type: application/json verwenden.

Wenn die Größe des Anfragekörpers einen bestimmten Schwellenwert überschreitet, schreibt nginx ihn in eine temporäre Datei. Die Implementierung der Media-Framework-API erfordert jedoch, dass der Anfragekörper von POST / PUT-Anfragen im Speicher verfügbar ist. Falls erforderlich, kann die nginx-Direktive client_body_buffer_size verwendet werden, um die Größe des für den Anfragekörper zugewiesenen Puffers zu erhöhen.

Multi-Anfrage

Das Einrichten eines Kanals im nginx-live-module kann mehrere API-Aufrufe erfordern - den Kanal erstellen, eine Zeitlinie erstellen, eine Variante erstellen usw. Um die Strafe mehrerer Rundreisen zu vermeiden, unterstützt die API-Schicht "Multi"-Anfragen. Eine Multi-Anfrage bündelt mehrere API-Anfragen in einer einzigen HTTP-Anfrage.

Multi-Anfragen müssen die POST-Methode verwenden, und ihre URI muss auf /multi gesetzt werden. Der Anfragekörper muss ein JSON-Array von Objekten sein, wobei jedes Objekt eine einzelne API-Anfrage darstellt.

Die Objekte enthalten die folgenden Felder: - uri - Zeichenfolge, erforderlich, der relative API-Pfad. - method - Zeichenfolge, erforderlich, das HTTP-Verb der Anfrage - GET / POST / PUT / DELETE. - body - beliebig (normalerweise Objekt), optional, der Körper von POST / PUT-Anfragen.

Die Antwort von Multi-Anfragen ist ebenfalls ein JSON-Array von Objekten. Die Anzahl der Elemente im Antwort-Array entspricht immer der Anzahl der Elemente im Anfrage-Array, und die Reihenfolge der Objekte im Antwort-Array entspricht der Reihenfolge im Anfrage-Array. Mit anderen Worten, das N-te Element des Antwort-Arrays ist die Antwort der N-ten Anfrage im Anfrage-Array.

Jedes Antwortobjekt enthält die folgenden Felder: - code - Ganzzahl, erforderlich, der HTTP-Statuscode - body - beliebig (normalerweise Objekt / Array), optional, der Antwortkörper

GitHub

Sie finden möglicherweise zusätzliche Konfigurationstipps und Dokumentationen für dieses Modul im GitHub Repository für nginx-module-live-common.