MPTS Migrate Perfect Streamer Toolkit v1.1 — Migration der MPTS-Identität

Teil des Perfect Streamer Toolkit — https://pstreamer.tv

Erfasst die DVB-SI/PSI-Identität eines laufenden Mehrprogramm-MPEG-TS-Stroms (MPTS) und bildet sie auf einer Perfect-Streamer-Instanz (PSS) auf demselben Host nach. Ergebnis: Teilnehmerempfänger (STB / TV) arbeiten nach einer Migration oder einer Umschaltung auf die Reserve ohne erneuten Kanalsuchlauf weiter.

Das Werkzeug ist Bestandteil des Pakets pstreamer und befindet sich nach der Installation unter /opt/pss/tools/mpts_migrate — eine separate Installation ist nicht erforderlich.

Voraussetzungen

Stellen Sie vor dem Start des Dienstprogramms sicher, dass:

  • PSS läuft auf demselben Host (oder auf einem über --pss-base erreichbaren Host). Das Dienstprogramm sucht pss in /proc und liest pss.json, um den Admin-Port zu ermitteln (43971, wenn die Konfiguration ihn nicht enthält).

  • Die MPTS-Quelle ist erreichbar, sofern eine Erfassung vorgesehen ist (Modi 1, 2, save+apply): Die als Positionsargument <input> übergebene URL muss einen MPEG-TS-Strom liefern. Für UDP-Multicast müssen IGMP / Firewall den Empfang zulassen; bei Dateien muss der Pfad vorhanden sein.

  • Das Ziel-MPTS ist in PSS bereits eingerichtet: Das Dienstprogramm legt keine neuen Streams an. Das MPTS-Objekt und mindestens so viele SPTS-Feeder, wie das Inventar Dienste enthält, müssen vorab vorhanden sein. Dienste ohne freien Feeder werden im Dialog angezeigt und können übersprungen werden.

  • Die HTTP-Admin-API ist auf localhost verfügbar — zum Lesen von /data/stream (wird bei verify verwendet) und zum Schreiben von /config/stream (apply).

Was migriert wird

Alle für den Empfänger sichtbaren Kennungen auf Transportstrom- und Dienstebene:

  • Transportstrom: TSID, ONID, network ID, network name, provider name (wird als mux-weiter sdt-provider-name angewendet, sofern alle Quelldienste ein und denselben Wert aufweisen), Delivery-Deskriptor (Parameter der terrestrischen / Kabel- / Satellitenübertragung), PAT/SDT/NIT-Versionen

  • Je Dienst: service_id, pmt_pid, pcr_pid, service_type, Dienstname, logische Kanalnummer (LCN), free-CA-Kennzeichen, EIT-present- / EIT-schedule-Kennzeichen

  • Elementarströme: PIDs (es wird ein identity remap angewendet — siehe Einschränkungen), Stromtypen, Sprachkennungen

  • Bedingter Zugriff: CA-Deskriptoren auf Programm- und ES-Ebene

Dienst- / Anbieternamen in DVB-Zeichenkodierungen außerhalb von ASCII (zum Beispiel ISO-8859-5 für Kyrillisch) werden automatisch nach UTF-8 dekodiert.

Für jeden Dienst wird das ES-PID-Remapping als Identitätspaare (mpegts-pid-old ≡ mpegts-pid-new) für jede PCR- / Video- / Audio- / Teletext- / Daten-PID aufgebaut, sodass die ursprünglichen PIDs in der resultierenden multiplexierten Ausgabe byte-exact erhalten bleiben. Ältere Empfänger, die die PMT nach dem ersten Suchlauf zwischenspeichern, arbeiten ohne Neukonfiguration weiter.

