Server-Side Ad Insertion

FAST Channels verdienen Geld mit Werbeunterbrechungen. Das gesamte Geschäftsmodell basiert auf einer einzigen Annahme: Wenn der Kanal sagt „Werbung einblenden“, hört jedes nachgeschaltete System – der Ad Server, der SSAI Splicer, der Smart-TV Player – dies genau im selben Moment und mit exakt derselben Dauer. SCTE-35 ist das Standardprotokoll, das diese Nachricht übermittelt. Wenn dies unbemerkt fehlschlägt – und stummes Fehlschlagen ist der Standard-Fehlermodus – werden Anzeigen entweder nicht gerendert, zum falschen Zeitpunkt ausgelöst oder haben die falsche Länge. Der Zuschauer sieht ein Testbild. Die Einnahmen bleiben aus.

Dies ist die technische Geschichte, wie die FAST Channels von mStudio standardkonforme SCTE-35 Cues aus bedienerfreundlichen Eingaben senden und warum wir es als drei Cues pro Unterbrechung anstatt nur einen aufgebaut haben.

Schneller Überblick

Das Geschäftsproblem

Jede Werbeunterbrechung auf einem FAST Channel ist ein Einnahmeereignis. Der Kanal sendet einen Marker, der besagt „hier wird eine Anzeige platziert, sie dauert 30 Sekunden, bitte vorbereiten.“ Nachgeschaltete Systeme – Google Ad Manager, AWS MediaTailor, regionale Ad Server, Smart-TV Player SDKs – lesen diesen Marker und entscheiden, was eingefügt werden soll.

Wenn der Marker korrekt ist, läuft die Werbeunterbrechung sauber ab, die Impression wird gezählt und der Betreiber wird bezahlt. Wenn der Marker falsch ist – falsche Dauer, falsche Form, falsches Format – lehnt das Ad System ihn entweder ab (keine Anzeige ausgeliefert) oder akzeptiert ihn fehlerhaft (Anzeige mit falscher Länge oder eine, die in das nächste Programm übergeht). Beide Ergebnisse kosten echtes Geld und beide schlagen still fehl. Der Kanal streamt weiter. Der Zuschauer sieht ein Testbild oder einen ungeschickten Schnitt. Die Monetarisierungspipeline liefert einfach niedrigere Zahlen und keine Fehlermeldung, der man nachgehen könnte.

Das technische Ziel ist nicht „Anzeigen zu unterstützen“. Es lautet: Jede vom Betreiber definierte Werbeunterbrechung muss bei jedem nachgeschalteten Konsumenten als standardkonformes SCTE-35 Signal ankommen, und zwar jedes Mal genau bei dem vom Betreiber gewählten Frame.

Was SCTE-35 tatsächlich ist (die 90-Sekunden-Version)

SCTE-35 ist ein Standard zum Einfügen von Cue-Nachrichten in einen Videostream. Die Cues enthalten keine Werbeinhalte; sie tragen Signale – „Werbeunterbrechung beginnt hier“, „Werbeunterbrechung endet hier“, „dieses Segment ist N Sekunden lang“. Das nachgeschaltete System liest diese Signale und reagiert darauf: Eine SSAI-Schicht fügt ein echtes Werbemittel in das HLS Manifest ein, ein Smart-TV Player löst ein Overlay aus, ein Ad Server protokolliert eine Slot-Möglichkeit.

Zwei Cue-Formen sind für unseren Anwendungsfall relevant:

• SpliceInsert – der ursprüngliche SCTE-35 Cue. Trägt eine SpliceEventId, eine Dauer in Sekunden und ein „Out-of-Network“-Flag. Die meisten klassischen Ad Server lesen dies.
• TimeSignal – der neuere, ausdrucksstärkere Cue. Trägt einen SegmentationDescriptor mit einer SegmentationTypeId (52 = Provider Ad Start, 53 = Provider Ad End) und einer SegmentationDuration in 90.000-Tick-Einheiten. SSAI Systeme und moderne Player bevorzugen diese Form, da sie sauber über Start und Ende hinweg paart.

