Ein Eingang, mehrere FAST-Kanalprogramme

Ein Eingang, Hunderte von Programmen — Betrieb von 24/7 FAST-Kanälen auf MediaLive

Ein 24/7 FAST-Kanal spielt täglich Hunderte einzigartiger Programme, jeden Tag, für immer. AWS MediaLive begrenzt einen Kanal auf 20 Input-Attachments. Das naive Design — ein Eingang pro Video — stößt vor dem Mittagessen an seine Kapazitätsgrenze und erzwingt einen Kanalneustart, der den Live-Stream offline nimmt. Wir haben dies mit einem dynamischen Eingang gelöst, der jedes Programm bedient, das der Kanal jemals abspielen wird, und einer darüberliegenden Schicht der programmstufenweisen Orchestrierung, die die Zeitleiste bei Deployments, Teilausfällen und Bedienerbearbeitungen selbstheilend hält.

Dies ist die technische Geschichte, wie diese Orchestrierung tatsächlich funktioniert.

Schnelle Übersicht

Das Geschäftsproblem

Ein FAST-Kanal ist ein 24/7-Dienst. Betreiber planen eine ganze Woche oder einen Monat einzigartiger Videos im Voraus, und der Kanal muss jedes davon zur richtigen Sekunde abspielen — Quellen sauber umschalten, das Wasserzeichen stabil halten, Ad-Break-Cues aussenden, Lücken mit einer markengeschützten Slate füllen. Der Zuschauer sollte niemals ein schwarzes Bild, ein feststeckendes Logo oder eine sich wiederholende Sendung der letzten Woche sehen.

Diese Orchestrierung muss alles überstehen, was Betreiber damit anstellen: das Bearbeiten des morgigen Programmplans, das Hinzufügen von Ad-Breaks mitten in der Woche, das erneute Deployment nach einem einzelnen fehlgeschlagenen Programm, das Wettrennen zweier Deploy-Klicks. Das System übernimmt entweder jede Änderung atomar auf den Live-Kanal oder stellt sich sauber wieder her. „Der Kanal befindet sich jetzt in einem Zustand, den niemand versteht“ ist kein akzeptables Ergebnis für eine Infrastruktur, die live sendet.

Eine 60-Sekunden-MediaLive-Einführung

AWS MediaLive ist ein langlebiger Cloud-Encoder. Sie geben ihm einen oder mehrere Inputs (Quell-Streams oder Datei-URLs) und einen Zeitplan von zeitgesteuerten Aktionen — zu diesem Input wechseln, dieses Overlay einschalten, diesen Cue einfügen. Der Encoder läuft unbegrenzt, führt Aktionen zu ihren geplanten Zeitstempeln aus und gibt ein HLS-Manifest aus, das der Player des Zuschauers konsumiert.

Zwei AWS-Grenzwerte prägen alles nachgelagerte:

• 20 Input-Attachments pro Kanal. Harte Grenze. Ein "Top 20 Filme"-Kanal, naiv mit einem Input pro Video entworfen, erreicht die Grenze beim 21. Film.
• 1500 Schedule-Aktionen pro Kanal. Ebenfalls eine harte Grenze. Jedes Programm besteht aus mehreren Aktionen (Input-Switch, Wasserzeichen pro Rendition, Ad-Cues, Slate-Switch), sodass die tatsächliche Obergrenze näher bei einigen hundert Programmen gleichzeitig liegt.

Beide Grenzwerte sind wichtig für einen 24/7-Kanal, der voraussichtlich unbegrenzt einzigartige Inhalte abspielen soll.

Warum naive Ansätze scheitern

Die offensichtlichen Wege scheitern jeweils auf unterschiedliche Weise:

• „Ein Input pro Programm.“ erreicht die 20-Attachment-Grenze des ersten Tages. Das Hinzufügen weiterer erfordert die Neuerstellung des Kanals — und die Neuerstellung eines Kanals dauert 60–90 Sekunden, während derer der Live-Stream offline ist. Für einen 24/7-Dienst inakzeptabel.
• „Den Kanal bei jedem Deploy neu erstellen.“ Selbes Problem, bei jedem Deploy. Zuschauer erleben bei jeder Programmänderung einen Ausfall. Dies ist keine echte Option für einen Kanal, der live sein soll.
• „Die gesamte Woche in eine riesige, sich wiederholende Datei vorab kodieren.“ Tötet das Bearbeitungsmodell. Morgen neu anordnen? Die ganze Woche neu kodieren. Eine Werbung einfügen? Neu kodieren. Der ganze Grund, warum FAST-Kanäle geschäftlich funktionieren, ist die dynamische Programmierung und die werbeblockweise Einfügung — alles in eine einzige Datei zu brennen, schließt beides aus.
• „Mehrere Kanäle parallel betreiben.“ Erfordert, dass der Player zwischen ihnen wechselt, vervielfacht die Kosten von AWS und unterbricht die Audio-, MediaPackage- und CDN-Pipeline. Löst das Problem nicht so sehr, als dass es es vervielfacht.

Der Hebel, den wir hatten, war ein einziges von AWS dokumentiertes Feature — der $urlPath$-Platzhalter auf einem dynamischen Input — und die Freiheit, jede gewünschte Orchestrierung darauf aufzubauen.

Warum das wichtig ist. Der Trick ist nicht die Verwendung von $urlPath$. AWS dokumentiert es. Der Trick besteht darin, eine selbstheilende Orchestrierungsschicht darauf aufzubauen, die Teildeployments, Bedienerbearbeitungen und gleichzeitige Wiederholungsversuche übersteht — ohne den Live-Kanal jemals in einen Zustand zu versetzen, den niemand über die UI beschreiben kann.

Unsere Lösung

Ein MediaLive-Kanal. Ein dynamischer Eingang, der mit der exakten URL $urlPath$ verknüpft ist. Ein Slate-Input für Lückenfüllungen. An jeder Programmgrenze überschreibt eine InputSwitchScheduleActionSettings-Aktion die URL des dynamischen Inputs mit dem tatsächlichen S3-Pfad dieses Programms. Der Kanal benötigt niemals ein neues Input-Attachment, niemals einen Neustart, geht niemals offline.

Die interessante Arbeit ist die Orchestrierungsschicht, die auf diesem einen Input läuft — jede Aktion mit einer Programm-ID zu benennen, damit verwaiste Elemente nach einem Fehler bereinigt werden können; Lücken von ≥ 6 Sekunden mit einem Slate zu füllen, damit der Zuschauer niemals ein Standbild sieht; das Wasserzeichen einen gemessenen Moment nach jedem Input-Switch zu aktivieren, damit das Overlay nicht durch Pufferrahmen flackert; und eine Vorabprüfung gegen die 1500-Aktionen-Grenze durchzuführen, damit Deployments in der UI fehlschlagen, anstatt während des Betriebs auf AWS.

Diagramm 1 · Kanalarchitektur

Architektur

• Slate-Input — ein statisches Asset, das dem Kanal zum Füllen von Lücken zwischen Programmen zugewiesen ist.
• Dynamischer Input — einmalig erstellt mit Sources: [{ Url: "$urlPath$" }], Type: MP4_FILE. Die URL ist ein Platzhalter; der tatsächliche Pfad wird pro Programm zur Zeitplanungszeit bereitgestellt.
• Lambda-Orchestrator (fastChannel-lambda-fun/index.js) — verwaltet jede Aktivität, die auf dem Kanal erscheint. Generiert eine 8-Byte-Hex- programId pro Programm und versieht jede zugehörige Aktion damit.
• MediaLive-Zeitplan — eine einzige geordnete Liste von Aktionen, die alle über einen BatchUpdateScheduleCommand laufen. Von AWS auf 1500 Aktionen begrenzt.
• Backend-Vorabprüfung (schedule.service.ts) — ruft Lambdas GET_SCHEDULE_COUNT vor jedem Deploy auf und verweigert die Fortsetzung, wenn die neuen Aktionen die Obergrenze überschreiten würden.

• Waisen-Bereinigung (sweepIncompleteProgramGroups) — läuft nach jedem Deploy. Gruppiert Aktionen nach programId, löscht jede Gruppe, der ihre Anker-input-switch-Aktion fehlt.

   

Wichtige technische Entscheidungen

1. Ein dynamischer Input, eine URL-Überschreibung pro Programm