Ab PSS 2.0.0.193 aktiviert der Plan am Muxer-Eingang des Ziel-MPTS zusätzlich den regulären Modus zur Beibehaltung der ursprünglichen PIDs (deaktiviertes Automatic PID mapping) und setzt für jeden Dienst die erfasste Programmnummer in der PAT (program order) — die On-Air-Reihenfolge der Programme übersteht die Migration. Die Unterstützung wird anhand der Konfiguration des Ziel-Streamers automatisch ermittelt; auf älteren Versionen werden diese Schlüssel nicht gesendet (das Dienstprogramm gibt eine Warnung aus), und die Identitätspaare bleiben der einzige Mechanismus zur Fixierung der PIDs, während die Programmreihenfolge in der PAT nicht erhalten bleibt.

Anwendungsfälle

  • Failover: Umschalten der Decoder vom primären MPTS auf das Reserve-MPTS unter Beibehaltung der Kanäle auf der Empfängerseite

  • Hardware-Migration: Umzug eines laufenden Multiplex von einem PSS-Host auf einen anderen ohne Anweisungen an die Zuschauer

  • Momentaufnahme vor / nach dem Update: Erfassung des Multiplex vor dem PSS-Upgrade und erneutes Anwenden danach, um bitidentische SI/PSI zu gewährleisten

  • Manuelle Bearbeitung und erneutes Anwenden: Erfassen, migrate.json bearbeiten (Dienste umbenennen, LCN ändern, service_type anpassen), erneut anwenden

  • Dry-run-Prüfung: Ausgabe jedes HTTP POST, der gesendet würde, ohne Auswirkung auf PSS

Schnellstart

# Capture from a live stream and apply to local PSS in one run
mpts_migrate udp://239.1.1.1:1234

# Capture, save to migrate.json and apply
mpts_migrate -s udp://239.1.1.1:1234

# Capture only — write to file, do not apply
mpts_migrate -o backup.json udp://239.1.1.1:1234

# Apply a previously saved JSON
mpts_migrate -i backup.json

# No arguments — load ./migrate.json and apply
mpts_migrate

# Preview what apply would do, without changes
mpts_migrate -i backup.json --dry-run

Arbeitsablauf

  1. Erfassung — das Dienstprogramm öffnet den Strom, wertet PAT / PMT / SDT / NIT / EIT über -t Sekunden aus (Vorgabe 30) und erstellt das Inventar; die Gesamtbitrate des Stroms wird gemessen.

  2. (Optional) Speichern — mit -s oder -o wird das Inventar zur Wiederverwendung als JSON geschrieben.

  3. PSS-Ermittlung — erkennt das laufende PSS über einen /proc-Scan und liest pss.json, um den Admin-Port zu ermitteln (43971, wenn die Konfiguration ihn nicht enthält); --pss-base http://host:port umgeht die automatische Ermittlung.

  4. Bestätigung der Zuordnung — ein interaktiver Dialog fragt ab, wie jeder erfasste Dienst einem vorhandenen SPTS-Feeder zugeordnet werden soll; --non-interactive übernimmt die Vorschläge und bricht bei einem Konflikt ab; --target-mpts <id> überspringt die Abfrage zur MPTS-Auswahl.

  5. Automatisches Aufheben der Feeder-Pause — für jeden zugeordneten SPTS / muxer-output sendet das Dienstprogramm {"pause":false}, falls der Feeder pausiert war, damit der Multiplexer nach dem Apply tatsächlich Daten erhält.

  6. Automatische Bitratenanpassung — überschreitet captured_bitrate × (1 + headroom%) die mpegts-output-bitrate des Ziel-MPTS, hebt das Dienstprogramm dieses Limit auf PSS mit einem einzigen POST an (mit Aufrundung auf die nächsten 1000 kbps). Abschaltbar über --no-bitrate-adjust.

  7. Planung — vergleicht das Inventar mit dem aktuellen /config/stream-Baum auf PSS und bereitet HTTP-POST-Anfragen nur für die abweichenden Felder vor. Das ES-PID-Remapping wird als Identitätspaare (mpegts-pid-old ≡ mpegts-pid-new) erzeugt, damit die multiplexierte Ausgabe jede ursprüngliche PID unverändert beibehält — einschließlich PCR, Video, Audio, Teletext, SCTE-35, DSM-CC. Ab PSS 2.0.0.193 aktiviert der Plan zusätzlich den Modus zur Beibehaltung der ursprünglichen PIDs am Muxer-Eingang des Ziels und setzt die Programmreihenfolge in der PAT (siehe Was migriert wird).

  8. Anwenden — sendet die geplanten POST-Anfragen und schaltet anschließend das MPTS auf pause/unpause, damit PSS die Konfiguration neu einliest; mit --dry-run wird der Plan lediglich ausgegeben.

  9. Verify (standardmäßig aktiviert, auch bei leerem Plan) — erfasst das resultierende MPTS über einen der UDP-Ausgänge von PSS und vergleicht es mit dem Ziel; kritische Abweichungen (TSID, ONID, service_id, name, type, LCN) → Exit-Code 5.