Beide Formen sind korrekt SCTE-35. Verschiedene nachgeschaltete Konsumenten bevorzugen unterschiedliche. Das Emittieren nur einer Form lässt Geld auf dem Tisch liegen.

Warum das wichtig ist. Eine naive Implementierung sendet einen SpliceInsert pro Werbeunterbrechung und betrachtet dies als erledigt. Die Werbeunterbrechung funktioniert auf älteren Playern und schlägt bei SSAI stillschweigend fehl. Die Hälfte Ihres Anzeigenbestands wird monetarisiert; die andere Hälfte nicht. Sie werden nicht wissen, welche welche ist, bis Ihre Einnahmezahlen niedrig ausfallen.

Warum naive Ansätze scheitern

Die Abkürzungen sind verlockend, weil sie alle fast funktionieren.

• „Zum Zeitpunkt der Kodierung Werbung in das Originalvideo einfügen.“ Es gibt keinen Raum für Flexibilität. Der Betreiber kann keine A/B-Tests für die Platzierung durchführen, Anzeigen nach dem Deployment nicht ändern, keine regionalen oder zielgruppenorientierten Anzeigen schalten. Der Hauptgrund für die Existenz von FAST Channels ist die Monetarisierung desselben Inhalts auf verschiedene Weisen – das Einbrennen von Anzeigen zum Zeitpunkt der Kodierung schließt dies aus.
• „Client-seitige Werbeeinblendung nutzen.“ Ad-Blocking ist einfach. Unterschiedlicher Codepfad pro Gerät. Keine serverseitige Personalisierung. Und es umgeht SSAI vollständig, was niedrigere CPMs bedeutet.
• „Einfach einen SpliceInsert pro Unterbrechung senden.“ Der häufigste Produktionsfehler. Funktioniert bei einigen Playern, wird aber von SSAI Systemen, die TimeSignal Cues zum Paaren von Start/Ende benötigen, stillschweigend ignoriert. Teilweise Monetarisierung, ohne Fehler zur Untersuchung.
• „Alles in 90 kHz Ticks ausdrücken, weil die Spezifikation sie erwähnt.“ Die Spezifikation ist ärgerlicher als das. SpliceInsert.Duration ist in Sekunden. SegmentationDuration ist in 90 kHz Ticks. Das Verwechseln führt zu Cues, die die Schema-Validierung bestehen und versendet werden, dann aber beim Player als fehlerhafte Dauern scheitern. Der Encoder wird es nicht bemerken. Der Player überspringt die Unterbrechung einfach.
• „MediaLive zur Bestätigung zulassen.“ Das wird es nicht. MediaLive akzeptiert überlappende Unterbrechungen, Unterbrechungen mit Null-Dauer und unmögliche Segmentierungsdauern ohne Beanstandung. Die Bestätigung muss erfolgen, bevor MediaLive die Aktion sieht.

Der Hebel, den wir hatten, war die Grenze zwischen der Operator UI – wo Werbeunterbrechungen nur {position, duration} Paare sind – und dem MediaLive Zeitplan, wo jeder Cue perfekt sein muss.

Unsere Lösung

Die Werbeunterbrechung als erstklassiges Datenobjekt durchgängig behandeln. Der Betreiber definiert sie in den einfachstmöglichen Begriffen. Das Backend validiert sie einmal auf der Schema-Schicht. Die Lambda-Funktion übersetzt sie zur Deployment-Zeit in einen Drei-Cue-Stack, wobei jeder Cue in der von seiner eigenen Spezifikation geforderten Zeitbasis ausgedrückt wird. Nichts anderes im Stack muss etwas über SCTE-35 wissen – die Übersetzung befindet sich in einer Funktion, in derselben Lambda-Funktion, die jede andere Zeitplanaktion besitzt.

Diagramm 1 · End-to-End Anzeigenmarker-Pipeline

Architektur

