Verfahren zum Einrichten redundanter Manifeste - MediaLive
Ergebnisse dieser Einrichtung

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verfahren zum Einrichten redundanter Manifeste

Um redundante Manifeste einzurichten, aktivieren Sie die Funktion in der Ausgabegruppe. Außerdem nehmen Sie Anpassungen an der Gestaltung der Ausgabenamen und Zielpfade vor (im Vergleich zu HLS-Ausgaben, bei denen keine redundanten Manifeste implementiert wird).

Das folgende Feld bezieht sich speziell auf redundante Manifeste:

  • Feld HLS output group – Manifests and Segments – Redundant manifests (HLS-Ausgabegruppe – Manifeste und Segmente – Redundante Manifeste)

So richten Sie redundante Manifeste ein

  1. Schauen Sie im nachgelagerten System nach, ob redundante Manifeste unterstützt werden.

  2. Lesen Sie die Informationen in Felder für das Ausgabeziel — Senden an einen HTTP Server. Manifeste gelten als Ausgabe von MediaLive. Daher gelten die allgemeinen Regeln über Ausgabeziele für redundante Manifeste.

  3. Planen Sie die URLs für die beiden Pipelines. Die URLs der HLS-Dateien unterliegen speziellen Anforderungen. Lesen Sie den entsprechenden Abschnitt:

    Diese Regeln ergänzen die Informationen in Felder für das Ausgabeziel — Senden an einen HTTP Server.

  4. Wenn Sie auch benutzerdefinierte Pfade für Manifeste benötigen, sollten Sie unbedingt die Informationen in Funktionsweise von benutzerdefinierten Pfaden lesen. Beim Planen der URLs müssen Sie die Regeln für benutzerdefinierte Pfade berücksichtigen.

  5. Wählen Sie im Abschnitt HLS output group (HLS-Ausgabegruppe) für Manifest and segments (Manifest und Segmente) und für Redundant manifest (Redundantes Manifest) die Option ENABLED (AKTIVIERT). Dieses Feld gilt für alle Ausgaben in der Ausgabegruppe.

  6. Füllen Sie diese Felder entsprechend Ihrer Planung aus:

    • Abschnitt Output group – HLS group destination (Ausgabegruppe – HLS-Gruppenziel)

    • Abschnitt Output group – HLS settings – CDN (Ausgabegruppe – HLS-Einstellungen – CDN)

    • Output group – Location – Directory structure (Ausgabegruppe – Speicherort – Verzeichnisstruktur)

    • Output group – Location – Segments per subdirectory (Ausgabegruppe – Speicherort – Segmente pro Unterverzeichnis)

    • HLS-Ausgaben — Ausgabeeinstellungen — Namensmodifikator

    • HLS-Ausgaben — Ausgabeeinstellungen — Segmentmodifikator

    • HLS-Ausgabegruppe — Standort — Basis-URL-Manifest (wenn Sie auch benutzerdefinierte Pfade einrichten)

    • HLS-Ausgabegruppe — Speicherort — Basis-URL-Inhalt (wenn Sie auch benutzerdefinierte Pfade einrichten)

Informationen darüber, wie mit dieser Funktion der Inhalt der HLS-Manifeste verändert wird, finden Sie unter Medieninhalte eines HLS-Manifests.

Ergebnisse dieser Einrichtung

Im Folgenden finden Sie Informationen darüber, wie redundante Manifeste in drei Ausfallszenarien funktionieren.

Szenario A — Die Aktion zum Verlust der Eingabe besteht darin, eine Ausgabe auszugeben

Wenn die Eingabe auf einer der Pipelines verloren geht und das Feld „Aktion beim Eingabeverlust“ auf EMIT_OUTPUT gesetzt ist, werden die übergeordneten und untergeordneten Manifeste MediaLive weiter aktualisiert.

Aus Sicht des Downstream-Systems gibt es für keine der Pipelines Änderungen an den übergeordneten oder untergeordneten Manifesten. Der Inhalt innerhalb der Mediendateien ist Füllinhalt, aber dies hat keinen Einfluss darauf, wie die Manifeste vom nachgelagerten System gelesen werden.

Szenario B — Die Aktion „Eingangsverlust“ besteht darin, die Ausgabe anzuhalten

Wenn die Eingabe in einer der Pipelines verloren geht (z. B. in Pipeline 0) und das Feld für die Aktion zum Eingabeverlust auf PAUSE_OUTPUT gesetzt ist, MediaLive wird wie folgt vorgegangen:

  • Es wird die Auflistung für die untergeordneten Manifeste für Pipeline 0 entfernt.

  • Es wird eine Anforderung an den untergeordneten Manifest-Speicherort für Pipeline 0 gesendet, um die untergeordneten Manifeste zu löschen.

Ergebnis für das nachgelagerte System, das das Hauptmanifest auf Pipeline 0 liest: Das System findet für Pipeline 0 keine Auflistung mehr für die untergeordneten Manifeste. Das System sucht dann im Hauptmanifest der Pipeline 0 nach einem alternativen untergeordneten Manifest. Wenn es das untergeordnete Manifest für Pipeline 1 findet, wechselt es auf das Lesen dieses untergeordneten Manifests.

Nachgelagerte Systeme, die das Hauptmanifest für Pipeline 1 lesen, sind nicht betroffen, da diese Systeme wahrscheinlich die untergeordneten Manifeste für Pipeline 1 lesen (da diese im Manifest zuerst angezeigt werden).

Szenario C — Pipelineausfall

Es ist auch möglich, dass eine Pipeline ausfällt. Dieser Ausfall ist nicht mit einem Eingabefehler zu vergleichen. Wenn eine Pipeline ausfällt (z. B. Pipeline 0), geschieht Folgendes:

  • Die Ausgabe wird beendet.

  • Das Hauptmanifest für Pipeline 0 wird nicht gelöscht. Es enthält weiterhin eine Auflistung für die untergeordneten Manifeste für die Pipeline 0.

  • Die untergeordneten Manifeste werden nicht aktualisiert, da keine neuen Mediendateien erstellt werden. Die untergeordneten Manifeste sind veraltet.

  • Das Hauptmanifest für Pipeline 1 ändert sich nicht. Es enthält weiterhin eine Auflistung für die untergeordneten Manifeste für Pipeline 0 (und für Pipeline 1).

Ergebnis für das nachgelagerte System, das das Hauptmanifest für die Pipeline 0 liest: Das System findet zwar eine Auflistung für die untergeordneten Manifeste für die Pipeline 0, dieses Manifest ist jedoch veraltet. Wenn das System feststellen kann, dass das Manifest veraltet ist, kann es zum Hauptmanifest der Pipeline 0 zurückkehren und nach einem alternativen untergeordneten Manifest suchen. Wenn es das untergeordnete Manifest für Pipeline 1 findet, wechselt es auf das Lesen dieses untergeordneten Manifests.

Nachgelagerte Systeme, die das Hauptmanifest für Pipeline 1 lesen, sind nicht betroffen. Diese Systeme lesen wahrscheinlich die untergeordneten Manifeste für Pipeline 1 (da diese im Manifest zuerst angezeigt werden).

Anmerkung

Wenn das Downstream-System für die HLS-Ausgabe ist AWS Elemental MediaStore, können Sie einrichten, dass veraltete MediaStore Eingaben gelöscht werden. Siehe Komponenten einer Objektlebenszyklus-Richtlinie. Nachdem das untergeordnete Manifest gelöscht wurde, MediaStore wird auf die Logik „Manifest wurde gelöscht“ von Szenario B zurückgegriffen.