Der dynamische Input wird mit Sources: [{ Url: "$urlPath$" }] erstellt. An jeder Programmgrenze gibt die Lambda eine InputSwitchScheduleActionSettings-Aktion aus, die UrlPath: [program.videoUrl] bereitstellt — die tatsächliche S3-URL des MP4 dieses Programms. MediaLive ersetzt den Platzhalter zur Ausführungszeit und zieht von der echten Quelle.

Ein Input-Attachment bedient nun jedes Programm, das der Kanal jemals abspielen wird — effektiv unbegrenzt einzigartige Videos über die Lebensdauer des Kanals, begrenzt nur durch das pro-Deploy Schedule-Aktionslimit zu einem bestimmten Zeitpunkt. Die 20-Input-Grenze ist keine Einschränkung mehr, und der Kanal benötigt niemals einen Neustart, um neue Inhalte hinzuzufügen.

Diagramm 2 · Dynamische Input-URL-Überschreibung

Kompromiss, den wir bewusst eingegangen sind. Ein dynamischer Input validiert die URL nicht vorab — MediaLive löst den Platzhalter erst zur Umschaltzeit auf, sodass ein 404-Fehler als Stream-seitiger Fehler statt einer Deploy-Zeit-Ablehnung auftritt. Wir akzeptieren diese Kosten im Austausch für die architektonische Einfachheit eines einzigen Inputs. Die separate ffprobe-Validierung des Backends fängt falsch formatierte Quellen vor dem Deploy ab.

2. Programm-getaggte Aktionsnamen ermöglichen Selbstheilung

Jede von der Lambda ausgegebene Aktion trägt die 8-Byte-Hex-programId des Programms in ihrem Namen: input-switch-${programId}, watermark-on-${programId}-${rendition}, ad-break-start-${programId}-${i}, program-end-${programId}, slate-switch-${programId}.

Nach jedem Deploy listet sweepIncompleteProgramGroups jede derzeit auf dem Kanal vorhandene Aktion auf, gruppiert sie nach ihrer eingebetteten programId und löscht jede Gruppe, der ihre Anker-input-switch-Aktion fehlt. Das ist der Bereinigungspfad für fehlgeschlagene Teildeployments, überlappende Bearbeitungen und jede andere Bedingung, die den Kanal mit halben Programmaktionen zurücklassen könnte.

Die Codierung des Aktionsnamens ist der gesamte Identitätsmechanismus. MediaLive selbst hat kein Konzept eines „Programms“ — die Orchestrierungsschicht projiziert eines über Namenskonventionen darauf.

Warum das wichtig ist. Ohne die in jedem Aktionsnamen eingebettete Programm-ID hätte die Waisen-Bereinigung keine Möglichkeit zu wissen, welche Aktionen zusammengehören. Die Bereinigung auf Aktionsebene würde entweder zu viel löschen (vollständiger Kanal-Reset) oder zu wenig (verwaiste Wasserzeichen, die sich nie abschalten). Die Namenskonvention ist das Datenmodell.

3. Die 6-Sekunden-Slate-Regel

Programme stoßen selten perfekt aneinander — es gibt fast immer eine Lücke von einigen Sekunden zwischen dem Ende einer MP4-Datei und dem Beginn des nächsten geplanten Programms. Die Orchestrierung gibt eine Slate-Switch-Aktion aus, wann immer diese Lücke ≥ 6 Sekunden (MIN_SLATE_GAP_MS = 6000) beträgt.

Der Schwellenwert ist nicht willkürlich. MediaLive erzwingt einen Mindestabstand von 5 Sekunden zwischen zwei Schedule-Aktionen; das Auslösen eines Slate-Switchs näher als dieser zum Input-Switch des nächsten Programms führt zu einer Ablehnung. Die 6-Sekunden-Regel gibt MediaLive den erforderlichen Abstand und lässt der Orchestrierungsschicht eine Sekunde Sicherheitsmarge für Zeitabweichungen. Unter 6 Sekunden lassen wir den letzten Frame des vorherigen Programms kurz einfrieren, anstatt eine Deploy-Ablehnung zu riskieren.

4. Wasserzeichen pro Rendition mit gemessener Aktivierungsverzögerung