• Frontend Ad-Break-Editor – Betreiber fügen Werbeunterbrechungen pro Programm hinzu, indem sie einen Positions-Offset (Sekunden vom Programmstart) und eine Dauer (Sekunden) angeben. Bumper Slots sind Teil des Datenmodells und bereit für die Ausspielschicht.
• AdMarker Collection (MongoDB) – ein Dokument pro Programm mit Werbeunterbrechungen, das auf das Video verweist. Das adBreaks[] Array speichert {position, duration}, wobei Mongoose zum Speicherzeitpunkt 10 ≤ duration ≤ 120 erzwingt. Bumpers tragen eine adBreakId Referenz für die nachgeschaltete Paarung.
• NestJS Backend (schedule.service.ts) – verbindet zur Deployment-Zeit jeden Zeitplan mit seinem AdMarker und benennt Felder gemäß dem Vertrag der Lambda-Funktion um (position → offsetSeconds, duration → durationSeconds). Ein Bulk-Abruf, kein N+1-Problem.
• Lambda Orchestrator (fastChannel-lambda-fun/index.js) – verantwortet die SCTE-35 Übersetzung. Für jede Werbeunterbrechung wird der Drei-Cue-Stack in denselben BatchUpdateScheduleCommand emittiert, der Eingabewechsel und Wasserzeichen enthält. Aktionsnamen werden pro Programm versioniert, damit der Orphan Sweep sie nach einem partiellen Deploy paaren kann.
• AWS MediaLive – empfängt die Aktionen, emittiert #EXT-SCTE35 Marker im HLS Manifest zur vom Betreiber gewählten Sekunde.

Wichtige technische Entscheidungen

1. Drei Cues pro Werbeunterbrechung, nicht einer

Jede Werbeunterbrechung sendet drei diskrete Aktionen für denselben logischen Moment im Programm.

Diagramm 2 · Lebenszyklus einer einzelnen Werbeunterbrechung

Die Start- und End-TimeSignal Cues teilen sich eine SegmentationUpid, damit nachgeschaltete Systeme sie deterministisch paaren können. Der SpliceInsert trägt eine eindeutige SpliceEventId zur Deduplizierung auf Player-Ebene. Verschiedene Konsumenten lesen verschiedene Cues. Das Emittieren aller drei deckt jeden Vertrag ab, der uns heute wichtig ist, und jeden plausiblen in der Zukunft.

Häufiger Produktionsfehler. Senden Sie einen SpliceInsert und gehen Sie davon aus, dass der Rest des Ökosystems es herausfindet. SSAI Systeme verwerfen stillschweigend Unterbrechungen, denen passende TimeSignal Cues fehlen; klassische Ad Server ignorieren TimeSignal-only Signale. Ohne alle drei wird jede Werbeunterbrechung von einem Teil Ihres nachgeschalteten Stacks monetarisiert und vom Rest übersehen – und Sie erfahren dies aus dem Umsatzbericht, nicht aus den Logs.

2. Zwei Zeitbasen, in einer Funktion abgeglichen

SpliceInsert.Duration ist in Sekunden. SegmentationDuration innerhalb eines TimeSignal Deskriptors ist in 90.000-Tick-Einheiten. Dieselbe logische Dauer, zwei Kodierungen – und der häufigste SCTE-35 Fehler in der Praxis ist das Verwechseln dieser.

Diagramm 3 · Zeitkonvertierungslogik

Die Konvertierung befindet sich in buildProgramActions und nur dort. Es gibt eine kanonische Stelle, an der man nachsehen muss, wenn eine Cue-Dauer falsch herauskommt, und eine Stelle, die man ändern muss, wenn sich die Spezifikation jemals weiterentwickelt.

Kompromiss, den wir absichtlich eingegangen sind. Wir hätten beide Zeitbasen im AdMarker Dokument speichern und die Lambda-Funktion sie durchkopieren lassen können. Wir haben dies bewusst nicht getan: Das Speichern nur des Sekundenwerts bedeutet, dass es nur eine Zahl gibt, die ein Operator festlegen muss, nur eine Zahl, die validiert werden muss, und nur eine Zahl, die falsch sein kann. Der 90 kHz Wert ist abgeleitet, niemals gespeichert. Abgeleitete Daten können nicht driften.