Ein erneuter Durchlauf der gesamten Verarbeitungskette ist idempotent: Der zweite Lauf meldet no changes needed, wenn PSS bereits dem Inventar entspricht, und verify bestätigt dies mit einer neuen Erfassung.

CLI-Optionen

Modusauswahl

Option

Beschreibung

Standard

-f, --file <path>

Pfad zum Migrations-JSON (dient als Standardimport, wenn -i fehlt, und als Speicherziel mit -s)

./migrate.json

-s, --save

Erfasstes Inventar in die Migrationsdatei speichern (kombinierbar mit einem Stromeingang; apply wird dennoch ausgeführt)

—

-o, --output <file>

Nur Erfassung: Schreiben in die Datei, kein apply

—

-i, --input <file>

Nur apply: Datei laden, keine Erfassung

—

Erfassung

Option

Beschreibung

Standard

-t, --time <sec>

Maximale Erfassungsdauer

30

-b, --bitrate <Mbps>

Hinweis zur TS-Bitrate für das Pacing im Dateimodus

38.8

Apply / Verify

Option

Beschreibung

Standard

--target-mpts <id>

Abfrage zur MPTS-Auswahl überspringen; auf diese stream id auf PSS anwenden

—

--non-interactive

Vorschläge des Dialogs automatisch übernehmen; bei einem Konflikt beenden

—

--dry-run

Plan der POSTs ausgeben, nichts senden

—

--pss-base <url>