Das Wasserzeichen ist eine StaticImageOutputActivate-Aktion, die pro Ausgabe-Rendition (1080p, 720p, 480p, 360p) ausgegeben wird — vier Aktionen pro Programm. Jede Aktion wird 1.500 ms nach dem Input-Switch dieses Programms ausgelöst.

Die Verzögerung besteht, weil die ersten Frames nach einem Input-Switch noch gepuffert werden; das Aktivieren des Overlays genau im Moment des Switches kann ein kurzes Flackern verursachen, wenn das Overlay auf einem noch nicht vollständig gerenderten Frame zeichnet. 1.500 ms war der Wert, der in Tests konsistent eine saubere Aktivierung über alle vier Renditions hinweg erzeugte. Es ist eine gemessene Konstante, kein dokumentierter MediaLive-Parameter — und sie befindet sich an einer Stelle im Code, sodass zukünftige Anpassungen eine Ein-Zeilen-Änderung sind.

Kompromiss, den wir bewusst eingegangen sind. Overlay-Aktionen pro Rendition kosten das 4-fache der Aktionsanzahl im Vergleich zu einem einzigen globalen Overlay. Wir akzeptieren die Kosten, weil der Pro-Rendition-Pfad es jeder Ausgabe ermöglicht, ein Wasserzeichen zu erhalten, das genau auf ihre Pixelabmessungen zugeschnitten ist, anstatt MediaLive ein einziges Overlay über alle vier herunterzuskalieren. Das Ergebnis ist ein sichtbar schärferes Logo auf SD-Ausgängen — und es bleibt genügend Aktionsbudget für Hunderte von Programmen, bevor die 1500-Grenze relevant wird.

5. Die 1500-Aktionen-Obergrenze, in der UI vorab geprüft

AWS begrenzt einen MediaLive-Kanal hart auf 1500 Schedule-Aktionen. Mit ~7–8 Aktionen pro Programm (Input-Switch + 4 Wasserzeichen + 2 Ad-Cues + gelegentlicher Slate) fasst der Kanal ungefähr 180–200 aktive Programme, abhängig von Werbedichte und Slate-Häufigkeit. Das ist eine echte Obergrenze für Langzeit-Deployments, und die genaue Zahl hängt von der Komplexität pro Programm ab.

Vor jedem Deploy ruft das Backend Lambdas GET_SCHEDULE_COUNT auf, das Live-Aktionen auf dem Kanal über DescribeScheduleCommand zählt und { liveCount, capacity: 1500 } zurückgibt. Wenn liveCount + (newPrograms × 8) 1500 überschreiten würde, wirft das Backend SCHEDULE_ACTION_CAP_EXCEEDED mit der genauen verbleibenden Kapazität — bevor es etwas an MediaLive übermittelt. Der Operator sieht die Grenze in der UI mit dem Hinweis, zuerst vergangene Programme zu löschen. Das Deploy läuft niemals halb gegen die Wand.

Diagramm 3 · Aktions-Timeline eines Programms

Ergebnisse

• Ein einziger MediaLive-Kanal bedient effektiv unbegrenzt viele einzigartige Programme über seine Lebensdauer, mit einem dynamischen Input-Attachment. Die 20-Input-Grenze ist keine Einschränkung mehr, um die wir herumplanen müssen — die Kapazität zu einem bestimmten Zeitpunkt wird durch das Schedule-Aktionslimit bestimmt, nicht durch das Input-Limit.
• Die Kanal-Orchestrierung ist selbstheilend: Jedes Deploy endet mit einer Waisen-Bereinigung, sodass fehlgeschlagene Teildeployments den Zeitplan nicht in einem inkonsistenten Zustand hinterlassen können.
• Die Schedule-Kapazität ist begrenzt und sichtbar. Operatoren sehen die 1500-Aktionen-Obergrenze in der UI, bevor sie klicken, nicht als eine undurchsichtige AWS-Ablehnung mitten im Deploy.
• Die Programm-ID-Namenskonvention ist die gesamte Identitätsschicht — und es ist ein String. Keine neue Infrastruktur, kein zusätzlicher Speicher, keine Abhängigkeiten. Die einfachstmögliche Projektion von „Programm“ auf MediaLives flache Aktionsliste.

Technologie-Stack: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · AWS SDK v3 (@aws-sdk/client-medialive)