3. Position ist relativ, Auslösezeit ist absolut

Der Betreiber sagt „Werbeunterbrechung bei 720 Sekunden ins Programm.“ Die Lambda-Funktion berechnet die tatsächliche UTC-Auslösezeit als programStartTime + offsetSeconds × 1000 und stempelt diese auf die Aktion. Jede andere Zeitplanaktion – Eingabewechsel, Wasserzeichen ein, Programmende – verwendet dieselbe Offset-zu-Timestamp-Pipeline. Anzeigen-Cues landen auf denselben Frame-Grenzen wie alles andere, ohne Mehrdeutigkeit darüber, welche Uhr die Zeitachse besitzt.

4. Validierung auf der Datenschicht, nicht am Draht

Das AdMarker Schema erzwingt duration ∈ [10, 120] Sekunden zum Mongoose Speicherzeitpunkt. Eine außerhalb des Bereichs liegende Unterbrechung erreicht niemals die Lambda-Funktion. Werbeunterbrechungen, die über das Programmende hinausgehen würden, werden zur Build-Zeit gekürzt anstatt abgelehnt – Betreiber verlieren ihre Arbeit nicht durch eine einzige schlechte Unterbrechung. Die Arten von Fehlern, die nicht auftreten können, sind interessanter als die, die auftreten können.

5. Cue-Emission von SSAI entkoppelt

Was wir heute ausliefern, ist die Signalisierungsschicht. Die serverseitige Werbeeinblendung über AWS MediaTailor – die diese Cues konsumieren würde, um echte Werbemittel in das HLS Manifest einzufügen – ist vollständig konzipiert und noch nicht angeschlossen. Die bewusste Reihenfolge: Zuerst die Cue-Schicht korrekt in Produktion bringen, von echten Kanälen verwendet, bevor SSAI aktiviert wird. Wenn die Integration live geht, sind die Cues bereits vorhanden. Das nachgeschaltete System erhält vom ersten Tag an einen sauberen Vertrag zur Konsumierung.

Warum diese Reihenfolge wichtig ist. Das Debugging von SSAI ist brutal, wenn Ihre Cues falsch sind, da jeder Fehler wie ein SSAI Fehler aussieht, selbst wenn die Cues fehlerhaft sind. Indem wir die Cue-Schicht zuerst isoliert ausgeliefert und gegen reale Player und Ad Server validiert haben, haben wir eine ganze Kategorie von Integrationsverwirrungen eliminiert, bevor sie überhaupt entstehen konnte.

Ergebnisse

• Jede vom Betreiber definierte Werbeunterbrechung sendet einen standardkonformen Drei-Cue SCTE-35 Stack im HLS Manifest des Kanals – zur richtigen Sekunde, gegen die richtige Zeitbasis.
• Die Übersetzungsschicht befindet sich in einer Funktion. Spezifikationsänderungen oder neue nachgeschaltete Konsumenten erfordern eine Änderung an einer einzigen Datei, nicht eine Suche quer durch die Codebasis.
• Die Dauervalidierung erfolgt auf der Datenschicht, bevor ein Cue den Encoder erreicht. Bedienerfehler werden in der UI sichtbar, nicht stillschweigend zur Sendezeit – fehlerhafte Cues können MediaLive nicht erreichen.
• Die Cue-Generierung ist deterministisch: Identische Bediener-Eingaben erzeugen identische SCTE-35 Aktionen, sodass dieselbe Unterbrechung sich bei jedem Deployment und jedem Kanal gleich verhält.
• Die Signalisierungsschicht ist ausgeliefert und live. Der SSAI Konsument (MediaTailor) ist konzipiert und bereit zur Anbindung – und wenn dies geschieht, werden die Cues jedes bestehenden Kanals bereits darauf warten.

Technologie-Stack: AWS MediaLive · AWS Lambda · NestJS · MongoDB · TypeScript · Node 18 · SCTE-35 (Scte35TimeSignalSettings, Scte35SpliceInsertSettings) · AWS SDK v3