Automatische PSS-Ermittlung überschreiben (zum Beispiel http://host:8808)

automatisch

--no-verify

Erfassung und Diff nach dem Apply überspringen

verify aktiviert

--verify-time <s>

Erfassungsfenster für die Verifikation

10

--no-bitrate-adjust

mpegts-output-bitrate am Ziel-MPTS nicht anheben

Anhebung aktiviert

--bitrate-headroom <pct>

Bitratenreserve über dem gemessenen Wert bei der Anpassung

15

Sonstiges

Option

Beschreibung

-v, --verbose

Ausführliches Protokoll (jeder HTTP POST und jeder Dialogzweig)

-h, --help

Hilfe anzeigen und beenden

Migrationsdatei (migrate.json)

Menschenlesbares JSON mit format_version: 1. Die Standardablage ist ./migrate.json; sie wird mit -f überschrieben. Beispiel für den Aufbau:

{
  "format_version": 1,
  "tool": "mpts_migrate",
  "capture": {
    "source": "udp://239.1.1.1:1234",
    "captured_at_utc": "2026-04-30T08:15:00Z",
    "duration_s": 8.2,
    "packets": 109344
  },
  "transport_stream": {
    "transport_stream_id": 1234,
    "original_network_id": 8442,
    "network_name": "Operator",
    "delivery": { "type": "terrestrial", "frequency_khz": 522000 }
  },
  "services": [
    {
      "service_id": 1, "pmt_pid": 256, "pcr_pid": 256,
      "service_type": 1, "service_name": "Channel 1",
      "provider_name": "MyProvider", "logical_channel_number": 101,
      "program_order": 1,
      "free_ca_mode": false,
      "elementary_streams": [
        { "pid": 256, "stream_type": 27, "language": "rus" }
      ]
    }
  ]
}

Die Datei kann vor einem erneuten Apply bearbeitet werden: Dienste umbenennen, LCN ändern, service_type wechseln, network_name anpassen — mpts_migrate -i migrate.json sendet nur die geänderten Felder.

Verbindung zu PSS

  • Automatische Ermittlung: Durchsuchen von /proc/<pid>/comm nach pss, Lesen der zugehörigen --config-Datei, Übernahme von web-server.bind-port (43971, wenn der Schlüssel fehlt).

  • Manuell: --pss-base http://host:port umgeht die automatische Ermittlung vollständig. Nützlich für ein entferntes PSS oder wenn --dry-run einen Plan ohne laufendes PSS erstellen soll.

  • Die Admin-REST-API erfordert auf localhost keine Authentifizierung.

Verifikation

Wenn --no-verify nicht angegeben ist (Vorgabe), führt das Dienstprogramm nach dem Anwenden des Plans Folgendes aus:

  1. Sucht am Ziel-MPTS einen UDP-Ausgang auf localhost oder fügt vorübergehend einen auf 127.0.0.1:<auto> hinzu (mit dem Vermerk added by mpts_migrate for verification).

  2. Erfasst das laufende MPTS über diesen Ausgang für --verify-time Sekunden (Vorgabe 10).

  3. Vergleicht das erfasste Inventar mit dem Ziel:

    • Kritische Abweichung (TSID, ONID, network name, service_id, name, type, LCN) → Exit-Code 5.

    • Weiche Abweichung (PMT PID, Anzahl der ES, Anbietername, Programmreihenfolge in der PAT) → wird als Warnung ausgegeben, Exit-Code 0.

  4. Ist das Ziel-MPTS überlastet (Ausgangsbitrate ≥ der konfigurierten mpegts-output-bitrate), wird WARNING: target MPTS is overloaded ausgegeben — siehe Bitrate adjust weiter unten.

Dry-run

--dry-run gibt jede HTTP-Anfrage aus, die das Dienstprogramm senden würde (Pfad, JSON-Rumpf), sendet jedoch keine davon. Nützlich für:

  • Die Durchsicht des Plans mit dem Bediener vor der Übernahme.

  • Die Erzeugung reproduzierbarer Änderungssätze in CI / Change-Management.

  • Den Betrieb bei nicht erreichbarem PSS (zu kombinieren mit --pss-base http://host:port).

Dry-run startet keine Verifikation.

Bitrate adjust

Überschreitet captured_bitrate × (1 + headroom%) standardmäßig die mpegts-output-bitrate des Ziel-MPTS, hebt das Dienstprogramm dieses Limit auf PSS an, bevor die SI/PSI-Änderungen angewendet werden. Ohne ausreichende Reserve verliert ein überlastetes MPTS Daten niedriger Priorität — typische Symptome sind Tonaussetzer bei Radiodiensten und sporadische EIT-CRC-Fehler. Abschaltbar über --no-bitrate-adjust; die Reserve wird über --bitrate-headroom <pct> eingestellt (Vorgabe 15).

Exit-Codes

Code

Bedeutung

0

Erfolg — apply und (sofern aktiviert) die Verifikation sind fehlerfrei durchgelaufen. Wird auch von einem erfolgreichen --dry-run zurückgegeben.

1

Fehler bei Argumenten / Datei / Ermittlung

2

In der Quelle wurde keine PAT gefunden — der Eingang ist kein gültiger MPEG-TS oder das Erfassungsfenster ist zu kurz; wird auch zurückgegeben, wenn der Bediener die Bestätigung der Zuordnung abgelehnt oder den Dialog verlassen hat (apply abgebrochen)

3

Ein oder mehrere HTTP POSTs des Apply sind fehlgeschlagen

4

Apply war erfolgreich, das Ziel-MPTS ist jedoch nicht in den Zustand Running zurückgekehrt

5

Die Verifikation ist fehlgeschlagen — der erfasste Strom weicht in kritischen Feldern vom Ziel ab

Einschränkungen und Fallstricke

  • PSS muss das Ziel-MPTS und die Feeder bereits vorhalten: Das Dienstprogramm legt keine neuen Streams an. Das Ziel-MPTS und mindestens so viele SPTS-Feeder, wie das Inventar Dienste enthält, müssen vorab vorhanden sein; Dienste ohne freien Feeder werden im Dialog übersprungen.

  • Die MPTS-Quelle muss während der Erfassung erreichbar sein (Modi 1, 2, save+apply): Die als Positionsargument <input> übergebene URL muss einen MPEG-TS-Strom liefern; für UDP-Multicast müssen IGMP / Firewall dies zulassen.

  • Das ES-PID-Remapping wird automatisch angewendet: Für jeden Dienst wird ein Identity-Remap (mpegts-pid-old ≡ mpegts-pid-new) für jede PCR-/Video-/Audio-/Teletext-/Daten-PID erzeugt, damit die multiplexierte Ausgabe die ursprünglichen PIDs byte-exact beibehält. Das PMT-Layout bleibt von Migration zu Migration stabil — selbst ältere Empfänger (STB vor 2015, Samsung vor der H-Serie, LG vor WebOS 3.0), die PIDs zwischenspeichern, benötigen keinen erneuten Suchlauf.

  • Der Delivery-Deskriptor muss dem tatsächlichen Übertragungsweg entsprechen — für Empfänger, die sich über die NIT neu abstimmen (DVB-T/T2/C/S). Ein nicht passender delivery-Block kann den Empfänger auf eine falsche Frequenz führen.

  • Die Konsistenz der LCN zwischen primärem und Reserve-MPTS ist für Failover entscheidend — unterscheiden sie sich, verschieben sich die Kanalpositionen in der Empfängerliste nach der Umschaltung.

  • Der Provider name ist in PSS mux-weit gültig (ein sdt-provider-name je MPTS-Muxer-Eingang). Das Dienstprogramm wendet ihn automatisch an, wenn alle erfassten Dienste ein und denselben Wert aufweisen; tragen verschiedene Dienste unterschiedliche provider_name-Werte, wird eine Warnung ausgegeben und das Feld bleibt unberührt — die Entscheidung liegt beim Bediener.

  • Kein PSS-Konfigurationswerkzeug: mpts_migrate berührt ausschließlich die SI/PSI-Identitätsfelder, das pause-Kennzeichen jedes Feeders, (optional) mpegts-output-bitrate sowie ab PSS 2.0.0.193 die Schlüssel für den PID-Beibehaltungsmodus und die Programmreihenfolge. Encoder, Eingänge, Verschlüsselung, Zeitpläne und Ähnliches konfiguriert es nicht.

  • Auf PSS älter als 2.0.0.193 werden der Modus zur Beibehaltung der ursprünglichen PIDs am Muxer und die Programmreihenfolge in der PAT nicht unterstützt: Das Dienstprogramm gibt eine Warnung aus, die PIDs werden allein durch Identitätspaare fixiert, und die Programmreihenfolge kann nach der Migration von der ursprünglichen abweichen.

Fehlerdiagnose

Symptom

Wahrscheinliche Ursache / Abhilfe

Error: no PAT seen in stream

Die Quelle ist kein MPEG-TS, IGMP/Firewall blockiert den Multicast, oder -t ist zu kurz

Error: cannot reach PSS

--pss-base http://host:port verwenden, um die automatische Ermittlung zu umgehen

Apply war erfolgreich, das MPTS bleibt jedoch pausiert

Das PSS-Protokoll prüfen; mit -v erneut starten, um den vollständigen Plan der POSTs zu sehen

Die Verifikation meldet eine kritische Abweichung

Ziel und erfassten Strom im JSON vergleichen; meist wurde ein Feeder im Dialog dem falschen Dienst zugeordnet

WARNING: target MPTS is overloaded

mpegts-output-bitrate auf PSS anheben oder --bitrate-headroom <higher %> verwenden; ohne Reserve werden das Audio der Radiodienste und die PSI-Tabellen beschädigt