FKTG-Journal: Wie gelingt die nahtlose Integration von DVB-I in bestehende Broadcast- und IP-Infrastrukturen? Welche Herausforderungen treten dabei auf?
Martin Schmalohr: DVB-I verknüpft klassische Rundfunkwege mit IP-Streaming über eine gemeinsame Serviceliste. In der Praxis wird der bestehende Broadcast-Playout-Stack mit SI/PSI-Generator und Multiplexer mit einer IP-Delivery-Kette gekoppelt, die DASH-Segmenter und CDN-Edge umfasst.
Der Schlüssel ist ein Aggregator, der für jedes Programm alle verfügbaren Übertragungsinstanzen (Satellit, Kabel, Terrestrik, OTT) mit Prioritäten in ein DVB-I-XML schreibt. Der Hybrid-Client wählt automatisch die beste Quelle aus.
Technisch funktioniert das System bereits, wie die Phase-1 des deutschen Piloten gezeigt hat. Die größte verbleibende Herausforderung sind Latenz und Umschaltzeiten beim Fallback von Broadcast auf IP. Diese werden durch SAT>IP-ähnliche Direkttune-Parameter und verkürzte DASH-Segmente deutlich reduziert.
Welche Rolle spielen DVB-DASH, HbbTV sowie DVB-NIP bei der Umsetzung von DVB-I?
DVB-DASH ist das verbindliche Streaming-Profil für DVB-I. Alle Live- und VoD-Assets werden in ETSI TS 103 285-konforme Manifeste verpackt, die von jedem kompatiblen Endgerät ohne proprietäre Anpassungen abgespielt werden können.
HbbTV liefert dabei die bewährte Laufzeitumgebung für EPG, Mediathek-Verlinkung und Login/DRM-Flows. Im Pilot wurde der nahtlose Wechsel von einem DVB-I-Kanal zur HbbTV-Replay-App erfolgreich demonstriert.
DVB-NIP eröffnet uns den umgekehrten Weg und ist wichtig für Regionen ohne Breitband. Damit können IP-Streams inklusive DVB-I-Signalisierung via Satellit oder DVB-T2 ausgestrahlt werden.
Zusammen bilden HbbTV, DVB-I und DVB-NIP also das technische Rückgrat von DVB-I.
Wie unterstützt G&L Systemhaus die Bereitstellung von Catch-up-TV und Video-on-Demand-Diensten im Kontext von DVB-I?
Wir liefern seit 1999 Non-Linear-Content für Broadcaster aus. Technisch ändert DVB-I an unserem Delivery-Footprint wenig - der Mehrwert liegt heute in der Metadaten-Orchestrierung.
Dazu verknüpfen wir EPG-Einträge mit VoD-IDs, setzen Time-Shift-Marker in die MPD und erzeugen "Replay-Links" für den DVB-I-Guide. Kurz gesagt: Wir sorgen dafür, dass Zuschauer nach einem Klick aus dem linearen Programm direkt in die zugehörige Mediathek-Folge springen können.
Alternativ ist auch Timeshift im Livestream über den sogenannten Internet Link Service möglich. Edge-Caches halten populäre Catch-up-Assets regional vor, um Startzeiten gering zu halten.
Welche Rolle spielt Edge-Caching dabei genau?
Edge-Caching ermöglicht es im Zusammenhang mit Edge-Computing, Service-Listen dynamisch und in der Nähe des Endgerätes an regionale oder funktionale Anforderungen anzupassen. Wir pflegen dann nur eine Master-Serviceliste, erzeugen aber zur Laufzeit Varianten nach Geo-IP oder Nutzerprofil, natürlich unter Berücksichtigung der jeweiligen Datenschutzbestimmungen.
Die Regeln - etwa "in Bayern Platz 3 = BR Fernsehen" - liegen in einer Redis-Datenbank an den CDN-Edges. Sie werden vom dem jeweiligen Service Listen-Aggregator synchronisiert. Fordert ein TV-Client die Liste an, erhält er binnen Millisekunden die passende XML-Version direkt aus dem Edge-Cache.
Wenn sich Metadaten oder Event-Kanäle aktualisieren, invalidieren wir nur das betroffene Objekt, nicht die gesamte Liste. Das System ist skalierbar, auch wenn Millionen Geräte zeitgleich ein Refresh triggern.
Diese Edge-Caching-Lösung wurde auch schon auf der DVB World vorgestellt.
Welche Caching-Strategien gibt es denn allgemein?
Beginnen wir mit dem traditionellen CDN-Caching, das statische Inhalte wie Bilder, Videos und Skripte an Edge-Standorten speichert. Dies reduziert die Latenz durch nutzernahe Bereitstellung und minimiert Pufferzeiten. Der Unterschied zwischen Antenne und IP wird kaum noch wahrnehmbar sein. Eine Umschaltung nach Trennen des Broadcast-Kabels auf DVB-I ist in weniger als 2 Sekunden möglich.
Edge Computing erweitert das Caching durch Code-Ausführung an Edge-Knoten für dynamische Inhaltsgenerierung und -anpassung. Ruft also ein TV-Client die Liste ab, wird die passende XML-Version direkt aus dem Edge-Cache ausgeliefert. Wie eben auch schon erwähnt, wird bei Änderungen an Metadaten oder Event-Kanälen gezielt nur das betroffene Objekt invalidiert.
Technische Konzepte umfassen WASM zur nativen Ausführung von Binärcode auf Cloud-Servern von Linode oder Akamai's Edge-Servern, benutzerdefinierte Cache-Invalidierungsregeln und Cache Key Generation für maßgeschneiderte Cache-Schlüssel.
Edge-Funktionen ermöglichen HTTP-Anfragen und -Antworten zu modifizieren für flexible Caching-Steuerung durch URL-Rewriting, Header-Manipulation und Authentisierung. Das Datenmanagement am Edge erfolgt über EdgeKV-Systeme wie bei Akamai, wo Edge Worker verteilte Key-Value-Store Funktionen nutzen.
Wie werden denn die Metadaten Innerhalb der Lösung behandelt?
Der Mehrwert liegt vor allem in der Metadaten-Orchestrierung. Wir koppeln den bestehenden Broadcast-Playout-Stack mit SI/PSI-Generator und Multiplexer mit einer IP-Delivery-Kette, in der wir DASH-Segmenter und CDN-Edge betreiben.
Interview: Angela Bünger
Aufmacherbild: KI-generiert mit DALL.E
