SMPTE ST 2110 - Und darüber hinaus

Fortschritt der Implementierung von neuen Standards im Broadcastbereich des deutschsprachigen Raums

Diplomarbeit

Ausgeführt zum Zweck der Erlangung des akademischen Grades Dipl.-Ing. für technisch-wissenschaftliche Berufe

am Masterstudiengang Digitale Medientechnologien an der Fachhochschule St. Pölten, Masterklasse TV- und Videoproduktion

von: Christoph Ruckenstuhl, BSc dm171551

Betreuer/in und Erstbegutachter/in: FH-Prof. Dipl.-Ing. Lars Oertel Zweitbegutachter/in: Dipl.-Ing. Michael Bock, BSc

Wien, 29.08.2020 Ehrenwörtliche Erklärung

Ich versichere, dass

- ich diese Arbeit selbständig verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfe bedient habe.

- ich dieses Thema bisher weder im Inland noch im Ausland einem Begutachter/einer Begutachterin zur Beurteilung oder in irgendeiner Form als Prüfungsarbeit vorgelegt habe.

Diese Arbeit stimmt mit der vom Begutachter bzw. der Begutachterin beurteilten Arbeit überein.

......

Ort, Datum Unterschrift

II Kurzfassung

Diese Diplomarbeit befasst sich mit den SMPTE ST 2110 Standards und deren Implementierungsstatutes in Broadcastunternehmen des deutschsprachigen Raums. Sie gibt einen Überblick über die Vor- und Nachteile sowie spezieller Eigenschaften dieser Standards und soll eine Entscheidungshilfe bei der Frage sein, ob und wann man von SDI- auf IP-Technologien umsteigt.

Der erste Teil dieser Arbeit befasst sich mit den derzeit verwendeten SDI- Standards und den Grundlagen der Netzwerktechnik sowie diversen Spezifikation zu IP-Standards und Organisationen die diese unterstützen. Die Informationen zu diesem und dem darauf folgenden Abschnitt welcher sich im Detail mit den diversen ST 2110 Teilstandards und deren Funktionsweise beschäftigt, wurden durch eine Literaturrecherche zusammengetragen.

Der darauf folgende empirische Teil beinhaltet Informationen, welche mittels einer qualitativen Inhaltsanalyse aus Experteninterviews gewonnen werden konnten. Die Experten setzen sich aus erfahrenen leitenden Personen der Broadcastbranche zusammen, die zum größten Teil bereits praktische Erfahrungen mit den neuen IP-Standards sammeln konnten.

Die Ergebnisse im letzten Teil der Arbeit zeigen die überwiegenden Vorteile und Möglichkeiten einer Umstellung auf eine ST 2110 Infrastruktur auf. Es werden jedoch auch Situationen dargestellt in denen es derzeit noch sinnvoll ist bei SDI- Technologie zu bleiben oder sich zumindest mit den Konsequenzen einer Umstellung auseinanderzusetzen. Darüber hinaus wird der aktuelle Stand der Implementierung von ST 2110 in vier Broadcastunternehmen aus Deutschland, Österreich und der Schweiz vorgestellt. Diese Implementierung befindet sich derzeit bei den meisten Unternehmen im Anfangsstadium, jedoch werden in den nächsten Jahren viele Investitionen in diese Richtung geplant.

III Abstract

This master thesis deals with the SMPTE ST 2110 standards and their status of implementation in broadcast companies in German-speaking countries. It gives an overview of the advantages and disadvantages as well as special properties of these standards and is intended to be a decision-making aid when it comes to whether and when to switch from SDI to IP technologies.

The first part of this thesis deals with the currently used SDI standards and the basics of network technology as well as various specifications for IP standards and organisations that support them. The information on this and the following section, which deals in detail with the various ST 2110 sub-standards and their functionality, was compiled through a literature research.

The following empirical part contains information that has been obtained from expert interviews using a qualitative content analysis. The experts are made up of experienced executive employees from the broadcast industry, most of them have already gained practical experience with the new IP standards.

The results in the last part of the thesis show the predominant advantages and possibilities of a changeover to an ST 2110 infrastructure. However, situations are also presented in which it currently still makes sense to stick with SDI technology or at least to deal with the consequences of a changeover. In addition, the current status of the implementation of ST 2110 in four broadcast companies from Germany, Austria and Switzerland will be presented. This implementation is currently in the early stages at most companies, but many investments will be made in this direction over the next few years.

IV Inhaltsverzeichnis

Ehrenwörtliche Erklärung II Kurzfassung III Abstract IV Inhaltsverzeichnis V 1 Einleitung 1 1.1 Thema und Fachbereich 1 1.2 Motivation 1 1.3 Forschungsfragen 2 1.4 Methoden 2 1.4.1 Literaturrecherche 2 1.4.2 Leitfadengestütztes Experteninterview 3 1.5 Vorgehensweise bei den Experteninterviews 3 1.5.1 Interviewleitfaden 3 1.5.2 Expertenauswahl 4 1.5.3 Planung und Durchführung der Interviews 5 1.5.4 Transkriptionsregeln 5 1.5.5 Inhaltlich strukturierende qualitative Inhaltsanalye 6 1.6 Anmerkung zu Formulierungen 10 2 Einführung 11 2.1 SDI 11 2.1.1 SDI Standards 11 2.1.2 Ancillary Data Space 13 2.1.3 Embedded Audio 15 2.1.4 Synchronisierung 16 2.2 Netzwerktechnik 17 2.2.1 Netzwerke 17 2.2.2 OSI-Referenzmodell 19 2.2.3 Verbindungsarten 21 2.2.4 Ethernet-Standards 22 2.2.5 Netzwerkprotokolle 23 2.3 IP Infrastruktur 27 2.3.1 Netzwerkarchitektur 27 2.3.2 Routing 29

V 2.3.3 Orchestrierung und Kontrolle 32 2.3.4 PTP – Precision Time Protocol 35 2.4 Allianzen 38 2.4.1 AIMS 38 2.4.2 AMWA 38 2.4.3 JT-NM 39 2.4.4 VSF 40 2.5 Spezifikationen, Richtlinien, Empfehlungen 41 2.5.1 AES67 41 2.5.2 VSF Technical Recommendations 42 2.5.3 NMOS 43 2.6 Weitere IP Standards 47 2.6.1 NDI 47 2.6.2 SMPTE ST 2022 48 3 SMPTE ST 2110 52 3.1 2110-10 – System Timing and Definitions 53 3.2 2110-20 – Uncompressed Active Video 54 3.3 2110-21 – Traffic Shaping and Delivery Timing for Video 56 3.4 2110-22 – Constant Bit-Rate Compressed Video 58 3.5 2110-30 – PCM Digital Audio 58 3.6 2110-31 – AES3 Transparent Transport 59 3.7 2110-40 – Transport of SMPTE Ancillary Data 59 4 Experteninterviews 61 4.1 Experten 61 4.1.1 Georg Kuntner 61 4.1.2 Matthias Barth 61 4.1.3 Philipp Beuchert 61 4.1.4 Sandro Furter 62 4.1.5 Stefan Kollinger 62 4.2 Ergebnisse 62 4.2.1 Vorteile von IP-Technologien 62 4.2.2 Nachteile von IP-Technologien 66 4.2.3 Vorteile von SDI-Technologien 69 4.2.4 Nachteile von SDI-Technologien 70 4.2.5 Gemeinsamkeiten 71 4.2.6 Herausforderungen 72 4.2.7 Möglichkeiten 78 4.2.8 Erfahrungen 79 4.2.9 Aktuelle Projekte 81 4.2.10 Umstiegs-Szenarien 83 4.2.11 Zukunftsaussichten 86

VI 5 Beantwortung der Forschungsfragen 89 5.1 Welche nennenswerten technischen und wirtschaftlichen Vor- bzw. Nachteile bietet eine Umstellung von SDI- auf IP-Technologien? 89 5.1.1 Vorteile gegenüber SDI 89 5.1.2 Nachteile gegenüber SDI 91 5.2 Auf welchem Stand der Entwicklung befindet sich die Implementierung der IP-Standards derzeit im deutschsprachigen Raum? 92 5.2.1 Deutschland – ProSiebenSat1 92 5.2.2 Österreich – ORF 93 5.2.3 Österreich – Puls4/ATV 93 5.2.4 Schweiz – TPC (SRF) 93 5.3 Inwieweit besteht derzeit aus technischer und wirtschaftlicher Sicht die Veranlassung von SDI- auf IP-Technologien umzusteigen? 94 6 Fazit 95 6.1 Ausblick auf weitere Forschung 96 Literaturverzeichnis 97 Abbildungsverzeichnis 104 Tabellenverzeichnis 106 Anhang 107 A. Interview Georg Kuntner 107 B. Interview Matthias Barth 116 C. Interview Philipp Beuchert 128 D. Interview Sandro Furter 135 E. Interview Stefan Kollinger 148

VII 1 Einleitung

1 Einleitung

1.1 Thema und Fachbereich

Der im September 2017 auf der IBC erstmals präsentierte SMPTE ST 2110 „Professional Media Over Managed IP Networks“ Standard ist im Broadcastbereich ein viel diskutiertes Thema. Er gilt als der nächste große Schritt in Richtung einer rein auf IP-Technologien basierenden Signalübertragung in der Studio- und Liveproduktion (Mailhot, 2017).

Der Übergang von SDI-Technologien auf IP-Technologien stellt sich für viele Unternehmen als Herausforderung unterschiedlicher Art da. Organisationen wie AIMS versuchen seit dem Erscheinen von ST 2110, Broadcastunternehmen durch Herausgabe von unterstützenden Guidelines beim Umstieg behilflich zu sein (AIMS, 2017). Ob und wann eine Umstellung von SDI-Technologien auf IP- Technologien, bezogen auf diese Arbeit vor allem im deutschsprachigen Raum, von Vorteil sein kann, soll unter anderem im Folgenden bearbeitet werden.

1.2 Motivation

Die Diskussion um die Vor- und Nachteile bei einem Umstieg dieser Größenordnung ist in Broadcastunternehmen seit mehreren Jahren im Gange. Allein aufgrund der Tatsache, dass technische Komponenten nicht ohne Weiteres von heute auf morgen ausgetauscht werden können, stellt sich für viele Unternehmen die Frage nach der Sinnhaftigkeit und Umsetzbarkeit der Umstellung.

Mit dem Umstieg wird sich voraussichtlich nicht nur die Technologie im Hintergrund ändern, sondern auch die Arbeitsweise wie mit dieser umgegangen werden soll. Des Weiteren wird der neue Standard neue Möglichkeiten bieten Workflows effizienter oder vielleicht sogar auch günstiger darzustellen. Ergebnis dieser Arbeit soll eine Auseinandersetzung mit der Thematik und deren technischen Grundlagen sein, sowie einen Überblick über den Status Quo in Broadcastunternehmen des deutschsprachigen Raums bieten.

1 1 Einleitung 1.3 Forschungsfragen

Im Rahmen dieser Arbeit sollen die folgenden Forschungsfragen durch Literaturrecherche und Experteninterviews behandelt, sowie auch beantwortet werden: 1. Welche nennenswerten technischen und wirtschaftlichen Vor- bzw. Nachteile bietet eine Umstellung von SDI- auf IP-Technologien?

2. Auf welchem Stand der Entwicklung befindet sich die Implementierung der IP Standards derzeit im deutschsprachigen Raum?

3. Inwieweit besteht derzeit aus technischer und wirtschaftlicher Sicht die Veranlassung von SDI- auf IP-Technologien umzusteigen?

1.4 Methoden

Nachfolgend werden die in dieser Arbeit die angewandten Methoden erläutert. Der erste Abschnitt der Arbeit besteht aus einem theoretischen Teil, welcher mittels Literaturrecherche und einer kurzen Vor-Ort-Recherche auf der Branchenmesse IBC 2019 durchgeführt wurde. Der zweite, empirische Teil basiert auf Leitfadengestützten Experteninterviews, welche mittels einer qualitativen Inhaltsanalyse bearbeitet wurden.

1.4.1 Literaturrecherche

Der theoretische Teil der Arbeit wird mittels eines State-of-the-Art Reports umgesetzt. Dabei wurden klassische Literatur, wissenschaftliche Publikationen und Online-Ressource kombiniert, da die vorhandene wissenschaftliche Literatur alleine den aktuellen Stand der Technik aufgrund der rasant voranschreitenden Entwicklung der Technologie nicht abbilden kann. Zu den Online-Ressourcen zählen unter anderem Veröffentlichungen von Herstellern, Standardisierungsorganisationen und Online-Fachzeitschriften im Bereich Broadcast, IP und Netzwerktechnik. Um die theoretischen Grundlagen für den State-of-the-Art Report zu ergänzen und zu vertiefen, wurde eine Vor-Ort- Recherche auf der International Broadcasting Convention 2019 (IBC) durchgeführt, wodurch ein besseres Verständnis der recherchierten Informationen erzielt werden konnte.

2 1 Einleitung

1.4.2 Leitfadengestütztes Experteninterview Der empirische Teil der Arbeit wird durch die Diskussion der Forschungsfragen anhand der Auswertung der leitfadengestützten Experteninterviews dargestellt. Experten verfügen aufgrund ihrer beruflichen Position und langjährigen Erfahrung über Spezialwissen zu einem bestimmten Thema, welches durch andere Quellen nur sehr schwer oder gar nicht bezogen werden kann. Dieses Spezialwissen setzt sich aus Daten und Fakten zu einem diskutierten Thema zusammen welches als „technisches Wissen“ bezeichnet wird (Bogner et al., 2014, S. 17f).

Die im Anschluss durchgeführte Auswertung der Interviews mit ihrem Fach- und Spezialwissen erfolgt mittels inhaltlich strukturierter und qualitativer Inhaltsanalyse. Zur computergestützten Durchführung wird die Software MAXQDA verwendet. MAXQDA ist eine Software zur qualitativen Forschung mithilfe derer eine Vielzahl an Daten analysiert und ausgewertet werden können (Kuckartz, 2016; VERBI Software GmbH, 2020).

1.5 Vorgehensweise bei den Experteninterviews

1.5.1 Interviewleitfaden Der Interviewleitfaden gilt als ein wichtiges Element in der qualitativen Forschung. Er dient dabei zum einen als Hilfe in der Strukturierung des Themengebiets und zum anderen bietet er bei der Durchführung des Interviews eine Orientierungshilfe. So hilft bereits die Erstellung des Leitfadens im Vorfeld dabei, das Themengebiet inhaltlich und methodisch einzugrenzen (Bogner et al., 2014, S. 27f).

Als Einstiegsfrage wird immer nach der aktuellen Position und dem Aufgabenbereich des Experten gefragt. Diese Frage ist für den Interviewpartner leicht zu beantworten und sorgt hierdurch für ein angenehmes Gesprächsklima. Weiters wird zu Beginn nach der persönlichen Erfahrung zu dem behandelten Thema gefragt, welche ebenso zumeist positiv beantwortet werden kann (Bogner et al., 2014, S. 60f).

Im Anschluss wurden auf Basis der Forschungsfragen Themenblöcke definiert und hierzu Fragen formuliert. Um sich dem Gespräch anpassen zu können wurden Unterfragen und Punkte hinzugefügt, die je nach Verlauf des Gesprächs verwendet wurden. Wurden beispielsweise gewisse Punkte bei der Beantwortung einer Frage bereits angesprochen in der sie nicht erwartet wurden, so wurde auf

3 1 Einleitung die spätere Verwendung dieser Punkte in der ursprünglich dafür vorgesehenen Frage darauf verzichtet.

Während der Gespräche diente der Leitfaden hauptsächlich als Orientierung und musste je nach Experte und Situation angepasst werden. So haben Inhalt und Reihenfolge der Fragen je nach Gesprächspartner variiert. Bei der qualitativen Forschung wird im Gegensatz zur quantitativen Forschung keine idente Fragestellung und Standardisierung der Fragen vorausgesetzt um eine Vergleichbarkeit der durchgeführten Interviews zu gewährleisten (Bogner et al., 2014, S. 28).

Wie bei Interviews üblich, stellten sich bereits nach den ersten Interviews Lerneffekte ein. So wurden Fragen, die nicht explizit zum Inhalt der Arbeit beitragen, gestrichen, sowie neu gewonnenes Wissen und Informationen ergänzt und den Fragen hinzugefügt. Der Grundaufbau des Interviewleitfadens blieb jedoch über sämtliche Interviews hinweg gleich (Gläser & Laudel, 2010, S. 194).

1.5.2 Expertenauswahl Die für diese Arbeit ausgewählten Experten zeichnen sich durch eine leitende Position in der Broadcastbranche, in speziellen Rundfunkanstalten, im DACH- Raum aus. Alle haben mehrjährige einschlägige Berufserfahrung, sowie, die meisten, bereits Praxiserfahrung mit IP-Technologien. Wenn diese Praxiserfahrung nicht gegeben ist, haben sie zumindest einen Überblick über die theoretischen Möglichkeiten in diesem Bereich oder planen bereits eine Integration von IP-Technologien in ihrem Unternehmen.

Die folgenden Experten haben sich für ein Interview im Rahmen dieser Arbeit bereiterklärt: - Georg Kuntner o Produktionssysteme Fernsehen / Planung Rundfunktechnik, ORF - Matthias Barth o Senior Solution Architect, ProSiebenSat.1 Tech Solutions - Philipp Beuchert o Head of Broadcast and Production Systems, ATV Privat TV - Sandro Furter o Projektleiter Medientechnologie, SRF - Stefan Kollinger o Referent des Technischen Direktors, ORF

4 1 Einleitung

Die Reihenfolge der Auflistung entspricht der Reihenfolge in welcher die Interviews durchgeführt wurden.

1.5.3 Planung und Durchführung der Interviews Die jeweiligen Experten der Rundfunkanstalten wurden alle per E-Mail angefragt. In der ersten Anfrage wurde nur der Titel der Arbeit genannt und der Inhalt derer grob umrissen um dem Interviewpartner die Möglichkeit zu geben für sich zu evaluieren, ob er zu diesem Themengebiet Aussagen treffen kann. Nach Wunsch und Nachfrage wurde zu diesem Zeitpunkt noch einmal nähere Fragen zu der Arbeit beantwortet. Der im Voraus definierte Interviewleitfaden wurde dabei jedoch nicht übermittelt um ein sich zu genaues Vorbereiten der Experten zu verhindern.

Das erste Interview mit Georg Kuntner wurde im August 2019 vor Ort im ORF- Zentrum durchgeführt. Die folgenden Interviews mit Matthias Barth, Philipp Beuchert und Sandro Furter im Zeitraum von März bis April 2020, und das letzte Interview mit Stefan Kollinger im Juli 2020 wurden mittels Skype oder Teams durchgeführt. Dies war der zu dem Zeitpunkt vorherrschenden Situation mit Covid-19 geschuldet. Durch diese nicht ganz so persönliche Aufzeichnung der Interviews konnten jedoch keine Unterschiede der Ausführlichkeit in der Beantwortung der Fragen oder des Gesprächsverlauf festgestellt werden.

Durch die zeitliche Differenz der Interviewaufzeichnung mit den beiden Experten des ORF von beinahe einem Jahr konnte hier unter anderem auch gut beobachtet werden wie weit sich zum einen das Unternehmen selbst und zum anderen die Standards weiterentwickelt haben.

Bereits im Vorfeld wurde die Dauer des Interviews auf etwa eine Stunde festgelegt. Dieser Zeitraum hat sich im Laufe der Interviews bewährt und konnte jedes Mal eingehalten werden. Die Interviews selbst wurden mit einem Tonaufzeichnungsgerät, Smartphone oder Aufzeichnungssoftware am Laptop je nach Situation immer mindestens mit zwei Methoden gleichzeitig aufgezeichnet, um eine eventuell schlecht verständliche und dadurch unbrauchbare Aufnahme verhindern zu können. Im Anschluss an die Gespräche wurden die Interviews für die spätere Analyse transkribiert.

1.5.4 Transkriptionsregeln Für die korrekte Durchführung der Transkription der Experteninterviews wurden die folgenden Transkriptionsregeln erstellt, um eine bessere Lesbarkeit und Verständlichkeit beim Leser zu erzielen:

5 1 Einleitung

- Das Gesprochene wird nicht zusammengefasst, sondern wird wortwörtlich transkribiert - Umgangssprachliche Ausdrücke und Dialekte werden in orthographisch korrektes Deutsch übersetzt - Parasprachliche Äußerungen, wie beispielsweise lachen oder räuspern, werden ebenso transkribiert wenn sie für das Verständnis des Lesens notwendig sind und werden in Klammern dargestellt: „(lachen)“ - Zur besseren Verständlichkeit des Gesprochenen werden Beistriche zur Gliederung gesetzt - Redepausen oder Unterbrechungen des Interviews werden je nach Länge mit Punkten und einer eventuellen Erklärung in Klammern gekennzeichnet: „... (Off-Topic)...“ - Akustisch unverständliche Wörter oder Äußerungen werden mit eingeklammerten Fragezeichen dargestellt: „(???)“

1.5.5 Inhaltlich strukturierende qualitative Inhaltsanalye Das Modell der inhaltlich strukturierenden qualitativen Inhaltsanalyse nach Kuckartz basiert auf einer deduktiv-induktiven Vorgehensweise bei der Bildung von Kategorien. Bei dieser werden zu Beginn die gesammelten Daten mit einem Kategoriensystem codiert. Dieses wurde deduktiv gebildet, basiert also auf den Forschungsfragen und der im Vorfeld durchgeführten Recherche. Im Anschluss werden anhand dieses kategorisierten Materials weitere Subkategorien gebildet. Mit diesen induktiv gebildeten Subkategorien werden die gesamten Daten nochmals codiert. Die Ergebnisse dieser erneuten Codierung werden daraufhin basierend auf den Kategorien ausgewertet und interpretiert. Aufgrund des Wechsels zwischen deduktiver und induktiver Bildung von Kategorien wird eine dem Material gegenüber offene Vorgehensweise sichergestellt (Kuckartz, 2016, S. 95f).

Die weitere Auswertung der Experteninterviews wurde anhand des von Kuckartz beschriebenen Ablaufschemas der inhaltlich strukturierenden Inhaltsanalyse und dessen sieben Phasen durchgeführt. Der Ablauf dieser Phasen ist in unten angeführter Grafik (Abbildung 1) dargestellt und wird im Folgenden näher beschrieben. Alle folgenden Schritte wurden in der Software MAXQDA durchgeführt (Kuckartz, 2016, S. 100f).

6 1 Einleitung

Abbildung 1. Ablauf der inhaltlich strukturierenden Inhaltsanalyse (Kuckartz, 2016, S. 100)

1.5.5.1 Phase 1: Initiierende Textarbeit In der ersten Phase wurden die Interviews, nach der Transkription der Audioaufnahmen inklusive Zeitmarkern, sorgfältig durchgearbeitet und entsprechend formatiert. Wichtige Textstellen sowie mögliche direkte Zitate wurden markiert, um erste Informationen zur Bildung weiterer Kategorien zu erhalten.

1.5.5.2 Phase 2: Entwickeln von thematischen Hauptkategorien Aus den Forschungsfragen und der vorangegangen Recherche wurden die einzelnen Hauptkategorien deduktiv gebildet. Hierzu wurden unter anderem Themengebiete als Grundlage für die Kategorien herangezogen. Daraus haben sich die folgenden Hauptkategorien entwickelt, welche als sogenannte Codes in MAXQDA angelegt wurden: - Informationen zur Person - Vor/Nachteile von IP-Technologien - Vor/Nachteile von SDI-Technologien - Gemeinsamkeiten - Herausforderungen

7 1 Einleitung

- Möglichkeiten - Erfahrungen - Aktuelle Projekte - Umstiegs-Szenarien - Zukunftsaussichten

1.5.5.3 Phase 3: Codierung des gesamten Materials mit den Hauptkategorien Nach dem Anlegen der Codes wurden in dieser Phase die Interviews sequenziell durchgearbeitet und entsprechend passende Textstellen durch Auswählen der Hauptkategorien dieser zugeordnet. Wenn Textstellen mehrere Themengebiete umfassen, ist eine mehrfache Kategorisierung dieser Passagen ebenfalls möglich.

1.5.5.4 Phase 4: Zusammenstellen aller mit der gleichen Hauptkategorie codierten Textstellen In Phase 4 wurden sämtliche gleich codierten Textstellen nach Kategorien zusammengestellt. Durch dieses „Text Retrieval“ (Kuckartz, 2016, S. 182) genannte Vorgehen wird eine übersichtliche Darstellung des thematisch kategorisierten Materials ermöglicht.

1.5.5.5 Phase 5: Induktives Bestimmen von Subkategorien am Material In dieser Phase wurden anhand der zuvor definierten Hauptkategorien jeweils mehrere Subkategorien definiert. Zu Beginn wurde eine Auswahl an Subkategorien an Teilen des Materials erprobt und im Anschluss weiter ausdefiniert. Wenn sich bei der Codierung weitere Subkategorien herausgestellt haben, wurden diese ergänzt und daraufhin weiter zusammengeführt.

1.5.5.6 Phase 6: Codieren des kompletten Materials mit dem ausdifferenzierten Kategoriensystem In der sechsten Phase wurde das gesamte Material, welches bereits in Hauptkategorien codiert wurde, erneut sequentiell durchgearbeitet und dieses Mal den ausdifferenzierten Subkategorien zugeordnet. Diese Zuordnung wurde auf die selbe Art wie bereits in der dritten Phase durch Auswählen der jeweiligen Textpassagen durchgeführt.

1.5.5.7 Phase 7: Einfache und komplexe Analysen, Visualisierungen In der letzten Phase wurde zuerst eine Themenmatrix erstellt welche in MAXQDA „Code-Matrix“ genannt wird. Durch diese erhält man einen Überblick über die

8 1 Einleitung

Kategorien und deren Häufigkeiten. In Abbildung 2 ist eine auf die Hauptkategorien reduzierte Code-Matrix dargestellt. Diese ist jedoch auch ausklappbar um auf die Subkategorien zugreifen zu können.

CodesystemCodesystem Georg Kuntner Matthias Barth Philipp Beuchert Sandro Furter Stefan Kollinger SUMME Person 11 Vorteile IP 30 Nachteile IP 26 Vorteile SDI 17 Nachteile SDI 4 Gemeinsamkeiten 6 Herausforderungen 43 Möglichkeiten 9 Erfahrungen 11 Aktuelle Projekte 17 Umstiegs-Szenarien 22 Zukunftsaussichten 28 SUMME 41 51 33 58 41 224 Abbildung 2. Ansicht der Hauptkategorien in der Code-Matrix (Ruckenstuhl, 2020)

Im Anschluss daran wurde das gesamte Material nach Subkategorien ausgewertet. Hierzu wurde jeweils immer eine Subkategorie ausgewählt und sämtliche zugehörigen Textpassagen aus allen Interviews zusammengefasst. In Abbildung 3 ist ein Ausschnitt der Zusammenfassung für den Code „Etablierung“ zu sehen.

Abbildung 3. Textsegmente mit aktiviertem Code „Etablierung“ (Ruckenstuhl, 2020)

9 1 Einleitung 1.6 Anmerkung zu Formulierungen

Um eine bessere Lesbarkeit der Arbeit zu erzielen, wird auf geschlechterspezifische Formulierungen und Bezeichnungen verzichtet. Wenn personenbezogene Bezeichnungen nur in männlicher Form vorhanden sind, beziehen sie sich immer sowohl auf Frauen wie auch auf Männer. Als Beispiel ist die Bezeichnung „Experte“ zu sehen, welche sich auf sämtliche Geschlechter bezieht, anstatt Formulierungen wie „ExpertInnen“ oder „Expertinnen und Experten“ zu verwenden. Diese Formulierung bedeutet keine Geschlechterdiskriminierung oder Verletzung des Gleichheitsgrundsatzes.

10 2 Einführung

2 Einführung

In diesem Kapitel werden grundlegende Informationen über die gängigen Standards in der Broadcastumgebung, sowie Basiswissen über IP-basierte Technologien erläutert. Wichtige Protokolle und Technologien, die für die Umsetzung von SMPTE ST 2110 Projekten notwendig sind, werden erklärt. Weiters werden bestehende Allianzen, welche für den Fortschritt der Umsetzung von Standards mitverantwortlich sind, vorgestellt.

2.1 SDI

Um zu verstehen, wo genau die Unterschiede von SDI- zu IP-Technologien, und im speziellen zu SMPTE ST 2110, liegen, muss man diverse Eigenschaften des SDI-Standards kennen. Im Folgenden wird auf einige davon eingegangen.

2.1.1 SDI Standards SDI Standards werden seit mehr als 30 Jahren eingesetzt und von der SMPTE spezifiziert. Die aktuell verwendeten und wichtigsten SDI Standards, gereiht nach dem Einführungsjahr, sind folgende:

2.1.1.1 SD-SDI Der erste SDI Standard ist im SMPTE Standard ST 259 aus dem Jahr 1989 spezifiziert (Hudson, 2013b). Dieser ist auf SD (Standard Definition) Signale im Zeilensprungverfahren mit einer Farbtiefe von 10-Bit und einer Farbunterabtastung von 4:2:2 ausgelegt. Typische Datenraten liegen zwischen 143 Mbit/s und 360 Mbit/s. Aus diesem Standard gehen auch die bis heute bekannten Unterschiede zwischen 576i50 (für PAL) und 480i59,94 (für NTSC) hervor (SMPTE, 2008). Mit 75Ω Koaxial Kabeln können hier Punkt zu Punkt Verbindungslängen von über 400m erreicht werden (Hudson, 2013a).

2.1.1.2 HD-SDI Der heute gängigste Standard ist der HD-SDI Standard SMPTE ST 292. Der 1998 eingeführte Standard für unkomprimierte hochauflösende HD (High

11 2 Einführung

Definition) Signale spezifiziert und gewährleistet die Übertragung eben jener. Der grundlegende Aufbau des Standards unterscheidet sich nicht großartig von seinem Vorgänger, wurde jedoch um beispielsweiße CRC (Cyclic Redundancy Check) zum Fehlerschutz, und LN (Line Number) als Zeilennummerierung erweitert (Schmidt, 2013, S. 154). Auch mit diesem Standard werden Signale mit 10 Bit Farbtiefe und 4:2:2 Farbunterabtastung übertragen, jedoch erhöhen sich die Auflösungen der Formate (1280x720, 1920x1080 und 2048x1080), die Signale können nun auch als Vollbilder übertragen werden (bspw. 1080p bis 30fps), und dementsprechend erhöht sich auch die Datenrate auf 1,485 Gbit/s. Meist wir jedoch aufgrund der Einfachheit von 1,5 Gbit/s gesprochen (SMPTE, 2018c). Durch die erhöhte Datenrate sind bei HD-SDI nur noch Kabellängen von 300m möglich (Hudson, 2013a).

2.1.1.3 3G-SDI SMPTE ST 424 wurde 2006 veröffentlicht und wurde danach auch des Öfteren weiterentwickelt und angepasst. So gibt es auch den neueren Standard ST 425 der auf ST 424 basiert (Hudson, 2013b; SMPTE, 2014). Mit diesen Standards sind eine Datenrate von 2,97 Gbit/s (3G) und Formate bis 1080p60 möglich. Bei 3G-SDI gibt es drei verschiedene Zuordnungsformate: Level A, Level B-DL (Dual Link) und Level B-DS (Dual Stream). Diese drei Level sind unterschiedlich aufgebaut und für verschiedene Anwendungszwecke konzipiert. Dadurch sind sie nicht untereinander kompatibel. So gibt es bei der Konvertierung zwischen Level A und Level B-DL ein Delay von mindestens einer Videozeile bei jedem Konvertierungsvorgang. Befinden sich noch Embedded Audio oder andere zusätzliche Daten im Signal, kann sich das Delay weiter erhöhen und zu einer zusätzlichen Komplexität bei der Korrektur der Positionierung der Datenpakete führen (Hudson, 2013b). Auch bei diesem Standard verkürzt sich die maximal mögliche Kabellänge im Vergleich zum Vorgänger wieder, es sind nun nur noch 200m möglich (Hudson, 2013a).

2.1.1.4 6G-SDI 2015 wurde SMPTE ST 2081 veröffentlicht, welcher genau wie 3G-SDI eine Single-Link, aber auch Dual-Link und Quad-Link Variante spezifiziert. Bei Single- Link kommt eine Datenrate von 5,940 Gbit/s (6G) zum Einsatz. Typische Formate sind auch hier 1080p bis zu 60fps mit 10 Bit Farbtiefe und einer Farbunterabtastung von 4:2:2. Es sind jedoch bis zu UHD-2 Signale mit einer Auflösung von 7680x4320, Farbunterabtastung von 4:4:4:4 und 12 Bit Farbtiefe mit Quad-Link (4 x 5,940 Gbit/s) möglich (SMPTE, 2018a). Kabellängen sind bei 6G-SDI auf etwa 100m beschränkt (Hudson, 2013a).

12 2 Einführung

2.1.1.5 12G-SDI Ebenfalls 2015 eingeführt wurde der Standard ST 2082, welcher die Übertragung von Videoformaten mit einer Datenrate von 11,88 Gbit/s (12G) spezifiziert. Wie bei 6G-SDI gibt es auch hier zusätzlich zur Single-Link Variante eine Dual-Link und eine Quad-Link Variante. Die unterstützten Formate sind ebenfalls ähnlich, es kommt noch die Möglichkeit 120fps bei bestimmten Formaten nutzen zu können hinzu (SMPTE, 2018b). Die maximale Kabellänge verkürzt sich weiter auf etwa 60m (Hudson, 2013a).

2.1.1.6 24G-SDI SMPTE ST 2083 befindet sich derzeit noch in Entwicklung. Mit diesem sollen in Zukunft Datenraten von rund 24 Gbit/s im Single-Link möglich sein. Mit Quad- Link sind Formate mit Auflösungen von 7680x4320 mit 60fps realisierbar. Die Grafik (Abbildung 4) zeigt einen Ausschnitt der Grenzen und Möglichkeiten der aktuelleren SDI Standards. Die maximale Entfernung, die mit 75Ω Koaxialkabeln zurückgelegt werden kann, verkürzt sich hier nun auf unter 40m (Hudson, 2013a).

Abbildung 4. SDI Formate (Hudson, 2013a)

2.1.2 Ancillary Data Space Der Ancillary Data Space ist auf die analoge Videotechnik zurückzuführen. Zu Zeiten der damaligen Röhrenfernsehertechnik war ein Elektronenstrahl für den

13 2 Einführung

Bildaufbau nötig. Dieser Strahl baut jedes Bild von links nach rechts und von oben nach unten auf. Bei den in Europa üblichen Formaten von 25 Vollbildern pro Sekunde benötigt der Strahl für jedes einzelne Bild 40ms, bei 50 Halbbildern sind es 20ms. Diese Zeit steht jedoch nicht allein dem Schreiben eines Bildes zur Verfügung, da der Strahl nachdem er am rechten Bildrand angekommen ist, eine gewisse Zeit benötigt um wieder an den linken Bildrand zu gelangen. Selbiges gilt wenn er am unteren Ende des Bildes angekommen ist und wieder nach oben, an den Beginn des nächsten Bildes, springt. Während dieser Zeit des Zurückspringens darf der Strahl nicht sichtbar sein und wird deshalb ausgeschalten, bzw. ausgetastet. Daraus ergibt der Begriff Austastlücke, wobei man hier zwischen der horizontalen (Strahl springt von links nach rechts) und der vertikalen (Strahl springt vom Bildende an den Bildanfang) Austastlücke unterscheiden muss (Schmidt, 2013, S. 43).

Das digitale Videosignal welches in der ITU-Rec BT.601 spezifiziert ist, orientiert sich an dem ursprünglichen analogen Signal (ITU, 2011). Hier werden die Austastlücken zum ANC (Ancillary Data Space). Die horizontalen Austastlücken werden zum HANC (Horizontal Ancillary Data Space) und die vertikale Austastlücke zum VANC (Vertical Ancillary Data Space). Durch den Fortschritt der digitalen Technik können diese Austastlücken mit zusätzlichen Daten gefüllt werden. Dazu zählen unter anderem Timecode Daten, Untertitel, Fehlerkorrekturen und eingebettete Audiodaten (siehe 2.1.3 Embedded Audio) (Schmidt, 2013, S. 145).

Der HANC Bereich beginnt dabei direkt nach einem EAV (End of Active Video), der VANC Bereich direkt nach einem SAV (Start of Active Video). Jedes Zusatzdatenpacket wird dabei von einem ADF (Ancillary Data Flag) angeführt und darf sich mit keinem anderen Bildteil (Video, SAV, EAV) überlagern. Vorausgesetzt, dass die ANC Pakete zusammenhängend sind, sind auch mehrere solcher erlaubt, wobei die beiden ANC Bereiche jedoch für bestimmte Zwecke reserviert sind (Poynton, 2012, S. 437).

In der Grafik (Abbildung 5) werden die genannten Bereiche in einem Komponenten Signal nochmals genauer deutlich.

14 2 Einführung

Abbildung 5. ANC Bereiche in den Austastlücken (Schmidt, 2013, S. 145)

2.1.3 Embedded Audio Wie im letzten Kapitel erwähnt, können Audiodaten im ANC Bereich des SDI- Signals eingebettet werden. Dies ist vor allem in großen Systemen nützlich, in denen ein separates Routen von Audiodaten eine Kostenfrage sein kann. Weiters ist es von Vorteil, da die Audiostreams direkt mit dem zugehörigen Videostream verknüpft sind (Lewis & Waidson, 2009, S. 45).

In SMPTE ST 272 sind die Spezifikationen für SD-Formate des SMPTE ST 259, in SMPTE ST 299 jene für HD-Formate des SMPTE ST 292 enthalten (Lewis & Waidson, 2009, S. 45). Dabei ist in ST 299-1 (2009) spezifiziert, dass maximal 16 AES Audiokanäle eingebettet werden können. Die Audiokanäle dürfen Abtastraten von 32 kHz, 44.1 kHz oder 48 kHz haben, wenn alle 16 möglichen Kanäle genutzt werden sollen. Es ist jedoch auch eine Abtastrate von 96 kHz möglich, dann können jedoch nur 8 Audiokanäle belegt werden. Die Kanäle werden dabei in Gruppen von Streams übermittelt, wobei jede Gruppe eine einzigartige Ancillary Data ID hat. Die reinen Audiodatenpakete werden in den HANC Bereich des Cb/Cr Datenstroms, und die Pakete zur Audiosteuerung in den HANC Bereich des Y Datenstroms eingebettet.

Ein Jahr später (2010) wurde SMPTE ST 299-2 spezifiziert, welcher die maximale Anzahl an eingebetteten Audiokanälen auf maximal 32 erhöht. Diese 16 zusätzlichen Kanäle enthalten wieder vier Gruppen die jeweils bis zu vier 24- bit Audiokanäle mit Abtastraten von 32 kHz, 44.1 kHz oder 48 kHz haben. Alternativ können auch pro Gruppe zwei Audiokanäle mit jeweils 96 kHz Abtastrate eingebettet werden. Diese Erweiterung wurde vorgenommen, um über einen einzelnen SMPTE ST 425 Level A 3G-SDI Stream 32 Audiokanäle übertragen zu können (SMPTE, 2010).

15 2 Einführung

2.1.4 Synchronisierung Damit Videosignale beim Empfänger genauso ankommen wie sie beim Sender ausgesandt werden, muss ein Gleichlauf mit Synchronsignalen erreicht werden. Bei analogen Signalen werden dabei Spannungsimpulse im Millivolt Bereich benutzt, um den Zeilenwechsel in der horizontalen Austastlücke und den Bildwechsel in der vertikalen Austastlücke zu signalisieren (Schmidt, 2013, S. 45f).

In digitalen SD-Signalen wird dieser analoge Spannungsimpuls durch zwei Bit codiert, wobei ein Bit das Ende der Zeile signalisiert und das zweite Bit zur Unterscheidung der horizontalen zur vertikalen Synchroninformation genutzt wird. Da diese beiden Bits sehr wichtig sind, werden sie fehlergeschützt und von besonders gut erkennbaren Bitkombinationen umgeben. Diese komplette Kette ergibt das Timing Reference Signal (TRS). Dieses TRS tritt pro Zeile zweimal auf, um jeweils den Start of Active Video (SAV) und das End of Active Video (EAV) zu kennzeichnen, und wird in der horizontalen Austastlücke übertragen. Das TRS ist durch eine spezielle Bitfolge, die ansonsten nicht im Datenstrom vorkommt, sehr gut erkennbar (Schmidt, 2013, S. 140f). Dieses Prinzip ist bei HD-Signalen fast genauso im Einsatz, einzig bei 1080i Signalen werden den EAV Daten noch zusätzliche Informationen zur Zeilennummerierung und Fehlerschutz angefügt (Schmidt, 2013, S. 153).

Um im Studiobetrieb den Gleichlauf aller Videosignale bei Signalwechseln zu gewährleisten, werden sämtliche Signalquellen an einen zentralen Studiotakt angepasst. Als Taktsignal wird bei SD-Signalen ein Black-Burst-Signal (BB) mit einem bipolaren Synchronimpuls und bei HD-Signalen ein Black-Signal mit Tri- Level-Sync (TLS) verwendet. Sollten SD- und HD-Signale in derselben Produktionsumgebung verwendet werden, müssen dementsprechend auch beide Taktsysteme vorhanden sein (Schmidt, 2013, S. 724f).

In der Abbildung unten (Abbildung 6) ist ein vereinfachter Aufbau eines Studiotaktsystems dargestellt.

16 2 Einführung

Abbildung 6. Studiotakt mit angeschlossenen Geräten (Schmidt, 2013)

2.2 Netzwerktechnik

In den folgenden Unterkapiteln werden die Grundlagen der Netzwerktechnik behandelt, welche für das grundlegende Verständnis der Unterschiede von SDI- basierter Signalübertragung zu IP-basierter Signalübertragung notwendig sind.

2.2.1 Netzwerke

2.2.1.1 Definition Ein Netzwerk stellt Datenendgeräten eine Infrastruktur bereit, um ihnen die Kommunikation untereinander, den Datenaustausch und eine gemeinsame Nutzung von Ressourcen und Diensten zu ermöglichen. Dabei muss sich der Endnutzer nicht mit den Einzelheiten der Verbindung auseinandersetzen. Dies wird vom Netzwerk selbst mittels vorgegebener Regeln, den Netzwerkprotokollen, übernommen. Diese übernehmen das Definieren der Bedingungen für den Verbindungsauf- und Abbau, den Datenaustausch und wie im Fehlerfall vorgegangen werden soll. Netzwerkprotokolle kann man als das Bindeglied zwischen der Hardware und den Softwareanwendungen sehen. Weiter unten werden sie nochmals genauer behandelt. (Zisler, 2018, S. 20).

2.2.1.2 Definition Netzwerkprotokolle Weiters kann man zwischen verbindungsorientierten und verbindungslosen Netzwerkprotokollen unterscheiden. Beide haben je nach Anwendung ihre Vor- und Nachteile. Erstere stellen vor der Datenübertragung eine Verbindung zwischen den Kommunikationspartnern her. Die Partner identifizieren sich gegenseitig und übertragen die Daten. Im Anschluss der Datenübertragung wird

17 2 Einführung die Verbindung wieder abgebaut. Der Vorteil liegt hier in der erhöhten Sicherheit der Verbindung, welche für Anwendungen ohne eigene übertragungssichernde Methoden verfügen, wie z.B. Telnet (Teletype Network) für Remotesessions und FTP (File Transfer Protocol) (Zisler, 2018, S. 22).

Die verbindungslosen Netzwerkprotokolle versenden die Daten in sich geschlossenen Datagrammen ohne vorher durchgeführten Verbindungsaufbau oder Empfangsbestätigung. Dies führt im Vergleich zu verbindungsorientierten Protokollen zu höheren Datendurchsätzen und weniger Netzlast. Im Gegenzug muss nun von den übergeordneten Schichten, also den Anwendungen, die Flusskontrolle und Fehlerkorrektur vorgenommen werden. Anwendungen die selbst über transaktionsichernde Methoden verfügen, wie beispielsweise Datenbanken, verwenden meist solche verbindungslosen Netzwerkprotokolle (Zisler, 2018, S. 22).

In Kapitel 2.2.5 werden einige Netzwerkprotokolle nochmals genauer erläutert.

2.2.1.3 Datenpakete Die meisten Netzwerkformen übertragen Daten mittels Datenpaketen. Dazu wird ein Verfahren namens Paketvermittlung (Packet Switching) angewandt. Dieses funktioniert komplett entgegengesetzt der Funktionsweise der älteren Schaltkreisvermittlung (Circuit Switching), welche bei den ursprünglichen Telefonleitungen zum Einsatz kam. Bei der Paketvermittlung wird zu keinem Zeitpunkt der Datenübertragung eine direkte Verbindung der verwendeten Endpunkte hergestellt. Dafür sind sie über ein loses Netz von Vermittlungsstellen (Router) miteinander verbunden. Um über diese Verbindung Daten übertragen zu können, müssen folgende Schritte durchgeführt werden (Kersken, 2013, S. 174).

Zuerst werden die Daten in kleinere Einheiten, eben bereits erwähnte Datenpakete, unterteilt. Jedes dieser Datenpakete erhält eine Absender- sowie Empfängeradresse. Nun übergibt der Absender jedes Datenpaket an den nächstgelegenen Router, welcher wiederrum das Paket an einen weiteren Router übermittelt, bis es bei seinem Empfänger angekommen ist. Beim Empfänger werden die Datenpakete entgegengenommen und interpretiert. Dies geschieht, je nach Daten- und Übertragungsart, auf unterschiedliche Weise, die sich die Endstellen im Vorhinein untereinander ausgemacht haben.

Standardmäßig wird weder der Erfolg noch die vollständige Auslieferung aller Datenpakete garantiert. Es wird ebenso auch keine Reihenfolge festgelegt in der die Pakete übertragen werden. Da jedes Datenpaket theoretisch einen anderen Weg durch das Netzwerk nehmen kann, kann es vorkommen, dass ein später

18 2 Einführung abgesendetes Paket vor einem früher abgesandten Paket beim Empfänger ankommt. Zu dieser potenziell unsicheren Art der Datenübertragung mittels Paketvermittlung wird eine zusätzliche Erfolgskontrolle implementiert, um die Übermittlung für bestimmte Anwendungen zuverlässiger zu gestalten. Dazu werden die einzelnen Datenpakete durchnummeriert, damit die korrekte Reihenfolge beim Empfänger wiederherzustellen (Kersken, 2013, S. 174f).

2.2.2 OSI-Referenzmodell Das OSI-Referenzmodell wurde ab 1978 von der Standardisierungsorganisation ISO (International Standardization for Organisation) entwickelt und beschreibt mittels sieben Schichten die verschiedenen Aspekte der Netzwerkkommunikation. Beim OSI- (Open Systems Interconnect) Modell handelt es sich um keinen Standard welcher konkrete Netzwerkprotokolle definiert. Er gibt nur die Funktionen der einzelnen Schichten an. Es kann je nach Netzwerk vorkommen, dass bestimmte Schichten wichtiger sind als andere oder auch, dass Protokolle Funktionen mehrerer Schichten übernehmen. Hierzu werden auch häufig anders angeordnete Schichtenmodelle angewandt, wenn es sich um die konkrete Beschreibung einer bestimmten Art von Netzwerk handelt. In Abbildung 7 sind die sieben Schichten sowie die Verbindungen untereinander dargestellt. Im Folgenden sollen die ursprünglichen OSI Schichten zusammengefasst werden (Kersken, 2013, S. 181f; Zisler, 2018, S. 25f):

Abbildung 7. OSI-Referenzmodell (Kriener, 2008)

19 2 Einführung

2.2.2.1 Layer 1: Bit-Übertragungsschicht (Physical Layer) Die erste und unterste Schicht beschreibt die reine Übertragung der Daten und wie diese elektrisch bzw. physikalisch durchgeführt wird. Dabei werden die Struktur der Signale beschrieben und diverse Aspekte behandelt. Dazu zählen ein zulässiger Amplitudenbereich, die Versand- und Empfangsmethoden sowie Umwandlungsoperationen für Bit-Folgen, Start- und Stoppsignale, und auch Übertragungseigenschaften der verwendeten Medien, wie Kupfer- oder Lichtwellenkabel, Funk oder ähnliches. Die verwendeten Medien oder Netzwerkkarten selbst, sind nicht Bestandteil der Definition. Um die Spezifikationen zu erfüllen, sind die Hersteller selbst dafür verantwortlich.

2.2.2.2 Layer 2: Sicherungsschicht (Data Link Layer) Die zweite Schicht sorgt dafür, dass der physikalische Stromfluss, welcher aus den einzelnen Bits besteht, zu einem Datenfluss wird. Dazu gehört die Regelung des Datenverkehrs in einem Kanal, der von mehreren Geräten genutzt wird (MAC, Media Access Control), sowie die Herstellung und Aufrechterhaltung der Verbindungen zwischen den Geräten (LLC, Logical Link Control). Protokolle die in dieser Schicht verwendet werden, implementieren Fehlerkontrollen (z.B. CRC, Cyclic Redundancy Check) oder Prioritätsinformationen. In dieser Schicht werden die aneinandergereihten Bits in Einheiten bestimmter Größen unterteilt, sowie mit Metainformationen in einem Header versehen. Beim Ethernet Standard spricht man von diesen Datenpaketen als Frames.

2.2.2.3 Layer 3: Vermittlungsschicht (Network Layer) Die dritte Schicht ist auch als Netzwerkschicht bekannt. Sie definiert die Bestandteile und Protokolle eines Netzwerks, welche für die direkte Verbindung von Endgeräten zuständig sind. Hierzu wird Routing benötigt, das Daten in andere logische oder physikalisch inkompatible Netzwerke weiterleitet. All diejenigen Protokolle, die die logischen Adressen der höheren Schichten in physikalische Adressen übersetzen, wie bei Ethernet das ARP (Address Resolution Protocol) Protokoll, gehören auch zu dieser Schicht. Die Daten werden hier ebenso wieder in Pakete unterteilt. Das IP-Protokoll (siehe 2.2.5.2) ist das mit Abstand verbreitetste Protokoll der Vermittlungsschicht.

2.2.2.4 Layer 4: Transportschicht (Transport Layer) In der Transportschicht werden die vorhin bereits erwähnten verbindungsorientierten und verbindungslosen Protokolle angewandt. Beispiele hierfür sind verbindungsorientierte TCP (Transmission Control Protocol, siehe 2.2.5.3) und das verbindungslose UDP (User Datagram Protocol, siehe 2.2.5.4).

20 2 Einführung

Auf dieser Schicht werden unterschiedliche Prozesse durchgeführt, wie z.B. Multiplex-Mechanismen, die bei TCP und UDP dafür sorgen, dass mittels Portnummern die Datenpakete an die richtigen Anwendungen übergeben werden. Einige der Transportprotokolle sind zudem mit Fluss- und Fehlerkontrollen ausgestattet, um die vollständige und korrekte Reihenfolge der Pakete am empfangenden Endgerät zu gewährleisten. Je nach verwendetem Protokoll werden die Datenpakete unterschiedlich bezeichnet, so spricht man etwa von Datagrammen, Sequenzen oder Paketen.

2.2.2.5 Layer 5: Kommunikationssteuerungsschicht (Session Layer) Die fünfte Schicht wird auch als Sitzungsschicht bezeichnet. Sie definiert die Anforderungen von Sitzungen und Datenströmen, ebenso wird die Zweiwegekommunikation zwischen Anwendungen oder Prozessen verschiedener Endgeräte sichergestellt.

2.2.2.6 Layer 6: Darstellungsschicht (Presentation Layer) Die vorletzte Schicht, welche auch als Präsentationsschicht bekannt ist, übernimmt die Übertragung von Daten, sowie standardisierte Codierungs-, Konvertierungs- und Kompressionsaufgaben. Verschiedenste Datenformate, Zeichensätze, grafische Anweisungen und Dateidienste werden auf dieser Schicht verarbeitet. Darunter zählen beispielsweise MPEG, TIFF, GIF oder ASCII.

2.2.2.7 Layer 7: Anwendungsschicht (Application Layer) Die letzte und oberste Schicht ist für die Interaktion und die Kommunikation der verschiedenen Anwendungen, welche Netzwerkzugriff benötigen, zuständig. Dienste die der Nutzer unmittelbar in Verwendung hat, werden in dieser Schicht verarbeitet.

2.2.3 Verbindungsarten Je nachdem an wie viele Teilnehmer eines Netzwerkes ein Datenpaket geschickt werden soll, gibt es unterschiedliche Verbindungsarten (Fairhurst, 2009): - Unicast erlaubt die Übertragung von Informationen von einem Sender zu einem Empfänger. Es handelt sich dabei um eine Punkt-zu-Punkt (P2P) Verbindung, welche die klassische Übertragungsart in Netzwerken darstellt. - Mittels Multicast ist es möglich, Datenpakete von einem oder mehreren Sendern an mehrere Empfänger gleichzeitig zu senden. Diese

21 2 Einführung

Verbindungsart ist für Audio- und Videoübertragungen von großem Vorteil, da dadurch Bandbreite eingespart werden kann. In SMPTE ST 2110 Netzwerken wird hauptsächlich Multicast eingesetzt. - Bei Broadcast werden die Datenpakete von einem Sender an sämtliche verbundenen Empfänger im Netzwerk gesendet.

2.2.4 Ethernet-Standards Ethernet ist der, Stand Heute, am weitesten in lokalen Netzen verbreitete Standard (Kersken, 2013, S. 202). Er spezifiziert unter anderem die Eigenschaften der Netzwerkkomponenten und den Aufbau der versendeten Datenpakete. Bereits in den 1970er Jahren wurde mit der Entwicklung begonnen. Die erste Veröffentlichung fand 1980 statt, welche als IEEE-802.3 Standard bekannt wurde. Im Folgenden werden die aktuelleren, bereits eingeführten und auch zukünftigen Ethernet-Standards, kurz vorgestellt (Riggert, 2014, S. 69f).

2.2.4.1 Gigabit-Ethernet (GbE) 1998 wurde Gigabit-Ethernet als IEEE 802.3z Standard veröffentlicht. Er unterstützt Datenraten von bis zu 1000 Mbit/s über Glasfaser (1000BASE-SX, 1000BASE-LX/EX) und ab 1999 mit dem 802.3ab Standard auch über Twisted Pair Kabel (Riggert, 2014, S. 100f).

2.2.4.2 10-Gigabit-Ethernet (10GbE) Mittels 10GbE als IEEE 802.3ae Standard wurden 2003 Übertragungen mit bis zu 10Gbit/s möglich. Zuerst wieder nur mittels Glasfaser (10GBASE-SR, 10GBASE-LR/ER) und drei Jahre später, 2006, auch mittels hochwertiger Twisted Pair Kabel der Kategorie CAT6 und CAT7. 10GbE war der erste Ethernet-Standard, welcher auf CSMA/CD (Carrier Sense Multiple Access with Collision Detection) verzichtete. Dadurch wurden schnellere Datenraten und größere Entfernungen möglich (Riggert, 2014, S. 105f).

2.2.4.3 25-Gigabit-Ethernet (25GbE) 25GbE (802.3by) wurde 2016 veröffentlicht und wurde speziell für Rechenzentren aus dem 100GbE-Standard entwickelt. Mit diesem Standard sind effizientere Vernetzungen mit reduziertem Energieverbraucht möglich. Als Übertragungsmedium kommen Twinaxial-Kabel (25GBase-KR) und Glasfaser (25GBase-SR, 25GBase-LR/ER) zum Einsatz (Lipinski, 2018a).

22 2 Einführung

2.2.4.4 40-Gigabit-Ethernet (40GbE) 40GbE wurde parallel zum 100GbE-Standard (IEEE 802.3ba) entwickelt. Er wurde spezifiziert um spezielle Anforderungen in optischen Transportnetzen zu unterstützen. Bei der Datenübertragung werden vier Adern bzw. Fasern mit jeweils 10Gbit/s verwendet (Lipinski, 2018b; Riggert, 2014, S. 110f).

2.2.4.5 100-Gigabit-Ethernet (100GbE) Der eben angesprochene 100GbE-Standard wurde 2010 standardisiert. Datenübertragungen sind mittels Twinaxial-Kabel (100GBase-CR10), sowie Glasfaser (100GBase-SR10, 100GBase-LR4, 100GBase-ER4) mit bis zu 100 Gbit/s möglich. Wie bei 40GbE werden die Daten auf mehrere Adern bzw. Fasern aufgeteilt. Bei Glasfaser entweder zehnmal 10 Gbit/s mittels Multimodekabel oder viermal 25 Gbit/s mittels Singlemodekabel (Lipinski, 2018c; Riggert, 2014, S. 110f).

2.2.4.6 200- und 400-Gibabit-Ethernet (200GbE, 400GbE) Ende 2017 wurde der Standard IEEE 802.3bs ratifiziert, welcher Datenübertragungen mit 200Gbit/s und 400Gbit/s ermöglicht. Er definiert die technischen Voraussetzungen um Übertragungen von bis zu 10km über Glasfaserkabel zu ermöglichen. Ursprünglich war für diesen Standard nur die 400GbE Variante geplant, die 200GbE Variante kam später hinzu, da der Aufwand für diesen zusätzlichen Standard relativ gering war, er aber dem Anwender mehr Möglichkeiten und Flexibilität bietet (Anslow & Xenos, 2018; Kesh, 2019).

2.2.4.7 Terabit-Ethernet (TbE) Unter diesen Begriff fallen generell sämtliche Standards über 100 Gbit/s. Derzeit im Gespräch sind Datenraten von bis zu 1.6 Gbit/s. Die Ethernet Alliance hat 2019 eine Roadmap für die Veröffentlichung der diversen Standards herausgegeben (Ethernet Alliance, 2019; Lipinski, 2017).

2.2.5 Netzwerkprotokolle In Kapitel 2.2.1.2 wurde bereits auf die Definition der Netzwerkprotokolle eingegangen. Hier sollen einige wichtige kurz erklärt werden.

2.2.5.1 TCP/IP TCP/IP (Transmission Control Protocol/Internet Protocol) ist eine der ältesten Protokollfamilien und auch heute noch gültig. 1974 wurden in RFC 675 die

23 2 Einführung

Grundzüge von TCP/IP festgelegt. Dies geschah durch das ARPA-Projekt (Advanced Research Projects Agency) der US-Regierung, um Netzwerktechnologien hinsichtlich militärischer Nutzbarkeit weiterzuentwickeln (Zisler, 2018, S. 22f).

Aufgrund der historischen Entwicklung wird es auch oft als DoD-Modell (Department of Defense) oder DDN-Modell (Department of Defense Network) bezeichnet. TCP/IP-Netzwerke können ebenso wie das OSI-Modell in Schichten aufgeteilt werden, welche speziell auf die Gegebenheiten in diesen Netzen angepasst sind. Man kann die Schichten ungefähr miteinander vergleichen. In Tabelle 1 wird dieser Vergleich dargestellt. (Kersken, 2013, S. 184).

Bei TCP/IP sind vier Schichten definiert (Kersken, 2013, S. 184f):

Die erste Schicht, die Netzzugangsschicht (Network Access Layer oder Link Layer) beschreibt die physikalische Datenübertragung, welche mittels vieler unterschiedlicher Protokolle durchgeführt wird. Im OSI-Model entspricht sie den beiden untersten Schichten.

Die Internetschicht (Internet Layer), welche der Vermittlungsschicht ähnelt, ist für die logische Adressierung der Hosts im Netzwerk, sowie das Routing der Daten über verschiedene Netze hinweg, zuständig.

Die Host-zu-Host-Transportschicht (Host-to-Host-Transport Layer oder Transport Layer) kümmert sich um den Datenaustausch der einzelnen Rechner. Dies geschieht meist mittels der Protokolle UDP oder TCP. Sie übernimmt dabei die Funktion der Transportschicht des OSI-Modells.

Die letzte Schicht, die Anwendungsschicht (Application Layer), definiert die Kommunikation der Anwendungen auf den Host. Das Äquivalent im OSI-Modell wären die letzten beiden Schichten. Die Sitzungsschicht ist nicht im TCP/IP- Modell definiert. Tabelle 1. Schichten des OSI- sowie DDN(TCP/IP)-Modells (Kersken, 2013, S. 185)

OSI-Modell DDN-Modell

7. Anwendungsschicht 4. Anwendungsschicht

6. Darstellungsschicht

5. Sitzungsschicht

24 2 Einführung

4. Transportschicht 3. Host-zu-Host-Transportschicht

3. Vermittlungsschicht 2. Internetschicht

2. Sicherungsschicht 1. Netzzugangsschicht

1. Bit-Übertragungsschicht

2.2.5.2 IP Das Internet Protocol (Layer 3) ist für das Bereitstellen von grundlegenden Transportmechanismen, die für das Senden von Datenpaketen über Netzwerkgrenzen hinweg benötigt werden, zuständig. Dabei arbeitet es verbindungslos, es wird also keine gesicherte Verbindung auf- und wieder abgebaut, wie es bei verbindungsorientierten Verfahren durchgeführt wird. Wie bereits weiter oben erklärt, werden die Daten ohne Erfolgskontrolle gesendet. Das Internetprotokoll verfügt über keine Mechanismen, die sicherstellen, dass Datagramme in der richtigen Reihenfolge oder vollständig beim Ziel ankommen. Diese Aufgaben werden eine Schicht darüber (Layer 4) angesiedelt, und werden von Protokollen wie TCP und UDP übernommen (Zisler, 2018, S. 89,111).

Das Internet Protocol verwendet IP Adressen. Eine klassische und nach wie vor etablierte IPv4 Adresse nach RFC 791 ist eine 32 Bit lange Zahl. Üblicherweise wird sie zur leichteren Lesbarkeit in, durch vier Punkte getrennte, Dezimalzahlen, im Bereich von 0 bis 255, angeschrieben. Die Logik im Adressaufbau ist jedoch binär (0, 1) leichter durchführbar. IP Adressen können in vier Adressklassen (Klasse A bis D) eingeteilt werden. Weiters können nicht sämtliche Adressen als Hostadresse (Adresse welche ein bestimmtes Gerät adressiert) definiert werden. So ist die niedrigste Adresse jedes Netzes die Netzadresse, welche das Netz nach außen identifiziert. Die höchste Adresse jedes Netzes ist die Broadcastadresse, über diese empfangen sämtliche Hosts dieses Netzes gesendete Datenpakete (Kersken, 2013, S. 226f).

Um die Datenpakete beim Ziel den richtigen Anwendungen zuordnen zu können, muss einer IP Adresse ein definierter Port angehängt werden, da die Anwendung an sich nicht nur mit einer IP Adresse angesprochen werden kann. Man kann Portnummern von 0 bis 65535 vergeben, wobei es vordefinierte Bereiche gibt die speziellen Protokollen oder Anwendungen zugesichert sind. 0 bis 1023 sind weltweit eindeutig zugewiesene Ports und sind für Dienste wie beispielsweise FTP, SSH oder HTTPS reserviert. 1024 bis 49151 sind für diverse Anwendungen von der IANA (Internet Assigned Numbers Authority) registriert. Die restlichen

25 2 Einführung

Ports 49152 bis 65535 können frei für eigene Anwendungen verwendet und definiert werden (Zisler, 2018, S. 207f).

2.2.5.3 TCP Wie im vorherigen Kapitel erklärt, übernimmt das verbindungsorientierte TCP (Transmission Control Protocol) auf Layer 4 Aufgaben, welche IP nicht durchführen kann. Dazu zählen der Auf- und Abbau von Verbindungen zwischen Endpunkten, sowie einer Flusskontrolle, die dafür sorgt, dass Daten zuverlässig durch das Netzwerk transportiert werden. Dabei werden die Datenpakete durchnummeriert, um die Reihenfolge zu überprüfen, sowie Lücken in der Übertragung festzustellen. Sollten Datenpakete fehlen, werden sie erneut versendet. Bei durch TCP übertragene Datenpakete werden die Anwendungen entlastet, da sie die Daten nicht mehr auf Vollständigkeit und Fehler überprüfen müssen. TCP führt dadurch jedoch zu einer höheren Netzlast sowie geringerer Bandbreite. Zusammengefasst stellt TCP sicher, dass Daten nicht verändert werden, nicht verloren gehen, nicht dupliziert werden und in der richtigen Reihenfolge ankommen (Kersken, 2013, S. 255f; Mandl, 2018, S. 44; Zisler, 2018, S. 199f).

2.2.5.4 UDP Ebenso wie TCP ist UDP (User Datagram Protocol) teil der Transportschicht des OSI-Modells (Layer 4), ist im Gegensatz aber ein verbindungsloses Protokoll. Es werden keine Verbindungen auf- oder abgebaut, noch wird sie überwacht. Dabei werden auch keine Pakete bei Nichteintreffen neu versendet oder Empfangsbestätigungen angefordert. Fluss- und Staukontrolle existieren ebenso nicht. Das bedeutet, dass sich die Anwendungen selbst um Fehlerkontrollen und Korrekturen kümmern müssen, sollten diese erwünscht sein.

Durch das Fehlen dieser Kontrollmechanismen kommt UDP der Audio- und Videoübertragung zu Gute. Da die Senderate bei zu hoher Netzlast nicht gedrosselt wird, kann ein kontinuierlicher Empfang von Multimediadaten sichergestellt werden. So können zwar Daten verloren gehen, die Anwendungen tolerieren jedoch einen gewissen Datenverlust. Eine weitere Zeitersparnis ergibt sich durch den, im Vergleich zu TCP, viel kleineren Header von 64 Bit (TCP 20 Byte).

UDP erlaubt ebenfalls Nachrichten an sämtliche Geräte in einem Subnetz (Broadcast) oder an eine definierte Gruppe (Multicast) zu senden. Diese Möglichkeit ist gerade für Audio- und Videoübertragungen im Broadcastbereich ausschlaggebend, da ansonsten für jede Übertragung eine eigene Verbindung

26 2 Einführung hergestellt werden müsste, was zu einer immensen Netzauslastung führen würde (Kersken, 2013, S. 258f; Mandl, 2018, S. 95f; Zisler, 2018, S. 205).

2.2.5.5 RTP RTP (Real-Time Transport Protocol) wird der Anwendungsschicht (Layer 7) zugeordnet und fügt UDP hauptsächlich Zeitstempel und Sequenznummern hinzu. Das Protokoll an sich hat, ebenso wie UDP, keine Paketwiederherstellungsmechanismen, jedoch erlauben die Sequenznummern dem Empfänger, falsch angeordnete Pakete neu zu ordnen und Paketverluste zu erkennen. Da RTP keine Wiederherstellungsmechanismen hat, ist die zugehörige Latenz genau so gering wie bei UDP. Ebenso ist RTP Multicast fähig, um einen Datenstrom an mehrere Empfänger gleichzeitig senden zu können. In Abbildung 8 sind nochmals die wichtigsten Protokolle mit den zugehörigen OSI Schichten dargestellt (Cobalt, 2016, S. 3–4).

Abbildung 8. OSI-Modell mit Protokollen (Barella, 2017c, S. 5)

2.3 IP Infrastruktur

2.3.1 Netzwerkarchitektur Um den Anforderungen eines Broadcastbetriebes gerecht zu werden, ist eine stabile Netzwerkarchitektur von Nöten. Aus diesem Grund wird eine Spine and Leaf-Topologie, welche schon seit längerem in Datencentern eingesetzt wird, empfohlen. In dieser Architektur sind sämtliche Geräte genau gleich weit voneinander entfernt, was zu vorhersehbaren Latenz- und Delayzeiten führt.

27 2 Einführung

Weiters ist sie für Netzwerke besser geeignet, in denen mehr Traffic von Osten nach Westen als von Norden nach Süden stattfindet (Olson, 2019).

Die Leaf Ebene besteht aus Access Switches, an denen Geräte wie Kameras, Mischer, Multiviewer, Storages, etc. angeschlossen sind. Die Spine Ebene ist der Backbone des Netzwerks und ist für die Verbindung der Leaf-Switches zuständig. Die einzelnen Spine-Switches sind nicht direkt miteinander verbunden. Dafür ist jeder Leaf-Switch mit dem jedem Spine-Switch verbunden. Abbildung 9 zeigt eine einfache Darstellung dieser Architektur (Merrill & Gagne, 2017).

Abbildung 9. Spine-Leaf-Architektur mit angeschlossenen Geräten (Cisco, 2019a)

Es existieren verschiedene Möglichkeiten, diese Architektur an die eigenen Bedürfnisse anzupassen. So ist es unter anderem möglich, mehrere dieser Topologien parallel für mehrere örtlich getrennte Bereich aufzubauen und sie im Anschluss über WAN (Wide Area Network) Router miteinander zu verknüpfen. Diese Strukturen können unterschiedlich aufgebaut und konfiguriert sein (siehe Abbildung 10). Vorstellbar sind beispielsweise getrennte Bereiche für Produktion und Playout. (Cisco, 2019a).

28 2 Einführung

Abbildung 10. Multi-site Aufbau (Cisco, 2019a)

Es ist auch möglich, Geräte aus Redundanzgründen mit mehreren dieser getrennten Bereiche zu verbinden. Dies wird durch eine direkte Verbindung mit jeweils einem Leaf-Switch aus jedem Bereich bewerkstelligt. So kann beim Ausfall einer Strecke oder eines Switches die Verbindung über andere Knotenpunkte geführt werden. Bei manchen Geräten macht es keinen Sinn sie mit beiden Bereichen direkt zu verbinden oder es ist technisch schlichtweg nicht möglich. Diese werden über einen Leaf-Switch an den jeweiligen Spine-Switches angebunden. Diese Variante (siehe Abbildung 11) ist nur eine von mehreren Varianten, wie eine Spine and Leaf-Topologie aufgebaut werden kann (Phillips, 2019).

Abbildung 11. Hybride Spine and Leaf-Topologie (Phillips, 2019)

2.3.2 Routing Um die Funktionen einer klassischen Kreuzschiene im IP-Umfeld zu erhalten, werden sogenannte Broadcast-Controller verwendet. Sie stellen die Schnittstelle zwischen traditionellen Routingoberflächen, IP-Routern und Endgeräten, aber auch klassischen SDI-Kreuzschienen und Gateways im Falle einer Mischlösung aus SDI und IP Technik zur Verfügung. Durch die Kontrolle und Überwachung

29 2 Einführung der Router bis hin zu den einzelnen Ports haben sie die Fähigkeit, verfügbare Bandbreiten zu überwachen und können so die beste Konfiguration für die zu übertragenden Streams vornehmen. Das heißt, dass die Verbindungen nicht von Routern selbst, sondern von den Broadcast-Controllern aufgebaut werden. Um die Umstellung auf die neue Technik für Operator zu erleichtern, werden bekannte Bedienoberflächen integriert (siehe auch 2.3.3). Um diese Operationen vornehmen zu können, unterstützen Broadcast-Controller das Protokoll IGMP (Internet Group Messaging Protocol) oder SDN (Software Defined Network), manchmal werden auch beide Techniken angewandt. Sie werden im Folgenden kurz beschrieben (AIMS, 2018).

2.3.2.1 IGMP Um Multicast-Streams zu verwalten, wird das bereits in Datencentern eingesetzte und bewährte Internet Group Management Protocol verwendet. Dabei gibt jeder Sender einen Multicast-Stream aus, der von einem Empfänger mittels IGMP Request entgegengenommen werden kann. Ein einzelner Stream kann von jedem Empfänger, der ihn angefordert hat, verarbeitet werden. So wird das Verhalten einer traditionellen Kreuzschiene emuliert. Das Routing der Signale wird durch die Switches durchgeführt, die das IGMP Kommando verarbeiten. Dadurch wird sichergestellt, dass dem korrekten Stream beigetreten wird und die korrekten Pakete weitergeleitet werden. Das empfangende Gerät tritt zwar dem Stream bei, es wird jedoch ein Broadcast-Controller benötigt, um den Beitritt zu initiieren. Dies stellt eine adäquate Bandbreite pro Port für die Streams sicher (AIMS, 2018).

Sollten in einem Netzwerk mehrere Subnetze vorhanden sein, ist es notwendig PIM (Protocol Independent Multicast) zu verwenden. PIM stellt Multicastroutinginformationen über das gesamte Netzwerk bereit, um die IGMP Funktionalität bei jedem Client oder Endgerät zu gewährleisten. Der Multicastadressbereich reicht von 224.0.0.0 bis 239.255.255.255, wobei einige Adressen von der IANA reserviert sind (siehe auch 2.2.5.2). Mittels IGMP muss der Broadcast-Controller nicht mehr sämtliche Switches direkt verwalten, es ist ihnen jedoch möglich Monitoringinformationen, Statusberichte und Konfigurationen zu übertragen, die der Controller über eine API (Application Programming Interface) abrufen kann (AIMS, 2018; Cisco, 2011).

Abbildung 12 zeigt einen typischen Ablauf eines IGMP Verbindungsaufbaus, bei dem mehrere Empfänger einen Multicaststream anfordern.

30 2 Einführung

Abbildung 12. IGMP Verbindungsaufbau (Cisco, 2011)

2.3.2.2 SDN Software Defined Networking bezeichnet eine Anzahl an Netzwerktechnologien, die durch Kombination eine flexiblere und agilere Netzwerkkonfiguration ermöglichen. Dies führt zu verbesserter Leistung und Überwachung. Bei SDN steuert der Broadcast-Controller die Switches direkt, um die Pfade zur Paketweiterleitung zwischen den Ports der Switches aufzubauen. Er übernimmt also im Vergleich zu IGMT viele Aufgaben selbst, was zu einer reduzierten Latenz der Prozessausführung führt, da die IGMT Anfragen wegfallen.

Es gibt zwei Arten wie SDN arbeiten kann. Zum einen können Endgeräte dauerhaft einen Multicaststream senden. In diesem Fall muss nur die Routerkonfiguration geändert werden, so dass die Pakete an den richtigen Port und Router geschickt werden. Der Empfänger kann dem Stream so jederzeit beitreten. Alternativ können die Routingpfade zuerst eingerichtet werden und ein zweites Kommando sendet dem Sender das Signal, um den Stream zu starten und dem Empfänger das Signal zum Beitreten. Hier müssen also eine Reihe von Schritten durchgeführt werden bevor der Stream übertragen werden kann. Der Broadcast-Controller muss im Vorhinein sicherstellen, dass die benötigte Bandbreite zur Übertragung reserviert ist (AIMS, 2018).

Ganz allgemein sorgt SDN für eine Trennung von Soft- und Hardware in einem Netzwerk, wobei die Steuerung die Control Plane (CP) übernimmt, also der Broadcast-Controller. Die Netzwerkhardware wird als Data Plane (DP) bezeichnet und übernimmt das Routing der Datenpakete. Ein Vorteil dabei ist, dass sich neue Komponenten sehr schnell in ein Netzwerk aufnehmen lassen und keine proprietären Protokolle zum Einsatz kommen. Die einzelnen Geräte müssen nicht separat konfiguriert werden und da der Broadcast-Controller die

31 2 Einführung komplette Netzwerktopologie kennt, ist effizienteres Routing, sowie eine optimale Auslastung der Übertragungsstrecken, möglich (Luber & Donner, 2018).

2.3.3 Orchestrierung und Kontrolle Beim Umstieg auf IP-basierte Infrastrukturen ändern sich die Anforderungen an das darüber liegende Kontrollsystem im Vergleich zu SDI nicht. Um alle operativen Anforderungen zu erfüllen, muss das Kontrollsystem die darunter liegende Infrastruktur, inklusive sendender und empfangender Netzwerkknoten (Nodes), sowie auch die Kontrolle von IT Hardware, welche nicht aus dem Broadcastbereich stammt, verstehen.

Die Architektur einer heute eingesetzten klassischen Videokreuzschiene besteht aus drei Elementen. Input und Output Module verbinden die Signale mit einem internen Router, welche von einer zentralen Controller Karte gesteuert werden. Diese drei Komponenten formen ein zusammenhängendes System, welches deterministisch ist und eine vorhersehbare Leitung und Zuverlässigkeit bietet.

In einer IP Infrastruktur werden Input und Output Module durch Netzwerk-Input und -Output Knoten ersetzt, welche auf die gesamte Netzwerkinfrastruktur aufgeteilt sind. Diese Knoten können sehr vielfältig sein; Kameras, Multiviewer, Prozessoren, Mischer und viele mehr sind möglich. Ebenjene verbinden sich zu einer Netzwerkinfrastruktur, welche die Routingfunktionalität mittels IP Netzwerkswitches emuliert. Als Mindestanforderung besteht das System aus einem einzelnen Switch, üblicherweise aber aus einer größeren Anzahl die in einer Spine-Leaf Topologie (siehe 2.3.1) verbunden sind. Dieses System sollte eine Abstraktion der darunter liegenden Infrastruktur für das Userinterface bieten. Dieser Prozess, welcher auch als Orchestration bekannt ist, beinhaltet die Kontrolle der involvierten Netzwerkknoten und der Endgeräte, sowie das tatsächliche Routen der Streams, was auch Routenfindung und Bandbreitenkontrolle inkludiert (Kern, 2017).

Abbildung 13 zeigt einen Vergleich einer Videokreuzschiene (Baseband Router) und Routing mittels IP Infrastruktur (IP Routing). Das Kontrollsystem (Control System) stellt eine darüber liegende Ebene dar, welche von der verwendeten Technologie unabhängig ist und in beiden Fällen ein ähnliches, wenn nicht sogar gleiches, Userinterface bietet.

32 2 Einführung

Abbildung 13. Vergleich Videokreuzschiene zu IP Routing (Kern, 2017)

Zur besseren Identifizierung der Anforderungen von IP-basierter Broadcast Infrastruktur zur Orchestrierung, werden Broadcastsysteme differenziert und in drei funktionale Ebenen eingeteilt. Den Physical, Logical und Operation Layer (Kern, 2017):

2.3.3.1 Physical Layer Die physische Ebene inkludiert alle sendenden und empfangenden Knoten. Jeder Knoten ist mit dem IT Backbone verbunden, welcher aus einem einzelnen oder mehreren Switches in vorher erwähnter Spine-Leaf Architektur aufgebautem System besteht. Dieser Aufbau kann auch redundant designt sein. In den meisten Fällen stammen die mit dem Backbone verbundenen Knoten (also sämtliche Geräte) von unterschiedlichen Herstellern, mit unterschiedlichen Funktionen und verschiedensten Typen. Gemeinsam bilden sie den Physical Layer der Produktionsumgebung.

2.3.3.2 Logical Layer Über der physischen Ebene vereint die logische Ebene die komplette Funktionalität, welche die darunter liegende Hardware verbindet und abstrahiert und somit bedienbar macht. Im Logical Layer ergeben sich dadurch mehrere Herausforderungen.

33 2 Einführung

Erstmal müssen Geräte unterschiedlicher Hersteller einem Kontrollsystem untergeordnet werden um eine grundlegende Steuerung zu ermöglichen. Hierzu arbeitet AMWA (siehe 2.4.2) an NMOS Spezifikationen, um diesen Prozess durch standardisierte Registrierungsmechaniken für Geräte und deren Streams zu vereinheitlichen. Weiters führt NMOS ein allgemeines Verbindungsmanagement für Streams zwischen den verschiedenen Geräten ein. Sobald so eine Streamkompatibilität zwischen den sendenden und empfangenden Geräten existiert, kann ein einfaches routen von Streams von Quellen zu Zielen realisiert werden.

Eine Schlüsselfunktion innerhalb der logischen Ebene ist die Orchestrierung oder auch Vereinheitlichung. Diese abstrahiert die Netzwerkkomponenten und den Backbone durch ein zentrales Kontrollsystem. Dadurch wird eine klassische XY Crosspoint Matrix der darunterliegenden IP-basierten Routing Infrastruktur bereitgestellt. Die Orchestrierung behandelt jedoch noch weitere Steuerungsaspekte. Dazu zählt etwa ein einfaches Verbindungsmanagement zum Streamen zwischen Geräten, ähnlich wie normales Patchen. Aber auch die Steuerung der darunter liegenden Switch Infrastruktur, Bandbreitenmanagement der benutzten Ports, fortgeschrittene Switching Mechanismen und mehr gehören dazu. Fortgeschrittene Orchestrierung bündelt diese und weitere komplexe Funktionen in einem zentralen Service und agiert als ein zentrales Steuerinterface jeder IP Routing Infrastruktur.

2.3.3.3 Operation Layer Die zentrale Rolle eines Kontrollsystems bleibt weiterhin kritisch hinsichtlich einer effizienten Bedienung der darunter liegenden IP Routing Topologie. Die Bedienungsebene bietet ein graphisches und physikalisches Userinterface für den Betrieb und bildet die Brücke zwischen klassischer SDI- und neuer IP- Infrastruktur. Dem menschliche Nutzer, dem Operator, wird jede Funktionalität der darunter liegenden Infrastruktur als ein übergreifendes Kontrollsystem präsentiert.

Die folgende Grafik (Abbildung 14) zeigt die drei Layer der IP Orchestrierung mit einem VSM Panel zur Steuerung in der Bedienungsebene.

34 2 Einführung

Abbildung 14. Ebenen der IP Orchestration (Kern, 2017)

2.3.4 PTP – Precision Time Protocol Das Precision Time Protocol ist im SMPTE Standard ST 2059-2 (IEEE-1588) definiert und stellt eine präzise Methode zur Verfügung, um Geräte in einem Netzwerk zu synchronisieren. Mittels PTP ist es möglich, mehrere Uhren mit einer Genauigkeit von unter 100 Nanosekunden miteinander abzugleichen. Dies geschieht durch Definition von Synchronisierungsnachrichten zwischen Master und Slave Uhren. Ein sogenannter Grandmaster ist ein Master, welcher mit einer Zeitreferenz von beispielsweise GPS (Global Positioning System) synchronisiert ist (EndRun Technologies, 2015; Meyer, 2016).

PTP ist an seinen zeitlichen Ursprung (Epoch) den 01.01.1970 um 00:00:00 gebunden. Dies ist die TAI (Temps Atomique International), die internationale Atomzeit, von welchem die aktuelle Zeit berechnet wird. Jedes Gerät, egal ob Sender oder Empfänger, behält eine Kopie dieser Referenzzeit in ihren jeweiligen lokalen Uhren (AIMS, 2019b, S. 14f).

Die PTP Nachrichten inkludieren Master Sync Message, Master Delay Response Message und die Slave Clock Delay Request Message. Zusätzlich zu diesen Nachrichten, gibt es einen Best Master Clock (BMC) Algorithmus, um bei mehreren Mastern die beste Clock für das Netzwerk festzustellen. Um die Uhren im LAN zu synchronisieren, wird mindestens ein Master und ein Slave benötigt, wobei mehrere Slaves von einem Master synchronisiert werden können.

Die Master Clock stellt oben genannte Synchronisationsnachrichten zur Verfügung, welche die Slaves dazu verwenden, um ihre eigene lokale Clock zu

35 2 Einführung korrigieren. Dazu werden präzise Timestamps bei Master und Slave Clock aufgezeichnet, um die Netzwerklatenz zu berechnen. Master Sync Messages werden typischerweise alle 2 Sekunden, Delay Request Messages etwa 1 mal pro Minute gesendet. Insgesamt werden 4 Timestamps zwischen Master und Slave Clock aufgezeichnet. In Abbildung 15 werden diese Timestamps t1-t4 dargestellt und im folgenden beschrieben (EndRun Technologies, 2015).

Abbildung 15. PTP Synchronisationsnachrichten (Cisco, 2019b)

Es müssen 2 Delayzeiten berechnet werden, vom Master zum Slave, und in die andere Richtung. Zuerst wird die Master zu Slave Differenz ermittelt, indem bei t1 eine Sync Message vom Master gesendet wird. Der Timestamp, zu dem diese Nachricht geschickt wurde, wird im Anschluss gesendet (Follow-Up). t2 ist der Timestamp, bei dem die Master Sync Message beim Slave eingetroffen ist. Somit kann der Slave die Differenz errechnen: �2 − �1.

Im Anschluss sendet der Slave bei t3 eine Delay Request Message mit dem Timestamp des Absendezeitpunktes. Bei t4 kommt die Nachricht beim Master an, welcher nun die Differenz zum Slave berechnen kann: �4 − �3. Der Master sendet diese Information an den Slave, der nun das Delay einer Strecke (Path Delay) mittels den beiden Differenzen berechnen kann: ()() ()() ���� . Um den Offset zu errechnen der auf die Slave Clock angerechnet wird, ergibt sich nun folgende Formel: (�2 − �1) − ���ℎ ����� (Cisco, 2019b; EndRun Technologies, 2015).

36 2 Einführung

In einem Netzwerk mit mehreren Geräten und Switchen kann es zu unterschiedlichen Laufzeiten kommen. Um den jeweiligen Gegebenheiten gerecht zu werden, gibt es vier unterschiedliche Arten an Clock Typen (Cisco, 2019b): - Eine Grandmaster Clock ist die primäre Quelle für Zeitangaben in einem PTP Netzwerk. Sie hat in den meisten Fällen eine sehr präzise Zeitquelle, wie GPS oder eine Atomuhr (Cisco, 2019b). - Ordinary Clocks haben einen einzelnen PTP Port. Sie fungieren als Node und können Master oder Slave innerhalb einer Subdomain sein. Weiters sind sie die üblichste Art von PTP Clocks, da sie als Endpunkte im Netzwerk dienen und mehrere Interfaces für Geräte bieten, die Synchronität voraussetzen (Cisco, 2019b). - Boundary Clocks sind Switches, die sich an einem Port mit dem Master synchronisieren und an den restlichen Ports selbst als Master für die angeschlossenen Geräte fungieren. Dies verhindert, dass die Grandmaster Clock überbeansprucht wird und führt zu größerer Genauigkeit der PTP Zeit, sowie verbesserter Systemskalierbarkeit (Cisco, 2019b; Viengkhou et al., 2018). - Der letzte Typ sind Transparent Clocks. Diese messen die Dauer, die ein Datenpacket im Switch benötigt bis es weitergeleitet wird. Diese Zeitangabe wird dann einem Korrekturfeld der Follow-Up Message hinzugefügt. So können vielschichtige Switch-Konfigurationen vorgenommen werden, ohne dass Geräte am Ende nicht mehr synchron laufen (Cisco, 2019b; Viengkhou et al., 2018).

Abbildung 16 zeigt ein Beispiel für einen Aufbau, welcher verschiedene Switch und Clock Typen vereint.

Abbildung 16. PTP Hierarchie (Cisco, 2019b)

37 2 Einführung 2.4 Allianzen

2.4.1 AIMS Die Alliance for IP Media Solutions (AIMS) ist eine Vereinigung, die von Broadcastingenieuren, Technikern, Visionären, Herstellern und Führungspersonen geleitet wird, die es sich zu Aufgabe gemacht haben, offene Standards zu entwickeln und zu fördern, um die Broadcast- und Medienunternehmen schnell und profitabel, von derzeit verwendeten Systemen zu IP-basierten Umgebungen zu bringen. Sie arbeiten dabei mit anderen Gesellschaften, unter anderem jenen die auch in den nächsten Kapiteln erwähnt werden, zusammen und fördern deren Arbeit. AIMS ist eine integrative und transparente Non-Profit Organisation, die enge Kooperationen zwischen Mitgliedern und Normungsgremien ermöglicht und dafür sorgt, dass geschäftliche und technische Anforderungen von Broadcastunternehmen und Audio-Video Fachkräften erfüllt werden. Zusammen arbeiten sie an allumfassenden IP- Standards, die Fragmentierungen eliminieren und Interoperabilität maximieren, sowie sicherstellen, dass heutige Entscheidungen nicht zu technologischen Sackgassen führen (AIMS, 2019a).

2.4.2 AMWA Die Advanced Media Workflow Association (AMWA) wurde im Januar 2000 als Advanced Authoring Format (AAF) Association gegründet. Im Mai 2007 wurde der Name der Organisation offiziell geändert, um die Ausrichtung und den Bereich der Gesellschaft, sowie ihr Leitbild besser darzustellen. Heute fokussiert sich AMWA, mit weltweiten Repräsentanten von Medienunternehmen und deren Lieferanten, darauf, die Industrie in Richtung IP-basierender Architekturen zu lenken. Um softwarebasierten Systemen die Möglichkeit zu geben Geräte zu erkennen und zu nutzen, hat AMWA die Networked Media Open Specifications (NMOS) entwickelt. Die NMOS Spezifikationen sind Teil von SMPTE ST 2110 und werden in Kapitel 2.5.3 weiter behandelt. Die Gesellschaft führt die Unterstützung für das Media Exchange Format (MXF), sowie das Advanced Authoring Format (AAF), welches von ihnen entwickelt wurde und aus welchem MXF hervorging, fort. AMWA sieht sich als offenes, von der Community geführtes Forum, welches unternehmerische Lösungen für Netzwerkmedien-Workflows weiterentwickelt (AMWA, 2019).

38 2 Einführung

2.4.3 JT-NM Die Joint Task Force for Networked Media (JT-NM) ist ein Zusammenschluss aus der Society of Television and Motion Picture Engineers (SMPTE), der European Broadcast Union (EBU), der Advanced Media Workflow Association (AMWA) und dem Video Services Forum (VSF) (Barella, 2017a). Diese wurde gegründet um bei der Umstellung auf IP zu unterstützen, Nutzeranfordungen zu sammeln, Lücken in der Technologie zu identifizieren, Empfehlungen für Best Practices zu geben, sowie die Tätigkeiten der Industrie zu koordinieren (JT-NM, 2019).

Im Laufe von 2013 wurden Dokumente zu Anforderungen für Technologien und Nutzeranforderungen herausgegeben, welche zu einem „Gap Analysis Report“ zusammengefasst wurden. Ebenfalls 2013 wurde eine Roadmap entwickelt, welche eine Übersicht über die geplanten Technologien gibt und dazu beitragen soll die Entwicklung neuer Standards und Produkte voranzutreiben. Die Roadmap ist an die Austragung der zwei wichtigsten Branchenkonferenzen, IBC (International Broadcasting Convention) und NAB (National Association of Broadcasters), gekoppelt und wird regelmäßig aktualisiert. Die derzeit aktuellste ist auf dem Stand der IBC 2018, siehe Abbildung 17 (JT-NM, 2018).

Abbildung 17. JT-NM Roadmap (JT-NM, 2018)

Des Weiteren führt JT-NM seit April 2019 regelmäßig Tests von Geräten durch, um sie auf ihre Kompatibilität untereinander und generell die Unterstützung der SMPTE ST 2110 Standards und der NMOS APIs zu überprüfen. Die Anforderungen der Tests und die genauen Ergebnisse jener werden offen auf der Webseite der JT-NM veröffentlicht. Der letzte Test bei dem erstmals auch NMOS

39 2 Einführung kompatible Broadcast Controller getestet wurden, fand im März 2020 statt, wobei hier anzumerken ist, dass viele Tests aufgrund der zu dem Zeitpunkt herrschenden Situation bezüglich Covid-19 nur über Fernzugriffe durchgeführt werden konnten. Abbildung 18 zeigt die vergebenen Prüfsiegel (JT-NM, 2020).

Abbildung 18. JT-NM Prüfsiegel (JT-NM, 2020)

2.4.4 VSF Das Video Services Forum (VSF) ist eine internationale Vereinigung von Dienstleistern, Anwendern und Herstellern, die sich mit Interoperabilität, Qualitätsmerkmalen und Schulungen für Mediennetzwerktechnologien auseinandersetzen. Das schaffen sie unter anderem durch Bereitstellung von Foren, um Probleme zu identifizieren, die mit neuen technischen Entwicklungen, der Bereitstellung jener, sowie dem Betrieb und der Sicherheit von eben erwähnten Mediennetzwerktechnologien zusammenhängen. Außerdem fördern sie Interoperabilität indem sie einen Beitrag zur Entwicklung von Standards leisten (VSF, 2020). Das VSF hat über die Jahre auch mehrere technische Empfehlungen herausgegeben. Darunter befinden sich einige, die sich mit der Übertragung von Medien über IP-basierte Technologien befassen, wie zum Beispiel die TR-01 und TR-03 (VSF, 2015a, 2018a), sowie auch Empfehlungen, die sich explizit mit SMPTE ST 2110 auseinandersetzen. Die TR-05 behandeln mögliche Videoformat-Standards, die mit SMPTE ST 2110-20 möglich sind. Ziel hierbei soll sein, logische Gruppen an Videoformaten zu definieren, um die Interoperabilität moderner Produktionsworkflows von Fernsehanstalten zu gewährleisten (VSF, 2018b).

40 2 Einführung 2.5 Spezifikationen, Richtlinien, Empfehlungen

2.5.1 AES67 AES67 (Standard for audio applications of networks - High-performance streaming audio-over-IP interoperability) ist ein 2013 eingeführter Standard, der es sich zur Aufgabe gemacht hat allgemeine Mechaniken und Protokolle zur besseren Interoperabilität von Audioanwendungen zu standardisieren. (Hildebrand, 2014).

Es wird dabei nicht exakt definiert wie die Standards implementiert werden müssen, sondern nur welche Voraussetzungen erfüllt werden müssen. Dazu zählen die Grundpfeiler Synchronisation, Multicast Pakettransport, Quality of Service (QoS) und Session Information. In diesen Bereichen wird definiert, welche Parameter eingehalten werden müssen, um AES67-konform zu sein. Es ist also grundsätzlich möglich, Geräte mit verschiedenen Standards in einem Netzwerk miteinander zu verwenden, solange sie die Anforderungen von AES67 erfüllen (siehe Abbildung 19). SMTE ST 2110-30 baut ebenfalls auf diesen Standard auf (Hildebrand, 2017).

Abbildung 19. AES67 Unterstützung (Ravenna, o. J.)

41 2 Einführung

2.5.2 VSF Technical Recommendations Das Video Services Forum veröffentlicht regelmäßig technische Empfehlungen, die sich mit IP-Technologien befassen (siehe Kapitel 2.4.4). Vor allem in der Zeit zwischen der Entwicklung von SMPTE ST 2022 und ST 2110 haben sie diverse Verbesserungen mit sich gebracht. Für das Verständnis dieser Arbeit sind die drei folgenden Empfehlungen von Bedeutung.

2.5.2.1 TR-03 Mittels SMPTE ST 2022 (siehe 2.6.2) ist es zwar möglich SDI-Signale über IP zu übertragen, jedoch wird dabei das komplette Signal (Audio-, Video- und Metadaten) in einem verkapselten Stream übertragen. Aufgrund der Tatsache wurde TR-03 (Transport of Uncompressed Elementary Stream Media over IP) im November 2015 veröffentlicht, welches die Möglichkeit bietet die einzelnen Streams individuell über separate Multicastadressen übertragen zu können (VSF, 2015a).

Um dies möglich zu machen, stützt sich die Empfehlung auf den Internetstandard RFC 4175, welcher die Notwendigkeit der vertikalen Austastlücke für Zusatzdaten und andere historische Verkapselungen von zusätzlichen Signalen eliminiert und die Übertragung unabhängig von Auflösung und Framerate erlaubt. Die ansonsten eingebetteten Audiospuren werden mittels AES67 übertragen, wodurch das De-embedden und Re-embedden nicht mehr nötig ist, um die einzelnen Streams zu bearbeiten. Der fehlende Timecode, und damit die Möglichkeit zur Synchronisation, wird mittels PTP (siehe 2.3.4) und SMPTE ST 2059-1/2 der Empfehlung hinzugefügt (Barella, 2016).

2.5.2.2 TR-04 Die Technical Recommendation TR-04 (Utilization of ST 2022-6 Media Flows within a VSF TR-03 Environment) wurde ebenfalls im November 2015 veröffentlicht. Diese ist eine Abwandlung von SMPTE ST 2022 und fügt die Option hinzu, separate AES67 Audiostreams zu übertragen. Man hat also die Möglichkeit, die dem SDI Signal sehr ähnlich und einfach aufgebauten Streams, auf einfache Weise zu erweitern. Abbildung 20 zeigt die Entwicklung, angefangen bei SMPTE ST 2022, über TR-04 und TR-03, bis hin zum darauffolgenden SMPTE ST 2110 und wie einzelnen Datenströme jeweils behandelt werden (Barella, 2016; VSF, 2015b).

42 2 Einführung

Abbildung 20. IP-Standards Entwicklung (Nevion, 2016)

2.5.2.3 TR-05 Die aktuellste, für diese Arbeit relevante Empfehlung, ist TR-05 (Essential Formats and Descriptions for Interoperability of SMPTE ST 2110-20 Video Signals), welche im Juni 2018 veröffentlicht wurde. In dieser Empfehlung werden Formate für ST 2110-20 Signale definiert. Da ST 2110 grundsätzlich formatunabhängig arbeitet, kann es in der Praxis durchaus vorkommen, dass unterschiedliche Hersteller diverse Formate selbst definieren. Um einen gewissen Konsens herzustellen, werden in TR-05 aus diesem Grund Formate anhand von Auflösung, Framerate, Bittiefe, Samplingtiefe, etc. definiert. Daraus sollen zum einen logische Gruppen festgelegt werden, die ähnliche Verarbeitungsanforderungen an Hard- und Software haben. Zum anderen soll eine Sammlung an präzise definierten Formaten, welche in modernen Produktionsumgebungen häufig eingesetzt werden, erstellt werden. Die Empfehlung soll aber auch niemanden daran hindern, andere Formate zu entwickeln und zu nutzen (VSF, 2018b).

Die definierten Formate bringen die Industrie weiter voran, IP-Systeme und deren Vorteile zu nutzen. Je mehr Unternehmen diese Empfehlungen umsetzen, desto besser wird die Interoperabilität von IP-Systemen. Weiters sinken die Kosten, die Flexibilität steigt und die Skalierbarkeit verbessert sich (Frostad, 2018).

2.5.3 NMOS Die Networked Media Open Specifications (NMOS) werden von AMWA entwickelt und veröffentlicht. Diese Interface Specifications (IS) sind APIs und definieren Schnittstellen, die nicht in SMPTE ST 2110 enthalten sind. Sie ermöglichen eine unkomplizierte und schnelle Konfiguration und Orchestrierung der kompatiblen Systeme. Derzeit wurden IS-04 bis IS-09 veröffentlicht und

43 2 Einführung werden im Folgenden beschrieben. Weitere Spezifikationen sind in Arbeit (AMWA, 2020a).

2.5.3.1 IS-04 – Discovery & Registration IS-04 wird zur Erkennung und Registrierung von Geräten in einem Netzwerk durch ein Kontrollsystem verwendet. Jedes Gerät welches an das Netzwerk angeschlossen wird, wird identifiziert und anschließend als Node registriert. Ein Node kann auch mehrere Geräte (Devices) beinhalten, wie zum Beispiel bei einem Multiviewer. Jeder Node kann des weiteren mehrere Funktionen erfüllen. Dazu zählen Sender, Receiver, Sources und Flows, welche als Resources bezeichnet werden. Der angesprochene Multiviewer wäre beispielsweise ein Node mit mehreren Devices, welche wiederum mehrere Receiver beinhalten. Eine Kamera beinhaltet mehrere Sender (Video- und Audiodaten) und mehrere Receiver (Video- und Steuerungsdaten). Der Broadcast Controller hat, nachdem alle Geräte registriert wurden, eine Übersicht über sämtliche Ressourcen und kann die einzelnen Geräte über ein ID ansprechen (siehe Abbildung 21) (Barella, 2017a; Porter, 2018).

Abbildung 21. IS-04 Abfrage der Ressourcen (Porter, 2018)

2.5.3.2 IS-05 – Device Connection Management IS-05 definiert eine Methode zum Auf- und Abbauen von Verbindungen. Es werden dabei die vorhin registrierten Sender und Receiver miteinander verbunden. Die Verbindungen können sofort oder nach einer gewissen Zeit aufgebaut werden. Es ist auch möglich mehrere Verbindungen gleichzeitig

44 2 Einführung herzustellen. Die Streamdetails werden mittels SDP (Session Description Protocol) übertragen. Abbildung 22 zeigt den Ablauf eines Verbindungsaufbaus und die Zusammenhänge von IS-04 und IS-05 (AIMS, 2018; Brightwell & Edwards, 2018; Porter, 2018).

Abbildung 22. Zusammenspiel von IS-04 und IS-05 (Brightwell & Edwards, 2018)

2.5.3.3 IS-06 – Network Control IS-06 definiert die Network Control API und wird vom Broadcast Controller verwendet, um Netzwerkservices zu sichern und zu reservieren. Sie erlaubt dem Broadcast Controller Informationen über die Netzwerktopologie zu erhalten, welcher dieser dann verwenden kann, um optimale Routen zu definieren und auch um diese in seinem UI darzustellen. Weiters werden mithilfe der API sogenannte Media Flows zwischen Sendern und Receivern aufgebaut wofür Bandbreite reserviert werden muss. Die Sicherheit kann erhöht werden, indem ausschließlich autorisierte Flows, Sender und Receiver erlaubt werden. Zusammengefasst bietet IS-06 Unterstützung, um Media Flows zu erstellen, zu modifizieren und zu beenden, sowie deren fehlerfreie Übertragung durch Bandbreitenreservierung und Priorisierung zu gewährleisten. Abbildung 23 zeigt den erweiterten Aufbau mit der in IS-06 enthaltenen Endpoint API und Network Flow API (AMWA, 2018; Porter & Vishwarupe, 2019).

45 2 Einführung

Abbildung 23. IS-06 Network Controller (Porter & Vishwarupe, 2019)

2.5.3.4 IS-07 – Event & Tally

IS-07 erlaubt einer Quelle ihren Status zu senden, sowie die Änderung dieses Status an verbundene Empfänger zu kommunizieren. Die API ist also das Äquivalent zu traditionellen GPI (General Purpose Interface) Signalen. Diese elektrischen On/Off Signale sind für moderne IP-Umgebungen nicht sehr praktikabel. IS-07 erlaubt im Gegensatz zu GPI nicht nur die Übertragung von logischen (booleschen) Datentypen (True/False). Es können auch, unter anderem, Zeichenketten (Strings) und Zahlen (Numbers) übertragen werden, welche mittels JSON formatiert werden. Somit sind zusätzlich zu einfachen Tally-Befehlen (An/Aus) auch komplexere Statusübertragungen möglich. Beispiele können sein; Netzwerk Portstatus Logging, Synchronisierung von Software GUIs mit Multiviewern oder Auswahl des korrekten Audio/Video Previews bei bestimmten Konfigurationen (Jeras, 2019).

2.5.3.5 IS-08 – Audio Channel Mapping IS-08 wird genutzt um ein Mapping zwischen einem oder mehrerer Audioinputs und einem oder mehrerer Audiooutputs zu definieren. Diese In- und Outputs sind lokale Ressourcen der Devices und als solche nicht in der Registry registriert. Jeder von diesen In- und Outputs kann mehrere Kanäle haben. Die Anzahl dieser ist vom Gerät definiert und kann nicht geändert werden. Um diese Kanäle zu routen wird eine Map, die zwei verschiedene Zustände haben kann, verwendet. Die „Active“ Map stellt den derzeitigen Zustand des Mapping dar. Die „Staged“ Map repräsentiert den gewollten Zustand zu einem späteren Zeitpunkt. Sobald die „Staged“ Map aktiviert wird, werden die neuen

46 2 Einführung

Mappingkonfigurationen übernommen. Diese Aktivierung kann sofort, nach einer bestimmten Zeit oder zu einem bestimmten Zeitpunkt durchgeführt werden. Abbildung 24 zeigt ein Device mit jeweils 2 Quellen und Senken welche mittels IS-08 gemappt werden (AMWA, 2020b).

Abbildung 24. IS-08 Audio Channel Mapping (Hildebrand, 2019)

2.5.3.6 IS-09 – System Parameters

IS-09 erlaubt einem Media Node gängige, globale Konfigurationsparameter eines Systems zu erhalten. Dies geschieht automatisch mittels DNS-SD (Service Discovery). Zu den Parametern, die erfasst werden, zählt unter anderem die System ID, welche zufällig generiert wird, um dem Gerät mitzuteilen in welcher Umgebung es sich befindet. So kann es feststellen, ob es sich nach einem Neustart noch im selben System befindet. Weitere Parameter welche überprüft werden sind; die verwendeten Netzwerkprotokolle (http oder https), die unterstützte NMOS API, die PTP Domain und ob es beispielsweise Syslog- Server im System gibt. Im Generellen sorgt IS-09 dafür einen Media Node in einem System auf eine definierte Art und Weise starten oder neustarten zu können, so dass es zu der verwendeten Umgebung konsistent ist (AMWA, 2020c; Deame, 2020).

2.6 Weitere IP Standards

2.6.1 NDI NDI (Network Device Interface) ist ein lizenzfreier Standard der Firma NewTek zur Übertragung von Videosignalen. Er wurde so entwickelt, dass er mit Standardhardware eingesetzt werden kann, solange sie gewisse

47 2 Einführung

Voraussetzungen erfüllt. Dazu zählt beispielsweise ein Mindestdurchsatz von 1 Gbit/s pro Port. NDI überträgt komprimierte Videodaten, unkomprimierte Audiodaten, sowie Metadaten wie Tallydaten. Im Vergleich zu SMPTE ST 2110 erfolgt die Übertragung jedoch als ein einzelnes Signal und nicht in getrennten Streams. Die Kommunikation ist bidirektional und auch mittels kabelloser Übertragung (WLAN) möglich. Der Transport der Pakete läuft über UDP und Multicaststreams. Voraussetzung ist, dass sich alle Geräte im selben physischen oder logischen Netzwerk befinden.

Für die Kompression der Videostreams wird ein Verfahren, basierend auf der diskreten Kosinustransformation (DCT), angewandt, welches das Signal in einzelne Frequenzen konvertiert. Der Codec hat die Fähigkeit sicherzustellen, dass Signale nur einmal komprimiert werden. Die x-te Kopie eines Streams ist dabei identisch zur ersten. NDI hat eine technische Latenz von 16 Bildzeilen, in der Praxis ist es jedoch meist 1 Field. Weiters werden sämtliche Auflösungen, Frameraten und Videostreams mit oder ohne Alphakanal unterstützt. Die Beschränkungen hängen allein von den verwendeten Endgeräten ab (NewTek, Inc, 2016).

Im September 2019 wurde NDI 4 veröffentlicht, welches diverse Verbesserungen bei unterstützten Formaten und Zusatzdaten brachte. NDI 4 ermöglicht nun Videoauflösungen über UHD, sowie mehr als 64 Audiokanäle mit beliebigen Abtastraten und deren Verwendung in kabellosen Umgebungen mithilfe von integrierten Audio- und Videocodecs. Es werden eine Reihe von Anwendungen bereitgestellt, inklusive Funktionen für Videoquellenkontrolle, Aufzeichnung, IP- basiertem KVM (Keyboard Video Mouse), Testbildgeneratoren und viele mehr. Weiters existieren Plug-Ins für beispielsweise Desktop Mediaplayer, wie VLC oder auch für die Adobe Creative Cloud. Das Einbinden von mobilen Devices, wie Smartphones und Tablets, und der Nutzung derer Kameras, ist mittels eigener Apps ebenfalls möglich. Durch das frei verfügbare SDK steht es jedem Entwickler frei seine eigenen Produkte mit NDI Unterstützung auszustatten. So verfügen schon zahlreiche Endgeräte diverser Hersteller über die Möglichkeit das NDI Protokoll zu verarbeiten (Carroll & Hidle, 2019).

2.6.2 SMPTE ST 2022 Die Standardsuite 2022-1 bis 2022-8 enthält die Spezifikationen um Videosignale mittels UDP Streams zu transportieren. Im Unterschied zu SMPTE ST 2110 wird jedoch das gleiche Signal wie bei SDI übertragen. Die einzelnen Signale werden also nicht aufgeteilt und getrennt gesendet. Sehr simpel ausgedrückt, ändert sich also nur das Übertragungs- und Verarbeitungsmedium. Der Aufbau des Signals

48 2 Einführung bleibt gleich. Die einzelnen Standards werden im Folgenden kurz vorgestellt (Barella, 2016; Kunic & Sego, 2018):

2022-1 (Forward Error Correction for Real Time Video/Audio Transport over IP Networks) aus dem Jahr 2007 legt den Grundstein, um die in späteren Standards definierten Signale fehlerfrei übertragen zu können. Da IP Pakete anders übertragen werden als ein SDI-Stream, ist eine FEC (Forward Error Correction) notwendig. Über eine einstellbare Matrix ist es möglich, die Genauigkeit der Zeilen- und Spaltenkorrektur zu definieren. Hier muss man jedoch einen Mittelweg zwischen zu hoch eingestellten Variablen, die zu einem erhöhten Delay führen, und zu niedrigen Werten, die zu verloren gehenden Paketen führen, finden (Orme, 2017).

Die Standards 2022-2 bis 2022-4 (Unidirectional Transport of Constant Bit Rate MPEG-2 Transport Streams on IP Networks, Unidirectional Transport of Variable Bit Rate MPEG-2 Transport Streams on IP Networks und Unidirectional Transport of Non- Piecewise Constant Variable Bit Rate MPEG-2 Streams on IP Networks) spezifizieren, wie MPEG-2 Transport Streams in IP Pakete gepackt werden. Dies jeweils einmal für Streams mit konstanter Bitrate und zweimal für variable Bitrate (bei diesen gibt es zwei verschiedene Ansätze). Da diese IP Pakete nicht konstant übertragen werden, sondern stoßweise, wird der vorhin erwähnte 2022-1 Standard benötigt (Barella, 2016; Kunic & Sego, 2018).

2022-5 (Forward Error Correction for Transport of High Bit Rate Media Signals over IP Networks (HBRMT)) ist 2022-1 sehr ähnlich. Es wurden weitere Headerinformationen und mehr Zeilen/Spaltenkombinationen hinzugefügt, um den Ansprüchen höherer Datenraten gerecht zu werden (Edwards, 2017; Kunic & Sego, 2018).

Der Standard, welcher das eigentliche Signal spezifiziert, ist 2022-6 (Transport of High Bit Rate Media Signals over IP Networks (HBRMT)). Er definiert die Übertragung von unkomprimierten SDI Streams, welche typischerweise Audio- und Metadaten integriert haben. Zur Zeit seiner Veröffentlichung war er einer der ersten und ausgereiftesten Standards für ebenjene unkomprimierte Übertragung. Als großen Vorteil kann man sehen, dass das Signal dem bekannten SDI-Signal sehr ähnlich ist. Einzig die Übertragungsart, bestehend aus Paketen im Gegensatz zu einem durchgehend Stream, ist unterschiedlich. Durch diese Ähnlichkeit ist es möglich ST 2022 beispielsweise zur Überbrückung großer Entfernungen zwischen Gebäuden einzusetzen. Man kann es jedoch auch als Nachteil betrachten, da die Möglichkeiten von IP-Techniken nicht vollends ausgeschöpft werden und das Signal weiterhin als ein einzelnes übertragen wird ohne die unterschiedlichen Bestandteile (Video, Audio, Metadaten) vorher zu

49 2 Einführung trennen. Auch die Verarbeitung des Signals ist recht umständlich, da es zuerst embedded, dann in Pakete umgewandelt und zur Verarbeitung wieder entpackt und de-embedded wird. Eine Darstellung eines solchen Vorgangs ist in Abbildung 25 zu sehen. Der Standard ist eher für Verteilungsnetzwerke einzusetzen, als für Produktionsumgebungen. Übertragen wird per Unicast oder Multicast, wobei bis zu 6 HD-Signale über eine 10 Gbit/s Leitung gleichzeitig gesendet werden können (Barella, 2016; Kunic & Sego, 2018; Nelson, 2016).

Abbildung 25. SMPTE ST 2022-6 Stream (Myers, 2017)

2022-7 (Seamless Protection and Switching of SMPTE ST 2022 IP Datagrams) erlaubt die Übertragung von zwei oder mehr redundanten Streams über unterschiedliche Routen. So ist es möglich, sollten auf einer Strecke Pakete verloren gehen, jene der anderen Strecken zu verwenden. Um ein nahtloses Umschalten zwischen den Paketen der Streams zu ermöglichen, ist jedoch ein Puffer auf der Empfängerseite nötig. Bei Ausfall einer kompletten Route wird das gesamte Signal der jeweils anderen verwendet (Barella, 2016; Kunic & Sego, 2018).

Dieser 2013 veröffentlichte Standard wird jedoch nicht nur ausschließlich in ST 2022-Umgebungen angewandt, sondern auch in den neueren ST 2110- Umgebungen. Abbildung 26 zeigt das Prinzip, wie der Redundanzmechanismus funktioniert. In dem Beispiel legen die beiden Quellensignale unterschiedlich lange Wege zurück, wodurch sie nicht gleichzeitig beim Empfänger eintreffen. Der Empfänger kann die Pakete durch den Puffer jedoch richtig zuordnen und im Fall eines defekten oder fehlenden Pakets nahtlos jenes der anderen Route verwenden (Simpson & Calverley, 2019).

50 2 Einführung

Abbildung 26. SMPTE ST 2022-7 Hitless Protection Switching (Simpson & Calverley, 2019)

Der letzte bis jetzt veröffentlichte Standard 2022-8 (Professional Media Over Managed IP Networks: Timing of ST 2022-6 Streams in ST 2110-10 Systems) spezifiziert die Zusammenarbeit von ST 2022 Streams in einem ST 2110 Timing- Modell. Ebenso wird die Kombination mit FEC und Redundanz behandelt. (SMPTE, 2019b).

Auch wenn derzeit primär an ST 2110 gearbeitet wird, können noch weitere Spezifikationen innerhalb von ST 2022 hinzukommen.

51 3 SMPTE ST 2110

3 SMPTE ST 2110

SMPTE ST 2110 ist in mehrere Substandards aufgeteilt, wobei jeder davon eine bestimmte Aufgabe übernimmt. Der ausschlaggebende Unterschied zu SMPTE ST 2022-6 und auch den klassischen SDI-Standards ist, dass mittels dieses Standards die einzelnen Essenzen (Video-, Audio- und Metadaten) in individuellen Streams übertragen werden. Hierzu werden die Signale in Datenpakete verpackt bevor sie in einem ST 2110 Netzwerk verarbeitet werden können. Nach der Verarbeitung müssen sie wieder miteinander synchronisiert werden. Hierfür werden die einzelnen Pakete mit Zeitmarken versehen. In Abbildung 27 ist so eine Übertragung dargestellt (Myers, 2017; Simpson & Calverley, 2019).

Abbildung 27. Transport mittels ST 2110 (Simpson & Calverley, 2019)

In Abbildung 28 ist noch einmal schematisch dargestellt, wie man sich die einzelnen Streams vorstellen kann. Links ist ein ST 2022-6 Stream zu sehen, der sämtliche Informationen enthält. Dieser ist auch mit einem klassischen SDI- Signal gleichzusetzen, welches einen HANC (Horizontal Ancillary Data) sowie einen VANC (Vertical Ancillary Data) Bereich besitzt, in dem Audio- und Metadaten mitübertragen werden. Rechts sind jeweils ein 2110-20 Videostream, 2110-30 Audiostream und 2110-40 Metadatenstream angeführt. Beispielsweise werden in dieser Darstellung dem Videostream 16 Audiostreams und 3 Metadatenstreams hinzugefügt. Es können aber auch mehr oder weniger sein, dies kommt ganz auf das Anwendungsgebiet an, in dem dieser gesamte 2110 Stream verarbeitet werden soll (Simpson & Calverley, 2019).

52 3 SMPTE ST 2110

Abbildung 28. ST 2022-6 im Vergleich zu ST 2110 (Simpson & Calverley, 2019)

3.1 2110-10 – System Timing and Definitions

Der erste der Sub-Standards spezifiziert das System-Timing-Modell und die Anforderungen, die alle Einzelströme des kompletten Standards gemein haben. Das umfasst die PTP Anforderungen, RTP Takt- und Zeitstempelbestimmungen, allgemeine SDP Anforderungen, sowie Größenbeschränkungen für UDP Datagrammen (SMPTE, 2019a). Beispielhaft für sämtliche Spezifikationen, werden die Eigenschaften von UDP und SDP im Folgenden näher beschrieben.

Die maximale Größe eines UDP Datagramm ist demnach mit 1460 Bytes inklusive dem UDP Header festgelegt. Es gibt jedoch auch eine Ausnahme für Jumbo Frames, welche beispielsweise bei großen Datenmengen verwendet werden können, mit einer Erweiterung auf 8960 Bytes. Des Weiteren sind RTP Timestamps an die Mediadaten gekoppelt. So sind beispielsweise die Timestamps aller Pakete eines einzelnen Videoframes ident. Dies gilt auch für Echtzeitquellen bei denen der Timestamp der Aufnahmezeit entspricht. Für von SDI konvertierte Pakete gibt es spezielle Regeln, die im PTP Standard 2059-1 genau definiert sind. Außerdem müssen alle Media Clocks einen Offset von null haben, um eine Wiederherstellung der Übertragung bei Signalverlust oder unerwartetem Neustart des Systems zu erleichtern (Simpson & Calverley, 2019).

SDP ist ein Format zur Beschreibung von Medieninhalten und ist als RFC 4566 von der IETF standardisiert worden. Im Fall von ST 2110-10 enthält es zur Verarbeitung von Mediendaten notwendige Informationen. Dazu zählen unter anderem Metadaten, Verbindungsinformationen und Informationen zum Timing eines jeden Streams. All diese Informationen werden Textdatei gespeichert und

53 3 SMPTE ST 2110 können so übertragen oder auch mittels einer NMOS API ausgelesen werden. Abbildung 29 zeigt beispielhalt den Inhalt einer SDP-Datei (Simpson & Calverley, 2019).

Abbildung 29. Inhalt einer SDP-Datei (Simpson & Calverley, 2019)

In diesem Beispiel stammt der Stream zu dem diese SDP-Datei gehört von einem System mit der IP-Adresse 10.201.33.19 ab. Es handelt sich um einen 1920x1080i29.97 Videostream mit einer Farbabtastung von 4:2:2 und 10-bit Samplingtiefe. Zum Schluss werden noch die PTP Timing Informationen angezeigt (Simpson & Calverley, 2019).

3.2 2110-20 – Uncompressed Active Video

Dieser Standard legt den RTP-basierten, also in Echtzeit stattfindenden, Transport von unkomprimierten Videostreams fest. Er definiert Weiters eine SDP-basierte Signalisierungsmethode für bildtechnische Metadaten, die notwendig sind, um den Stream empfangen und interpretieren zu können.

ST 2110-20 ist formatunabhängig oder wird auch als formatagnostisch bezeichnet. Er erlaubt die Übertragung von unterschiedlichsten Videoformaten die folgende Eigenschaften inkludieren (SMPTE, 2019a): - Breite und Höhe des Bildes: o Bis zu 32767 x 32767 Pixel - Farbabtastung: o 4:4:4, 4:2:2 und 4:2:0 - Farbmodelle:

54 3 SMPTE ST 2110

o Y’C’BC’R, Y’CC’BCC’RC, ICTCP, RGB, R’G’B‘, X’Y’Z‘ und RP 157 Key Signale - Samplingtiefen: o 8-bit, 10-bit, 12-bit, 16-bit Integer, 16-bit Floating Point - Farbmetriken: o ITU-R BT.601-7, ITU-R BT.709-6, ITU-R BT.2020-2, ITU-R BT.2100-0, ST 2065-1 (“ACES”), ST 2065-3 (“ADX”), ISO 11664-1 - Übertragungsfunktionssysteme: o ITU-R BT.709, ITU-R BT.2100-0 (inkl. “PG“, “HLG“), linear, ST 2065-1 (“ACES”), ST 2065-3 (“ADX”)

In einem 2110-20 Frame sind mehrere Videopixelgruppen (pg, pixel group oder pgroup) enthalten, welche von einem RTP Header angeführt werden. Der RTP Header wird um einen RTP Payload Header erweitert, welcher spezifische Informationen der Pixelgruppen beinhaltet. Dieses RTP Paket wird in ein UDP Paket verpackt und es wird ein IP Header hinzugefügt. Zum Schluss wird daraus ein Ethernet-Frame erstellt, welcher mit einem MAC Header angeführt und einem Frame Footer inklusive Prüfsumme (CS, Checksum) abgeschlossen wird. In Abbildung 30 ist dies übersichtlich dargestellt (Simpson & Calverley, 2019).

Abbildung 30. 2110-20 Video Encapsulation (Simpson & Calverley, 2019)

Die Größe der Pixelgruppen kommt auf die Samplingtiefe des Formats an und setzt sich immer aus vollen Oktetten zusammen. Zusätzlich müssen Pixel, die dasselbe Sample darstellen, immer in derselben Pixelgruppe sein. Der Standard definiert hier für jede Kombination an Samplingtiefe und Farbabtastung die Pixelgruppengröße, wie viele Pixel beinhaltet und in welcher Reihenfolge die einzelnen Samples sind. Abbildung 31 zeigt ein Beispiel für eine Pixelgruppe die 2 Pixel eines 4:2:2 10-bit Signals enthält (Simpson & Calverley, 2019).

55 3 SMPTE ST 2110

Abbildung 31. Pixelgruppe (Simpson & Calverley, 2019)

Im RTP Payload Header sind Informationen zu den darauf folgenden Videosamples angegeben. Dazu zählen die Länge der Videosampledaten, welche als Anzahl der Oktetten angegeben wird, sowie in welcher Zeile und mit welchem Offset die Videosamples beginnen. Des Weiteren wird mit Flags angegeben, ob es sich um eine Vollbild- oder Halbbildzeile handelt (F) und wann eine neue Zeile beginnt (C). Abbildung 32 zeigt den erweiterten RTP Header (Simpson & Calverley, 2019).

Abbildung 32. RTP Header und RTP Payload Header (Simpson & Calverley, 2019)

Die spezielle Neuerung bei diesem Standard im Vergleich zu SDI ist, dass hier, wie eben beschrieben, ausschließlich Videodaten übertragen werden. Zusätzliche Daten, die ansonsten im HANC oder VANC Bereich untergebracht wären, werden in einem separaten Stream übertragen und sind somit unabhängig vom Videosignal (Siehe Kapitel 3.7) (Barella, 2017b).

3.3 2110-21 – Traffic Shaping and Delivery Timing for Video

ST 2110-21 spezifiziert ein Zeitsteuerungsmodell für 2110-20 Streams, welches beim Verlassen des Absenders gemessen wird und definiert des Weiteren die SDP Parameter des Absenders, die verwendet werden, um die Timing

56 3 SMPTE ST 2110

Eigenschaften solcher Streams zu signalisieren. Außerdem werden Packet Read Schedules (PRS), welche angeben, wann der späteste Moment ist um ein Packet zu senden, definiert. Es gibt die folgenden drei Arten von PRS, welche auch in Abbildung 33 dargestellt sind: Type N (Narrow), Type NL (Narrow Linear) und Type W (Wide) (SMPTE, 2019a).

Type N entspricht dabei ungefähr der Art der Übertragung, wie sie bei SDI stattfindet. Hier werden einzelne Pakete in gleichmäßigem kurzen Abstand versendet und werden regelmäßig von einer größeren Lücke unterbrochen, welche die Austastlücke im SDI-Signal imitiert. Dadurch ist diese Variante am kompatibelsten mit SDI und auch für die Echtzeitaufnahme und Verarbeitung konzipiert. Type NL teilt die Pakete vollkommen gleichmäßig über den gesamten Intervall auf und verzichtet auf die größere Lücke zugunsten einer linearen Übertragung. Type W wurde für softwarebasierte Videoquellen entwickelt, bei denen öfters eine unregelmäßigere Übertragung der Pakete üblich ist. Aus diesem Grund ist bei dieser Variante auch ein um vielfaches größerer Puffer vorgesehen, der die unregelmäßig eintreffenden Pakete zwischenspeichern kann (Simpson & Calverley, 2019).

Abbildung 33. ST 2110-21 Sender Types (Simpson & Calverley, 2019)

Damit ein 2110-20 Sender zum 2110-21 Standard kompatibel ist, muss er das Network Compatibility Model und das Virtual Receiver Buffer Model unterstützen. Das Network Compatibility Model sorgt dafür, dass ein Sender die Puffer, die es in den diversen Geräten eines Netzwerks gibt, nicht zum Überlaufen bringt. Hierzu wird ein Skalierungsfaktor angegeben, welcher das Verhältnis der Geschwindigkeit des Füllens und Leerens des Puffers angibt. Das Virtual Receiver Buffer Model hingegen sorgt für das korrekte Zusammenspiel von Sender und Receiver. Dafür wird die Rate mit der sich der Puffer beim Sender leert an die Lesegeschwindigkeit beim Receiver angepasst, mit dem Ziel dass sich der Puffer weder komplett leert oder überfüllt wird (Simpson & Calverley, 2019).

57 3 SMPTE ST 2110 3.4 2110-22 – Constant Bit-Rate Compressed Video

ST 2110-22 ermöglicht die Verwendung von komprimierten Videostreams in einer 2110-Umgebung. Dazu werden Kodierungsverfahren mit sehr geringer Latenz verwendet, die das Videomaterial für den menschlichen Betrachter nicht sichtlich komprimieren. Es werden ausschließlich Codecs mit CBR (Constant Bitrate) Kodierung, wie beispielsweise VC-2 oder JPEG XS unterstützt, wobei hier Kompressionsraten von 2:1 bis zu 8:1 möglich sind. Für die korrekte Verarbeitung müssen in der SDP-Datei gewisse Parameter unbedingt enthalten sein. Dazu gehören unter anderem die Auflösung, die Framerate und ein Parameter, welcher angibt wie stark das Signal komprimiert ist (Simpson & Calverley, 2019).

3.5 2110-30 – PCM Digital Audio

Dieser Standard spezifiziert die RTP-basierte Übertragung von digitalen PCM (Puls Code Modulation) Audiostreams unter Bezugnahme auf AES67. Nicht PCM Audiosignale, einschließlich komprimierter, fallen nicht in den 2110-30 Standard. Zusätzlich ist eine SDP-basierte Signalisierungsmethode für Metadaten definiert, die zum Empfangen und Interpretieren des Streams notwendig ist. Es wird außerdem eine Kanalanordnungskonvention definiert, die zur Identifizierung von Kanaltypen innerhalb von Mehrkanalaudio dient. Der Standard bestimmt auch eine Reihe von Konformitätsstufen basierend auf der Anzahl der Kanäle, den Abtastfrequenzen und den Paketzeiten (SMPTE, 2019a).

Der Aufbau eines 2110-30 Frame ist dem des 2110-20 sehr ähnlich. Hier werden mehrere Audiosamples mit entweder 16- oder 24-bit Auflösung aneinandergereiht. Es wird jedoch im Gegensatz zu 2110-20 kein RTP Payload Header benötigt, sondern nur ein einfacher RTP Header verwendet. Der Timestamp im RTP Header bezieht sich auf das erste Audiosample im Frame. Abbildung 34 zeigt den Aufbau eines kompletten Audio Frames (Simpson & Calverley, 2019).

Abbildung 34. 2110-30 Audio Encapsulation (Simpson & Calverley, 2019)

58 3 SMPTE ST 2110

Des Weiteren wird zum einen eine Receiver Classification definiert, in der 6 Klassen spezifiziert sind. Je nach Klasse kann ein System mehr oder weniger Kanäle, Abtastraten und Paketzeiten verarbeiten. Und zum anderen werden Gruppierungssymbole für Audiokanäle definiert,, welche anzeige wie viele Audiokanäle sich in einer Gruppe und in welcher Reihenfolge sich die einzelnen Kanäle in der Gruppe befinden (Simpson & Calverley, 2019).

3.6 2110-31 – AES3 Transparent Transport

ST 2110-31 spezifiziert den RTP-basierten Transport von AES3 Signalen. Das moderne Broadcastökosystem hat die weite Verbreitung des AES3 Signaltransports genutzt, um viele verschiedene Datenelemente darin zusammenzufassen. So gibt es bereits die Standards SMPTE ST 337 und ST 338, die einerseits allgemeine Verfahren zum Zusammenfassen verschiedener Nutzdaten in den AES3 Transport definieren, und andererseits den wachsenden Namespace dieser Nutzdaten verwalten (SMPTE, 2019a).

3.7 2110-40 – Transport of SMPTE Ancillary Data

Der letzte Teil-Standard spezifiziert den RTP-basierten Transport von SMPTE ST 291 Ancillary (ANC) Datenpaketen (SMPTE, 2019a). Solche ANC Daten finden sich im HANC und VANC Bereich von SDI-Signalen. Die Metadaten, die sich derzeit bei SDI Signalen im VANC Bereich befinden, werden in der neuen IP- Umgebung in separaten RTP Streams übertragen, die nicht an das eigentliche Videosignal gebunden sind. Typische ANC Daten sind Untertitel, Timecode oder AFD (Active Format Description) (Barella, 2017b).

Vorteilhaft ist, dass die Metadaten bereits als Datenpakete existieren und beinahe identisch im neuen Standard verwendet werden können. Dies trifft auf die folgenden Pakete zu: DID (Data Identification), SDID (Secondary Data Identification), DC (Data Count), die eigentlichen Metadaten (User Data) und CS (Checksum). Die ursprüngliche Ancillary Flag wird durch den Ancillary Packet Header ersetzt. Dieser enthält die Zeilennummer und den Offset, welche die Position analog zum ursprünglichen SDI-Signal angeben. Diese Zeilennummer und der Offset dürfen nicht mit jenen aus ST 2110-20 verwechselt werden, da diese sich ausschließlich auf das reine Videosignal beziehen. Wie in Abbildung

59 3 SMPTE ST 2110

35 zu sehen ist wird auch hier wieder ein RTP Header und ein Payload Header vorne angefügt (Simpson & Calverley, 2019).

Abbildung 35. Ancillary Data Aufbau (Simpson & Calverley, 2019)

Im Detail sieht ein jedes Ancillary Datagramm wie in Abbildung 36 abgebildet aus. Zusätzlich zu den eben erwähnten Parametern sind hier noch 2 Flags (C und S) angeführt, welche dazu genutzt werden anzuzeigen, aus welchem Farbkanal die Metadaten stammen, und ob sie sich aus mehreren Streams des originalen Videosignals zusammensetzen. Da die ursprünglichen Parameter nicht für den Transport mittels IP-Protokollen ausgelegt sind, wird nach der Checksum noch ein Padding hinzugefügt, um die Gesamtlänge des Pakets auf ein vielfaches von 32-bit aufzufüllen (Simpson & Calverley, 2019).

Abbildung 36. Format eines Ancillary Data Paket (Simpson & Calverley, 2019)

60 4 Experteninterviews

4 Experteninterviews

4.1 Experten

4.1.1 Georg Kuntner Georg Kuntner ist beim österreichischen Rundfunk (ORF) in der technischen Direktive in der Abteilung für Rundfunktechnik und Planung tätig. Dabei ist er für Projektentwicklung und deren Umsetzung zuständig. Sein Hauptaufgabenbereich sind neue Technologien, wobei SMPTE ST 2110 ein wesentlicher Faktor ist. Er ist Projektleiter bei einem IP Testlabor und Projektmitarbeiter bei einem Ü-Wagen Projekt, welcher komplett in SMPTE ST 2110 umgesetzt wurde.

4.1.2 Matthias Barth Matthias Barth ist Senior Solution Architect bei der Playout und Production Solutions innerhalb der ProSiebenSat.1 Gruppe. Zusätzlich zu seinen Aufgaben im Bereich Playout beschäftigt er sich schon seit mehreren Jahren mit der Umstellung von SDI auf IP und betreibt ein Testlabor, in dem die Umsetzbarkeit von SMPTE ST 2110 für das Unternehmen geprüft wird. Seiner langjähren praktischen Erfahrung kommt Weiters eine Mitgliedschaft bei AIMS zugute, durch die er immer am neuesten Wissensstand bleibt.

4.1.3 Philipp Beuchert Philipp Beuchert ist Leiter der Abteilung Broadcast and Production Systems bei ATV, welche die broadcasttechnische Infrastruktur zur Verfügung stellt und verwaltet. Angefangen von Studio- und Regietechnik, über Postproduktion und Media Asset Management, bis hin zum Playout der vier Sender ATV, ATV2, Puls 4 und Puls 24. Er und sein Team planen derzeit sich in naher Zukunft eine Testumgebung für SMPTE ST 2110 aufzubauen, um ein praktischeres Verständnis für die Materie zu erhalten.

61 4 Experteninterviews

4.1.4 Sandro Furter Sandro Furter ist Projektleiter im Projekt Metechno in der Abteilung SRF Operationen. Er ist Detailprojektleiter des Baustein 0, welcher sich unter anderem mit sämtlichen zentralen Diensten, Netzwerkarchitekturen und der SMPTE ST 2110 Umgebung befasst. Des Weiteren ist er Leiter der Fachcommunity IP innerhalb des SRF und SRG, sowie Mitglied der SMPTE Drafting Group, AIMS und AMWA. Er und seine Kollegen des SRF waren die ersten im deutschsprachigen Raum, die ein Projekt in der Größenordnung von Metechno umgesetzt haben.

4.1.5 Stefan Kollinger Stefan Kollinger ist Referent des technischen Direktors des ORF. Sein Aufgabenbereich reicht von Projektbegleitung über Planung bis hin zu seinen Aufgaben als Referent. Sein derzeitiger Hauptbezug zum Thema SMPTE ST 2110 besteht durch die Planung der Systemarchitektur für das ORF-Zentrum, welche mittels eines IP-Realtime-Videonetzwerks umgesetzt werden soll.

4.2 Ergebnisse

Im Zuge der Interviews wurden die Gesprächspartner unter anderem auf eine Gegenüberstellung von IP- und SDI-Technologie, die Möglichkeiten und Herausforderungen, die der neue SMPTE Standard mit sich bringt, und ihre Erfahrungen anhand aktueller Projekte, angesprochen. In den folgenden Unterkapiteln werden die Ergebnisse der durchgeführten Experteninterviews in Kategorien zusammengefasst und dargestellt.

4.2.1 Vorteile von IP-Technologien

4.2.1.1 Infrastruktur Einer der ersten Punkte die als Vorteil von IP-Technologien gesehen wird, ist die damit zusammenhängende Infrastruktur und deren platzsparende Eigenschaften. So wird man teilweise sogar aufgrund von baulichen Gegebenheiten gezwungen Glasfaserkabel, welche sehr viel mehr Daten übertragen können, statt Kupferkabel zu verlegen. Wenn man dann diese fertige IP-Infrastruktur umgesetzt hat, ist es erheblich leichter diese auf eine neue technologische Stufe zu bringen, beispielsweise die Möglichkeit UHD-Signale zu verarbeiten, als es mit SDI der Fall ist. So reicht es im Idealfall die Konfiguration der verwendeten Geräte anzupassen oder neue Geräte mit der gewünschten Funktion zu

62 4 Experteninterviews integrieren ohne die grundlegende Infrastruktur ändern zu müssen (Barth, 2020, Abs. 6).

Ebenso bringt die neue IP-Technologie eine große Ersparnis im Platzbedarf der einzelnen Geräte mit sich. Das errichtete Rechenzentrum für das Projekt Metechno bietet in 192 19-Zoll Racks Platz für Geräte, wobei für das Projekt selbst nur rund 30 Racks, welche mit sehr viel Luft zwischen den Geräten verbaut wurden, benötigt werden. Diese Reduzierung des Platzbedarfs spiegelt sich auch in dem Vergleich wieder, dass allein das Playoutcenter des SRF für 3 TV-Sender mehr Rackplatz benötigt, als der komplette Metechno Neubau mit mehreren Studios und sämtlichen technischen Zusatzräumen (Furter, 2020, Abs. 42).

Grundsätzlich ist die Infrastruktur sehr schnell und kostengünstig erweiterbar. Vereinfacht gesagt, reicht es bei der Erschließung eines neues Standortes innerhalb einer Organisation aus, eine geringe Anzahl an Glasfaserleitungen legen zu lassen, welche an den Switch Vorort angeschlossen werden, um eine große Anzahl an Signalen verfügbar zu haben (Furter, 2020, Abs. 6).

4.2.1.2 Skalierung, Flexibilität und Ressourcenteilung Ein Punkt, welcher stark mit der Infrastruktur zusammenhängt, ist die damit verbundene Skalierung und Flexibilität. So spricht auch Kuntner (2019, Abs. 6) die einfache Erweiterbarkeit, beispielsweise durch den Austausch eines einzelnen Switch, der Funktionalität der vorhanden Infrastruktur an.

Im Gegensatz zu SDI ist es mittels eines IP-Backbones einfacher möglich große Strukturen zu erzeugen. Bei SDI-Kreuzschienen stößt man hier ab einer gewissen Größe an die Grenzen des Machbaren und muss mehrere Kreuzschienen mittels Tielines verbinden. Wohingegen bei einem IP-Backbone sozusagen nur eine Kreuzschiene existiert (Barth, 2020, Abs. 6).

Um diese Flexibilität erreichen zu können, ist es laut Beuchert (2020, Abs. 8) aber auch notwendig die bis heute vorhandene Denkweise von klassischen Broadcastmitarbeitern, bezogen auf statische Signalwege von einem Eingangssignal über mehrere Verarbeiter bis hin zu einem Ausgangssignal, auf eine neue Denkweise, die die Möglichkeiten von Multicast berücksichtigt, zu ändern. Beuchert sowie Kuntner versprechen sich außerdem eine höhere Flexibilität von möglichen neuen Virtualisierungslösungen, bezogen auf einfachere Ressourcenteilung (Beuchert, 2020, Abs. 12; Kuntner, 2019, Abs. 6).

Furter sieht die versprochene Flexibilität von IP etwas kritischer, da sie seiner Meinung nach auch mit SDI-Technologien erreicht werden kann. Er spricht

63 4 Experteninterviews jedoch eine andere Art der Flexibilität an, die speziell in der Schweiz mit ihren 4 Landessprachen nützlich ist. So ist es mittels ST 2110 flexibler möglich diese große Zahl an benötigten Audiokanälen zu verarbeiten. Man ist im Vergleich zu SDI nicht mehr an die 16 Embedded Audiokanäle gebunden, die zusätzlich noch je nach Sprache embedded oder de-embedded werden müssen (Furter, 2020, Abs. 6).

4.2.1.3 Kosten Ein weiterer Punkt, welcher auch öfters genannt wurde, sind mögliche Kosteneinsparungen, die derzeit zwar aufgrund der noch neuen Technologie im Vergleich zu SDI, noch nicht vorhanden sind, welche in Zukunft jedoch möglich sein sollen (Beuchert, 2020, Abs. 24; Kuntner, 2019, Abs. 6).

Der Kostenvorteil ergibt sich einerseits durch die bereits verbreiteten Common- of-the-shelf Produkte. So kann man bereits jetzt schon einen Preisverfall bei bestimmten Produkten wie Switches feststellen, die für die jeweiligen Anforderungen schon mehr als genug Leistung bieten (Barth, 2020, Abs. 6; Furter, 2020, Abs. 6). Barth sieht auch in den kürzeren Erneuerungszyklen von IP-Technologie eine Kostenersparnis. So kann man diese zwar auch als Nachteil betrachten, jedoch ergeben sich durch diese kürzeren Zyklen von 3 bis 5 Jahren Situationen durch die man leistungsfähigere Hardware früher verwenden kann als bei längerfristigen Abschreibungen von 10 und mehr Jahren (Barth, 2020, Abs. 8).

Kollinger (2020, Abs. 6) sieht diesbezüglich den bereits vorhandenen branchenähnlichen Markt an Datacenter-Technologie ebenfalls als Vorteil. Auch wenn ihm natürlich bewusst ist, dass diese Hardware auch komplex und teuer sein kann.

4.2.1.4 Formatagnostik Die Vorteile der Formatagnostik, also der Möglichkeit eine Vielzahl von Formaten in seiner Produktionsumgebung zu verwenden und zu verarbeiten, sprechen Furter und Kollinger an. Für Furter (2020, Abs. 6) ist diese Technologie zukunftsweisend. So muss man sich nicht heute schon entscheiden welche möglichen Formate (zB.: HDR oder 8K) man in Zukunft in seinem Netz verarbeiten können will. Klassische Koaxialkabel die in der SDI-Welt verwendet werden, stoßen hier an ihre Grenzen.

Auch Kollinger (2020, Abs. 6) sieht die Formatagnostik als sehr großen Vorteil und erwähnt ebenfalls die Einschränkungen von HDSDI und bereits vorhandener SDI-Kreuzschieneninfrastruktur. Für ihn sind aber nicht die unkompliziert

64 4 Experteninterviews realisierbaren höheren Auflösungen ein Vorteil, sondern auch die Möglichkeit andere Bildformate, als das heute übliche 16:9, zu verarbeiten. Er denkt dabei vor allem an digitale Verbreitungswege wie der Konsumation von Inhalten über das Smartphone. Bildseitenverhältnisse von 9:16 oder 1:1 sind mittels ST 2110 einfacher realisierbar und eröffnen so Wege zu neuen Produkten im digitalen Umfeld.

4.2.1.5 Controlling Ein kurz von Beuchert (2020, Abs. 12) erwähnter Vorteil sind die erhöhten Kontrollmöglichkeiten über das gesamte System. Er erhofft sich nicht nur ganz rudimentäre Kontrollen, wie zum Beispiel die einfache Erkennung, ob ein Stream ankommt, sondern auch tiefergehende Möglichkeiten, wie Bandbreitenanalyse oder Fehlererkennung.

4.2.1.6 Kompression Ein Vorteil, welcher nur selten angesprochen wurde, sind theoretisch mögliche Dateneinsparungen. Auch wenn der Standard grundsätzlich einzelne voneinander getrennte Streams verarbeitet, sehen die Experten hier in der Anwendung derzeit keinen großen Vorteil, da die im Endeffekt erreichten Bandbreiten für die heute verfügbare Technologie im Broadcastumfeld keine Herausforderung darstellt. Größere Unternehmen wie Amazon oder Google erreichen hier weitaus mehr Datendurchsatz in ihren Netzen (Kuntner, 2019, Abs. 18). Für Furter (2020, Abs. 42–44) bleibt die schlussendliche Bandbreite mehr oder weniger dieselbe im Vergleich zu 3G-SDI, außer man verwendet Komprimierungsverfahren wie JPEG XS.

JPEG XS spricht Kollinger (2020, Abs. 26) an und sieht in diesem praktisch latenzfreien Realtimecodec einen Vorteil, welcher sich in Zukunft eher durchsetzen wird. Aus seiner Sicht stellt sich die Frage, warum man denn unkomprimierte Videodaten verarbeiten soll, wenn man hier die Möglichkeit hat Daten einzusparen.

4.2.1.7 Zukunftssicherheit Der letzte große Vorteil der genannt wurde ist die Zukunftssicherheit. Wenn man heutzutage ein größeres Produktionsumfeld auf- oder umbaut, ist es aus Sicht von Furter (2020, Abs. 30) ein Fehler auf SDI-Technologie zu setzen. Da IP- Technologien von immer mehr Herstellern angeboten werden und immer mehr Produkte vorgestellt werden, sind hier die Entwicklungsressourcen höchstwahrscheinlich mehr vertreten, als bei SDI-Technologien. Man muss sich also im Klaren sein, auch wenn man heute noch SDI-Technologie ohne Weiteres

65 4 Experteninterviews kaufen kann, so muss man dann bis zum nächsten Investitionszyklus mit dieser, womöglich nicht mehr so stark von den Entwicklern unterstützten, Technologie arbeiten.

Barth (2020, Abs. 6) spricht diesbezüglich auch wieder die bereits vorhin erwähnte Flexibilität in der Infrastruktur an. Wenn er zukünftig den Campus um die Möglichkeit erweitern möchte UHD verarbeiten zu können, braucht er im Idealfall nur wenig bis Garnichts an der grundlegenden Infrastruktur ändern. Weiters sieht er ebenfalls keinen Grund bei SDI-Technologie zu bleiben, unabhängig davon, ob er die Wahl hat oder nicht. Für ihn sind Zukunftstechnologien wie Next Generation Audio, Higher Framerates oder eine einfachere Bereitstellung von OTT-Content ohne Ändern der Infrastruktur ein klarer Vorteil (Barth, 2020, Abs. 10).

4.2.2 Nachteile von IP-Technologien

4.2.2.1 Knowhow

Einer der ersten Nachteile, die bei IP-Technologien genannt wird, ist das fehlende Knowhow der Mitarbeiter, beziehungsweise der Personen, die die Integration planen und verantworten. Kuntner (2019, Abs. 8) sieht hier eine Verlangsamung der Implementierung, die zu mehr Kosten führt. Auch Beuchert sieht hier einerseits generell fehlende Erfahrung und Wissen über IP- Technologien (2020, Abs. 10), und andererseits, im Speziellen, fehlendes Wissen über Netzwerktopologien bei klassischen Broadcastmitarbeitern als Problem (2020, Abs. 14). Hier muss ein Wissensaustausch zwischen dem Netzwerkbereich und Broadcastbereich über den Aufbau von Topologien und generellem Netzwerktechnikwissen stattfinden.

Eine Abwandlung des Problems sieht Barth (2020, Abs. 10) darin, dass die wenigen Experten auf dem Gebiet der IP-Technologien in der Industrie und der Entwicklung angestellt, und deswegen nicht in den jeweiligen Unternehmen vorhanden sind, die diese Technologie einsetzen wollen. Er findet ebenfalls wie seine Kollegen, dass spezielleres Wissen über Netzwerktechnik im Broadcastbereich eher selten ist. Auch generelles Knowhow über Themen, die erst bei der wirklichen Planung und Umsetzung der Projekte auftreten, wie beispielsweise die Grenzen der Bandbreitenauslastung auszutesten, fehlt (Barth, 2020, Abs. 14).

66 4 Experteninterviews

4.2.2.2 Komplexität Im Gegensatz zur SDI-Welt sieht Kuntner (2019, Abs. 8) den ST 2110 Standard komplexer in der Anwendung. Bei SDI ist oftmals ohne großen Konfigurationsaufwand schnell ein Ergebnis sichtbar. Wohingegen IP-Standards hier mehr Feinarbeit benötigen. Für kleine Anwendungen sieht er hier einen Nachteil, da sie ohne unterstützende Steuersysteme nicht ihr volles Potential ausschöpfen können.

Kollinger (2020, Abs. 12) erwähnt auch, dass die Konfiguration der Geräte relativ aufwändig ist. Beispielsweise nennt er hier FPGA-basierte Multifunktionsgeräte. Diese Geräte können je nach Konfiguration der in ihnen vorhandenen Hardware unterschiedliche Aufgaben übernehmen. Grundsätzlich gibt es diese Geräte aber in der SDI-Welt auch schon. Er spricht aber auch erneut die voneinander getrennten Streams an. Diese müssen alle richtig konfiguriert und gebündelt werden, welcher ein aufwendiger Prozess ist, der nur schwer mit mehr Personalressourcen ausgeglichen werden kann.

Eine andere Art der Komplexität ist eventuell in naher Zukunft vorhanden, wenn die Kapazitäten der derzeitigen Hard- und Software an ihre Grenzen gehen. Dies könnte passieren, wenn sich die Bandbreiten, Bitraten, Auflösungen und andere Eigenschaften, beispielsweise mit dem Umstieg auf UHD, erhöhen (Kollinger, 2020, Abs. 14).

4.2.2.3 Produktverfügbarkeit Im Gegensatz zur SDI-Technologie gibt es in der IP-Technologie, allen voran für ST 2110, noch eine gewisse Produktknappheit. Dementsprechend kann es schwierig sein gewisse Workflows oder Produktionsketten vollständig in IP umzusetzen, da die vorhandenen Produkte eventuell noch nicht alle gewünschten Funktionen unterstützen (Barth, 2020, Abs. 10). Barth (2020, Abs. 12) fehlt beispielsweise immer noch ein Videotextinserter, der ST 2110 unterstützt. Noch lieber wären ihm natürlich mehrere Produkte einer Kategorie, so dass er gewisse Auswahlmöglichkeiten hat, da es natürlich vorkommen kann, dass einzelne Produkte in gewissen Disziplinen nicht ausreichend gut durchdacht sind.

Da der TPC eines der ersten großen Projekte in ST 2110 umgesetzt hat, berichtet auch Furter (2020, Abs. 18) von einem Mangel an Produkten. Vor allem zu Beginn des Projektes wurden von den Herstellern Funktionen versprochen, die sich später als lückenhaft herausgestellt haben. Da Furter und sein Team sich sehr früh sehr intensiv mit dem Standard auseinandergesetzt haben, konnten sie den Herstellern genaue Anforderungen kommunizieren, welche im

67 4 Experteninterviews

Anschluss in die Produkte integriert wurden. Trotz der engen Zusammenarbeit mit den Herstellern gibt es jedoch auch für Furter heute immer noch Anwendungsgebiete, in denen keine ST 2110 Lösungen vorhanden sind.

4.2.2.4 Etablierung Ein Punkt, der an die Produktverfügbarkeit anknüpft, ist der Stand der Etablierung im Anwendermarkt. Beispielsweise müssen bei größeren Produktionen, in denen mehrere Ü-Wägen zum Einsatz kommen, diese natürlich untereinander kompatibel sein. Wenn nun ein Signal von einem in ST 2110 gebauten Ü-Wagen in einen klassisch, mit SDI Gebauten weitergegeben werden soll, muss dieses Signal zwangsweise über Gateways gewandelt werden. Auch an anderen Produktionsorten, wie einem Hauptschaltraum, der auf IP basiert, müssen die einkommenden SDI-Signale zuerst über Gateways konvertiert werden. Man kommt also heutzutage nicht daran vorbei Signale häufiger an der Grenze seiner Produktionsumgebung zu wandeln, wenn man mit anderen Unternehmen oder Dienstleistern kooperiert (Kollinger, 2020, Abs. 14).

4.2.2.5 Neuer Markt Bezogen auf Gateways spricht Kollinger (2020, Abs. 14) auch die ST 2110 Geräte direkt an. Einige dieser Geräte besitzen derzeit noch eingebaute Signalwandlerkarten, die Signale am Ein- und Ausgang zu und von SDI wandeln. Nach außen hin wirken sie so wie ein vollwertiges IP-Produkt, intern arbeiten sie aber weiterhin auf Basebandbasis. Bis also sämtliche Produkte vollständig auf IP-Technologien umgestellt wurden, kann es noch ein paar Jahre dauern.

Ein weiterer Nachteil an einem neuen Markt ist die Ungewissheit mit welchen neuen Partnern man zusammenarbeiten muss, die unter Umständen das Geschäftsmodell oder die Arbeitsweise des Kunden nicht verstehen (Furter, 2020, Abs. 6).

Furter (2020, Abs. 30) sieht generell auch das Risiko, welches immer bei einem neuen Markt inkludiert ist, als Nachteil. Man kann heute noch nicht mit Gewissheit voraussehen, ob man in den nächsten Jahren beispielsweise keinen Ausfall des Netzwerkes haben wird, da es derzeit noch keine Langzeiterfahrungen in diesem Gebiet und dieser Größenordnung gibt. Diesbezüglich spricht er auch das Broadcastpersonal an, welches erfahrungsgemäß meistens auf Nummer sicher gehen möchte, und nicht immer gewillt ist das Risiko einer neuen Technologie einzugehen, was wiederum die vorhin angesprochene Etablierung im Markt verlangsamt.

68 4 Experteninterviews

4.2.2.6 Lebensdauer Ein weiterer angesprochener Nachteil von IP-Technologien sind die kürzeren Lebensdauern und Abschreibungszyklen. Die Erwartung an die Einsatzdauer von IP-Anlagen ist im Vergleich zu Broadcastanlagen geringer (Kuntner, 2019, Abs. 6).

Ein Netzwerkswitch wird in der Realität alle 3 bis 5 Jahre getauscht. In der Broadcastumgebung werden die Kernsysteme, wie beispielsweise Kreuzschienen, jedoch häufig bis zu 10 Jahre lang betrieben. Dies erfordert ein wirtschaftliches Umdenken was Investitionszyklen, Abschreibungen und Supportverträge betrifft (Beuchert, 2020, Abs. 24; Furter, 2020, Abs. 10).

4.2.2.7 Sicherheit Ein letzter Nachteil der erwähnt wurde, der später auch noch bei den Herausforderungen genannt wird, ist die derzeit noch nicht voll gegebene Sicherheit der Systeme. Es gibt Geräte die von sich aus nicht ausreichend abgesichert sind. Vor allem bei kleineren Systemen würde der Aufwand das System ausreichend abzusichern sich nicht mehr lohnen und es wäre ratsamer auf eine andere Technologie auszuweichen (Furter, 2020, Abs. 8; Kuntner, 2019, Abs. 20).

4.2.3 Vorteile von SDI-Technologien

4.2.3.1 Etablierung und Stabilität

Einer der großen Vorteile von SDI-Technologie ist derzeit noch die großflächige Etablierung der Systeme. Es ist durch die lange Verfügbarkeit am Markt eine bekannte Technologie und es gibt eine große Auswahl an Produkten die stabil funktionieren (Barth, 2020, Abs. 10).

Durch die große Verfügbarkeit an Produkten sind einzelne Geräte auch um einiges günstiger in der Anschaffung, als IP-Produkte, die natürlich in der Anfangszeit durch höheren Entwicklungs- und Forschungsaufwand teurer sind. Des Weiteren sind durch jahrelange Entwicklung bereits alle Probleme gelöst, die man jetzt eventuell bei IP hat. So ist es bei SDI im Grunde immer einfaches Plug- and-Play und die Geräte funktionieren ohne Probleme. Diese fertige Lösung funktioniert ohne großen Konfigurationsaufwand und ist dadurch in der Handhabung um einiges effizienter (Beuchert, 2020, Abs. 10, 2020, Abs. 24; Kuntner, 2019, Abs. 8).

69 4 Experteninterviews

Durch die langjährige Erfahrung mit SDI-Technologie kann man sie zum einen risikomäßig viel besser einschätzen als IP-Technologie, ohne einen externen Berater zu benötigen (Furter, 2020, Abs. 30). Und zum anderen ist für den täglichen Betrieb weniger Schulungsbedarf für das operative Personal notwendig, welches sich um den Support kümmert (Kollinger, 2020, Abs. 8).

4.2.3.2 Vorhandene Infrastruktur Als weiteren Vorteil sieht Kollinger (2020, Abs. 8) derzeit noch den Faktor der bestehenden Infrastruktur. Wenn man nicht aufgrund des Endes der Lebenszyklen von Produkten oder anderen Umständen dazu gezwungen ist seine Infrastruktur grundlegend zu erneuern, gibt es aus seiner Sicht heute keinen Grund sofort auf eine IP-Infrastruktur zu wechseln. Wenn man ein funktionierendes und erprobtes System hat, welches derzeit ohne Einschränkungen einsetzbar ist, braucht man sich derzeit keinem Druck aussetzen dieses so bald wie möglich tauschen zu müssen. Auch Beuchert (2020, Abs. 12) würde aus heutiger Sicht nicht ohne guten Grund seine komplette SDI-Verkabelung gegen einen IP-Infrastruktur austauschen.

4.2.3.3 Knowhow Der letzte Vorteil, der bei IP-Technologien vorhin als Nachteil angegeben wurde, ist das weit verbreitete Knowhow der Mitarbeiter. Durch die langjährige Nutzung der Systeme hat sich ein breites Grund- und Fachwissen beim Personal und Herstellern entwickelt, auf das man jederzeit zugreifen kann (Barth, 2020, Abs. 10; Beuchert, 2020, Abs. 10).

4.2.4 Nachteile von SDI-Technologien

4.2.4.1 Technische Einschränkungen

Als ein großer Nachteil von SDI-Technologien wurden die technischen Einschränkungen genannt. Wenn man beispielsweise ein neues Format in seiner vorhandenen Kreuzschieneninfrastruktur verarbeiten möchte, ist das grundsätzlich erstmal nicht möglich. Die einzige Möglichkeit besteht hier durch ein manuelles Eingreifen mittels im Vorhinein durchgeführter Konvertierung des Signals (Kollinger, 2020, Abs. 6).

Des Weiteren wurde vorhin schon erwähnt, dass eine weitere Einschränkung von SDI die Limitierung auf 16 Embedded Audiokanäle ist. Möchte man mehr oder unterschiedliche Konfigurationen der Kanäle, muss man immer de-embedden und wieder embedden (Furter, 2020, Abs. 6).

70 4 Experteninterviews

4.2.4.2 Verkabelungsaufwand Für eine Infrastruktur ab einer gewissen Größe ist ein enormer Aufwand, bezogen auf die physische Verkabelung, notwendig. Da über Kupferkabel, die in der SDI-Technologie für kürzere Strecken eingesetzt werden, nur begrenzt Signale übertragen werden können, muss man hier relativ schnell auf Glasfaserverkabelung umsteigen. Um also eine Vielzahl von Signalen von A nach B zu übertragen, ist ein vergleichsweise hoher Aufwand notwendig (Barth, 2020, Abs. 4).

4.2.4.3 Abschreibungszyklen Einen letzten Nachteil der vorhin auch als Nachteil von IP-Technologie erwähnt wurde, nennt Barth (2020, Abs. 8). So kann es aus seiner Sicht eben auch ein Nachteil sein, sich in zu langen Abschreibungszyklen von 10 bis 15 Jahren zu befinden, da man während dieser Zeit an seinen derzeitigen technologischen Stand gebunden ist.

4.2.5 Gemeinsamkeiten

4.2.5.1 Anwendungsbezogen Es muss jedoch nicht immer eine Technologie der anderen überlegen sein. So kommt es laut Furter (2020, Abs. 6) auch immer darauf an, welche Art von Projekt man umsetzt, beziehungsweise welche Systeme man implementiert. Auch Kollinger (2020, Abs. 8) sieht die Situation generell etwas differenzierter, da sich die IP-Standards derzeit noch in Entwicklung befinden und dadurch natürlich derzeit noch Probleme auftreten können.

4.2.5.2 Bedienung Generell kann man sagen, dass sich an der schlussendlichen Bedienung der Endgeräte für den Operator nichts ändert. Das Betriebspersonal bekommt im besten Fall nicht zu spüren, dass sich der Transportweg der Signale im Hintergrund grundlegend geändert hat. So kann der tägliche Betrieb und sämtliche Produktion ungehindert fortgesetzt werden, ohne das Personal umschulen zu müssen (Kollinger, 2020, Abs. 12; Kuntner, 2019, Abs. 36).

4.2.5.3 Updateintervalle Die Updateintervalle der Systeme, sobald diese im Einsatz sind, haben sich im Vergleich zu früher nicht verändert. Auch wenn derzeit noch viel Entwicklungsfortschritt und häufig verfügbare Updates der Geräten zu beobachten sind, werden diese, wenn sie in Verwendung sind, deswegen nicht

71 4 Experteninterviews jedes Mal sofort eingespielt. Wie bei klassischer SDI-Technologie wird hier sehr stark beobachtet und abgewogen, ob ein Update für spezifische Systeme notwendig ist oder eventuell garkeinen zusätzlichen Nutzen mit sich bringt (Kuntner, 2019, Abs. 22).

4.2.6 Herausforderungen

4.2.6.1 Technisch

Als technische Herausforderung sieht Kuntner (2019, Abs. 18) die Echtzeitfähigkeit der verwendeten IT-Hardware. Im Gegensatz zur IT-Branche ist nämlich in der Broadcastbranche eine Übertragung in Echtzeit notwendig. Ein zu spät angekommenes Paket oder genereller Paketverlust hat hier mehr Auswirkungen als in normalen Netzwerken. Die Systeme brauchen also genügend Leistung und Ressourcen um die Datenströme zügig verarbeiten zu können. Kollinger (2020, Abs. 24) widerspricht hier seinem Kollegen teilweise. Aus seiner Sicht besteht hier keine technische Herausforderung, da die verwendetet Hardware auch in Datencentern zum Einsatz kommt, in denen ebenfalls hohe Datenraten und zeitkritische Übertragungen vorkommen. Er sieht jedoch in der Inbetriebnahme und der Konfiguration die Möglichkeit, dass es hier zu Problemen kommen kann. Grundsätzlich sieht Kollinger (2020, Abs. 46) aber keine Probleme in der verwendeten Netzwerktechnologie.

Darüber hinaus ändert sich der grundlegende Aufbau der Signalkette. Eine messtechnische Fehlersuche ist bei IP-Infrastruktur aufwendiger durchzuführen, da es keine eindeutigen Signalwege mehr gibt. Aufgrund der Komplexität der Systeme im Aufbau und der Vielfältigkeit der Funktionen von einzelnen Geräten ist hier ein Umdenken notwendig (Kuntner, 2019, Abs. 36).

Grundsätzlich sieht Barth (2020, Abs. 10) es als schwierig an ein Projekt komplett mittels IP-Technologie umzusetzen. So ist für ihn beispielsweise ein Ü- Wagen, der zwar im Kern auf IP-Komponenten aufgebaut ist, jedoch um diese herum eine Vielzahl von Gateways verbaut hat, laut seiner Definition kein vollwertiger IP-Ü-Wagen.

Barth (2020, Abs. 26) sieht ebenso eine Herausforderung in der Verwaltung der unzähligen Multicast-Adressen. Er nennt als Beispiel einen Videostream aus dem Ü-Wagen des TPC, welcher 32 einzelne Audiostreams und zusätzliche Metadatendaten-Streams zugeordnet hat. Hier kommt man also im Vergleich zu einem einzelnen SDI-Signal auf rund 40 einzelne Streams, die man verwalten muss.

72 4 Experteninterviews

Eine weitere technische Herausforderung spricht Beuchert (2020, Abs. 14) an. Aus seiner Sicht ist das korrekte Timing in einer ST 2110 Umgebung von großer Bedeutung. Jede kleine Abweichung kann hier zu Bild/Ton-Asynchronität oder Metadatenverlust führen. Auch Furter (2020, Abs. 22) hat zu Beginn PTP als Herausforderung betrachtet. Jedoch eher in der Komplexität der Architektur, da diese sehr viele Möglichkeiten bietet. Für Kollinger (2020, Abs. 20) ist ebenfalls klar, dass die Verteilung des PTP komplex ist und dementsprechend mit entsprechender Genauigkeit umgesetzt werden muss. Er führt auch die Wandlung von SDI auf IP-Streams aufgrund des Taktes als Herausforderung an. Aufgrund der unterschiedlichen Genauigkeiten von PTP und Black Burst kann es hier zu Jitter kommen.

Beuchert (2020, Abs. 16) erwähnt auch den in vielen Situationen unvermeidbaren Mischbetrieb von SDI- und IP-Technologie. In diesem könnte es sich als Herausforderung darstellen, neben der Funktionalität, auch die Sendesicherheit und stabile Systeme zu gewährleisten.

4.2.6.2 Wirtschaftlich Bei den wirtschaftlichen Herausforderungen werden wieder die bereits oben angesprochenen kürzeren Abschreibungszyklen erwähnt. Hier gibt es einfach Unterschiede in den Geschäftsmodellen bei den diversen Herstellern von Broadcast- und IT-Infrastrukturhardware, sowie in der Lebensdauer dieser Geräte. Es müssen sich dementsprechend die Anschaffungsintervalle der Kunden ändern, was zu einer Herausforderung werden kann (Furter, 2020, Abs. 10; Kollinger, 2020, Abs. 16).

Es wird auch die Situation des Herstellermarktes an sich als Herausforderung angesprochen. Dieser liefert laut Kollinger (2020, Abs. 46) nicht so schnell neue Produkte und Lösungen, wie es eigentlich möglich wäre. Er sieht jedoch auch ein, dass sie die Unternehmen selbst auch erst an die neue Situation anpassen müssen. Diese haben selbst eventuell zu wenige Mitarbeiter mit dem richtigen Knowhow, zu wenig Ressourcen oder müssen sich parallel natürlich auch um den Support von derzeit am Markt befindlicher Hardware kümmern. Er merkt auch an, dass gerade in den letzten Jahren sich viele Unternehmen sich gegenseitig aufkaufen, um an mehr Ressourcen, Produktkategorien und Knowhow zu gelangen. Dies führt aber auch zu einer schrumpfenden Auswahl von Mitbewerbern.

Barth (2020, Abs. 26) erwähnt diesbezüglich auch die Möglichkeit der Problematik wenn Firmen aufgekauft werden, kann es dazu führen, dass eventuell Produkte nicht mehr weiterentwickelt werden. Wenn man sich an einem

73 4 Experteninterviews

Punkt nun für die falsche Technologie entschieden hat und diese aufgrund der wirtschaftlichen Situation nicht im Markt bestehen bleibt, hat man hier keine Möglichkeit aktiv entgegenzuwirken.

4.2.6.3 Organisatorisch Eine weitere Herausforderung stellt für Kollinger (2020, Abs. 54) die Dokumentation dar, da es hierfür noch keine zufriedenstellende Lösung gibt. Es ist im Vergleich zu konventioneller SDI-Technik nicht immer „Ein Kabel ist gleich ein Signal“. Über eine 400Gbit Schnittstelle können beispielsweise tausende HD- Signale, Audiostreams und Metadatenstreams übertragen werden. Hier ist die Herausforderung diesen Signalfluss so darzustellen, dass zum einen eine Person sich diese Darstellung ansehen und zum anderen auch einen Nutzen daraus ziehen kann. Hier muss die Broadcastindustrie noch von der IT-Industrie lernen (Kollinger, 2020, Abs. 56). Kollinger (2020, Abs. 58) würde es auch als Vorteil sehen, wenn sich für die verschiedenen Darstellungen beim Monitoring von diversen Datenströmen ebenfalls Standards entwickeln.

Auch Beuchert (2020, Abs. 14) sieht die Herausforderung in der Dokumentation der unzähligen IP-Adressen der Geräte und einzelnen Streams. Eine vernünftige Dokumentation ist zwar bei einer klassischen SDI-Verkabelung auch unabdingbar, jedoch wird sie bei der Komplexität von IP-Infrastruktur noch um einiges wichtiger. Für ihn ist auch aufgrund seiner noch nicht vorhandenen praktischen Erfahrung mit dem neuen Standard eher die Planung der Infrastruktur eine Hürde vor der er noch Respekt hat (Beuchert, 2020, Abs. 16).

4.2.6.4 Personell Eine große Herausforderung, die ebenfalls bereits unter den Nachteilen von IP- Technologien angeführt wurde, ist das noch fehlende Knowhow der Mitarbeiter. Dieses kann einer Implementierung im Weg stehen, oder es wird Zeit benötigt um die Mitarbeiter in die neue Thematik einzuführen. Diese Wissensgebiete sind ganz klassische wie Synchronität und Timing, da diese Themen natürlich weiterhin wichtig sind, jedoch anders funktionieren. Es kommt jetzt jedoch noch grundlegendes Netzwerkwissen hinzu, welches eben viele Mitarbeiter nur bis zu einem gewissen Grad haben (Kuntner, 2019, Abs. 8–10).

Ein anderer Schritt wäre, explizit Netzwerkexperten in den Broadcastbereich zu integrieren, um von ihnen spezifisches Wissen zu erhalten. Im speziellen werden hier Kenntnisse über Netzwerktopologien und den generellen Aufbau eines Netzwerkes genannt, aber auch ganz grundlegende Fähigkeiten betreffend der

74 4 Experteninterviews

Denkweise wie diese Systeme überhaupt aufgebaut sind (Beuchert, 2020, Abs. 14, 2020, Abs. 24).

Für Furter (2020, Abs. 14) und seine Kollegen war das fehlende Knowhow aufgrund des sehr frühen Starts des Metechno Projekts naturgemäß ebenfalls anfangs eine Herausforderung. Die Implementierung hat zu einem Zeitpunkt begonnen, zu dem von ST 2110 auf den Branchenmessen noch nicht viel präsentiert wurde. Zu Beginn des Projektes waren es 3 Personen, die begonnen haben sich mit IP-Technologien vertraut zu machen. Durch den frühen Wissensaufbau und die Mitgliedschaft im Standardisierungsgremium konnten sie bald ein tieferes Verständnis für die Technologie entwickeln als die Hersteller selbst. Auch wenn dieser Prozess zu Beginn sehr intensiv und auch zeitaufwendig war, hat er sich im Nachhinein gelohnt. So bemerken Furter und sein Team jetzt die Ähnlichkeiten zu klassischem SDI und sehen darin keine undurchschaubare Wissenschaft mehr.

Kollinger (2020, Abs. 54) sieht im noch fehlenden Netzwerktechnikknowhow, im Gegensatz zu seinen Kollegen, kein allzu großes Problem. Nach seiner Erfahrung haben die meisten Broadcastkollegen derzeit schon ein gewisses Netzwerktechnikwissen. Außerdem kann man, nachdem der Standard noch sehr neu ist und sich am Markt etabliert, mit ihm mitwachsen.

Ein Bereich, in dem man nach Kollinger aber noch Wissen aufbauen muss, ist in der korrekten Auswertung von Monitoring- und Telemetriedaten. Diese Daten sind in der IP-Umgebung um einiges wichtiger, als in der konventionelle SDI- Umgebung. Die Systeme liefern eine Vielzahl von Daten, die korrekt ausgelesen werden müssen, um mögliche Fehler erkennen zu können. So kann es beispielsweise notwendig sein bis in die kleinste Detaileinstellung des PTP zu gehen, bei einem Fehlerfall, der im ersten Moment auf gar kein Problem mit dem Takt hindeutet. Kollinger streicht auch nochmal hervor, dass man eben zum einen ein sehr viel umfassenderes Monitoring, und zum anderen natürlich auch ein tieferes Verständnis dafür benötigt, um Fehlerfall richtig eingreifen zu können (Kollinger, 2020, Abs. 56–58).

Barth (2020, Abs. 27) und Furter (2020, Abs. 14) sehen jedoch auch eine personelle Herausforderung, nicht nur in den eigenen Unternehmen sondern auch bei den Herstellern und den Consultingfirmen selbst, die natürlich ebenfalls Experten mit einem gewissen Skillset benötigen, um die Geräte herstellen und richtig verplanen zu können.

75 4 Experteninterviews

4.2.6.5 Stand der Entwicklung Bei den Nachteilen von IP-Technologien wurde bereits auf dessen Etablierung und den derzeitigen Markt eingegangen. Bei den Herausforderungen kommt dieses Thematik wieder vor. So stellt aus Sicht von Kollinger (2020, Abs. 40) der vorhandene Herstellermarkt eine Problematik dar. Im Grunde bedienen sich alle Broadcastunternehmen an demselben Markt, der derzeit noch nicht alle Versprechen erfüllen kann, die von der Industrie angepriesen werden. Bis auf wenige Unternehmen, wie die BBC und Rai, die selbst ihre eigenen R&D (Research and Development) Abteilungen haben, sind jedoch alle an denselben Markt und dessen Entwicklungsstand gebunden. Er nennt auch als Beispiel die Tatsache, dass die vom JT-NM veröffentlichte Roadmap zur Entwicklung von ST 2110 nicht mit der tatsächlichen Entwicklung am Markt korreliert. Hier wird man immer wieder von den Herstellern vertröstet, gewisse Funktionen erst in Zukunft liefern zu können (Kollinger, 2020, Abs. 46).

Furter (2020, Abs. 18) spricht diesbezüglich von einem sehr intensiven Austausch mit den Entwicklungsabteilungen der jeweiligen Hersteller. So konnten sie fehlende Funktionalitäten mittels Firm- und Softwareupgrades während der Implementierung nachliefern. Es wurde auch darauf geachtet, bei nicht vorhandenen Standards diese, wenn möglich, mit einem offenen Standard zu lösen und Funktionen zu implementieren, die auch für andere Unternehmen nützlich sind. Furter merkt hier auch an, dass es natürlich auch auf die Skalierung des Projektes ankommt. So braucht man klarerweise für ein kleineres Projekt, wie eine Testumgebung, weniger Funktionen als für ein Projekt in dem man einen einzelnen Gerätetyp hunderte Male vollautomatisiert integrieren muss.

Als Beispiel für so eine Zusammenarbeit mit einem Hersteller nennt Furter (2020, Abs. 20) die Anforderung einen Audiosender dynamisch zur Laufzeit erstellen und konfigurieren zu können. Diese Funktionalität war zu Beginn des Projektes in den NMOS Standards nicht vorgesehen. Die Problematik die daraus entsteht, wurde den Herstellern vermittelt und daraufhin in den Standard aufgenommen. Generell haben sehr viele Lösungen, Produkte, Standards oder Überlegungen zu bestimmten Problematiken zu Beginn des Metechno Projekts noch gar nicht existiert (Furter, 2020, Abs. 22).

Furter (2020, Abs. 50) hebt auch noch einmal deutlich hervor, dass es vor allem in der Implementierung der NMOS Standards noch deutliche Lücken gibt. Die ersten Standards IS-04 und IS-05 sind zwar den meisten bekannt, die folgenden bereits veröffentlichten Standards IS-06 bis IS-09 sind jedoch noch in wenigen bis garkeinen Produkten integriert. Dies führt zu der Situation, dass man sich selbst eigene Softwarelösungen, wie speziell angepasste Treiber, entwickeln

76 4 Experteninterviews muss, um gewisse Funktionalitäten gewährleisten zu können. Es sollte jedoch das Ziel von gemeinsam genutzten offenen Standards sein, diese auch nutzen zu können. Ohne diese Standards wird zwar ST 2110 auch voll unterstützt, jedoch sind ohne die NMOS-Standards die Konfiguration und Steuerung der kompletten Systemlandschaft um einiges komplizierter und aufwendiger durchzuführen.

Auch Barth (2020, Abs. 26) und Beuchert (2020, Abs. 18) sprechen die oft noch nicht integrierten NMOS-Standards an und befürchten, dass sie sich nicht im Markt durchsetzen werden und fordern mehr Abstimmung der Hersteller in diesem Bereich. Auch wenn Beuchert feststellt, dass sich in den letzten Jahren einiges am Markt weiterentwickelt hat, merkt Barth die sich oft noch im Betastadium befindlichen Produkte und zu wenige alternative Produkte an.

4.2.6.6 Sicherheit Die letzte explizit genannte Herausforderung betrifft den Sicherheitsaspekt. Als Hersteller von Broadcastprodukten musste man sich bis jetzt nicht großartig um Sicherheitsthemen kümmern, da die meisten Systeme in sich abgeschlossenen Umgebungen operiert haben. Dieser Umstand ändert sich jetzt jedoch und die Hersteller müssen nun IT-Security viel früher in der Entwicklung ihrer Produkte miteinbeziehen. So gibt es nun beispielsweise die Anforderungen, dass jeder benutzte Netzwerkport automatisch Security-Funktionalitäten implementiert hat, oder dass eine Software auf einem normalem Server ohne spezielle Administratorenrechte und Firewalleinschränkungen funktionsfähig sein muss (Barth, 2020, Abs. 26; Furter, 2020, Abs. 22).

4.2.6.7 Generell Furter (Furter, 2020, Abs. 22) spricht aber auch den Fakt an, dass sie zwar zu Beginn ihres Projektes ein paar Herausforderungen und viele kleine Diskussionen zu bestimmten Problematiken hatten, diese jedoch alle mit der Zeit gelöst werden konnten. Sie sind mittlerweile nach mehreren Jahren an Erfahrung schon so weit in der Implementierung und Umsetzung fortgeschritten, dass sich über viele Herausforderungen auf die andere Unternehmen stoßen gar nicht mehr als Problem sehen, sondern eher schon einen Schritt weiter sind und über weitere Möglichkeiten von IP-Technologien nachdenken.

77 4 Experteninterviews

4.2.7 Möglichkeiten

4.2.7.1 Virtualisierung

Wenn man allgemein von IP-Technologien im Broadcastbereich spricht, wird häufig die bessere Möglichkeit der Virtualisierung genannt. Für Barth (2020, Abs. 20) wird dieses Thema jedoch noch überbewertet. Als Vorteil wird hier beispielsweise die flexible, unkomplizierte und schnelle Erweiterung von bereits existierenden Systemen, wie dem Playout, auch von Beuchert (2020, Abs. 12) erwähnt. Dies ist zwar technisch möglich, es hängen aber trotzdem noch andere Prozesse wie ein Beantragen von Sendelizenzen damit zusammen. Dementsprechend fallen hier die technischen Vorteile weniger stark ins Gewicht. Des Weiteren haben virtualisierte Systeme heute immer noch Nachteile gegenüber dedizierter Hardware. Als Beispiel wird hier die Möglichkeit genannt, unkomprimierte Videodaten in Echtzeit verarbeiten zu können.

4.2.7.2 Cloud Ein weiterer Punkt der genannt wird ist die Möglichkeit gewisse Prozesse oder Systeme in die Cloud auszulagern. An und für sich ist ST 2110 nicht dafür ausgelegt, es ist jedoch generell möglich unter gewissen Einschränkungen diversere Bereiche in die Cloud zu bringen (Kollinger, 2020, Abs. 26). So sprechen sowohl Barth (2020, Abs. 20) als auch Beuchert (2020, Abs. 12) hier den Bereich Playout an. Hier kommt für sie aber derzeit nur ein eingeschränktes Playout für den absoluten Notfall, ein sogenanntes Disasterplayout, in Frage.

4.2.7.3 Vereinheitlichung Eine letzte Möglichkeit nennt Barth (2020, Abs. 24) speziell bezogen auf ihre Sendeautomation. Hier ist es ein Ziel im Zuge von zukünftigen Umstellungen auf neue Technologien die unterschiedlichen Ausprägungen der Sendewege der derzeit 25 Sender aneinander anzugleichen. Im Zuge dessen ist der Plan sich in Zukunft mehr auf sogenannte Channel-in-a-Box Systeme zu konzentrieren, die den kompletten Sendeweg in einem System abbilden können. Derzeit sind etwa 4 verschiedene Ausführungen mit unterschiedlicher Komplexität vorhanden. Für eventuell zukünftige Sender wäre es von Vorteil, wenn es nur einen einzelnen vordefinierten Blueprint gibt den man beliebig vervielfältigen kann.

78 4 Experteninterviews

4.2.8 Erfahrungen

4.2.8.1 Interoperabilität

Angesprochen auf die Erfahrungen die die Interviewpartner bereits mit ST 2110 gemacht haben, wurde unter anderem die gut funktionierende Interoperabilität genannt. So funktionieren auf rein physikalischer Ebene, als Beispiel wird das einfache Übertragen, Routen und Decodieren von Signalen genannt, bereits eigentlich sämtliche Geräte die den Standard unterstützen ohne Probleme miteinander. Dieser Umstand ist unter anderem AIMS und ihren regelmäßigen Veranstaltungen, bei denen diverse Hersteller ihre Produkte auf Kompatibilität überprüfen, zu verdanken (Barth, 2020, Abs. 16).

Auch Furter (2020, Abs. 50) hat gute Erfahrungen mit der Interoperabilität von ST 2110 gemacht, führt jedoch noch einmal, die oft fehlenden offenen NMOS Standards an, die die Konfiguration und den Betrieb der Systeme um einiges vereinfachen.

Bezogen auf die Interoperabilität gibt es generell zwei Möglichkeiten die Situation anzugehen. Entweder man entscheidet sich wie Barth (2020, Abs. 20) für eine Best-of-Breed Lösung bei der man Geräte unterschiedlicher Hersteller in seine Infrastruktur einbindet und hat dementsprechend ein paar mehr Herausforderungen diese Geräte über Schnittstellen zu vernetzen. Oder man entscheidet sich für eine One-Stop-Shop Lösung bei der man sämtliche Geräte von einem großen Hersteller, wie Grass Valley oder Imagine, bezieht und sich dann jedoch mit eventuell für sich unpassenden Produkten abfinden muss, die gar nicht zu der Arbeitsweise des Unternehmens passen. Beide Varianten haben ihre Vor- und Nachteile.

4.2.8.2 Entwicklungsstatus Barth (2020, Abs. 16) hat die Erfahrung gemacht, dass viele Produkte, die sie testen noch nicht fertig entwickelt wurden. Dies ist aber auch dem Fakt geschuldet, dass sie mit verschiedenen Firmen Absprachen getroffen haben, ihre Produkte vor dem eigentlichen Verkaufsstart in ihrer eigenen Testumgebung einbinden und testen zu können. So können sie frühzeitig Feedback zu noch fehlenden oder fehlerhaften Funktionalitäten geben. Generell suchen sie sich immer aus einer Produktkategorie einzelne Geräte heraus um sie für ihre Anforderungen testen zu können.

Im Metechno Projekt hingegen wurde die Erfahrung gemacht, dass es für sämtliche Anforderungen mittlerweile IP-Lösungen gibt. Es sind zwar derzeit noch ein paar wenige Geräte, wie beispielsweise die Slowmotion Server mittels

79 4 Experteninterviews

SDI angebunden, diese sind mittlerweile aber alle IP-fähig (Furter, 2020, Abs. 38).

Generell funktionieren die meisten Geräte so wie sie sollen und laufen stabil sagt auch Kuntner (2019, Abs. 20). Manche Geräte benötigen noch etwas Feinarbeit in der Entwicklung, sind aber auf einem guten Weg. Hier kommen dann auch die unterschiedlichen Qualitäten des jeweiligen Herstellersupports zum Tragen.

4.2.8.3 Updates und Firmwares Auf die Updatehäufigkeit angesprochen erwähnt Kuntner (2019, Abs. 20) ebenfalls, dass es vor allem in der Fertigstellungsphase ihres IP-Ü-Wagens noch zu regelmäßigen Updates von einzelnen Komponenten gekommen ist. Hier konnte man sehr gut beobachten, dass es sich noch um Entwicklungsprojekte handelte. Die selbe Erfahrung deckt sich auch mit den ersten Anlagen die im ORF selbst installiert wurden. Je nachdem wie der Hersteller agiert kommt es hier bis zu wöchentlichen Updates. Das Intervall hängt unter anderem mit der Größe der Entwicklungsabteilung oder auch mit der Anzahl der Kunden zusammen. Wie weiter oben schon beschrieben werden jedoch sobald Geräte im Einsatz sind diese nur noch sehr selten, beispielsweise bei einem Sicherheitspatch, upgedatet.

4.2.8.4 Bedienung Ebenfalls weiter oben schon einmal erwähnt wurde die Bedienung der Geräte. Hier haben Kollinger (2020, Abs. 12) und seine Kollegen, die die Anlagen betreiben und warten, die Erfahrung gemacht, dass es grundsätzlich keinen Unterschied macht, ob man vor einem Bildmischer sitzt der mit SDI- oder IP- Technologie angesteuert wird. So konnten die Produktionen wie gewohnt fortgesetzt werden ohne große Auswirkung der Umstellung beobachten zu können.

4.2.8.5 NMOS Integration Die Erfahrung der fehlenden NMOS Unterstützung spricht erneut Barth (2020, Abs. 16) an. Die diversen Hersteller nutzen leider immer noch eher ihre eigenen proprietären Protokolle als auf offene Standards zu setzen. Aus diesem Grund funktioniert das Testlabor von Barth immer noch mittels IGMP mit dessen sich das Netz im Gegensatz zu einem SDN Controller von selbst regelt. Produkte, die die Funktion des SDN Controllers übernehmen, gibt es zwar am Markt, nur eben ohne NMOS Unterstützung. Barth befürchtet diesbezüglich, dass hier die Hersteller bewusst ihre eigenen Protokolle bevorzugen. Dies geschieht eventuell auch aus Markenschutzgründen, um ihre Position am Markt zu stärken.

80 4 Experteninterviews

4.2.9 Aktuelle Projekte

4.2.9.1 Bereits umgesetzte Projekte

Zu den bereits komplett umgesetzten Projekten in SMPTE ST 2110 des ORF zählt deren Ü-Wagen FÜ1 (Kuntner, 2019, Abs. 38).

Auch TPC hat bereits mit dem UHD-1 einen ST 2110 Ü-Wagen realisiert und auch schon etwas länger im Einsatz. Dieser hat einen komplett in ST 2110 aufgebauten Backbone und ist für bis zu 24 Kameras ausgelegt. Der UHD-1 war das erste ST 2110 Projekt des TPC welches auch aktiv für reguläre Produktionen eingesetzt wurde (Furter, 2020, Abs. 2). Aufgrund der sehr frühen Umsetzung des Ü-Wagens in ST 2110 sind in diesem etwa 80% der Geräte über Gateways angeschlossen (Furter, 2020, Abs. 34).

Im Metechno Projekt, welches sich derzeit in der ersten Phase der Inbetriebnahme der Bereiche Postproduktion, Sportproduktion und des Newsroom befindet, hat sich dieses Verhältnis umgedreht. Hier werden etwa 90% der Komponenten nativ mit IP angebunden (Furter, 2020, Abs. 34, 2020, Abs. 52). Zu den wenigen Ausnahmen die Gateways benötigen, sind unter anderem die Kamerasignale, welche noch mittels SDI angebunden werden, zu zählen. Auch kleinere Lösungen, wie ein einfacher Loopplayer, oder Geräte zur Aufzeichnung von Skype-Interviews, sind noch über Gateways angebunden, da es gerade solche Produkte für sehr spezielle Anwendungen eben noch nicht mit ST 2110 Unterstützung gibt (Furter, 2020, Abs. 36).

Um jedoch bereits bestehende Infrastruktur in der Übergangszeit von SDI auf IP anbinden zu können, sind natürlich ebenfalls eine große Anzahl an Gateways notwendig. Zu den Bereichen zählen die 14 Studios, der Hauptschaltraum und auch die nationale Kontribution die über 54 Gateways à 32 SDI-Ports an die neue ST 2110 Umgebung angebunden werden können (Furter, 2020, Abs. 36).

Im Neubau befinden sich rund 500 Sender und 1.000 Empfänger von Ancillarydaten, 750 Sender und 2.300 Empfänger von Videodaten sowie 13.000 Sender und 24.000 Empfänger von Audiodaten. Daraus resultieren etwa 500 Mbit/s an ANC-Datentraffic, 104 Gbit/s Audiotraffic und 5,1 Tbit/s Videotraffic wenn man im Format 1080i50 rechnet (Furter, 2019, 2020, Abs. 40).

4.2.9.2 In Umsetzung In Umsetzung befinden sich derzeit die reinen Testumgebungen von Barth (2020, Abs. 14) bei ProSieben und Kuntner (2019, Abs. 4) im ORF in denen sie und ihre

81 4 Experteninterviews

Teams ausgiebig die einzelnen Geräte, wie auch bereits weiter oben erwähnt, testen können.

4.2.9.3 In Planung Beim ORF befindet sich derzeit ein Großprojekt in Planung. In diesem ist es das Ziel, die Konzeption einer Systemarchitektur mittels eines IP-Realtime- Videonetzwerks für das gesamte ORF-Zentrum umzusetzen. Hierfür soll der dafür notwendige Backbone produktiv realisiert werden. Wie bei solchen Umstrukturierungsprojekten üblich, wird natürlich nicht die gesamte Infrastruktur auf einmal umgestellt. Das heißt, es werden Stück für Stück die einzelnen Teilbereiche von den Studios über die Regieplätze bis hin zur Postproduktionsanbindung auf die neue IP-Infrastruktur übersiedelt. Nichtsdestotrotz muss das Netzwerk einmal für alle Systeme konzipiert werden, um die gesamte Funktionalität sicherzustellen. Im Fall des ORF ist der erste Bereich welcher umgestellt wird das Sendezentrum (Kollinger, 2020, Abs. 4, 2020, Abs. 28).

Generell werden die Projekte des ORF, bei denen es sinnvoll ist, so ausgeschrieben, dass sie zumindest mit IP-Technologien umsetzbar sein sollen. Hier wird je nach Projekt entschieden, ob es für diesen oder jenen konkreten Teilbereich von Vorteil ist diesen in Richtung einer neuen Infrastruktur zu bringen (Kuntner, 2019, Abs. 38).

Bei ProSieben hat die Planungsphase für eine Infrastruktur auf einer ST 2110 Basis vor knapp 2 Jahren begonnen. Zu dem Zeitpunkt war klar, dass es in dem geplanten Neubau am Campus keine klassischen Geräteräume, sondern nur noch Datencenter geben würde, wodurch eine klassische SDI-Kupferverkabelung im größeren Stil nicht mehr möglich ist. Da das Neubauprojekt unter anderem auch den Produktions- und Postproduktionsbereich beinhaltet, wurde sich von vornherein auf ST 2110 geeinigt. Würde man nur einen Bereich wie das Playout auf IP-Technologien umstellen wollen, so wäre auch eine Umsetzung mittels ST 2022 denkbar gewesen (Barth, 2020, Abs. 4).

Des Weiteren konzentriert sich Barth (2020, Abs. 29) wie schon erwähnt gerade darauf einen Channel-in-a-Box Blueprint eines kompletten Sendeweges zu erstellen. Dieser soll die gesamten Funktionalitäten eines typischen Sendeweges abdecken, inklusive Echtzeitgrafiksystem, R128 Normalisierung und Dolby Encoding. Außerdem hat dieser Blueprint zum Ziel, sobald der Neubau realisiert wird, schon eine fertige Lastenheftvorlage zu haben mit der man das neue Playout umsetzen kann. Darüber hinaus gehören natürlich auch andere

82 4 Experteninterviews

Komponenten wie Messgeräte, Abhören und die Switches an sich dazu, die ebenfalls schon berücksichtigt werden.

Beuchert (2020, Abs. 22) plant derzeit für die ATV und Puls 4 Gruppe ebenfalls eine ST 2110 Testumgebung aufzubauen und merkt auch an, dass sie eigentlich relativ spät damit anfangen sich mit dem neuen Standard zu beschäftigen.

4.2.10 Umstiegs-Szenarien

4.2.10.1 Projektbezogen Die Experten wurden auch danach gefragt in welchen Situationen sie heute schon ST 2110 gegenüber anderen IP-Technologien oder SDI vorziehen würden. Hierbei gab es ganz unterschiedliche Ansätze. Einer der am häufigsten Genannten war, dass es stark auf das Projekt ankomme, welche Technologie besser geeignet sei.

Zum einen kommt es auf die Größe des Projekts an. Bei kleinen Projekten ist es meist teurer, wenn man heute auf IP-Technologien setzt, beispielsweise bei kleinen Ü-Wägen. Man kann jedoch auch ein kleines Projekt wie ein Radioregionalstudio kostengünstig mittels IP-Technologien umsetzen, wenn man keine großen Ansprüche an die Orchestration hat, oder es nicht in ein größeres Ökosystem integriert werden muss. Sobald jedoch mehr Anforderungen, wie unter anderem Cloudunterstützung oder Sicherheitsthemen hinzukommen, sind andere Technologien als ST 2110 hier empfehlenswerter (Furter, 2020, Abs. 8).

Auch Kuntner (2019, Abs. 24) und Barth (2020, Abs. 4) sehen es ähnlich. Für sie kommt es unter anderem auf das Budget und den Einsatzzweck an. Es macht auch einen Unterschied, ob man ein Projekt für sich selbst, einen Kunden oder auch nur eine einzelne Sendung umsetzt. Schlussendlich muss es für den jeweiligen Anwendungsfall sinnvoll sein (Kuntner, 2019, Abs. 38).

Wenn man ein größeres Unternehmen hat, welches auf eine neue Technologie umgestellt wird, ist es sogar relativ wahrscheinlich hier die Umstellung nach Projekten beziehungsweise nach Bereichen durchzuführen. Als Beispiel nennt Barth (2020, Abs. 18) ihre Pay-TV Sender, bei denen sie derzeit ein Channel-in- a-Box System einsetzen. Wenn es hier eine gute Lösung gibt, kann man diesen Teilbereich bereits auf IP-Technologien umstellen, auch wenn man davor und danach wieder auf SDI wandeln muss. Ähnliches gilt auch für den Produktionsbereich in dem es an einem gewissen Punkt zu Neuanschaffungen kommen kann und dann nur dieser Teilbereich umgestellt wird. So kann man bereits in kleinen abgeschotteten Systemen Erfahrungen sammeln.

83 4 Experteninterviews

Beuchert (2020, Abs. 12) hat beobachtet, dass IP-Technologien vor allem in der Remoteproduction schon häufiger eingesetzt werden. Diese sind zwar noch mit Gateways auf der Eingangsseite ausgestattet, was aber auch dem Fakt geschuldet ist, dass die meisten externen Anlagen mit denen sich ein Ü-Wagen verbindet noch mittels SDI angeschlossen werden müssen.

4.2.10.2 Größe des Unternehmens Laut Barth (2020, Abs. 10) macht es für kleinere Unternehmen noch durchaus Sinn bei SDI zu bleiben, da dies eine bekannte und stabile Technologie ist bei der es eine große Produktauswahl und viel Knowhow gibt. Da es eine relativ große Umstellung der grundlegenden Technologie ist bei der viele Aspekte komplett anders funktionieren, kann es hier bei kleinen Unternehmen zu größeren Herausforderungen kommen.

Auch Kuntner (2019, Abs. 24) sieht für kleine Produktionsfirmen den Vorteil noch bei anderen Technologien, wie beispielsweise NDI. Bei dieser ist der Konfigurationsaufwand geringer und es funktioniert schneller sowie günstiger. Es kommt diesbezüglich auch immer auf die Ansprüche an das System an welches man einsetzen möchte.

4.2.10.3 Ähnliche Technologien Generell sieht Kuntner (2019, Abs. 26) auch weiterhin Technologien wie NDI durchaus als nützlich in gewissen Situation an. Aus seiner Sicht gibt es keinen Grund warum beispielsweise NDI als alternative IP-Technologie in den nächsten Jahren weniger gefragt sein sollte. NDI hat, wie eben erwähnt, vor allem für kleinere Unternehmen und Projekte Vorteile und seine Daseinsberechtigung.

Aus seiner Sicht wird es auch in den nächsten Jahren noch viele 12G-SDI oder auch nur einfache SDI-Lösungen geben. Auch hybride Ansätze sind denkbar (Kuntner, 2019, Abs. 30–32).

4.2.10.4 Management Ein weiterer Fakt der einen Umstieg beeinflussen kann, ist das jeweilige Management der Unternehmen. So ist beispielsweise ProSieben bei verschiedenen Bereichen sehr stark in Bewegung was Entscheidungen angeht. Zum einen kann es sein, dass sobald der neue Campus fertig ist, das Management zu diesem Zeitpunkt entscheidet, auf die neueste Technologie umzusteigen. Zum anderen kann es aber auch sein, dass das Management mit der derzeitigen technischen Infrastruktur zufrieden ist und hier noch weiter auf eine bewährte Technologie setzt. Es spielt also auch eine gewisse Rolle wie

84 4 Experteninterviews risikobereit oder aufgeschlossen das jeweilige Management gegenüber neuen Technologien ist (Barth, 2020, Abs. 18).

Furter (2020, Abs. 14) kann diesen Fakt bestätigen. In ihrem Fall hat das Team von Anfang sehr große Unterstützung des CTO erhalten. Dieser hat auch den initialen Anstoß gegeben das Projekt mittels einer IP-Technologie umzusetzen. Bis heute erfahren sie generelle starke Unterstützung aus Richtung des Management.

4.2.10.5 Bedarf Ein weiterer Punkt, der unter anderem von Kollinger (2020, Abs. 30) genannt wurde, ist die Frage nach dem Bedarf dieses neuen Standards. Man sollte sich im Vorherein überlegen wie man in Zukunft arbeiten möchte und dementsprechend Betriebskonzepte entwickeln. Darunter fallen dann auch Überlegungen zum Personalmodell und welchen Einfluss der Umstieg auf das Betriebsmodell hat. Im Endeffekt wird die Einführung von ST 2110 laut Kollinger nur wenig Auswirkungen haben, sondern nur die Umstellung an sich.

Im Grunde muss man sich die Frage stellen, aus welchem Grund man derzeit auf eine neue Technologie wechseln möchte. Wenn es nur darum geht seine eigentlich voll funktionsfähige bestehende SDI-Infrastruktur mit einer neuen IP- Infrastruktur zu ersetzen, ist es der falsche Weg. Der reine Technologiewechsel hat wie erwähnt im Endeffekt keinen Einfluss auf die Art wie täglich gearbeitet wird und dementsprechend auch keinen Mehrwert für das Unternehmen (Kollinger, 2020, Abs. 38, 2020, Abs. 60).

Auch Furter (2020, Abs. 30) erwähnt, dass man zuerst einen gewissen Mehrwert in einer Technologie sehen muss um sich für sie entscheiden zu können.

Man kann auch den Fehler machen auf eine IP-Umgebung zu wechseln, von dieser aber nicht die dafür notwendige geänderte Denkweise zu übernehmen. So sollte man auch laut Barth (2020, Abs. 26) immer vorher überlegen, welches Ziel man erreichen will und wie man dorthin kommen kann. Das kann auch bedeuten seine Workflows anzupassen, wenn sie mittels der neuen Technologie leichter oder schneller durchzuführen sind. Also wenn man schon auf eine IP- Infrastruktur umsteigt, sollte man auch die Vorteile dieser nutzen.

85 4 Experteninterviews

4.2.11 Zukunftsaussichten

4.2.11.1 Maßnahmen

Darauf angesprochen wie man den Technologiewechsel einfacher gestalten kann, ist eine Empfehlung von Furter (2020, Abs. 24) sich ein Testlabor aufzubauen. Dadurch bekommen die Broadcastmitarbeiter, welche noch keine praktische Erfahrung mit Netzwerktechnik haben, Knowhow und lernen mit der IP-Technik umzugehen.

Seine zweite Empfehlung ist das Netzwerk nicht ohne Orchestrierungslösung aufzubauen. Ohne diese hat man keine ausreichende Kontrolle über das Netzwerk und die Sicherheitsaspekte. Der Ü-Wagen UHD1 wurde ohne große Orchestrierung umgesetzt, wodurch sie eine schlechte Erfahrung gemacht haben. Bei den diversen Lösungen gibt es laut Furter auch viele Versprechen die das Marketing gibt, dann aber in der Realität nicht zufriedenstellend funktionieren (Furter, 2020, Abs. 24).

Beuchert (2020, Abs. 18) findet kurze mehrtägige Workshops hilfreich bei denen man praktische Erfahrung sammeln kann und sich mit Herstellern, Systemhäusern aber vor allem auch anderen Kunden austauschen kann. Er findet es ebenfalls, wie auch seine Kollegen, wichtig sich eine Testumgebung aufzubauen in der man eine Produktionskette nachstellen und zum Beispiel auch die ersten Messgeräte testen kann, so dass die Mitarbeiter nicht erst beim tatsächlichen Umstieg zum ersten Mal mit der neuen Technologie konfrontiert werden (Beuchert, 2020, Abs. 22).

Auch die Empfehlung von Barth (2020, Abs. 14) ist ähnlich. Wie bereits weiter oben erwähnt, empfiehlt er sich einen Teilbereich auszuwählen in dem man neue IP-Technik verbaut und dann damit Erfahrungen sammelt. So kann man in kleinen Umgebungen Fehler machen und aus diesen lernen.

4.2.11.2 Situation in DACH Unternehmen Der ORF war das erste Broadcastunternehmen in Österreich welches ein ST 2110 Projekt umgesetzt hat und wird auch in den nächsten Jahren sukzessive Anlagen, die erneuert oder erweitert werden müssen, nach Sinnhaftigkeit in IP- Technologien umsetzen (Kuntner, 2019, Abs. 30–32).

Barth (2020, Abs. 10) möchte bei ProSieben, sollte sich die Industrie noch ein bisschen weiterentwickeln, in den nächsten 1 bis 2 Jahren keine SDI- Technologie mehr verbauen.

86 4 Experteninterviews

Bei ATV und Puls 4 sind derzeit noch alle Systeme mittels SDI angebunden, auch wenn viele davon schon IP-tauglich sind. In den nächsten Jahren fallen jedoch größere Neuanschaffungen der Kernsysteme an bei denen eine Entscheidung für ST 2110 getroffen werden kann. Aus Sicht von Beuchert werden die größeren Broadcastunternehmen in den nächsten 5 Jahre die Vorreiter auf dem Gebiet sein. Die kleineren Unternehmen wie sie selbst werden zu dem Zeitpunkt vereinzelte Bereiche umgestellt haben und die restlichen daraufhin nachziehen (Beuchert, 2020, Abs. 20).

Beim TPC stellt sich gar nicht mehr die Frage, ob SDI- oder IP-Technologie verwendet werden soll. Bei neuen Projekten wird nur noch entschieden welches ST 2110 Produkt denn nun hierfür besser geeignet ist. Hier sind Furter und seine Kollegen anderen Unternehmen schon voraus. Die Schweiz hat hier auch den Vorteil, dass sie nicht an EU-konforme Ausschreibungen gebunden ist, die viele Prozesse verlangsamen und verkomplizieren (2020, Abs. 26, 2020, Abs. 30–32).

4.2.11.3 Europaweit Furter (2020, Abs. 26) sieht generell die meisten europäischen Unternehmen als nicht mutig genug an. Aus seiner Sicht benötigen die Unternehmen ausreichend Unterstützung, auch vom jeweiligen Management, welches auch hinter der Entscheidung steht auf neue IP-Technologien zu wechseln. Des Weiteren sind auch die Ausschreibungen, welche in der EU an strengere Regeln gebunden sind als in der Schweiz, ein Hindernis. So sind schnelle und kurzfristige Änderungen von bereits verplanten Projekten kaum möglich. Ein durchschnittliches größeres Projekt in der Broadcastumgebung dauert etwa 2 bis 3 Jahre. Wenn nun eine Ausschreibung gemacht wird, können viele Monate vergehen bis die Systeme wirklich angeschafft werden. Besonders in der IT- Umgebung, welche sich sehr schnell verändert und in der häufig neue Produkte auf den Markt gebracht werden, ist dieser Zeitraum, von der Ausschreibung bis zur Beschaffung der Geräte, sehr lange. Furter spricht auch an, dass amerikanische Unternehmen im Vergleich zu solchen in der EU finanziell wesentlich freier sind und hier mehr Spielraum haben.

Kuntner (2019, Abs. 32) beobachtet in Europa einen Anstieg der Projekte, welche mit IP-Technologien umgesetzt werden und denkt dass die Umstellung momentan auf einem guten Weg ist.

4.2.11.4 Generell Generell würde Kollinger (2020, Abs. 26) einen Technologiewechsel in dieser Größenordnung niemals bedenkenlos anstreben. Er ist sich jedoch bewusst,

87 4 Experteninterviews dass sich die Industrie darüber einig ist, dass es der richtige Schritt ist von SDI- auf IP-Technologie zu wechseln. Es sind sich jedoch nicht alle darüber einig, ob ST 2110, so wie er derzeit definiert ist, die perfekte Lösung ist. IP-Umgebunden sind bereits und werden auch in Zukunft sich entwickelnde Systeme sein. Der Standard ist zwar grundsätzlich fertig geschrieben und funktioniert bewiesenermaßen auch, die nächsten geplanten Erweiterungen sind jedoch vielversprechender.

Kollinger (2020, Abs. 48) beobachtet auch eine Ähnlichkeit der Investitionszyklen von großen Rundfunkunternehmen. Das heißt, größere Anschaffungen werden in einem ähnlichen Zeithorizont immer wieder getätigt. Dadurch vollziehen gerade jetzt viele Unternehmen gerade den Technologiewechsel oder streben ihn zumindest an.

Generell benötigt man auch eine gewisse IT-Affinität um diesen Technologiewechsel durchführen zu können. Hier kann es zu Problemen kommen, wenn das Durchschnittsalter des Projektteams zu hoch ist oder Netzwerkarchitekturvorgaben nicht zeitgemäß sind. Bei diesem Wechsel muss es auch zu einem Mentalitätswandel und einem Ändern der Denkweise von Mitarbeitern kommen. Es gibt mittlerweile Lösungen für sämtliche Herausforderungen, man muss nur bereit sein diese auch anzunehmen und unbekannte Technologien nicht automatisch kritischer betrachten (Furter, 2020, Abs. 26, 2020, Abs. 30).

SDI- und IP-Technologien werden die nächsten Jahre noch koexistieren. Es wird auch weiterhin SDI-Anlagen geben, die auch in SDI erneuert werden. Vor kurzem wurde auch wieder ein 12G-Ü-Wagen für eine Privatfirma gebaut. Diese können auch etwas flexibler wirtschaften als öffentliche Anstalten und können so in ein paar Jahren diesen wieder abschreiben und einen neuen Ü-Wagen mit dann ausgereifterer Technik bauen lassen. Generell muss man darauf schauen welche Anforderungen und welches Budget man für ein Projekt hat sowie in welchem Zeitraum dieses fertiggestellt werden muss. Des Weiteren darf man das Knowhow der Mitarbeiter und den Personalstand nicht unberücksichtigt lassen. Daraufhin trifft man die Entscheidung für das jeweils dafür richtige System (Kuntner, 2019, Abs. 30–32).

88 5 Beantwortung der Forschungsfragen

5 Beantwortung der Forschungsfragen

5.1 Welche nennenswerten technischen und wirtschaftlichen Vor- bzw. Nachteile bietet eine Umstellung von SDI- auf IP- Technologien?

Im Laufe der Recherche haben sich einige vermeintliche Vorteile von IP- Technologien gegenüber der klassischen SDI-Technologie angesammelt die größtenteils von den interviewten Experten bestätigt werden konnten. Aufgrund der Tatsache, dass in Präsentationen auf Fachmessen und in diversen online verfügbaren Informationen von SMPTE ST 2110 naturgemäß meist nur positive Fakten präsentiert werden, spiegeln diese nicht unbedingt den realen Einsatz in der Praxis wider. In der Auswertung der Interviews wurde bereits ausführlich auf die Unterschiede, Herausforderungen und Möglichkeiten eingegangen. Zusammengefasst haben sich die folgenden wichtigsten Vor- bzw. Nachteile von IP-Technologien, im Speziellen von SMPTE ST 2110, herausgestellt.

5.1.1 Vorteile gegenüber SDI

5.1.1.1 Einsparungen in der Infrastruktur

Einer der ersten Vorteile ist die Einsparung des physisch notwendigen Platzbedarfs. Zum einen sind die Geräte und Systeme an sich kleiner als gleichartige Geräte mit SDI-Technologie. Dadurch gewinnt man in den jeweiligen Geräteräumen der Sendeanstalten und Ü-Wägen viel Platz den man entweder anderweitig nutzen kann oder die Räume in Zukunft von Haus aus kompakter planen kann. Dies führt beispielsweise wieder zu einer Reduzierung der notwendigen Kühlleistung und dementsprechend hier zu einer möglichen Kostensenkung. Auch der Verkabelungsaufwand reduziert sich, da über eine einzelne Leitung jeweils mehrere Signale übertragen werden können. So reicht es zukünftig etwa eine CCU nur noch mit jeweils einer ST 2110 Main und Backup

89 5 Beantwortung der Forschungsfragen

Leitung an seine vorhandenen Infrastruktur anzubinden. Dies spart Zeit beim Wechseln einer CCU, reduziert die Fehleranfälligkeit und ebenso den Materialaufwand der Kabel und Stecker. Diese Einsparungen summieren sich schlussendlich zu einem Kostenvorteil.

5.1.1.2 Mehr Flexibilität Ein weiterer Vorteil ist die gewonnene Flexibilität in der Erweiterbarkeit der Infrastruktur. So ist es ab einer gewissen Größe der vorhandenen Infrastruktur mit geringerem Zeit- und Kostenaufwand möglich seinen IP-Backbone zu erweitern, als es mit einer klassischen SDI-Kreuzschiene der Fall ist. Auch die Anbindung eines neuen Standorts innerhalb eines Unternehmen ist durch vergleichsweise geringen Aufwand möglich. Im Idealfall reicht es aus, eine geringe Anzahl an Glasfaserleitungen zu legen sowie einen Switch am neuen Standort zu installieren um dort auf die komplette Produktionsinfrastruktur zugreifen zu können.

Auch der Vorteil in der technischen Flexibilität, bezogen auf die unabhängige Übertragung der einzelnen Medienstreams, ist nicht außer Acht zu lassen. Durch diese ist es möglich, ausschließlich die Signale zu übertragen, die auch tatsächlich benötigt werden.

5.1.1.3 Formatagnostik Ein sehr wichtiger technischer Vorteil ist die sogenannte Formatagnostik von ST 2110 die es möglich macht unterschiedlichste Formate in der selben Produktionsumgebung zu verarbeiten. So ist man zum einen nicht ausschließlich an das eigene „Hausformat“ gebunden und zum anderen ist man heute schon, ohne großartige Änderungen der Systeme vorzunehmen, in der Lage ein besseres Sendeformat wie UHD oder HDR zu verarbeiten. Ebenso ist die Verarbeitung von bis heute untypischen Sendeformaten mit Seitenverhältnissen von 9:16 oder 1:1 für neue Distributionswege problemlos möglich.

5.1.1.4 Zukunftssicherheit Ein weiterer Vorteil ist die Sicherheit, in Zukunft auf dem neuesten Stand der Technik zu sein. Derzeit konzentrieren sich die meisten Hersteller von Broadcastequipment vermehrt auf die Integration der 2110-Standards und NMOS. Es ist zwar durchaus noch ohne weiteres möglich SDI-Equipment zu kaufen und einzusetzen, man muss sich jedoch bewusst sein, dass in diese Geräte eventuell nicht mehr der Großteil der Entwicklungsarbeit fließt. Mit dem Einsatz von IP-Technologien ist es zukünftig auch einfacher und kostengünstiger möglich sich auf neue Anforderungen einzustellen.

90 5 Beantwortung der Forschungsfragen

5.1.2 Nachteile gegenüber SDI

5.1.2.1 Komplexität

Da die IP-Standards und Technologien für die meisten Broadcastmitarbeiter noch relativ neu sind, wird die vergleichsweise hohe Komplexität dieser als Nachteil angesehen. Dies trifft aber oft nur Anfangs zu, da mit steigender Nutzungsdauer und praktischer Erfahrung Lerneffekte hinzukommen und so immer intuitiver mit der neuen Technik umgegangen werden kann. Nichtsdestotrotz bleibt es ein technisch komplexer Standard.

Die Komplexität spiegelt sich auch in der Verwaltung der unter anderem in sehr großer Anzahl vorkommender Multicastadressen wider. Hier ohne Unterstützung einer Orchestrierungslösung oder der NMOS APIs den Überblick über die Konfiguration zu behalten, ist sehr schwierig. Auch dieser Nachteil sollte sich mit fortlaufender Implementierung von standarisierten offenen APIs mit der Zeit auflösen.

5.1.2.2 Etablierung und Verfügbarkeit am Markt Aufgrund der Aktualität der neuen Standards ist derzeit noch keine so große Produktvielfalt am Markt verfügbar wie man es von SDI-Geräten gewohnt ist. Da die SDI-Standards in den letzten Jahrzehnten den Markt beherrscht haben, sind Geräte hier natürlich in sämtlichen Varianten und Preisklassen verfügbar. Diese geringere Auswahl an Produkten mit IP-Unterstützung kann auch zu einer Herausforderung werden, da man sich eventuell für ein Produkt entscheiden muss, welches die Anforderungen nicht oder nur unzureichend erfüllt. Generell befinden sich einige Geräte noch im Entwicklungszustand und liefern nicht die von den Herstellern versprochenen Funktionalitäten.

5.1.2.3 Derzeit noch fehlendes Knowhow Ein Nachteil, der von sämtlichen Interviewpartnern entweder als solcher oder als Herausforderung angesprochen wurde, ist das derzeit noch großteils fehlende Knowhow der eigenen Mitarbeiter. Dieses muss meist erst erarbeitet werden, was Zeit und dadurch Geld kostet. Einer der Wege, wie dieser Nachteil aufgearbeitet werden kann, ist die Errichtung eines Testlabors, in dem die Mitarbeiter, ohne Auswirkung auf die tatsächliche Produktionsumgebung, Erfahrungen sammeln können. Im Folgenden kann man dann damit beginnen einzelne Bereiche der Infrastruktur umzustellen um in abgetrennten Teilbereichen praxisrelevantere Erkenntnisse zu erlangen.

91 5 Beantwortung der Forschungsfragen 5.2 Auf welchem Stand der Entwicklung befindet sich die Implementierung der IP- Standards derzeit im deutschsprachigen Raum?

Im Zuge dieser Arbeit wurden leitende Personen in broadcasttechnischen Positionen von Sendeanstalten aus Deutschland, Österreich und der Schweiz nach der aktuellen Lage, bezogen auf die Implementierung von IP-Standards speziell in ihren Unternehmen, und auch nach der generellen Lage außerhalb davon befragt.

5.2.1 Deutschland – ProSiebenSat1 Bei ProSiebenSat1 ist derzeit eine Testumgebung in Betrieb in der Barth und seine Kollegen diverse Geräte testen und Erfahrungen sammeln können. Hierzu haben sie Abkommen mit Herstellern getroffen um bereits vor Markteinführung Testgeräte zu erhalten und diese in ihrer eigenen Umgebung auf ihre gewünschten Funktionalitäten zu überprüfen. So können sie den Herstellern frühzeitig Feedback geben und die Wahrscheinlichkeit bei Markteinführung ein ausgereiftes Produkt zu haben steigt.

Des Weiteren hat vor rund 2 Jahren (2018) die Planungsphase für eine ST 2110 Infrastruktur begonnen. Dies geschah zu einem Zeitpunkt, als klar war, dass der geplante Neubau am Campus keine klassischen Geräteräume mehr haben wird, sondern ausschließlich Datencenter. Da der Neubau mehrere technische Bereiche, wie unter anderem einen Produktions- und Postproduktionsbereich beinhalten wird, wurde sich schon sehr früh auf ST 2110 geeinigt. Müsste nur ein in sich abgeschlossener Bereich, wie beispielsweise das Playout auf IP- Technologie umgestellt werden, wäre auch eine Umsetzung in ST 2022 denkbar gewesen.

Im Speziellen konzentriert sich Barth im Moment auf die Erstellung eines Channel-in-a-Box Blueprints welcher sämtliche Funktionalitäten eines Sendeweges in sich vereint. Dies hat zum Ziel, das Playout zu Vereinheitlichen und die Integration neuer Sender beziehungsweise die Umstellung der bestehenden Sender auf IP-Technologien zu vereinfachen. Außerdem ist es, sobald der Neubau umgesetzt wird, möglich diesen Blueprint auf alle Sender anzuwenden und so diesen Prozess zu vereinfachen.

92 5 Beantwortung der Forschungsfragen

Sollte sich die Industrie noch ein bisschen weiterentwickeln, möchte Barth bei ProSiebenSat1 in den nächsten 1 bis 2 Jahren keine SDI-Technologie mehr verbauen.

5.2.2 Österreich – ORF Zu den bereits umgesetzten Projekten mit ST 2110 Integration des ORF zählt deren Ü-Wagen FÜ1. Dieser ist seit Dezember 2019 erfolgreich im Einsatz. Des Weiteren hat der ORF ebenfalls eine Testumgebung in der sie die Geräte testen und Erfahrungen sammeln können.

In Planung befindet sich derzeit ein Großprojekt. Dieses umfasst die Konzeption einer IP-Systemarchitektur und deren anschließender produktiver Umsetzung. Hierzu wird zu Beginn das Netzwerk für die gesamte Infrastruktur und alle Systeme konzipiert. Nach Beendigung der Konzeptionsphase werden einzelne Teilbereiche nacheinander umgestellt. Der erste Bereich, welcher umgestellt werden wird, ist das Sendezentrum.

Unabhängig von diesem Großprojekt werden alle Projekte bei denen es sinnvoll ist grundsätzlich auch so ausgeschrieben, dass eine Umsetzung mittels IP- Technologien möglich sein soll. Je nach Teilbereich wird dann im Detail entschieden, ob dieser sich in Richtung einer neuen Infrastruktur entwickeln soll.

5.2.3 Österreich – Puls4/ATV Puls4/ATV hat derzeit noch kein Projekt mit ST 2110 umgesetzt oder in Planung auch wenn sie bereits einige Geräte im Einsatz haben die den Standard unterstützen würden. Noch für das Jahr 2020 ist jedoch ebenfalls eine kleine Testumgebung geplant in der Knowhow erlangt werden kann.

Des Weiteren fallen in den nächsten Jahren größere Neuanschaffungen von Kernsystemen an bei denen es zu einer Umsetzung mit IP-Technologien kommen kann.

5.2.4 Schweiz – TPC (SRF) TPC hat mit dem UHD-1 schon vor dem ORF einen IP-Ü-Wagen in Betrieb genommen. Dieser war das erste ST 2110 Projekt welches das Schweizer Unternehmen durchgeführt hat. Aufgrund der damals noch nicht weit verbreiteten IP-Technik befinden sich in dem Ü-Wagen noch eine Vielzahl an Gateways in die SDI-Welt.

93 5 Beantwortung der Forschungsfragen

Das aktuelle Metechno Projekt, ein Neubau in dem mehrere Bereiche zusammengefasst werden, ist das derzeit größte Projekt des TPC. Dieses befindet sich derzeit in der ersten Phase der Inbetriebnahme der Bereiche Postproduktion, Sportproduktion und des Newsroom. In diesem Projekt wird nur noch eine sehr geringe Zahl an Gateways eingesetzt, da es die meisten Produkte bereits mit ST 2110 Unterstützung gibt. Ausnahmen die noch über SDI-Gateways eingebunden sind, sind speziellere Produkte für sehr spezifische Aufgaben oder auch die Kameras. Die bereits existierende Infrastruktur, wie die Studios und der Hauptschaltraum werden ebenso über Gateways eingebunden.

Zukünftige Projekte werden nicht mehr mit SDI-Technologie umgesetzt. Somit ist das TPC in dieser Hinsicht den Kollegen aus Deutschland und Österreich voraus.

5.3 Inwieweit besteht derzeit aus technischer und wirtschaftlicher Sicht die Veranlassung von SDI- auf IP- Technologien umzusteigen?

Diese Frage ist nicht allgemein zu Beantworten. Hier kommt es auf verschiedene Faktoren an.

Zum ersten kommt es auf das Projekt an, welches man umsetzen möchte. So kann es durchaus unterschiedliche Anforderungen an beispielsweise einen Ü- Wagen geben, der dementsprechend entweder mit SDI- oder IP-Technologie gebaut werden kann. Neben der Anforderung hat auch das Budget, welches für ein Projekt zur Verfügung steht, klarerweise Einfluss auf die Entscheidung.

Des Weiteren spielt die Größe des Unternehmens eine Rolle. Für kleinere Unternehmen macht es durchaus noch Sinn bei SDI-Technologie zu bleiben, da der Umstieg derzeit noch relativ aufwendig ist und es hierbei zu wenig Kapazitäten zu größeren Herausforderungen kommen kann. Eine weniger komplexe und günstigere Alternative zu ST 2110 wäre in diesem Fall zum Beispiel NDI.

Der wichtigste Faktor welcher beachtet werden muss, ist die Frage, ob man einen Bedarf für den neuen Standard hat. ST 2110 liefert zwar Vorteile gegenüber SDI, wenn man daraus jedoch keinen Nutzen ziehen kann, sind diese hinfällig. Man sollte sich also überlegen wie man in Zukunft arbeiten möchte und ob man durch die Umstellung auf ST 2110 und dessen anderer Funktionsweise Workflows und Arbeitsweisen anpassen kann und will.

94 6 Fazit

6 Fazit

Diese Arbeit sollte einen Überblick über die derzeit spezifizierten SMPTE ST 2110 Standards und die Rahmenbedingungen in denen diese implementiert werden können geben. Weiters war es Ziel, den derzeitigen Stand der Implementierung bei Broadcastunternehmen im deutschsprachigen Raum festzustellen.

Die Vor- und Nachteile gegenüber klassischer SDI-Technologie und daraus resultierende Möglichkeiten und Herausforderungen wurden von den Experten vielfach angesprochen. Die größten Vorteile sind die Einsparungen in der Infrastruktur, die gewonnene Flexibilität in der Nutzung und Erweiterbarkeit eben jener, die Formatagnostik und schlussendlich die Gewissheit in eine Technologie zu investieren, die sich in den nächsten Jahren weiter etablieren und entwickeln wird. Gravierende technische oder wirtschaftliche Nachteile von ST 2110 existieren derzeit im Prinzip nicht mehr. Zusammengefasst wurde das noch fehlende Knowhow über die neuen Funktionsprinzipe und der derzeit noch relativ dürftig ausgestattete Herstellermarkt als Herausforderungen angemerkt.

Den derzeitigen Stand der Implementierung von ST 2110 im deutschsprachigen Raum kann man als im Anfangsstadium bezeichnen. Es gibt bereits Ü-Wägen welche auf den IP-Standard aufbauen und auch schon im Einsatz sind. Bereits umgesetzte Großprojekte wie Metechno in der Schweiz sind im Moment noch Einzelfälle. In diesem Bereich befinden sich die Unternehmen in Österreich und Deutschland derzeit in der Planungs- und Testphase.

Generell kann man zusammenfassen, dass aus technischer oder wirtschaftlicher Sicht nichts einer Implementierung von ST 2110 im Wege steht solange die daraus resultierenden Vorteile und Möglichkeiten die Arbeitsweise im Unternehmen unterstützen. Bei einem Umstieg auf eine neue Technologie in dieser Größenordnung, muss sich auch die Denkweise der damit arbeiteten Mitarbeiter ändern, um das volle Potenzial dieses Standards ausschöpfen zu können.

95 6 Fazit 6.1 Ausblick auf weitere Forschung

Die Recherche und die Auswertungen der Experteninterviews haben gezeigt, dass SMPTE ST 2110 grundsätzlich funktioniert und erfolgreich eingesetzt werden kann. Das heißt der Standard an sich hält ein was er verspricht und ist in realen Anwendungen im Einsatz. Für die zukünftige Entwicklung der Implementierung ist es jedoch nicht nur wichtig die Übertragung der Signale sicherzustellen welche in ST 2110 spezifiziert ist. Aus heutiger Sicht wichtiger, ist die Entwicklung der NMOS APIs und deren Implementierung in die Produkte der Hersteller. Erst mit diesen ist ein effizientes und angenehmes Arbeiten möglich. Zukünftige Forschungen könnten sich auf die Weiterentwicklung dieser APIs und deren Einsatzgebiete fokussieren.

96

Literaturverzeichnis

AIMS. (2017). AIMS Guidelines to Preparing Broadcast Facilities for IP-based Live TV Production. https://www.live-production.tv/sites/default/files/aims-guidelines-to- preparing-broadcast-facilities-for-ip-based-white-paper.pdf

AIMS. (2018). Essential Considerations for Live Content Production and Broadcast. https://www.aimsalliance.org/wp-content/uploads/2018/04/AIMS-Updated-Guidelines- for-IP-0402108.pdf

AIMS. (2019a). Overview. AIMS Alliance. https://aimsalliance.org/overview/

AIMS. (2019b). AES67 / SMPTE ST 2110 Commonalities and Constraints. https://aimsalliance.org/wp-content/uploads/2019/04/AES67-SMPTE-ST-2110- Commonalities-and-Constraints-Updated-April-2019.pdf

AMWA. (2018). AMWA NMOS Network Control Specification (IS-06) Project Scope. http://gilmer.tv/downloads/reference_documents/AMWA%20NMOS%20Project%20Sco pe%20IS-06.pdf

AMWA. (2019). About. About the AMWA. https://www.amwa.tv/about

AMWA. (2020a, Februar 17). Networked Media Open Specifications: Introduction. Nmos. http://amwa-tv.github.io/nmos/

AMWA. (2020b, März 18). AMWA NMOS Device Audio Channel Mapping Specification: Overview. Nmos-Audio-Channel-Mapping. https://amwa- tv.github.io/nmos-audio-channel-mapping/branches/v1.0.x/docs/1.0._Overview.html

AMWA. (2020c, Juli 16). AMWA IS-09 NMOS System Parameters Specification. Nmos- System. https://amwa-tv.github.io/nmos-system/

Anslow, P., & Xenos, H. (2018, Januar 29). Standards Update: 200GbE, 400GbE and Beyond with Pete Anslow – “Live” from Geneva - Ciena. http://www.ciena.com/insights/articles/Standards-Update-200GbE-400GbE-and-Beyond- with-Pete-Anslow--Live-from-Geneva.html

Barella, S. (2017a). The IP Baseband Migration: A Hybrid Approach for SDI Facilities. 12.

Barella, S. (2017b). The Pillars of the New SMPTE 2110 Standard. 5.

Barella, S. (2017c). Unbundling Ethernet for Studio Video Over IP. 9.

Barella, S. (2016). Practical Transition Strategies of SDI Facilities Utilizing Newer IP

97

Baseband A/V Signals. 1–10. https://doi.org/10.5594/M001714

Barth, M. (2020, März 11). Interview.

Beuchert, P. (2020, April 14). Interview.

Bogner, A., Littig, B., & Menz, W. (2014). Interviews mit Experten (1. Auflage). Springer VS.

Brightwell, P., & Edwards, T. (2018, September). AMWA NMOS: State of Play and What’s Next. http://www.ipshowcase.org/wp-content/uploads/2018/11/Peter-Brightwell- IPShowcase-2018-NMOS-Brightwell-Edwards-Final-version.pdf

Carroll, S., & Hidle, E. (2019). NDI® Makes IP Accessible for Live, Post-Production, Mobile Devices, and Delivery at IBC2019 (S. 3). https://www.newtek.com/press- releases/ndi-makes-ip-accessible-ibc-2019/#

Cisco. (2011). IP Multicast – Concepts, Design and Troubleshooting.

Cisco. (2019a). Cisco IP Fabric for Media Design Guide.

Cisco. (2019b). Precision Time Protocol Software Configuration Guide for IE 2000U and Connected Grid Switches.

Cobalt. (2016). IP Video Transport Protocols—Knowing What To Use When—And Why. 8.

Deame, J. (2020, Juni 15). What is NMOS? with a Secure Control Case Study. The Broadcast Knowledge. https://thebroadcastknowledge.com/tag/jed-deame/

Edwards, T. (2017). SMPTE ST 2022: Moving Serial Interfaces (ASI & SDI) to IP. 22.

EndRun Technologies. (2015). Precision Time Protocol. https://endruntechnologies.com/pdf/PTP-1588.pdf

Ethernet Alliance. (2019). Ethernet Roadmap 2019 Side 2. https://ethernetalliance.org/wp-content/uploads/2019/08/EthernetRoadmap-2019-Side2- ToPrint.pdf

Fairhurst, G. (2009, März 10). Unicast, Broadcast, and Multicast. https://erg.abdn.ac.uk/users/gorry/course/intro-pages/uni-b-mcast.html

Frostad, S. (2018, Juli 2). Bridge Technologies Applauds VSF Announcement of TR-5 Availability—Bridge Technologies. Bridge Technologies. https://bridgetech.tv/wp/bridge- technologies-applauds-vsf-announcement-of-tr-5-availability/

Furter, S. (2019). Tpc | Metechno, Nevion.

Furter, S. (2020, April 23). Interview.

98

Gläser, J., & Laudel, G. (2010). Experteninterviews und qualitative Inhaltsanalyse: Als Instrumente rekonstruierender Untersuchungen (4. Aufl.). VS Verlag für Sozialwissenschaften. https://www.springer.com/de/book/9783531172385

Hildebrand, A. (2014). RAVENNA & AES67.

Hildebrand, A. (2017, August 23). Your Practical Guide To AES67- Part 1. https://www.thebroadcastbridge.com/content/entry/9360/your-practical-guide-to-aes67- part-1

Hildebrand, A. (2019). SMPTE ST2110 & NMOS IS-08: Audio Transport and Routing. 18.

Hudson, J. (2013a). UHD-SDI Standards Overview – Towards a Hierarchy of SDI data Rates.

Hudson, J. (2013b, September 10). 3Gb/s SDI for Transport of 1080p50/60, 3D, UHDTV1 / 4k and Beyond. https://www.smpte.org/sites/default/files/2013-09-10-3GSDI- Hudson-V3-Full.pdf

ITU. (2011). Recommendation ITU-R BT.601-7 Studio encoding parameters of digital television for standard 4:3 and wide-screen 16:9 aspect ratios.

Jeras, M. (2019). NMOS IS-07 GPI Replacement and Much, Much More…. 9.

JT-NM. (2018). JT-NM Roadmap. http://jt-nm.org/documents/JT- NM_Roadmap_IBC_2018-FINAL.pdf

JT-NM. (2019). Joint Task Force on Networked Media (JT-NM) About. http://jt- nm.org/about.shtml

JT-NM. (2020, Mai). JT-NM Tested Program. https://jt-nm.org/jt-nm_tested/

Kern, A. (2017). From Baseband to IP - Orchestration and Control. https://www.thebroadcastbridge.com/content/entry/8269/wp-lawo-from-baseband-to-ip- orchestration-control?highlight=true

Kersken, S. (2013). IT-Handbuch für Fachinformatiker: Für Fachinformatiker der Bereiche Anwendungsentwicklung und Systemintegration (6. Aufl.). Galileo Computing.

Kesh, E. (2019, April 2). THE MIGRATION TO 400 GIGABIT ETHERNET (400GBE). Interface Masters Technologies. https://interfacemasters.com/company/blog/the- migration-to-400-gigabit-ethernet-400gbe/

Kollinger, S. (2020, Juli 31). Interview.

Kriener, T. (2008). Das OSI-Modell | Thomas Kriener. https://www.kriener.de/?q=node/14

99

Kuckartz, U. (2016). Qualitative Inhaltsanalyse. Methoden, Praxis, Computerunterstützung (3. Auflage). Beltz.

Kunic, S., & Sego, Z. (2018). Analysis of Television Technology Transformation from SDI to IP Production. 211–216. https://doi.org/10.23919/ELMAR.2018.8534669

Kuntner, G. (2019, August 30). Interview.

Lewis, G., & Waidson, M. (2009). A Guide to Standard and High-Definition Digital Video Measurements. https://www.appliedelectronics.com/documents/Guide%20to%20Standard%20HD%20Di gital%20Video%20Measurements.pdf

Lipinski, K. (2017, März 22). Terabit-Ethernet. https://www.itwissen.info/Terabit- Ethernet-terabit-Ethernet-TbE.html

Lipinski, K. (2018a, Oktober 11). 25-Gigabit-Ethernet. https://www.itwissen.info/25- Gigabit-Ethernet-25-gigabit-Ethernet-25GbE.html

Lipinski, K. (2018b, Oktober 11). 40-Gigabit-Ethernet. https://www.itwissen.info/40- Gigabit-Ethernet-40-Gigabit-Ethernet-40GbE.html

Lipinski, K. (2018c, Oktober 11). 100-Gigabit-Ethernet. https://www.itwissen.info/100- Gigabit-Ethernet-100-Gigabit-Ethernet-100GbE.html

Luber, S., & Donner, A. (2018, August 1). Was ist Software-Defined Networking (SDN)? https://www.ip-insider.de/was-ist-software-defined-networking-sdn-a-657442/

Mailhot, J. (2017). What is SMPTE ST2110 and Why Does It Matter? https://www.smpte.org/sites/default/files/2017-06-22-ST-ST2110-Mailhot-V2- Handout.pdf

Mandl, P. (2018). TCP und UDP Internals: Protokolle und Programmierung. Springer Vieweg. https://doi.org/10.1007/978-3-658-20149-4

Merrill, C., & Gagne, A. (2017). Building a Cisco IP Fabric. 9. https://www.grassvalley.com/docs/WhitePapers/broadcast/GVB-1-0620D-EN- WP_Building_IP_Fabric.pdf

Meyer, P. (2016, Februar 9). SMPTE ST-2059-2 (IEEE1588). https://www.smpte.org/sites/default/files/users/user27446/IEEE%201588%20&%20SMP TE%20Montreal%202016_02_09.pdf

Myers, P. (2017). SMPTE ST 2110—The Basics. https://www.smpte.org/sites/default/files/users/user29811/SMPTE%20UK%20%26%20S AM%20-%20ST%202110%20The%20Basics%20FINAL.pdf

Nelson, B. (2016). DECONSTRUCTING LIVE IP - Overview and Analysis of IP

100

Protocols for Television Production.

Nevion. (2016, April 7). Standards for media transport over IP - Nevion. https://nevion.com/blog/standards/

NewTek, Inc. (2016). NDI Technical Brief. https://233b1d13b450eb6b33b4- ac2a33202ef9b63045cbb3afca178df8.ssl.cf1.rackcdn.com//pdf/newtek-ndi-technical- brief.pdf

Olson, G. (2019, Januar). IP Infrastructure Global Viewpoint – Jan 2019. https://www.thebroadcastbridge.com/home/category/ip- infrastructure/entry/12654/understanding-leaf-spine-network-topology

Orme, T. (2017, Januar 3). Understanding IP Networks—Forward Error Correction— The Broadcast Bridge—Connecting IT to Broadcast. https://www.thebroadcastbridge.com/content/entry/7502/understanding-ip-networks- forward-error-correction

Phillips, G. (2019, April). Red & Blue, or Purple. Your network, your way. http://www.ipshowcase.org/wp-content/uploads/2019/05/1500-Gerard-phillips-Arista- Red-Blue-or-Purple-your-network-your-way.pdf

Porter, R. (2018). AMWA NMOS IS-04 and IS-05 Scalability and Performance. 19.

Porter, R., & Vishwarupe, S. (2019). Using AMWA IS-06 for Flow Control on Professional Media Networks. 11.

Poynton, C. A. (2012). Digital video and HD: Algorithms and Interfaces (2nd ed). Morgan Kaufmann.

Ravenna. (o. J.). What is AES67. RAVENNA IP-Based Media Network. Abgerufen 28. März 2020, von http://www.ravenna-network.com/aes67/what-is-aes67-1/

Riggert, W. (2014). Rechnernetze: Grundlagen - Ethernet - Internet (5.). Carl Hanser Verlag GmbH & Co. KG.

Schmidt, U. (2013). Professionelle Videotechnik: Grundlagen, Filmtechnik, Fernsehtechnik, Geräte- und Studiotechnik in SD, HD, DI, 3D (6. Aufl.). Springer- Verlag.

Simpson, W., & Calverley, E. (2019). Fundamentals of IP in Broadcast Production. 48.

SMPTE. (2008). ST 259:2008—SMPTE Standard—For Television—SDTV - Digital Signal/Data—Serial Digital Interface. https://ezproxy.fhstp.ac.at:2329/document/7292109?

SMPTE. (2010). 24-Bit Digital Audio Format for SMPTE Bit-Serial Interfaces at 1.5 Gb/s and 3 Gb/s—Roadmap for the 299Document Suite. 2.

101

SMPTE. (2014). OV 425-0:2014—SMPTE Overview Document—SMPTE Bit-Serial Interfaces at 3 Gb/s—Roadmap for the 425 Document Suite. https://ezproxy.fhstp.ac.at:2329/stamp/stamp.jsp?tp=&arnumber=7292127

SMPTE. (2018a). OV 2081-0:2018—SMPTE Overview Document—6G-SDI Bit-Serial Interfaces Roadmap for the SMPTE ST 2081 Document Suite. https://ezproxy.fhstp.ac.at:2329/stamp/stamp.jsp?tp=&arnumber=8356219

SMPTE. (2018b). OV 2082-0:2018—SMPTE Overview Document—12G-SDI Bit-Serial Interfaces—Overview for the SMPTE ST 2082 Document Suite. https://ezproxy.fhstp.ac.at:2329/stamp/stamp.jsp?tp=&arnumber=8356216

SMPTE. (2018c). OV 292-0:2018—SMPTE Overview Document—SMPTE Bit-Serial Interfaces at 1.5 Gb/s—Roadmap for the 292 Document Suite. https://ezproxy.fhstp.ac.at:2329/stamp/stamp.jsp?tp=&arnumber=8398500

SMPTE. (2019a). OV 2110-0:2018—SMPTE Overview Document—Professional Media over Managed IP Networks Roadmap for the 2110 Document Suite. https://ezproxy.fhstp.ac.at:2329/document/8626804/metrics#metrics

SMPTE. (2019b). ST 2022-8:2019—SMPTE Standard—Professional Media Over Managed IP Networks: Timing of ST 2022-6 Streams in ST 2110-10 Systems. https://ezproxy.fhstp.ac.at:2329/document/8716819

VERBI Software GmbH. (2020). MAXQDA | Die #1 Software für Qualitative & Mixed- Methods-Forschung. MAXQDA - The Art of Data Analysis. https://www.maxqda.de/

Viengkhou, S., Gagnon, F., Martel, J., & Lavoie, R. (2018, Februar 28). Transparent versus Boundary clocks (PTP) in Broadcast environment. https://www.embrionix.com/resource/transparent_boundary_clock_ST2059_in_broadcast

VSF. (2015a). Video Services Forum (VSF) Technical Recommendation TR-03 Transport of Uncompressed Elementary Stream Media over IP. http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR- 03_2015-11-12.pdf

VSF. (2015b). Video Services Forum (VSF) Technical Recommendation TR-04 Utilization of ST-2022-6 Media Flows within a VSF TR-03 Environment. https://www.videoservicesforum.org/download/technical_recommendations/VSF_TR- 04_2015-11-12.pdf

VSF. (2018a). Video Services Forum (VSF) Technical Recommendation TR-01:2018 Transport of JPEG 2000 Broadcast Profile video in MPEG-2 TS over IP. http://vsf.tv/download/technical_recommendations/VSF_TR-01_2018-06-05.pdf

VSF. (2018b). Video Services Forum (VSF) Technical Recommendation TR-05 Essential Formats and Descriptions for Interoperability of SMPTE ST 2110-20 Video Signals.

102

http://vsf.tv/download/technical_recommendations/VSF_TR-05_2018-06-23.pdf

VSF. (2020). Video Services Forum. http://vsf.tv/

Zisler, H. (2018). Computer-Netzwerke: Grundlagen, Funktionsweisen, Anwendung. Für Studium, Ausbildung und Beruf. (5. Aufl.). Rheinwerk Computing.

103

Abbildungsverzeichnis

Abbildung 1. Ablauf der inhaltlich strukturierenden Inhaltsanalyse (Kuckartz, 2016, S. 100) ...... 7

Abbildung 2. Ansicht der Hauptkategorien in der Code-Matrix (Ruckenstuhl, 2020) ...... 9

Abbildung 3. Textsegmente mit aktiviertem Code „Etablierung“ (Ruckenstuhl, 2020) ...... 9

Abbildung 4. SDI Formate (Hudson, 2013a) ...... 13

Abbildung 5. ANC Bereiche in den Austastlücken (Schmidt, 2013, S. 145) ...... 15

Abbildung 6. Studiotakt mit angeschlossenen Geräten (Schmidt, 2013) ...... 17

Abbildung 7. OSI-Referenzmodell (Kriener, 2008) ...... 19

Abbildung 8. OSI-Modell mit Protokollen (Barella, 2017c, S. 5) ...... 27

Abbildung 9. Spine-Leaf-Architektur mit angeschlossenen Geräten (Cisco, 2019a) ...... 28

Abbildung 10. Multi-site Aufbau (Cisco, 2019a) ...... 29

Abbildung 11. Hybride Spine and Leaf-Topologie (Phillips, 2019) ...... 29

Abbildung 12. IGMP Verbindungsaufbau (Cisco, 2011) ...... 31

Abbildung 13. Vergleich Videokreuzschiene zu IP Routing (Kern, 2017) ...... 33

Abbildung 14. Ebenen der IP Orchestration (Kern, 2017) ...... 35

Abbildung 15. PTP Synchronisationsnachrichten (Cisco, 2019b) ...... 36

Abbildung 16. PTP Hierarchie (Cisco, 2019b) ...... 37

Abbildung 17. JT-NM Roadmap (JT-NM, 2018) ...... 39

Abbildung 18. JT-NM Prüfsiegel (JT-NM, 2020) ...... 40

Abbildung 19. AES67 Unterstützung (Ravenna, o. J.) ...... 41

Abbildung 20. IP-Standards Entwicklung (Nevion, 2016) ...... 43

Abbildung 21. IS-04 Abfrage der Ressourcen (Porter, 2018) ...... 44

104

Abbildung 22. Zusammenspiel von IS-04 und IS-05 (Brightwell & Edwards, 2018) ...... 45

Abbildung 23. IS-06 Network Controller (Porter & Vishwarupe, 2019) ...... 46

Abbildung 24. IS-08 Audio Channel Mapping (Hildebrand, 2019) ...... 47

Abbildung 25. SMPTE ST 2022-6 Stream (Myers, 2017) ...... 50

Abbildung 26. SMPTE ST 2022-7 Hitless Protection Switching (Simpson & Calverley, 2019) ...... 51

Abbildung 27. Transport mittels ST 2110 (Simpson & Calverley, 2019) ...... 52

Abbildung 28. ST 2022-6 im Vergleich zu ST 2110 (Simpson & Calverley, 2019) ...... 53

Abbildung 29. Inhalt einer SDP-Datei (Simpson & Calverley, 2019) ...... 54

Abbildung 30. 2110-20 Video Encapsulation (Simpson & Calverley, 2019) ...... 55

Abbildung 31. Pixelgruppe (Simpson & Calverley, 2019) ...... 56

Abbildung 32. RTP Header und RTP Payload Header (Simpson & Calverley, 2019) ...... 56

Abbildung 33. ST 2110-21 Sender Types (Simpson & Calverley, 2019) ...... 57

Abbildung 34. 2110-30 Audio Encapsulation (Simpson & Calverley, 2019) ...... 58

Abbildung 35. Ancillary Data Aufbau (Simpson & Calverley, 2019) ...... 60

Abbildung 36. Format eines Ancillary Data Paket (Simpson & Calverley, 2019) . 60

105

Tabellenverzeichnis

Tabelle 1. Schichten des OSI- sowie DDN(TCP/IP)-Modells (Kersken, 2013, S. 185) ...... 24

106

Anhang

A. Interview Georg Kuntner

1 Erstmal Vielen Dank für Zeit und für den Anfang würde ich dich bitten deine aktuelle Position und deinen Aufgabenbereich ein bisschen vorzustellen.

2 Gut, ich bin tätig beim österreichischen Rundfunk in der technischen Direktion in der Abteilung für Rundfunktechnik und Planung. Dabei bin ich zuständig, in erster Linie für Projekte, Projektentwicklung, Projektumsetzungen die wir aus unterschiedlichen Quellen, also teilweise aus Eigeninitiativen aus der technischen Direktion, andererseits auch getriggert durch Redaktion oder anderer technischer Bereiche, bekommen wir Aufgaben gestellt die wir dann bewerten, Lösungen entwickeln, zur Umsetzung empfehlen oder nicht. Beziehungsweise dann eben auch wenn es umgesetzt wird und budgetiert wird, dann auch umsetzen.

3 Welchen Bezug hast du zum Thema IP und Implementierung von IP Techniken?

4 Mein Hauptaufgabenbereich sind eigentlich neue Technologien, da ist IP 2110 ein wesentlicher Faktor und ich bin auch Projektleiter für eine der ersten Anlagen hier im Haus die IP 2110 schon implementiert haben. Das ist ein Testlabor, eine Testumgebung wo wir die ersten Schritte gehen in dieser Technik für eine spätere Implementierung auf der gesamten Hausinfrastruktur und des Weiteren bin ich auch noch Projektmitarbeiter bei einem Ü-Wagen Projekt den wir auch komplett in IP 2110 bauen.

5 Nachdem du da schon ein bisschen Erfahrung hast, welche Vorteile bietet deiner Meinung nach IP gegenüber SDI?

6 Vorteile. Naja man verspricht sich auf alle Fälle eine bessere Skalierung der Systeme. Früher war es ja so, man baut eine Anlage, zum Beispiel in Standard Definition, plötzlich kommt HD und die Kabel und die Anlage ist einfach nicht mehr für den Transport ausgelegt, dass das dann noch mit der gleichen Datenrate funktioniert und man müsste die komplette Infrastruktur tauschen. Bei IP könnte ich zumindest aus heutiger Sicht die Glasfaser Verkabelungen die da in erster Linie eingesetzt werden lassen, den Switch vielleicht tauschen, und die Geräte hätten die selbe Anbindung. Aber ich könnte dann die gleichen Leitungen und so weiter benutzen.

107

Zweiter großer Punkt den ich eigentlich noch fast wichtiger sehe wäre dann Ressourcenteilung. Was früher nicht so einfach gegangen wäre, wäre dann hoffentlich möglich mit in Richtung Virtualisierung und Ressourcensharing. Das ist so das große Thema das wir uns irgendwie wünschen. Ja, was noch? Ansonsten, Nachteile wollen wir mal nicht besprechen. Irgendwann hoffentlich auch mal geringere Kosten. Also zur Zeit ist es noch nicht so, aber später muss man sich das anschauen. Es kommt dann ja auch die Frage mit den Erneuerungszyklen, wie oft muss man die Anlagen wirklich tauschen. IT Anlagen sind, sage ich mal, fehleranfälliger als die anderen alten Broadcastanlagen. Die Lebensdauer und die Erwartung dafür ist geringer. Aber jetzt sind wir schon bei den Nachteilen (lacht).

7 Ist ja kein Problem, das wäre nämlich meine nächste Fragen gewesen. Wo siehst du dann jetzt noch die Vorteile von SDI?

8 Vorteil ist momentan einmal ganz klar in der Handhabung. Es ist eine fertige Lösung die funktioniert. Es ist ohne viel Konfigurationsaufwand schnell einmal ein Ergebnis sichtbar. Das ist jetzt in der 2110 Welt nicht der Fall. Es beginnt bei ganz rudimentären Sachen, wie einen 2110 Bildschirm, Videomonitor und ein 2110 Kamerasignal oder was auch immer. Das hier einfach anzuschließen und hoffen das es spielt, das funktioniert nicht mehr. Das war bei SDI schon wesentlich einfacher. Kabel, Danke, und Bild ist zu sehen. Also das ist definitiv jetzt mal ein Nachteil für kleine schnelle Anwendungen. Die Komplexität, die steigt auf alle Fälle. So ohne Steuersysteme, Broadcaststeuersysteme oder auch bei größeren Systemen dann mit Netzwerksteuersystemen also SDN Controllern wird man nicht mehr weit kommen. Und ja wie gesagt zur Zeit ist einfach auch das Knowhow bei den meisten Mitarbeitern noch nicht sehr weit ausgeprägt, das heißt das steht einer Implementierung natürlich auch oft im Wege, beziehungsweise braucht halt mehr Zeit und Zeit ist leider Geld und dadurch steigen da in dem Bereich die Kosten.

9 Wenn wir schon beim Knowhow sind, das könnte man auch eine Herausforderung nennen, da eben neue Mitarbeiter heranzubilden. Wo siehst du da noch Herausforderungen bei dem Umstieg auf IP- Technologien?

10 Ja natürlich ist zum einen vom Knowhow gesprochen jetzt mehrere Aspekte notwendig beim Wissen. Man braucht einerseits Wissen um Videotechnik, ganz klassische, weil da die Signale oder wie man mit den Sachen umgeht, und was Synchronität bedeutet und was Timing bedeutet. Die Punkte gelten nach wie vor. Aber jetzt kommt eben dazu, dass man eben auch ein bisschen tieferes Netzwerkwissen braucht, was vielleicht viele, sage ich mal, Kollegen oder andere Leute in der Branche die eben

108

ewig mit SDI und anderen Systemen gearbeitet haben einfach nicht haben. Das heißt ein Hybrid aus IT-Spezialist und Audio-Video Spezialist ist eigentlich das was da momentan gefragt wird und oft in der Branche als Unicorns bezeichnet wird. Das heißt diese Leute sind momentan sehr gefragt, haben sicher gute Chancen bei Gehaltsverhandlungen. Ansonsten, was noch, kann man die Frage vielleicht nochmal kurz spezifizieren?

11 Welche Herausforderungen du siehst bei einem Wechsel auf IP.

12 OK. Ja.

13 Vielleicht auch Stichwort Bandbreite, Kompression, Latenz,...

14 Ah technisch, nicht Personal.

15 ... und solche Sachen.

16 Ja technisch, welche Herausforderungen bei technischen Umstiegen? Kompression, ja wir sind es gewohnt von SDI alles unkomprimiert ...

17 Genau, ja. Darauf wollte ich hinaus.

18 Ok, gut. Und das gibt es bei ST 2110 natürlich genauso. Aufgrund der anderen Header Informationen spart man sich ein bisschen was ein im Vergleich zu einem normalen SDI Signal aber trotzdem sind natürlich große Bandbreiten von Nöten die aber, sage ich mal, in klassischen Datennetzwerken jetzt gar nicht so das große Problem eigentlich sind. Große Serverfarmen, also die von Amazon und Google und was weiß ich, die werden wesentlich mehr Daten herumschieben auf den Switchen als jetzt wir in unseren ersten Systemen. Aber was halt der große Unterschied ist, dass wir eben einfach Echtzeit brauchen, Realtimefähigkeit. Und bei uns auch ein paar Paketfehler auch Auswirkungen haben was bei einer normalen Datenübertragung eigentlich egal ist, es wird neu angefragt, es dauert halt vielleicht ein bisschen länger bis das Bild da ist oder andere Sachen da sind, aber das geht bei uns eben nicht. Also das ist eigentlich die große Herausforderung auch für die IT-Branche eigentlich und die Switch Hersteller in dem Bereich. Also Systeme schaffen die auch schnell genug sind und auch einen großen Puffer haben um die ganzen hereinströmenden Daten auch zu bewerkstelligen.

19 Weißt du wie es da im Moment mit der Zuverlässigkeit der bis jetzt am Markt verfügbaren Geräte die SMPTE 2110 unterstützen aussieht, also Ausfallsicherheit oder auch Netzwerksicherheit? Es gibt ja dieses eine Beispiel wo ein Fernsehsender gehackt wurde.

20 Das kann man jetzt unmöglich für alle Geräte sagen. Also die Hersteller, es

109

gibt ja sehr viele Geräte, es gibt alle paar Wochen neue Firmwares und Updates, geschweige denn das wir jetzt jegliches Gerät schon in der Hand gehabt hätten, das stimmt natürlich nicht. Und von dem her kann man jetzt auch nicht sagen wie zuverlässig die alle spielen. Wir können nur von den Geräte sprechen die wir selber schon im Haus haben oder auch beim Ü- Wagen jetzt verbaut haben, und das ist ganz unterschiedlich. Also beim Ü- Wagen Projekt sind wir momentan soweit, dass wir noch in der Fertigstellungsphase sind beim Ü-Wagen Bau. Und auch hier sehen wir das regelmäßig neue Updates bei den einzelnen Herstellern und Komponenten immer wieder hereingespielt werden, also das sind alles Entwicklungsprojekte. Genauso mit der Anlage bei uns hier im Haus, das deckt sich auch sehr mit den Erfahrungen im Ü-Wagen. Generell stabil laufen, Ja meistens, das kommt jetzt auch eben auf Aspekte darauf an, manche Geräte gehen gut, manche halten nicht was sie versprechen, andere kommen so schrittweise nach, also da sieht man dann auch die jeweiligen Qualitäten des Supports oder eben auch nicht die jeweiligen Qualitäten des Supports, das ist auch ganz interessant zum Sehen. Und ja ansonsten ist Frage jetzt schwer zu beantworten weil man einfach jetzt über den generellen Markt da jetzt sagen kann was wie gut, welche gesichert sind, manche besser, manche schlechter, manche gar nicht, Standardpasswörter sind echt weit verbreitet, sagen wir mal so.

21 Da hab ich jetzt gleich zwei Unterfragen. Du hast es jetzt gerade gesagt. Support, gibt es da Unterschiede, beziehungsweise du hast es auch angedeutet, es gibt immer wieder neue Firmwares, also relativ häufig. Wie oft muss man sich da umstellen oder neu einstellen oder den Support befragen?

22 Naja, also das kommt eben darauf an, also ist eine Anlage gerade im Aufbau und in der Entwicklung, bis zu dem Punkt, jetzt funktioniert alles so wie ich mir das vorstelle. Jetzt ist es heute so gewesen, dass wir sehr viel mit den diversen Entwicklungsabteilungen bei den Firmen in Kontakt stehen, weil einfach viele Firmwarebugs oder Features noch nicht da sind, oder auch versprochen wird sie werden später nachgeliefert, oder auch wenn Dinge nicht funktionieren und das ist natürlich auch ganz häufig der Fall gewesen, dass es nicht auf Anhieb funktioniert hat. Auch bei den Produktherstellern eben dann Nachentwicklungen es geben muss, und diese dann eine neue Firmware schicken, ein Update. Das kann wöchentlich sein, das kann jedes Monat sein, je nachdem wie der Hersteller eben da agiert. Manche sind schneller, manche sind langsamer, manche nehmen sich eben viel Zeit oder weniger oder haben zu viele Kunden, man weiß es nicht so genau, oder eine zu kleine Entwicklungsabteilung, oder bauen auch zu viele Fehler ein. Ansonsten,

110

wenn die Anlage mal spielt und es läuft, wird man nicht jede neue Firmware sofort einspielen, außer es behebt ein bestimmtes Problem das noch in der Anlage existiert. Oder es ist ein Securitypatch eben oder sonst irgendwas. Aber ansonsten wenn es einmal spielt wird man sich gut überlegen und sich genau anschauen wann man genau wieder auf die nächste Version updatet. Das ist dann im Endeffekt auch so wie es schon früher der Fall war, also da hat man ja auch laufende Anlagen nur dann geupdatet wenn es Sicherheitsaspekte gab die dort behoben werden müssen, oder wenn es neue Features gibt, wo man sagt hey die wären jetzt gut für uns die brauchen wir oder auf das haben wir schon lange gewartet, jetzt ist es endlich da. Oder halt andere Komponenten mitziehen die man durch diese Komponenten auch mit anheben muss. Also die ganze Supportwartung und diese Updategeschichten auf allen Systemen, das ist schon eine große Nummer vor allem wenn man viele Geräte hat. Das heißt je größer das Medienunternehmen oder eben der Anbieter umso mehr ist diese Thematik auch zeitintensiv und muss natürlich dementsprechend behandelt werden.

23 Du hast jetzt schon öfter gesagt, dass ihr schon getestet habt und teilweise auch schon IP-Technik verwendet. Gibt es Bereiche oder Situation in denen du heute diese bedenkenlos einsetzen würdest im Vergleich zu SDI, wo du sagst, Ok, SDI funktioniert zwar aber wir nehmen neue IP Technik.

24 Jetzt kommt es darauf an. Also was ist das für eine Sendung, was ist das für ein Projekt, also es mag Dinge geben wo man sagt, Ja eh. Es kommt auch auf das Budget darauf an, also es ist eine sehr allgemeine Frage die schwierig zu beantworten ist weil es wird an meinen Kunden liegen, was möchte ich meinen Kunden anbieten. Soll es für den ORF sein, soll es für eine Sendung sein? Wir haben uns jetzt auch entschieden Anlagen damit zu bauen, das heißt soweit vertrauen wir der Technik schon das es da hinkommt. Wäre ich jetzt eine kleine Videoproduktionsfirma, würde ich es jetzt noch nicht machen weil einfach der Konfigurationsaufwand eigentlich zu groß ist und es anders schneller und billiger geht. Da werden vielleicht auch so Dinge wie NDI wieder interessant, also was jetzt auch eine Netzwerktechnikgeschichte ist aber doch ein bisschen anders funktioniert als ST 2110. Da ist das vielleicht ganz spannend weil man mit Kompressionen und nicht mit unkomprimiertem Video arbeiten möchte. Und das geht echt auch ganz gut.

25 Weil du es gerade angesprochen hast, glaubst du, dass NDI, sollte SMPTE 2110 irgendwann einmal voll im Markt stehen, dass NDI irgendwann einmal ausstirbt?

26 Beides hat seine Berechtigung. Es ist wie, ein sehr vereinfachendes Beispiel, es gibt ja auch Prosumer Kameras, Professionelle Kameras,

111

Consumer Kameras, für jeden Markt das Richtige. Bei manchen Anforderungen wird es völlig Ok sein die billigste Kamera zu nehmen und nicht jetzt die teuerste Professional Kamera. Und genau so ist es auch mit den verwendeten Protokollen hier, also brauch ich in einem kleinen System wirklich 2110? Wahrscheinlich nicht wenn ich jetzt auch nicht die Ansprüche habe die dahinter stehen und die Flexibilität. Da kommt man mit NDI wahrscheinlich genauso gut aus. Jetzt kommt es auch ein bisschen darauf an, wie möchte ich das Signal noch weiter verarbeiten oder was ist mein Endformat, wie viele Wege muss es gehen, wie viele Generationen muss es durchmachen? Welche Systeme können damit arbeiten, wo wäre eine Transformation notwendig? Also das sind viele Aspekte die man beachten muss bevor man sich für irgendein System entscheidet. Und in dem Fall, ich sehe jetzt momentan aus heutiger Marktsicht jetzt keine Grund warum eines der beiden in nächster Zeit jetzt nicht mehr da sein sollte, weil jedes hat für sein Segment Berechtigung. Wir haben auch mit NDI herumprobiert und es hat auch ein paar sehr elegante Features die ganz super sind. Vor allem für kleine Unternehmen sehe ich das eigentlich schon sehr gut.

27 Ein kleiner Blick in die Kristallkugel. Wie glaubst du wird die Situation in etwa 5 bis 10 Jahren aussehen, oder anders gefragt, was erwartest du dir von der IBC jetzt zum Beispiel?

28 Kurz um die erste Frage zu spezifizieren, die Situation im ORF, die Situation weltweit, die Situation in Österreich?

29 Gern die Situation im ORF und dann in Österreich.

30 Ja im ORF, wir werden jetzt sukzessive Anlagen die erneuert oder erweitert werden nach Maßgabe in IP umsetzen, weil die Industrie drängt ganz stark in die Richtung. Ist auch klar dass wir da irgendwie mitziehen werden. Weil, die anderen Geräte sterben aus, es wäre irgendwie der falsche Weg sonst. Ansonsten, weltweit wird es ähnlich sein. Ich mein SDI wird jetzt nicht aussterben demnächst. IP wird koexistieren. Und vielleicht gibt es bei uns genauso Anlagen die auch teilweise in SDI erneuert werden, also es wird sich auf den Anwendungsfall irgendwie auswirken. Dann, was erwarte ich mir von der IBC? Das ist relativ einfach, den Status Quo zu sehen. IBC oder diese große Messen sind da eigentlich immer der Status Quo an fertigen Produkten. In der Future Zone und Konferenzen sieht man ein bisschen was kommt. Wenn man mit den Leuten, also mit den Heads in den diversen Firmen spricht hört man auch ein bisschen raus was kommt, an fertigen Produkten sieht man natürlich nur das was geht. Das wird uns wenig überraschen, da haben wir einen recht guten Überblick. Es wird natürlich viel 12G Lösungen geben, es wird sehr viel 2110 Lösungen

112

geben. Und abgesehen davon gibt es auch viele andere Themen die dort auch präsentiert werden. Cloud Computing, Virtualisierungen, viel mit Streaming Lösungen, Streaming Anbieter, ja und ansonsten mal schauen, also sie ist sehr vielfältig diese Messe.

31 Das heißt du glaubst, dass die Umstellung auf IP derzeit auf einem guten Weg ist?

32 Momentan schon. Also die Projekte, die werden immer mehr, also jetzt europaweit, hab ich so ein bisschen mitbekommen. Wir sind jetzt in Österreich sicherlich die ersten die jetzt 2110 umsetzen. Also zumindest ist es mir soweit bekannt das es kein anderer machen würde. Anhand der internationalen Projekte die man auch so von den Partnerfirmen die man so hat als Lieferanten mitbekommen, nimmt es natürlich zu. Natürlich nicht nur. Andere Sachen werden natürlich auch ganz klassisch gebaut, vor kurzem wieder ein 12G Ü-Wagen, also macht auch Sinn, wenn ich jetzt sage, ich betreibe den jetzt 3, 4 Jahre und dann schreib ich ihn ab und bau mir einen neuen, also Privatfirmen können sich das leisten, wir nicht. Dass wir so schnell Anlagen erneuern, da fehlt uns einfach das Geld dafür. Ok, der rentiert sich in der Zeit, er hat jetzt sofort ein fertiges Produkt das funktioniert, kann damit Geld verdienen, Geschichte erledigt. Und baut eben in 5 Jahren wieder einen neuen. Unser Ü-Wagen wird wesentlich mehr Jahre fahren müssen als 5 Jahre. Der letzte ist 20 Jahre jetzt in Betrieb gewesen, den wir jetzt ersetzen werden. Also von dem her, das gibt es jetzt in dem Sinn nur für uns in diese Richtung. In den nächsten 5 Jahren, wie du gemeint hast, wird es sicherlich hybride Lösungen geben oder einfach auch nur SDI Lösungen oder 2110 Lösungen. Jedes Haus, jeder Systemplaner oder wie auch immer muss sich das genau überlegen. Was ist die Anforderung, wie viel Budget, welcher Zeitraum muss das fertig werden, wie komplex darf das sein, wer bedient das Ganze ist eine ganz wesentliche Frage. Also das Knowhow und den Personalstand darf man wirklich nicht außen vor lassen. Dann trifft man eben die Entscheidung für das richtige System.

33 Weil du es gerade wieder gesagt hast. Personalstand, da du ja laut deiner Stellenbeschreibung oder so wie du es mir gesagt hast auch für Personalplanung zuständig bist, und...

34 Ich bin nicht für Personalplanung zuständig, also da muss ich gleich mal widersprechen. Was wir machen, also wir überlegen uns auch, schon auch wer das bedienen kann, also wir planen Anlagen und Systeme und Workflows und das ganze Drumherum und wie Dinge funktionieren können österreichweit, oder auch mit den Außenstellen in anderen Ländern. Wir sagen jetzt nicht wir stellen fünf Leute ein, das können wir nicht leisten,

113

dafür gibt es andere Abteilungen. Wir sagen aber es braucht zumindest die und die Personen oder die und die Anforderungsprofile an die Personen in Absprache mit den Kollegen und Abteilungen die das dann betreiben.

35 Darauf wollte ich nämlich hinaus, ob es dann bei der Übergabe oder beziehungsweise bei der Schulung der Systeme dann gravierende Unterschiede geben wird zu Stand Jetzt. Du hast es ja vorhin schon gesagt, es braucht anderes Personal um IP-Technik zu bedienen. Beziehungsweise in der Bedienung für den Endnutzer sollte es sich ja eigentlich nichts ändern, also für den Operator dann.

36 Ja wird es auch nicht. Also die Leute die dann vorm Bildmischer sitzen, das ist ein klassischer Bildmischer von der Oberfläche. Das dahinter IP, der Transportweg IP ist und so weiter, das ist dem Bediener eigentlich egal. Es ändert sich eben was für die Messtechnik wenn es um die Fehlersuche geht. Und auch muss man sich das Denken ein bisschen anders vorstellen, wie die Anlagen funktionieren. Vor allem dieses eingehender, ausgehender Stream, Stream Inside, also in den Maschinen drinnen. Das funktioniert ein bisschen anders als einfach nur Kabel, SDI Ausgang und Eingang, und Fertig. Das hier Alles Alles sein kann und auch weil die meisten Maschinen ja eigentlich nur mehr einen Chip haben der eben alles rechnen kann. Es kann nicht nur mehr ein, sagen wir mal, Delay sein, es kann auch genauso gut ein Farbkorrektur Tool sein und alles andere. Je nachdem wie man es sich konfiguriert und welche Software man darauf laufen lässt. Ja, von dem her muss man sich definitiv überlegen wie das Ganze funktioniert und ein klassischer Schaltplan ist gar nicht mehr so einfach.

37 Gut dann würde ich dich zum Schluss noch einmal zusammenfassend bitten, wie der derzeitige Stand hier im Haus ist und woran gerade gearbeitet wird, bezogen auf IP Technik oder Umstellung auf IP Produkte. Soweit du das sagen kannst.

38 Jetzt muss ich auch überlegen wie viel ich überhaupt sagen darf. Ja, Geheimnis ist es keines das wir eben schon eine Anlage im Haus haben, das hab ich ja eingangs ja erwähnt. Mit der wir die ersten Schritte durchführen als Test/Schulungsumgebung. Auch der Ü-Wagen ist kein Geheimnis bei dem wir gerade in der Endfertigung sind und den wir dann hoffentlich ab Herbst schon hier haben im Haus. Der ist ebenso in 2110 ausgeführt. Des Weiteren zukünftig kommende Projekte die ich jetzt noch nicht vorgreifen möchte weil die Ausschreibungen noch nicht draußen sind werden teils teils je nach Projekt ebenso in IP, sagen wir mal, zumindest einmal ausgeschrieben. Also der Weg geht schon in die Richtung natürlich, das heißt eben noch nicht für alle Anlagen, aber für Teile wo es schon Sinn macht hier die Infrastruktur in die Richtung zu bringen werden wir das

114

weiter treiben. Da wo es noch keinen Sinn macht muss man es momentan auch noch nicht machen.

39 Gut, dann hast du noch irgendwelche Anmerkungen oder Ergänzungen die jetzt nicht im Gespräch vorgekommen sind die du noch loswerden möchtest?

40 Wunschlos Glücklich. (Lacht)

41 Dann Vielen Dank.

42 Gerne.

115

B. Interview Matthias Barth

1 Für den Anfang würde ich dich bitten, deine aktuelle Position und deinen Aufgabenbereich ein bisschen vorzustellen.

2 Also ich bin Senior Solution Architect bei der Playout und Production Solutions und innerhalb der Firma die sich ProsiebenSat1TechnologiesSolutionsGmbH nennt. PTS. Und der Aufgabenbereich von mir ist jetzt, also ich komme aus dem Bereich der sich mit dem Playout beschäftigt und mein Aufgabenbereich in dem Zusammenhang ist, dass ich mich jetzt schon länger mit der Umstellung Richtung All IP beschäftige. Und sonst ist natürlich der Aufgabenbereich einfach da die verschiedenen Technologien die im Playoutbereich eingesetzt werden zu steuern und zu schauen wo es da hingeht und welche Lösungen man da einsetzt und wie das Ganze dann in das Applikationsökosystem von ProSieben sich da einfügen soll. Und natürlich mit dem entsprechenden nötigen Sendesicherheitsdenken versorgt.

3 Alles klar. Dann möchte ich gern näher drauf eingehen, beziehungsweise du hast es eh gerade gesagt, wie genau dein Bezug zum Thema IP Allgemein, also NDI, SMPTE 2022 aber auch im Speziellen zu SMPTE 2110.

4 Ok. Also wir haben hier am Campus seit, ja also die Planungsphase hat mehr oder weniger vor diesen anderthalb, knapp 2 Jahren begonnen, als es geheißen hat, es wird hier einen Neubau am Campus geben und innerhalb dieses Neubaus am Campus war relativ schnell klar, dass es keine großartigen Geräteraume mehr geben wird, sondern das es nur noch Datencenter geben wird. Sprich, wir haben gar nicht mehr, wir werden gar nicht mehr den Platz haben um großartig Kupfer zu verlegen. Also um SDI Verkabelung in einem größeren Stil überhaupt möglich zu machen. Und dementsprechend war ganz klar der Schritt das wir gesagt haben, wir müssen kucken das wir für den neuen Campus in All IP Broadcastumgebung auf die Beine stellen. Für den Bereich Playout ist das dann bei mir gelandet das Thema. Und da hab ich mich natürlich dann mit den Standards beschäftigt. Wir sind auch Mitglied bei AIMS damit wir quasi mehr oder weniger aus erster Hand mitbekommen wo die Industrie da so hinläuft und haben uns dann eben auch mit den verschiedenen Varianten, also dem 2022 beschäftigt und mit dem 2110. Und haben dann für uns entschieden, dass es mit dem Ansatz das wir den gesamten Campus betrachten, Broadcastseitig, und im Zuge dieses Neubaus eben, das da nur ein All IP Ansatz in Frage kommt. Und zwar einer mit 2110. Eben weil wir auch den Produktions- und auch den Postproduktionsbereich direkt mit einbinden wollen und da macht es dann nicht Sinn mit 2022 zu arbeiten.

116

Wenn man sich nur auf den Playoutbereich konzentrieren würde, da würde es ja durchaus Sinn machen, dass man das Audio einfach immer synchron hält und ich sag mal mehr oder weniger bei dem bleibt was man bisher kennt und es nur auf eine andere Physik hebt. Aber eben weil Produktion und Postproduktion mit eingebunden werden, werden wir das in 2110 bauen.

5 Dann möchte ich dich ganz allgemein bitten zu erklären wo für dich die Vorteile liegen von IP gegenüber SDI.

6 Warum kann man, warum sollte man in Richtung IP gehen. So. Da gibt's natürlich die schon genannten Gründe. Wir sind schon, wir werden baulich gezwungen sein Glas statt Kupfer zu legen. Das ist der eine Punkt. Der andere Punkt ist, es ist auch wenn wir jetzt als ProSieben das bisher noch nicht mit einem starken Fokus verfolgen, ist ganz klar dass, UHD schaut deutlich über den Horizont heraus von den Dingen die da kommen werden. Wenn ich mir überlege, dass ich den Campus irgendwann mal UHD-fertig machen will und zwar in der Breite, nicht nur in einzelnen Inseln, dann macht IP sehr stark Sinn. Weil im Idealfall hab ich meine IP Infrastruktur fertig und entweder sind die Geräte schon so weit dass sie schon UHD können oder ich muss nur noch vorne und hinten Geräte austauschen und ich hab meinen Campus auf UHD gehoben ohne das ich an der Infrastruktur noch groß was ändern muss. Dann ist natürlich IP so, wenn man IP weiterdenkt ergeben sich eine ganze Menge Möglichkeiten wie man in Operations und Service einfacher werden kann. Und es natürlich auch so, mit IP sind ganz andere Skalierungen möglich. Also ich kann wenn wir jetzt auf dem Campus eine größere naja, also auf alle Fälle eine zweistellige Zahl an jeweils großen SDI Kreuzschienen haben die wir miteinander verkoppeln über Tielines, kann ich mir in IP eine große, kann ich das ganze Haus mehr oder weniger zu einer großen Kreuzschiene zusammenklemmen, was ein enormer Vorteil ist. Und ich denke, dass wir im Ende da auch einen Kostenvorteil daraus ziehen. Also das ist zwar vielleicht jetzt am Anfang wo die Technologie jetzt gerade steht noch nicht ganz so aber es gibt einen massiven Preisverfall jetzt schon zu, sieht man jetzt schon bei den Switch Herstellern, da kommen jetzt schon die 400G Switche heraus und mit denen kann man schon Dinge machen die selbst für so eine Größe von unserem Haus schon fast nicht mehr auszufüllen sind dann.

7 Das heißt, du siehst nicht nur aus technischer Sicht einen Vorteil sondern mittlerweile schon auch aus wirtschaftlicher Sicht einen Vorteil, jetzt schon da vorzudenken und vorzuarbeiten?

117

8 Also ich habe jetzt keine genauen Zahlen hier was das jetzt tatsächlich kosten würde den gesamten Campus einmal neu in SDI zu bauen und einmal neu in IP zu bauen. Ich glaube aber, dass das sich dort auf alle Fälle einfacher und schneller Kosteneinsparungen dann auch realisieren lassen werden. Auch unter anderem weil ich zum Beispiel kürzere Refreshzyklen habe in der Technologie, also ich bin halt in 3 bis 5 Jahren, das kann man jetzt als Vorteil und als Nachteil sehen, kann ich Geräte austauschen die dann halt jeweils leistungsfähiger sind. Während wenn ich halt in langfristigen Abschreibungen gebunden bin läuft das eben 10 oder 15 Jahre, also in der traditionellen Broadcasttechnik. Das spiegelt sich dann natürlich auch in den Kosten wider, das wird billiger werden, das wir günstiger werden, ja.

9 Gehen wir mal in die andere Richtung. Wo würdest du denn heute noch SDI einsetzen und sicher nicht auf IP Standards setzen wollen? Wo sagst du dir, IP schön und gut, aber in diesem Bereich ist SDI einfach immer noch vorne, oder einfacher umzusetzen?

10 Da hast du 2 Punkte angesprochen die auseinander gehen. Also eigentlich würde ich zumindest mittelfristig im Sinne von 1, 2 Jahren kein SDI mehr bauen wollen. Da muss sich aber noch ein bisschen was tun in der Industrie. Also für mich gibt's da keinen Weg dran vorbei. Und ich sehe auch nicht warum man in einem größeren Haus wie unserem noch weiter mit SDI bleiben soll. Also mal ganz abgesehen davon das wir keine Wahl haben. Weil es einfach an vielen Stellen Sinn macht. Flexibilität. Mit einfacheren Services für linearen OTT bereitzustellen, einfach Zukunftstechnologien wie Next Generation Audio oder Higher Framerates oder solche Dinge dann einfach umzusetzen ohne das ich immer in der Infrastruktur mir die Finger brechen muss. Deswegen. Ich würde immer zu IP gehen. Auf der anderen Seite macht das natürlich für kleinere Unternehmen meines Erachtens durchaus noch Sinn weiter noch bei SDI zu bleiben weil das eine bekannte Technik ist, weil es eine stabile Technik ist, weil es dafür das Knowhow in der Breite gibt, weil es eine große Auswahl an Produkten gibt und das sind einige der Themen die es bei IP noch nicht gibt. Ja also, es gibt praktisch keine Möglichkeit mir Wissen einzukaufen extern, weil es die wenigen wirklichen Experten die es gibt, die sind in der Entwicklung, in der Industrie drin, und noch nicht am Markt verfügbar. Ich muss dann schon kucken wie ich da rum komme. Also da sehe ich wie gesagt für kleine Häuser durchaus schwierig, weil es ist tatsächlich ein Quantensprung der sich da tut. Viele Dinge werden ganz anders gemacht und müssen ganz anders gemacht werden. Können teilweise auch noch gar nicht gemacht werden weil die Produkte noch fehlen oder noch nicht so miteinander verkoppelt sind wie sie sein sollen.

118

Wenn man jetzt direkt ein Projekt machen muss dann kann man, dann sollte man sich schon überlegen welchen, muss ich jetzt IP machen? Ja, also man sieht, dass die Häuser, die Projekte die da draußen sind die manchmal auch aus Prestigegründen sagen sie sind jetzt ein IP Haus, wirklich große Probleme haben die Projekte umzusetzen. Beziehungsweise ihrem eigenen Anspruch gerecht zu werden dass das dann auch wirklich IP ist. Und nicht bei allen Projekten die ich bis jetzt gesehen hab ist es dann im Grunde genommen so das man ganz viele SDI Gateways außen rum hat. Das die eigentliche Technik im Studio und bei den Kameras oder wo auch immer noch SDI ist und ich im Kern ich sag mal so eine Art IP Kreuzschiene hab. Zum Beispiel so einen Ü-Wagen beim TPC. Das Ding besteht nur aus Gateways. Und innen drin hab ich eine Kreuzschiene. Ja das kann man so machen, ist aber für mich in dem Sinn kein IP. Ja da sind IP Komponenten mit dabei, das ist aber nicht ein IP Ü-Wagen deswegen. Bei vielen anderen Dingen die wir uns angesehen haben oder die ich mir angeschaut hab ist das ähnlich. Ob dass das BCE in Luxemburg ist die als erste gesagt haben, sie machen IP, die haben eine irre Gateway Arie da außen rum. So langsam, und ich weiß manchmal gar nicht ob die dann tatsächlich propagiert werden, kommen jetzt so die ersten richtigen IP Projekte. Gerüchteweise hab ich gehört, dass TPC da auch sehr, sehr stark am Kämpfen ist und wohl dann im Endeffekt dann doch nicht ihrem Anspruch gerecht wird das wirklich mit IP 2110 auf allen Ebenen durchziehen zu können. Ja, also einfach weil es die Produkte nicht gibt oder zu wenig Produkte gibt die dann nicht den Anforderungen entsprechen oder so was.

11 Das heißt, du würdest auch sagen, dein Hauptgrund warum es derzeit noch nicht funktioniert oder in vollem Umfang funktioniert, ist eben die fehlende Produktauswahl?

12 Die Produktauswahl ist im Moment noch sehr eingeschränkt, ja. Beziehungsweise gibt es Bereiche die meines Wissens noch gar nicht abgedeckt sind. Ja also ich bin immer noch auf der Suche nach einem Videotextinserter in 2110. Hab ich noch keine gesehen, ja. Also noch keinen einzigen. Mal ganz abgesehen davon das du ja vielleicht sagst, ich will eine gewisse Auswahl haben oder das Produkt dass das macht ist vom Operativen her eine Katastrophe und ich brauch was anderes. Aber was machst du wenn du nur dieses eine Produkt hast. Ja dann musst du da entweder den Tod sterben, oder du sagst du nimmst noch ein SDI Produkt und gehst halt über Gateways einmal aus der IP-Welt raus und wieder rein.

13 Angenommen man möchte jetzt noch nicht in 2110 oder IP investieren, hat aber vor, ich sag jetzt mal in den nächsten 5 bis 10 Jahren darauf

119

umzusteigen, was könnte man da deiner Meinung nach jetzt schon beachten um den späteren Umstieg ein bisschen einfacher zu gestalten?

14 Hmm. Also ich denke, den Ansatz den die meisten Häuser gehen werden, der auch nicht verkehrt ist, ist dass man mit einer Art kleinen Insel anfängt Erfahrungen zu sammeln. Also, dass man sagt, das nächste Studio das man baut, baut man in IP. Und schaut einmal, dass man da eben Erfahrungen sammelt, dass man dort Wissen aufbaut, dass man dort Fehler macht und aus den Fehlern lernt und dann eben auch mit den Produkten lernt und mit diesem Hands-On einfach die Lernkurve startet, ja weil das Hauptproblem hatte ich ja vorher schon angesprochen, oder eines der Hauptprobleme ist auch das fehlende Wissen in den Häusern, ja also die regulären Netzwerker kennen sich mit den Multicast Themen die da kommen nicht wirklich gut aus, zumindest nicht in der Breite. Und über das Timing, und wie generell so ein Netzwerk aufgesetzt wird, also schon von der Architektur her, wie ich die ganzen Geräte steuere, Inbound, Outbound, gibt’s viele Themen die da mitspielen wo man erstmal überhaupt darüber nachdenkt wenn man dann versucht mehrere Geräte mal in einem Netzwerk zusammen auch zu kontrollieren, und die Streams zu kontrollieren. Und zu kucken, kann ich das kaputt machen indem ich zu viel Bandbreite benutze? Und lauter so Themen. Also da gibt's ein weites Gebiet und ich glaube der erste Schritt ist, so haben's ja wir auch gemacht, wir haben ja hier ein Labor aufgebaut wo wir jetzt einfach ausprobieren und lernen. Ja, und ich glaub das ist der einzige Weg. Ob das jetzt über ein Labor ist oder über produktiven Dingen die man sich ins Systemhaus holt, die einen dabei unterstützen. Das muss dann jedes Haus selbst entscheiden. Aber ich glaub es geht nicht anders erstmal überhaupt einen Fuß reinbekommen und dann von dort aus sich vorarbeiten in die Richtung die man dann selber braucht und für die Produkte die da anstehen.

15 Weil du gerade das Labor angesprochen hast. Auf welche Stolpersteine seid ihr denn da gestoßen in den letzten Jahren? Ich nenn jetzt mal ein paar Stichworte: Bandbreite, Latenz, Synchronisierung. Was sind da so die Erfahrungswerte?

16 Um mal mit der positiven Erfahrung anzufangen, also diese Initiative die AIMS da angeschoben hat in der Industrie mit den regelmäßigen Veranstaltungen für Interoperabilität und so, die haben schon sehr geholfen, ja. Wir haben jetzt im Gegensatz zu den MXF Anfängen eigentlich nie gehabt, dass auf der rein physikalischen Ebene jetzt zwei Geräte nicht miteinander funktioniert haben. Also wenn ich von irgendeinem Gerät als Sender was auf einen Empfänger geroutet habe oder übers Netzwerk geschickt habe dann konnte der das auch empfangen

120

und decodieren. Und das ist innerhalb dieser kurzen Zeit seit es den Standard gibt schon ein relativ gutes und positives Ergebnis. Und da endet es dann auch schon bald. Also im Moment sind wir schon seit längerem in dem Stand, den ersten Schritt den die Industrie gemacht hat war das sie, jedes kleinere und größere Haus hat angefangen irgendwelche Gateways zu entwickeln. Weil natürlich nicht alle unseren Ansatz gehen mit gleich All IP, sondern ebenso Inseln bauen werden die sie in ihre jetzige SDI Welt integrieren müssen. Und da macht es natürlich auch Sinn diese Gateways zu haben. Die Probleme die da sind, ist das es darüber hinaus, jetzt wenn es Richtung Steuerung geht, die ganzen Hersteller immer noch sehr verhaftet sind in ihre bisherigen proprietären Protokolle und leider nicht diesem Standard folgen der, ich sag mal, also mit NMOS ist ja die Fortführung von dem 2110 der ja den Transport beschreibt. Und über diese NMOS Geschichten wird ja alles außen herum Richtung Discovery, Registration und Kontrolle im weitesten Sinne dann geregelt. Und diese Umsetzung die ist jetzt bei weitem nicht so aktiv wie ich mir das als Kunde wünschen würde. Das heißt wir haben im Labor immer noch so, dass wir nicht ein voll gemanagtes Netz haben, sondern dass das noch über IGMP sich selbst regelt. Also das ist einer der Punkte die ich ja vorher versucht habe anzusprechen, es gibt da verschiedene Philosophien. Lass ich den Switch machen was er will oder nehme ich die Intelligenz aus dem Switch heraus und manage ich das durch einen externen Controller. Und für einen großen Campus muss das meiner Meinung nach ein externer Controller sein. Da muss es so einen SDN Controller geben, so einen Layer der die Bandbreiten managet. Und da gibt es schon ein, zwei vielversprechende Produkte. Aber die scheitern dann eben wieder daran das sie eben in alle Geräte rein proprietäre Protokolle umsetzen müssen anstatt das die Hersteller eben diesem NMOS Standard folgen und eine relativ einfache Möglichkeit der Integration schaffen dadurch. Also das ist der, für mich der Haupthindernis gerade, dass die, dass es da so langsam voran geht. Ich glaube, dass da auch ein bisschen so Markenschutzgedanke mitspielt, nach dem Motto wenn wir da mal drinnen sind und wenn unser Produkt mit unserem Protokoll da drinnen ist, dann bleiben wir auch da drinnen ist, so wie das bisher auch war. Und das finde ich ziemlich schade. Und das ist auch schwierig das den Firmen beizubringen. Sind da schon deutlich in der Kommunikation aber es bewegt sich nur langsam. Die anderen Probleme im Labor sind mehr oder weniger so, dass wir natürlich immer wieder Geräte haben die wirklich Early Stage sind. Das heißt also die noch nicht fertig in der Entwicklung sind. Beziehungsweise wir machen das sogar anders herum, wir arbeiten mit verschiedenen Firmen zusammen mit denen wir abgesprochen haben das wir schon in der Beta Version oder teilweise noch früher mal Produkte bekommen zum Testen. Wo wir dann immer

121

Feedback geben, wo wir sagen, das ist schon super umgesetzt, das fehlt noch, wir würden uns wünschen für ein fertiges Produkt dass das und das Feature da noch mit reinkommt und da gibt es auch welche die das längerfristig mit uns machen, die da sehr froh sind um den Input. Und wir sind froh, dass wir dann eben die entsprechenden Geräte da auch im Labor haben. Und so, wie gesagt, es ging eigentlich ganz gut. Die ersten Erfolge waren recht schnell da. Aber es ist natürlich auch klar, dass so ein Labor nicht super skaliert. Also wir nutzen den Switch Backbone den wir da haben nicht annähernd aus weil wir einfach nicht genügend Geräte haben, beziehungsweise auch nicht das Budget dafür haben da jetzt riesig einzukaufen dafür. Sondern wir fokussieren uns natürlich auf die Punkte die wir unbedingt sehen, wo wir bestimmte Ideen verfolgen. Und da sind wir sehr stark in der Zusammenarbeit mit den verschiedenen Firmen. Bei den anderen haben wir generell den Ansatz, wir picken uns immer wieder einzelne Produkte raus. Als Beispiel: Ist der und der Multiviewer was, was wir in einer IP Umgebung einsetzen können? Würden wir den auf eine Shortlist setzen? Weil wir ja immer sehen müssen, wann fällt jetzt der Projektstart tatsächlich vom Himmel. Wann entscheidet es sich ob wir dieses All IP Playout beginnen oder bauen. Weil wir haben ja jetzt durch den, durch verschiedene Baumaßnahmen hier, müssen wir unser SDI Playout umziehen, und deswegen wahrscheinlich noch ein bisschen länger betreiben, weil durch den Umzug doch ein paar Investitionen nötig sind die natürlich auch erst wieder buchhalterisch abgearbeitet werden müssen.

17 Nachdem jetzt wie du gerade gesagt hast auch wieder Investitionen getätigt werden, nehme ich an, dass wenn dann der Umstieg erfolgt, das stückchenweise vonstatten geht. Also ich nehme nicht an, dass das komplette Haus auf einmal umgestellt wird, sondern, Hausnummer, Regieweise oder einmal Playout, dann einmal das. Wie ist da der Plan, wie sieht es da aus?

18 Der Plan ist, dass wir dort mehr oder weniger, nach den, wie soll ich das sagen. Also generell ist ja das Management sehr stark in Bewegung. ProSieben ist sehr stark in Bewegung mit verschiedenen Themen die die Firma so umtreiben. Es ist vom Ansatz her möglich dass wir das länger hinauszögern können, genauso wie es eine Entscheidung geben kann sobald der neue Campus fertig ist. Dass ein CTO, oder ein CEO an der Stelle sagt, also Leute da sind jetzt zwei schöne Datencenter und ich möchte jetzt da die neueste Technik drin haben. Und jetzt geh mal bitte. Und genauso ist es anders herum, wenn die Managemententscheidung an der Stelle ist, das passt jetzt alles so wie es ist. Dann wird es sich halt noch verzögern. Gefühlt wird es auf einen Mittelweg rauslaufen, wo man dann sagt, ja wir werden sicher das mit dem All-IP machen und vielleicht fangen

122

wir im Kleinen an wenn irgendwo ein Technologierefresh ansteht. Zum Beispiel bei den Pay-TV Sendern die wir jetzt so mit einem Channel-in-a- Box System fahren. Wo wir dann sagen, ja Ok, da gibt es schon eine ganz gute Lösung. Wenn das jetzt ansteht dann wird man das in IP machen, selbst wenn wir es hinterher wieder in SDI wandeln damit unsere bisherigen Verbreitungswege damit füttern können die noch Standard sind. Und anhand von dem macht man dann die ersten breiteren Erfahrungen im operativen Bereich und geht dann von dort wieder weiter und baut das dann aus. Ja, so würde ich es jetzt für den Playout Bereich sehen, die Kollegen in der Produktion würden es wahrscheinlich ähnlich machen. Ja, da müsste man dann auch mal kucken wenn da was ansteht, und man sagt ja, da gibt es jetzt ein neues Studio. Oder es ist ein bestimmter Satz an Technik, muss jetzt ersetzt werden, dann ist auch das Budget da um reine IP Kameras zu kaufen. Und dann kann ich anfangen, dass ich ein Studio aufbaue damit. Und dann werden wir uns da so in kleinen Stücken annähern. Ist für mich der wahrscheinlichste Ansatz. Es sind aber auch, es sind auch genau die anderen beiden Möglichkeiten da, je nachdem wie das Management entscheidet. Das kann ja von ganz oben reinregiert werden. So wie es beim TPC war. Ich will jetzt ein All-IP Haus haben. Dann laufen die da los und machen das. Oder eben auch genau das Gegenteil. Du hast irgendjemanden der sagt, Nö ist jetzt nicht so wichtig, das läuft doch alles und da will ich jetzt erstmal kein Geld dafür ausgeben.

19 Also ich bin jetzt mit meinen Hauptfragen eigentlich durch. Gibt es von deiner Seite irgendetwas zu diesem Thema das du unbedingt loswerden möchtest?

20 Also vielleicht noch ein Ding. Wir sind jetzt ein Haus was generell so ne Best of Breed Solution immer angehen würde. Das ist das was es auch noch mal komplizierter macht. Weil ich dann eben diese allgemeinen, oder eben in diese viele Schnittstellen hinein laufe. Es gibt ja immer wieder die Häuser die sich an einen der großen Hersteller binden. Ob das jetzt Imagine ist oder Grass Valley ist oder Evertz ist oder so. Und die halt einfach so One-Stop-Shop, alles bei einem einkaufen. Und innerhalb dieser Ein-Hersteller Welten kann man natürlich schon größere Lösungen aufbauen. Aber dann hab ich halt die ganzen Probleme die ich halt mit den Produkten dieser einzelnen Hersteller hab, und die passen vielleicht gar nicht in die Art wie ich arbeite. Ja dann hab ich halt eine Technik hergestellt, die geht und, aber die vielleicht gar nicht zum Haus passt. Genauso mit Virtualisierung, ist für mich ein Thema das noch ein bisschen zu sehr gehyped wird. Auch immer im Thema, im Zusammenhang dann mit IP. So mit, ja und wenn ich dann virtualisiert bin dann kann ich einfach schnell noch ein drittes Playout irgendwie hochfahren. Ja, kann ich. Geht

123

aber komplett an der Wirklichkeit vorbei. Von wegen Sendelizenzen die beantragt werden müssen und solchen Sachen. Es gibt bei uns rechtlich so und so viele Hindernisse dazu, dass man, dass wir bei uns eigentlich diese Popup Channels, die das Marketing da gerne herum trägt, die gibt es bei uns gar nicht. Und damit hängt auch direkt zusammen die Cloudthemen. Das würden wir schon in Betracht ziehen, allerdings nur für ein reines Disasterplayout zukünftig. Weil die Anforderungen an dem was da passiert, in Echtzeit unkomprimiertes Videohandling, das passt einfach nicht zu einer richtigen Virtualisierung. Weil wir jetzt schon sehen, dass die einzelnen Geräte immer noch kämpfen den nötigen Durchsatz auf die Netzwerkkarte zu bringen. Schon auf dedizierter Hardware. Und das ist für mich deswegen keine Lösung, noch keine Lösung, um das jetzt mit unkomprimiertem Video zu machen. Also Cloud ja, aber dann eben mit Komprimiert und für Disasterplayout.

21 Wenn wir gerade bei diesen Chancen und Möglichkeiten sind, wie sieht es mit Automatisierung aus? Glaubst du, dass damit mehr möglich ist mit IP als derzeit mit SDI?

22 In welchem Sinne?

23 Playout...

24 Ich mein klar, die Sendeautomatisierung, die haben wir ja sowieso. Unser Ansatz an der Stelle ist aber sowieso dass wir wahrscheinlich von dieser bisherigen, ich nenn sie mal so ne Dachautomation, eher weggehen würden. Also wie sie bei euch bei Pebble Beach ist, oder bei uns mit der ADC 100 von Imagine ist, sondern das wir versuchen würden eher in diese Channel-in-a-Box Systeme zu gehen, und dort hinein möglichst den gesamten Sendeweg in ein System rein zu integrieren. Das ist für uns eher der Weg. Wir haben mit den 25 Sendern im Moment ungefähr 4 unterschiedliche Ausprägungen von den Sendewegen. Also wir haben schon versucht die möglichst gleich zu machen. Sie sind aber nicht gleich. Ja, also es gibt einfach Sender, die haben eine Echtzeitgrafik im Main und im Backup. Es gibt Sender die haben eine Echtzeitgrafik nur im Main und einen Logoinserter im Backup. Und dann gibt es noch die ganz einfachen Varianten und nochmal was dazwischen. Und eins der Dinger ist, eines der Ziele wäre die alle gleich zu machen zukünftig. Also es gibt nur noch quasi einen Blueprint, und den vervielfältige ich nach verschiedenen, so viel Sender wie ich eben habe, ja.

25 (langes Schweigen)

26 Wer zu IP geht soll sich genau überlegen was er eigentlich will, ja. Und ich glaube der größte Fehler den man am Weg Richtung IP machen kann ist,

124

dass man in seiner SDI Denkwelt bleibt und versucht, das in IP abzubilden. Da wird man ganz viel Möglichkeiten verlieren. Ich glaube der besser Weg ist, zu sagen, was muss bei mir hinten passieren? Was will ich eigentlich gemacht haben? Und selbst wenn es diese Lösung so am Markt noch nicht gibt, wie kann ich die bauen, wie kann ich die bauen lassen, wie kann ich den Weg dahin gehen dahin zu kommen? Ja also, bin ich auch bereit meine Workflows vielleicht anzupassen, weil ich, nicht weil wir das immer so gemacht haben an der Stelle und dann muss ich das jetzt in IP auch so machen. Sondern halt überlegen, macht das an der Stelle überhaupt noch Sinn dass ich das so mache? Kann ich das nicht anders machen? Kann ich das nicht besser machen? Kann ich das nicht einfacher, schneller machen, billiger machen? Wenn ich schon IP bin weil ich irgendwie von überall Zugriff hab auf bestimmte Dinge. Also da kann man, ist glaub ich eines der grundlegenden Dinge wirklich, an dem Punkt zu sagen, darüber nachzudenken, wie will ich zukünftig arbeiten. Was muss ich wirklich haben? Dieser ganze Changeprozess ist natürlich enorm und mit auch der parallelen Einführung von einer neuen Technologie eine gewaltige Aufgabe, ja. Die eben auch ganz schön ermüdend sein kann weil die Begeisterung für neue Dinge und Dinge anders machen, hält sich im Allgemeinen gerade in größeren Firmen stark in Grenzen. Deswegen ist das sicher einer der Punkte die noch maßgeblich sind das man eben es möglich früh schafft alle dafür zu begeistern und sich zu überlegen wo man da hin will und gemeinsam an dem Weg dahin auch zu arbeiten. Selbst wenn man nicht genau weiß wo man hinten raus kommt. Weil das ist einfach noch zu neu. Und ich glaub da kommen noch ganz viele tolle Dinge die man halt erst sieht wenn man diesen Schritt gegangen ist. Und an Herausforderungen hatte ich ja schon gesagt, also alles unter 2110 ist noch in größerer Entwicklung. Das heißt also, die Produkte ändern sich stark. Es gibt wenig Produkte. Es gibt wenig Alternativen. Manchmal sind die Produkte wirklich noch Beta oder schlimmer. Der Standard entwickelt sich noch. Ich hab so ein bisschen die Angst, dass NMOS nur ein Standard bleiben wird aber sich nicht im Markt durchsetzt und dann mit den schon geschilderten Problemen dann. Es ist jetzt in den Zeiten von 2110, die Marketing und Verkaufsversprechen gegenüber dem was an tatsächlichen Funktionen und Systemen dann verfügbar ist, diese Kluft war glaube ich nie größer. Das ist echt schwierig. Ich glaube, dass die, diese Lücke die Broadcasthersteller, also wenn man jetzt IT Sicherheit, sollte man von vornherein mitbedenken wenn man ein Produkt macht. Also nicht eine Lösung bauen und nachher versuchen das sicher zu machen, sondern, ich glaube Projekte in dem Maße können nur erfolgreich sein wenn IT Security von Anfang an mitgedacht wird. Und das ist halt gerade für die Broadcasthersteller die bisher so auf der Insel der Glückseligen gelebt

125

haben und sich um IT Sicherheit überhaupt nicht gekümmert haben auch wirklich schwierig das entsprechend da in die Köpfe zu kriegen. Die schlagen immer noch die Hände überm Kopf zusammen wenn es darum geht zu sagen, ja klar das Ding kann auf einem Server laufen, aber dann, die lokale Firewall ist An und der Virenscanner läuft auch. Und das Ding läuft nicht unter einem Admin, unter einem lokalen. Dann steigen im Moment schon mal 90% aller Firmen aus. Und das ist halt das was da auch noch gelernt werden muss. Ich hab das Thema, wenn ich einen größeren Campus habe, was noch ungelöst ist, wie ich diese Millionen von IP Multicast Adressen manage. Weil ich hab ja für jeden Stream den ich da herumschicke mit 2110 mal mindestens 3 Ausprägungen. Also Video, mindestens 1 Audio dazu und mindestens 1 Metadatenstrom dazu. Die ich alle irgendwie managen und verwalten muss. Die muss ich vergeben. Und das ist ja jetzt das kleinste Setup. Ja also, beim TPC, die haben in ihrem Ü- Wagen, die haben zu jedem Video haben die 20 einzelne Audiostreams, oder sogar 32 einzelne Audiostreams und nochmal ein paar Metadatenstreams. Die haben also so ein Set von 30-40 einzelnen Streams für 1 Signal. Ein SDI-Signal sozusagen. Und wenn ich das auf den Campus hochrechne, und das verwalten muss? Und da fehlt noch, die Tools dafür, ja. Ich hab durch die schnelle Entwicklung die da in der Technologie gerade passiert, ich nehme mal das Wort Disruption da schon in den Mund, ist natürlich auch immer die Gefahr gegeben, dass ich mich für ein falsches Produkt oder für einen falschen Standard entscheide. Die Technologie entwickelt sich so schnell, dass wenn ich an einem bestimmten Punkt eine Entscheidung treffen muss, dann treffe ich die vielleicht durchaus vernünftig. Aber ich hab dann doch das falsche gekauft weil ein Jahr später irgendwo der Markt irgendwo anders abgebogen ist und dieser Bereich nicht mehr weiterentwickelt wird. Das gilt natürlich auch genauso für die Hersteller, ja. Nicht alles was die bauen gerade ist richtig futureproof. Da gibt es immer wieder diese proprietären Ansätze die da mit herein spielen und ob sich das dann durchsetzt oder nicht durchsetzt, das muss sich dann zeigen, ja. Genauso spielt gerade im Markt eine riesige Konsolidation statt. Ständig werden Firmen aufgekauft und miteinander integriert. Und dann ist natürlich auch wieder die Frage, ist das Produkt das ich mir jetzt gerade ausgesucht habe, überlebt das überhaupt? Ja, diesen Merge? Ja, da kann man schon viel falsch machen ohne dass man das tatsächlich steuern kann. Ja einfach, ich hab mir eine Firma ausgesucht und die wird gekauft und dann wird das Produkt eingestellt. So, hm.

27 Und, was hab ich noch? Ja also die Experten brauchen ein komplett neues Skillset. Das ist eben gerade auch schwierig bis unmöglich einzukaufen.

28 Gut. Dann würde ich dich zum Schluss einfach nochmal bitten, ganz kurz

126

zusammen zu fassen, wie der derzeitige Stand bei euch im Haus ist und woran gerade gearbeitet wird.

29 Aktuell konzentrieren wir uns darauf die kurz angesprochene Lösung voranzutreiben, dass wir ein Channel in a Box System haben, das die gesamten Funktionalitäten eines Sendeweges abdeckt. Also nicht nur eine normale Channel in a Box Grafik, sondern dass da ein Echtzeitgrafiksystem tatsächlich mit im Sendeweg ist. Als echte Engine, nicht nur als Fill und Key eingefügt wird. Das dort über Softwareplugins R128 Normalisierung und Dolby Encoding gemacht wird. Und dass wir auf diese Art den angesprochenen Blueprint fertig machen. Weil wir eben am Ende, wenn wir in ein Projekt gehen würden, dann dieses Ding als Lastenheftvorlage mehr oder weniger schon fertig haben wollen. Weil wir nicht an ein großes Systemhaus gehen würden und sagen würden, könnt ihr uns bitte einen All- IP Campus bauen. Oder könnt ihr uns bitte ein All-IP Playout bauen. Sondern das was wir gerade machen ist, wir picken uns durch diese einzelnen Produkttests die Bausteine zusammen mit denen wir später dann an den Start gehen wollen. Also wir identifizieren jetzt schon die einzelnen Produkte die für uns in Frage kommen. Das ist ein laufender Prozess, da kann sich durchaus auch mal ein Produkt ändern. Aber dass wir uns mehr oder weniger im Groben schon im Klaren sind, zum jetzigen Zeitpunkt würden wir ein Setup aus diesen Systemen nehmen und für uns aufbauen wollen. Ja, also das ist der Stand an dem wir sind. Also wir arbeiten hart an dieser Erstellung von diesem Blueprint "Alles in einer Box". Und auch die Systeme außen rum die dazu nötig sind, das geht von Messgeräten, Abhöre, der Switchinfrastruktur und den ganzen Themen, diesen ganzen Block eben rum. Dass wir am Ende dann sagen können, hier, das ist das was wir wollen und die Aufgabe an das Systemhaus ist an der Stelle quasi nur, das dann so hoch zu skalieren, dass das für unsere 25 Sender dann auch funktionieren kann. Das ist der Ansatz den wir gehen.

30 Gut. Alles klar. Dann bedanke ich mich herzlich.

31 Gerne.

127

C. Interview Philipp Beuchert

1 Herzlichen Dank für deine Zeit und ich würde dich für den Anfang bitten deine aktuelle Position und deinen Aufgabenbereich vorzustellen.

2 Aktuelle Position ist Leitung Broadcast and Production Systems, das beinhaltet die gesamte technische Zurverfügungstellung von dem gesamten Workflow von der Produktionsseite über Postproduktion bis hin zum Playout. Umfasst quasi eigentlich die gesamte Videobroadcasttechnik im Studio- und Regiebereich. Also von Studiokameras über den gesamten Bildmischer/Videoserverbereich in der Regie. Gesamte Postproduktion wie Schnittplätze, VJ-Selbstschnittplätze aber auch die technische Grundkompetenz bei der Grafik. Alle Systeme im Hintergrund, jetzt eben das neu eingeführte Media Asset Management System, bis hin in das Playout, wo das Playout derzeit für vier Sender österreichweit stattfindet.

3 Welchen Bezug hast du zum Thema IP oder Implementierung von IP- Technologien?

4 Leider noch nicht so viel. Bezug zu IP ist bis jetzt eigentlich ein rein theoretischer Bezug. Wir wollten letztes Jahr ein erstes IP-Testsystem aufbauen, da haben wir einmal darüber gesprochen und haben uns dann eigentlich aufgrund von Projekten die ungeplanter Weise gekommen sind, haben wir das Thema verschieben müssen, wollten es dieses Jahr nochmal angehen. Steht jetzt eigentlich immer noch an für Herbst, dass wir mal anfangen eine kleine erste Testinfrastruktur aufzubauen, dass wir einfach alle ein bisschen mehr praktische Erfahrung bekommen und einfach einmal ein Gefühl für das Thema IP generell bekommen. Das heißt, so wirkliche Erfahrung hab ich noch keine, außer eben was man in Büchern und Fachzeitschriften liest und hört.

5 Also IP generell oder auch speziell auf SMPTE 2110 oder SMPTE 2022 und NDI und alles was es gibt?

6 Also ich wollte gerade sagen, Standard dahinter ist sich verstärkt in den letzten Monaten auf SMPTE 2110 eingeschossen worden. Aber ich meine jetzt generell allgemein IP-Videoübertragung.

7 Du bist ja schon ein bisschen in dem Thema drinnen. Wo siehst du die Vorteile von IP gegenüber SDI?

8 Vorteile von IP gegenüber SDI. Auf jeden Fall in der Flexibilität in der Zukunft, wo man sicherlich viel mehr... sagen wir mal so, es wird einfach eine komplett neue Denke notwendig sein. Ich glaub dieses klassische Broadcasterdenken das wir oder ich derzeit noch haben, sozusagen diese

128

gesamte Kette von einem auf den nächsten auf den nächsten zu einem Vervielfältiger und so weiter, wird es in Zukunft so nicht mehr spielen. Sondern, da ist einfach die gesamte Grunddenke anders weil du einfach viel mehr mit Multicast arbeiten kannst, du bist viel erweiterbarer was deine ganzen Grundsysteme angeht. Das ist glaub ich einer der Hauptvorteile von IP. Natürlich alles wenn man dann in Richtung Produkte schaut, Cloud- Playout ist gerade eines der Schlagworte gerade im Playoutbereich das natürlich in den nächsten Jahren verstärkt kommen wird, was jetzt auch schon da ist, was sicher ein Thema ist das spannend wird. Sonstige Vorteile... SDI könnte ich dir ein paar Vorteile sagen (lacht).

9 Ja bitte, gerne.

10 Also aus meiner Sicht jetzt noch die Vorteile, weil es halt einfach Nachteile auf der IP Seite sind. Du hast bei SDI logischerweise extrem viel Erfahrung und Wissen. Den Standard gibt es seit fast 30 Jahren oder mehr als 30 Jahren mittlerweile. Wo du natürlich gerade auch in der Anfangszeit sehr viele Kinderkrankheiten hattest die du jetzt wahrscheinlich auf der IP Seite hast, ähnlich aber halt doch anders. Und da ist einfach extrem viel, natürlich, Erfahrung da, extrem viel Grundwissen da, extrem viel Fachwissen bei den einzelnen Mitarbeitern da. Vorteil ist, bei SDI ist es mittlerweile so, es ist quasi einfach ein Plug-and-Play, mittlerweile unterstützen fast alle Systeme das Ding. Du steckst an und wenn das Kabel halbwegs passt dann kommt ein Bild hinten raus. Messtechnisch ist es dann natürlich immer noch was anderes aber im Großteil ist es ein Plug- and-Play. Du hast derzeit auch nur, weil du vorhin die verschiedenen Standards angesprochen hast, du hast derzeit nur einen Standard quasi. Das sind mal die Punkte die aus der Sicht sind. Und die Stabilität ist halt ein Punkt. Es ist halt, wie gesagt, wir haben jetzt mit IP noch nicht so wahnsinnig viel Erfahrung aber gerade was IP angeht ist SDI extrem stabil. Aber sicher hängt das natürlich auch damit zusammen weil da sehr, sehr viel Wissen da ist über das Thema. Und da es ein 30 Jahre alter Standard ist, der mittlerweile mehr als auserprobt, ausdefiniert ist, ja, deswegen ist es relativ einfach. Wird wahrscheinlich mit IP in 10 Jahren auch so sein.

11 Weil du vorhin die verschiedenen Bereiche angesprochen hast. Studiobetrieb, Playout, etc. Wo glaubst du wird sich IP am ehesten, oder am einfachsten durchsetzen?

12 Also wo es sich schon teilweise durchgesetzt hat in der Produktion ist in der Remote-Produktion, ist sicher ein Thema, wo es teilweise jetzt schon zum Einsatz kommt. Zwar verstärkt noch mit IP-SDI-Gateways auf der Eingangsseite, aber das ist halt jetzt noch weil einfach die meisten Häuser einfach noch auf Baseband verkabelt sind. Das ist glaub ich einer der

129

Einsatzzwecke wo es extrem viel Potential bietet. Vor allem wenn du dann komplette IP Häuser hast und dann wirklich per Knopfdruck sozusagen auf die externen Produktionsumgebungen zugreifen kannst. Wo wird es noch großen Einfluss haben? Eh auch schon was ich vorhin kurz angesprochen habe, Playout, alles was in Richtung Cloud-Playout geht, da ist es ja auch schon da. Wo es aus meiner Sicht einfach noch dauert ist generell in der Studio-Inhouse Produktion oder generell in der Inhouse Verkabelung. Es gibt zwar jetzt die ersten Firmen die auch schon bestehende Infrastruktur teilweise umbauen aber bis jetzt war es halt eher, wenn du neu baust dann baust du auf IP oder planst einfach auf IP Großteils. Aber aus meiner Sicht geh ich jetzt nicht her und reiß die SDI Verkabelung aktiv heraus und bau mir ein IP Haus auf, derzeit. Ja, Virtualisierung, aber das hängt mit Cloud- Playout zusammen, ist sicher ein spannendes Thema. Weil du dann auch wieder diese Flexibilität wieder die ich vorhin angesprochen habe einfach gewinnst. Was auch ein extremer Vorteil von IP ist vielleicht noch, du hast quasi mehr Controlling über das gesamte System. Jetzt quasi nicht nur, ist der Stream da, sondern auch inhaltlich. Welche Bandbreite, vielleicht Fehlererkennung, das sind natürlich alles Sachen die du deutlich intensiver nutzen kannst als bei SDI.

13 Weil du gerade die Bandbreite angesprochen hast. Glaubst du wird es da Herausforderungen geben was da den Wechsel angeht? Herauszufinden wo die Grenzen sind, bandbreitenmäßig?

14 Gute Frage, Ja, wird sicher eine Herausforderung werden gewissermaßen. Ich sehe die größere Herausforderung nicht in der Bandbreite sondern eher im Timing. Gerade wenn man SMPTE 2110 anspricht ist das natürlich eine extrem wichtige Komponente. Derzeit ist bei uns im Haus ein bisschen vernachlässigt worden. Geht bei SMPTE 2110, was ich halt gelesen habe, genau gar nicht mehr. Da wirst du quasi für jeden Timingfehler und wenn es noch so ungenau ist relativ schnell ziemlich stark bestraft. Das heißt das du dann Bild/Ton Asynchronität hast, Metadaten verlierst, etc. Also ich glaube das ist eine ziemlich große Herausforderung. Bandbreite sicher auch, kann ich aber jetzt aus meiner Sicht noch nicht so viel dazu sagen. Ich glaube was auch eine große Herausforderung ist bei dem Thema, ist das ganze Management dahinter. Ich glaube da wird das ganze Thema Dokumentation auch noch mal auf ein nächstes Level gehoben. Gerade was man hört, die ersten Ü-Wägen mit keine Ahnung wie viel hunderttausend IP-Adressen von den jeweiligen Einzelgeräten, einzelnen Streams, etc. Also ohne vernünftige Dokumentation geht auch jetzt schon nichts mehr, aber ist natürlich dann nochmal um ein vielfaches wichtiger. Das man einfach diese Menge der IP-Adressen haushalten kann und natürlich ein großes Thema ist generell die Netzwerktopologie. Netzwerk ist

130

zwar in den letzten Jahren auf der Broadcastseite auch immer wichtiger geworden aber bei den klassischen Broadcastern fehlt halt einfach noch dieses Netzwerkwissen. Deswegen ist da dieser wichtiger Schritt das man die Netzwerker in den Broadcastbereich holt oder die Broadcaster im Netzwerkbereich ausbildet. Und das ist sicher noch eine Herausforderung für die nächsten Jahre, das man dieses Wissen über Netzwerktopologien und den richtigen Aufbau et cetera herausfindet.

15 Also du siehst eher keine technischen Schwierigkeiten, sondern...

16 Ich sehe es jetzt eher noch organisatorische Probleme sag ich jetzt mal. Weil ich die technischen einfach noch nicht kenne. Das ist ein bisschen so der Fall. Wir haben einfach noch keine Erfahrung, noch keine Berührungspunkte, deswegen kann ich jetzt noch nicht so vom Technischen reden, außer die man halt jetzt quasi liest. Aus meiner Sicht, ich hab jetzt im Moment bisschen mehr Respekt unter Anführungsstrichen vor den ganzen operativen Themen die auf einen zukommen. Gerade wenn ich es aus Planungsseite aus sehe, weil ich vielleicht einfach noch zu wenig Wissen über dieses Thema habe. Deswegen ist da der Respekt noch da. Technisch wird es mehr als genug Hürden geben, vor allem dieser Mischbetrieb ist sicher ein schwieriges Thema. Ich kann mir vorstellen wenn ich jetzt wirklich auf der grünen Wiese plane und entsprechend alles nur noch IP mache, gibt es auch schon mehr als genug Herausforderungen aber ich glaube dieser parallel aufbauende Mischbetrieb, das wird eine technische Herausforderung. Das man da neben der Funktion quasi auch die Sendesicherheit gewährleisten muss, das ist sicher was. Und einfach, dass die Systeme zuverlässig laufen. Ist wieder Thema Stabilität.

17 Was würde es brauchen damit der Umstieg vor allem im deutschsprachigen Raum vielleicht ein bisschen besser gestaltet werden kann? Bessere Informationsveranstaltungen, irgendwelche Get-Togethers von Herstellern?

18 Gibt es in letzter Zeit eh schon öfters, immer mehr Hersteller die quasi ihre, natürlich mit Fokus auf ihre eigenen Produkte logischerweise, da quasi verstärkt an die Systemhäuser, Broadcaster herantreten. Also auf den letzten IBCs die letzten Jahre war das natürlich immer ein großes Thema. Was vor allem spannend war, die letzten Jahre hat man einfach gesehen, was sie früher sehr viel in der Theorie erklärt haben, verkauft haben, fließt mittlerweile in die ersten Produkte ein oder mittlerweile auch schon in relativ viele. Das ist natürlich ein spannendes Thema. Was braucht man? Also ja, sicher mehr Abstimmungen vor allem im Standardisierungsbereich. Mehr Get-Togethers, ja. Wie gesagt wir waren bis jetzt in noch keinem aktiv

131

mit dabei weil wir, ich mein einerseits ein relativ kleines Haus sind, aber andererseits sieht man es aus vielen anderen Bereichen wo wir mit dabei sind, du lernst natürlich auf so einem 2 bis 3-tägigen Workshop, nimmst du natürlich viel mehr praktische Erfahrungen von anderen Herstellern, von anderen Systemhäusern, andern Broadcastern mit. Also ich glaub so etwas ist sicher nicht so schlecht wenn das verstärkt wird. Auch, ich sag mal, der Kundenaustausch, jetzt quasi nicht nur von Herstellerseite sondern wirklich wenn die Kunden miteinander reden.

19 Wie etwa denkst du wird die Situation in etwa 5 bis 10 Jahren einerseits bei dir im Haus aussehen oder im größeren deutschsprachigen Raum oder ich sag jetzt mal Europa?

20 Da find ich ist ein relativ großer Unterschied, weil ich sag mal in den nächsten 5 Jahren, tut sich wahrscheinlich nicht so wahnsinnig viel. Technik die wir in den nächsten 5 Jahren einsetzen werden kaufen wir heute, sozusagen. Und da wir einfach noch fast alles eben auf SDI, oder alles auf SDI verkabelt sind, kaufen wir derzeit nur SDI Systeme. Viele davon sind schon IP tauglich, aber ich sehe es dann eher erst beim nächsten Investitionszyklus, sozusagen für dann in 10 Jahren. Weil die Sachen kaufen wir in 5 Jahren. Und da schaut natürlich dann die Sache schon anders aus. Unser Haus ist jetzt quasi 10 Jahre alt, nein jetzt gerade 8 Jahre, 2022 sind wir dann 10 Jahre alt. Wo es dann eben Zeit wird die ersten Core Systeme abzulösen, wo es dann eben Thema wird teilweise die Verkabelungen zu erneuern, etc. Und da ist dann eben spannend, was ist in 2 Jahren, in welche Systeme investieren wir dann. Und das sind dann die Systeme die 5 bis 7 Jahre im Einsatz sind. Also ich glaube, jetzt ist der Wechsel in den nächsten 5 bis 10 Jahren extrem stark. Wie die Situation aussehen wird, ja also aus meiner Sicht werden jetzt alle die quasi jetzt sozusagen neu bauen wie ORF, TPC sind in 5 Jahren die ersten Vorreiter auf dem Gebiet, dann schon mit 2, 3 Jahren Erfahrung. Und in 10 Jahren werden die meisten Großen schon umgestellt haben, zumindest den Core Betrieb aus meiner Sicht. Und die kleineren wie wir werden vereinzelte Bereiche die wir eingebunden haben hier auch nachziehen. Wobei das ist jetzt eher die Systeminfrastruktur aus meiner Sicht. Wenn man jetzt in einen anderen Bereich schaut wie Cloud-Playout et cetera wird das ganze schneller gehen.

21 Kann man derzeit aus deiner Sicht schon irgendetwas beachten um den späteren Umstieg vielleicht ein bisschen einfacher zu gestalten?

22 Wie gesagt auch da fehlt mir noch die Erfahrung aber ich glaube genau das ist das Wichtige, das wir jetzt in unserem Fall, und wenn es nur eine kleine Mini-Testumgebung ist, das wir einfach jetzt schon vielleicht die erste

132

kleine Produktionskette aufbauen, die ersten Systeme anschaffen, die ersten Messgeräte anschauen. Das wir einfach jetzt ein Gefühl bekommen, wie geht das, wie kann ich damit umgehen, was sind mögliche Fehler. Das wir da schon von Anfang an mit dabei sind. Ich glaube das ist ein Punkt wo man es sicher vereinfachen kann. Wenn ich sag, die Leute haben jetzt schon ein bisschen Erfahrung und nicht erst wenn wir sagen, OK wir machen jetzt in 3,4 Jahren etwas und dann stehen sie sozusagen vor einem neuen Pferd. So dass man jetzt schon ein bisschen ein Gefühl dafür bekommt, wie verhält sich das. Also ich glaube da sind wir vielleicht eher schon zu spät was die ganze Testumgebung angeht, aber ja, Ziel wäre es diesen Herbst, mal schauen ob uns da Corona jetzt nicht noch einen Strich durch die Rechnung macht.

23 Gut, also grundsätzlich war es das. Hast du noch irgendwelche Anmerkungen oder Ergänzungen die du noch loswerden möchtest die jetzt nicht vorgekommen sind?

24 Vielleicht einfach nochmal das Thema Netzwerk weil es einfach extrem wichtig ist. Wo ich einfach merk, wenn ich mit den Netzwerkkollegen plaudere, dann ist es natürlich immer so, weil wir jetzt vorher über die Kreuzschiene gesprochen haben, wie lange halten die Core-Systeme dann? Ich höre halt immer von den Netzwerkern, einen guten Switch solltest du alle 3 bis 5 Jahre tauschen. Und da ist halt immer der Fall wo ich sage, Ja ist schon richtig, ich meine unsere Kreuzschiene wird jetzt bald 10 Jahre alt und die werden wir auch irgendwann tauschen, aber wenn ich jetzt davon ausgehe weil die IT halt alle 3 bis 5 Jahre ihre Core-Systeme komplett austauscht, ist das sicher ein Thema was einfach von Investitionsseite noch spannend wird. Weil ich auf Investitionsseite auch einfach noch überhaupt keine Ahnung habe derzeit in welche Richtung es geht. Im Grunde sollte es mittelfristig günstiger werden, aber ich glaube gerade jetzt der erste Schritt ist noch relativ teuer, weil es eben eine neue Technologie ist im Vergleich zu SDI. Wo einfach alles erprobt ist und die Dinger mittlerweile nichts mehr kosten unter Anführungsstrichen. Also eine SDI Schnittstelle kostet ja defacto nichts mehr im Vergleich wenn du jetzt in Richtung IP schaust wo natürlich sehr viel Forschung, sehr viel Entwicklung hineingeflossen ist, das wollen sich die Hersteller natürlich alles zahlen lassen logischerweise. Ich glaube das ist sicher noch ein Anfangsschritt. Sonst noch Punkte die ich loswerden möchte... Ja eben eh schon was ich vorher schon angesprochen habe, die Denke von klassischen Broadcastern muss sich quasi ändern. Also wie ich ein System designe, wie ich es aufbaue. Wir müssen extrem viele neue Kenntnisse lernen, extrem viel neue Tools lernen. Tools sind immer mehr erforderlich Richtung Software. Sonst fällt mir eigentlich jetzt nichts mehr ein.

133

25 Gut. Dann Vielen Dank.

26 Bitteschön.

134

D. Interview Sandro Furter

1 Ich möchte mich erstmal herzlich dafür bedanken, dass du dir die Zeit nimmst und für den Anfang deine aktuelle Position und deinen Aufgabenbereich vorzustellen.

2 Ich bin als Projektleiter engagiert im Projekt Metechno, das ist auch der Projektname wie es sich nennt, in der Abteilung SRF Operationen. Wir sind eine Abteilung von rund 25 Projektleitern die sich um eigentlich sämtliche Projekte kümmern die mit irgendwelchen technischen Dingen zu tun haben. Im Projekt Metechno selbst bin ich Detailprojektleiter vom Baustein 0, nennt sich dieses Teilprojekt. Wir kümmern uns um die gesamten zentralen Dienste, die 2110 Umgebung, die Netzwerkarchitekturen, die Security Themen, eigentlich alles was sich so im Bereich IP abspielt. Aber es hat auch noch einen zweiten Teil. Alle weiteren zentralen Dienste wie KVM, Multiviewer, virtuelle Server, Clients, also einfach alles was, wo jedes Teilprojekt irgendwas davon nutzen kann. Aber der Schwerpunkt ist ganz klar im Bereich 2110, wo ich ein Team von rund 15 Spezialisten leite die sich wiederum bis hin zum Support und Implementierung leiten. Daneben bin ich noch Leiter der Fachcommunity IP innerhalb des SRF und SRG, auch teilweise mit den Kollegen aus den restlichen Sprachregionen, wo wir im Bereich IP uns regelmäßig abgleichen, auch Architekturthemen diskutieren damit wir im Gesamtunternehmen eine möglichst breite Durchdringung des Themas IP haben. Und beim Projekt Metechno, ein bisschen vorher, war ich involviert im Bau des Projekts UHD-1, das ist unser erstes 2110 Projekt gewesen. Das ist ein Ü-Wagen, ein relativ großes Ding, 24 Kameras, doppelseitig ausfahrbares Chassis, auch dort komplett auf 2110 gebaut, rund seit eineinhalb Jahren in Betrieb. Das ist eigentlich so unser erstes Projekt in 2110 gewesen wo wir auch wirklich im Feld damit aktiv produzieren und nicht die Nerdtruppe vor Ort haben, also nicht die Supercracks, sondern eigentlich wirklich das Tagesbetriebspersonal im Feld dann damit Sendungen produziert. Das sind so die Projekte wo ich im Moment tätig bin, die für dich im Fokus liegen.

3 Das heißt du hast schon langjährige Erfahrung mit der Implementierung von IP.

4 Ja, ich bin auch in der SMPTE Drafting Group mit dabei, die SMPTE 2110 Standards geschrieben haben oder immer noch daran sind für die nächsten Standards zu entwickeln. Wir sind Member von AIMS, wo ich auch Delegierter bin, also auch ein bisschen in dieses Standardisierungsgremien, AMWA, was sich da alles noch rumschlägt.

135

5 Sehr gut. Dann würde ich dich ganz allgemein bitten für dich zu erklären was die Vorteile von IP gegenüber SDI sind. Gern auch schon speziell von 2110 gegenüber SDI.

6 Ist immer schwierig, da gibt es so viele verschiedene Möglichkeiten das als Vorteil zu machen, weil du kannst ganz vieler dieser Vorteile auch in SDI haben. Es ist immer die Frage was du implementierst. So der klassische Vorteil den wir immer wieder nennen und den ich aber persönlich sehr schwierig finde einfach so aufzuführen ist, man ist flexibler mit IP. Das tönt immer so schön, das ist so wunderbar für das Management, mit IP sind wir flexibler. Ich finde es persönlich schwierig das zu sagen weil du auch mit SDI eine hohe Flexibilität hinbekommst. Ich persönlich finde die Formatagnostik sehr interessant in IP, das ist eine zukunftsweisende Technologie im Sinne von; du musst heute nicht wissen was du morgen auf deinem IP Netz transportieren wirst. Gerade in der schnelllebigen Zeit, wir reden von UHD, von HDR, von 8K Tests, das sind alles Technologien die du auf einem klassischen BNC-Kabel, Koaxkabel in SDI nicht realisieren kannst. Das ist sicher für mich persönlich einer der Vorteile. Ein zweiter Vorteil, der ist ein bisschen spezifischer jetzt bei uns als Schweiz, weil wir 4 Landessprachen haben plus viele Filme noch in Englisch. Für uns ist das Thema Audio in IP eigentlich eines der größten Vorteile. Wir haben eine sehr große Dynamik im Audio die möglich ist. Im SDI hast du einfach 16 Embedded Audiokanäle und dann musst du damit klarkommen. Die routest du auch immer an das gleiche Ohr, du musst sie embedden, de-embedden, all diese Workflows sind in IP wesentlich einfacher. Nein, ich will nicht sagen einfacher. Sie sind flexibler möglich, einfacher sind sie definitiv nicht weil die Komplexität im Audio nimmt gerade bei unserer Umsetzung zu, aber du hast eine viel größere Flexibilität und Vielfalt die du mit deinem Audiorouting machen kannst. Und dann sicher, bewegst du dich in einer IP- Welt, das kann sowohl Fluch wie auch Segen sein. Du hast mit neuen Playern zu tun die vielleicht nicht immer dein Business verstehen. Auf der anderen Seite kannst du in der Produktvielfalt aus dem Vollen schöpfen, plus minus. Es heißt immer Common-of-the-shelf, du kannst einen COTS- Switch nehmen. Wir haben mal gesagt du kannst einen 2110 COTS-Switch nehmen weil du dann doch relativ bald einmal Anforderungen hast an so eine Hardwarekiste die doch 2, 3 spezifische Funktionen benötigt. Stichwort PTP, Multicast, hohe Bandbreiten, etc. Und ein Learning das wir im Projekt gemacht haben der ein riesen Vorteil ist, ist die Geschwindigkeit von der Umsetzung. Also wir haben noch nie ein Projekt in der Größenordnung gebaut bei dem wir in der Geschwindigkeit eine Basisinfrastruktur gemacht haben. Wenn du dir vorstellst, du musst einfach noch 2, 3 Glasfaserkabel ziehen und dann hast du deinen Backbone gemacht, wenn du einen neuen Standort beschließen willst, kommt dort

136

einfach ein Switch hin und 2, 3 Kabel dorthin und schon hast du irgendwie 100 Signale verfügbar. Da haben wir einen massiven Mehrwert, und auch Geld gespart in der Implementierungszeit. Das sind so die 3, 4 Punkte wo wir uns eigentlich viele Vorteile damit erschaffen haben.

7 In die andere Richtung gefragt, gibt es Bereiche wo du sagst, in diesem Bereich würde ich heutzutage noch überhaupt nicht IP einsetzen, sondern noch 100% SDI?

8 Ja. Je kleiner die Umgebung ist desto eher würde ich auf andere Technologien setzen. Ganz konkret fängt es beim Ü-Wagen an. Einen ganz kleine Ü-Wagen in IP zu bauen ist machbar, ist finanziell eine Herausforderungen. Wir haben es durchgerechnet, es ist unserer Meinung etwas teurer als eine SDI-Verkabelung. Es gibt dir aber aus unserer Sicht keinen großen Vorteil einen kleinen Ü-Wagen, solange der nicht UHD, 4K, HD, was auch immer, flexibel von heute auf morgen umstellen kann, ist das sicher der falsche Ort. Dann ist halt die Frage, wann wirst du wie orchestrieren? Wenn du einfach nur den technologischen Standard ansiehst und sagst, soll ich ein kleines Radioregionalstudio in IP oder in anderen Technologien bauen? Solang du das nicht komplex in dein Ökosystem integrieren musst, kannst du das problemlos statisch in IP bauen, ist dann kostenmäßig nicht so ein Thema. Wenn es dann aber dann darum geht dass das Ding noch in die Cloud kommunizieren muss, Securitythemen dazukommen, dann stellt sich bei kleinen Systemen für mich schon die Frage ob 2110 dann der richtige Standard ist und ob dann halt nicht Dante nimmst oder was es da noch alles für andere Möglichkeiten gibt.

9 Weil du vorhin schon die COTS angesprochen hast. Gibt es für dich wirtschaftliche Herausforderungen, bezogen auf laufende Kosten, die anders sind... ?

10 Ja, die Abschreibedauer. Es ist ganz klar dass du einen Switch in einer gewissen Größenordnung, seien es modulare Chassis für Spines oder so, dass du die nicht mehr gleich lange am laufen lassen kannst mit einem guten Supportvertrag dahinter damit du die auch in 8 Jahren noch betreiben kannst. Und das ist halt nun mal so, eine SDI-Kreuzschiene die lebt bei uns auch mal 8 Jahre, oder vielleicht auch 10 Jahre wenn es sein muss. Das kannst du bei einem Netzwerkswitch ganz sicher vergessen, das geht nicht, und das ist finanziell eine gewisse Herausforderung.

11 Kannst du generell einmal erklären wie euer derzeitiges Projekt 2110 mäßig aussieht? Und woran ihr gerade arbeitet.

137

12 Ja, im Moment arbeiten wir an der Abnahme, also wir gehen Live in eineinhalb, zwei Monaten. Wir gehen sehr gestaffelt Live, also bei diesem Projekt da kannst du nicht alles auf einmal umstellen. Wir gehen mit 2, 3 Systemen, Postproduktion, Newsroom für Sport gehen wir OnAir. Sag mir noch einmal vielleicht ein bisschen spezifischer was du wissen willst, weil bei der Frage kann ich dir jetzt ganz viel darüber erzählen. (lacht)

13 Dann mach ich es anders. Auf welche Herausforderungen seid ihr bei dem Wechsel gestoßen, beziehungsweise bei der Planung von 2110?

14 Ich meine wir waren sehr früh dran. Wir haben uns für 2110 entschieden als es den Standort noch gar nicht gab. Wir hatten dort den Vorteil, dass wir im Standardisierungsgremium mit dabei waren, das wir ein bisschen mehr unter die Haube sehen konnten wie weit der Standard wirklich ist. Das war auch sehr wertvoll. Wir haben die Grabenkämpfe zwischen den einzelnen Herstellern die auch in dem Standardisierungsgremium dabei waren, konnten wir natürlich von innen beurteilen. Dementsprechend auch ein bisschen mehr das Risiko einschätzen. Wir waren sehr, sehr früh dran mit der Implementierung. Die hat vor rund 3 Jahren begonnen, da war noch nicht 2110 auf der NAB groß Thema. Es gab da so Gespräche, da gibt es doch irgendwas IP-mäßiges und so. Das war für uns auf der einen Seite eine große Herausforderung, das Knowhow hinzubekommen. Wir sind gestartet mit 3, oder wir waren zu dritt als wir mit IP uns einmal Knowhow aufgebaut haben. Das war der CTO der das von Anfang an unterstützt hat und auch mit der Idee kam IP zu bauen, und wir hatten sehr starken Managementsupport, auch heute noch. Die Herausforderung war eigentlich die Technologie zu verstehen, die Hersteller auch zu challengen schlussendlich. Weil wir wussten, oder auch noch heute wissen wir vielfach, eigentlich, mehr als die Hersteller überhaupt wissen. Es gibt so 3, 4 Fragen die ich einem Hersteller stellen kann und ich kann relativ gut herausspüren, wie tief ist er in der Materie drinnen. Das ist einerseits hilfreich aber das war ein sehr intensiver Prozess dieses Wissen hinzubekommen. Das war aber eher am Anfang schwierig. Heute hat sich das ganze ein bisschen geändert und wir merken eigentlich wie ähnlich IP gegenüber SDI ist. Also es ist jetzt nicht diese Rocketscience die du nicht mehr verstehen kannst, sondern da haben wir eigentlich am Anfang viel Lehrgeld bezahlt, oder Lehrgeld, einfach ja, viel investiert in Ausbildung, das war die Herausforderung. Und eine zweite Herausforderung war, wir waren am Anfang mit einer externen Consultingfirma unterwegs, für das Projekt die Ausschreibungsphase zu machen, weil wir schlicht zu wenig Knowhow hatten diese Ausschreibungen hinzubekommen. Die Schwierigkeit war zu dem Zeitpunkt auf dem freien Markt ebenso dieses Knowhow zu finden. Weil es sehr dünn gesätes Knowhow ist, und leider

138

auch heute noch ist in der Größenordnung und Komplexität wie halt ein Campusprojekt ist.

15 Wie sieht es denn bei 2110 mit Produkten aus? Nachdem es ein relativ neuer Standard ist, ist da die Vielfalt noch nicht so groß wie bei SDI.

16 Genau.

17 Gibt es trotzdem schon genug Auswahlmöglichkeit um, sag ich mal, für seine Bedürfnisse das richtige Produkt zu finden oder ist man dann in gewissen Bereichen auf ein, oder fünf Produkte beschränkt?

18 Ja das ist ein bisschen, es ist lustig. Es wird dir marketingmäßig alles Mögliche verkauft. Und am Anfang waren wir natürlich die ersten die so ein Riesenprojekt IP bauen wollten. Das heißt jeder Hersteller hatte logischerweise ein riesen Interesse sich da irgendwie zu platzieren. Wir wurden zu Beginn auch von sämtlichen Herstellern umgarnt. Im Sinne von: "Wow, cooles Projekt. Ja wir können da das Beste liefern. Wir können das alles". Das hat sich relativ schnell dann gedreht, dass die Hersteller das Projekt dann plötzlich nicht mehr alle so supercool fanden weil wir so tief in dem Standard drinnen waren das wir bei vielen Projekten gleich zu Beginn einfach aufzeigen konnten, wo in dem Produkt noch die Lücken drinnen waren. Das heißt am Anfang war es relativ schwer, wie bei jeder neuen Technologie, neue Produkte zu finden die wirklich alle Anforderungen können die wir benötigen. Stand heute würde ich sagen, wir bekommen eigentlich für jede Anwendung bis auf vielleicht 2, 3 spezifische Fälle, finden wir eigentlich Lösungen in 2110. Die Auswahl ist sehr klein und wir haben Stand heute noch kein Produkt gekauft und eingesetzt, das so wie es uns präsentiert wurde eingebaut haben, sondern durch jede Nachfrage an eine fehlende Funktionalität ist irgendwo ein Firmwareupgrade, ein Softwareupgrade entstanden. Weil die Hersteller gemerkt haben, hey die Jungs stellen eine richtige Frage, es stimmt, macht Sinn, komm lass uns die implementieren. Wir haben durch das einen sehr intensiven Austausch zu den Entwicklungsabteilungen der Hersteller die wir einsetzen, weil wir, ja, gewisse Funktionalitäten benötigen in Geräten, die vielfach einfach noch gar nicht implementiert wurden. Und das kommt meistens daher weil im Moment einfach nicht viele Projekte in der Skalierungsgröße unterwegs sind wie wir das machen. Das ist halt schon ein Unterschied ob du jetzt 3, 4 Geräte vom gleichen Typ in einem Labor oder in kleinem PoC (Proof of Concept) oder Testumgebung aufbaust, oder ob du plötzlich 200 von diesen Geräten einsetzt, und diese dann irgendwie vollautomatisiert einsetzen musst. Das ist ein sehr schöner Weg für uns mit den Herstellern, weil du bekommst dann auch das was du benötigst. Wir sind aber auch dort im stetigen Austausch mit anderen Projekten und den

139

Standardisierungsgremien. Mit dem Ziel das da nicht irgendwelche Funktionen entstehen die dann nur uns etwas bringen sondern bis jetzt haben wir eigentlich immer irgendwie einen offenen Standard gefunden der diese Funktionalität dann abbilden kann. Ich kann dir ein Beispiel geben.

19 Bitte.

20 Wir haben das Thema. Wir sind sehr dynamisch im Audioumfeld unterwegs und zu Beginn des Projekts war es im Standard von NMOS zum Beispiel nicht vorgesehen, dass du zur Laufzeit dynamisch einen Audiosender aufsetzen und umkonfigurieren kannst. Das ist ganz klar eine must-have Anforderung von uns gewesen weil ich weiß nicht stand heute wie meine Produktion morgen aussieht. Deshalb muss ich auch morgen dynamisch die Konfiguration anpassen können, und das vollautomatisiert. Und das sind dann so Funktionen die am Anfang ein bisschen schwierig zu vermitteln sind und dann irgendwie sagen sie: "Ah doch, macht eigentlich Sinn, komm, lass uns das irgendwo in einen Standard aufnehmen oder in unsere Software aufnehmen" wie auch immer.

21 Du hast vorhin bei den Herausforderungen hauptsächlich das Wissen angesprochen, was derzeit leider immer noch fehlt. Gab es auch technische Herausforderungen, oder auch Sicherheitsherausforderungen in die Richtung?

22 Die gab es sicher aber ich hätte jetzt keine im Kopf wo ich dir sagen kann, das war nicht lösbar. Also PTP war eine Herausforderung. Nicht weil es technisch nicht machbar ist, sondern einfach weil die Architektur relativ komplex ist in, ja, der Vielfalt der Möglichkeiten. Aber so wirklich eine Herausforderung wo wir jetzt wochenlang oder monatelang darüber diskutieren mussten bis wir eine Lösung hatten, die gab es eigentlich nicht. Es gibt viele kleine technische Diskussionen wo wir uns zuerst finden mussten, wo wir Lösungen entwickeln mussten. Ganz viele Sachen haben einfach zu Beginn des Projektes nicht existiert. Sei es in den gewählten Produkten, sei es in den Standards, sei es das es einfach gar keine Überlegungen dazu gab. Ich mein so ein Beispiel, wir haben gesagt, jeder Port der konfiguriert wird wo ein Gerät, wo am Switchport was dranhängt, muss automatisch Security-Funktionalitäten implementiert bekommen. Das ist was, was du als Hersteller dann zum Schluss noch machst, dich um Security kümmern. Da beginnst du nicht gleich weil ohne Security funktioniert dein Netzwerk ja auch. Und bei uns stand zum Beispiel Security relativ hoch oben auf der Liste der Anforderungen. Das gab schlussendlich Diskussionen, es war sicher eine Herausforderung aber wir haben eigentlich all diese Dinge irgendwie lösen können. Es ist doch schwierig so nach 2 Jahren zu sagen, was waren die Herausforderungen, weil ja klar sie

140

waren da aber irgendwie sind mittlerweile alle Dinge gelöst und wir hören immer wieder von Kollegen die erzählen: "Ah, weißt du, wir bekommen das PTP nicht hin, wir bekommen das nicht hin", da denkst du so: "Ok, machs doch so, ist doch kein Thema". Aber wir sind manchmal einfach schon so weit in dieser Thematik drinnen, das wir, wir denken über ganz andere Themen nach. Wie bringen wir den Multiviewer in die Azure Cloud, wie können wir Multicast in die Azure Cloud bringen? Wie kann ich Remotestandorte auf einer Olympiade über IP und 2110 anbinden? Wir sind da manchmal schon ein bisschen zu weit weg um vielleicht Herausforderungen die andere, die erst damit beginnen überhaupt noch adressieren zu können. Es ist ein Luxusproblem schlussendlich. (lacht)

23 Ja weil du es gerade angesprochen hast. Was könnte man denn jetzt schon beachten um einen späteren Umstieg auf IP ein bisschen einfacher zu gestalten?

24 Bau dir ein Labor auf. Und zwar morgen und nicht erst übermorgen. Das ist das, das ich jedem empfehle, ein Labor aufzubauen. Weil einfach das Knowhow, das musst du lernen. Das ist lernbar. Und es ist auch für Broadcastexperten lernbar, das ist das Learning das wir gemacht haben. Wir haben Leute gehabt im Team die haben von IP nichts gewusst und die sind jetzt die IP-Cracks. Wir haben nicht versucht unseren IT Netzwerkjungs Broadcast beizubringen, sondern wir haben das Netzwerk- Knowhow den Broadcastkollegen beigebracht. Das war erfolgversprechender als der umgekehrte Weg. Also das Labor ist sicher etwas. Und das Zweite ist, Augen auf bei der Wahl des Orchestrators. Also baue nie ein Netzwerk ohne Orchestrierungslösung. Weil sonst bist du einfach blind was dein Netzwerk macht, und auch was Security und so angeht. Das ist einfach ein Learning das wir gemacht haben. Wir haben den Ü-Wagen ohne große Orchestrierung gebaut und das ist einfach überhaupt nicht lustig. Und dann bei der Orchestrierung fliegst du einfach relativ rasch mal auf die Schnauze sag ich, weil da gibt es so viel Marketing was dir alles versprochen wird. Und ich sag mal, ich bin immer noch davon überzeugt das es im Moment auf dem Markt einen sehr guten Orchestrator gibt, den wir logischerweise gewählt haben (lacht). Hinter dem Entscheid stehe ich immer noch. Und dann gibt es 2, 3 vielversprechende Kandidaten, aber das ist ein Thema da gibt es nicht viel am Markt was wirklich funktioniert und alles in aller Breite kann. Und das brauchst du schlussendlich ab einer gewissen Größe deines Netzwerks.

25 Gibt es für dich einen Unterschied, ich weiß nicht wie weit du da informiert bist, speziell vom deutschsprachigen Raum im Gegensatz zum amerikanischen oder asiatischen Markt, wie es da aussieht mit der

141

Implementierung?

26 Ja. Wir, ich nehme mal die Schweiz heraus, wir sind auch nicht in der EU. Nein, also erfahrungsgemäß sind die Europäer einfach nicht mutig. Ich sehe es immer wieder wenn ich jetzt Diskussionen habe mit Kollegen von Öffentlich Rechtlichen, sei es ein ARD, ein ZDF, ein ORF, kannst auch die Italiener nehmen mit den Rai-Kollegen mit den BBC-Kollegen, wo ich einfach so denke, hey Leute, wenn ihr nicht mutig seid, wenn ihr aber auch nicht ein Management habt das dahinter steht und sagt, wir bauen das jetzt. Wenn ihr kommt mit EU konformen Ausschreibungen wo bis ins Detail schon heute klar sein muss was du dann drei Jahre später für einen Switchtyp nimmst, da kommst du nie auf einen grünen Zweig mit IP Technologie. Da brauchst du irgendwie eine Mentalität die ein bisschen IT- affiner ist und so leid es mir tut, wenn dein Projektteam ein Durchschnittsalter von 55 oder 60 Jahren hat, und deine Netzwerkarchitekturvorgabe von Kollegen kommt der in einem Jahr dann pensioniert wird, dann bist du ein bisschen schwierig unterwegs sage ich jetzt mal. Das sage ich als junger, ja Projektleiter, da bin ich so frech und sage das. Es ist ein Mentalitätswandel der hier vor sich geht. Es braucht komplett neue Skills, es braucht ganz neue Themenfelder die du hier zu bearbeiten bekommst, es geht um ganz viele IT-affine Themen. Da muss die Broadcast noch eine Veränderung durchmachen. Weil, das beginnt beim Mindset in den Köpfen der Mitarbeiter, und das meine ich unabhängig vom Alter. Es geht aber auch um Knowhow und dieses IT-Knowhow, gerade wenn es um Datacenternetze geht und so weiter, das ist im Broadcast eher schwierig zu finden und ist noch viel schwieriger zu finden je älter die Kollegen sind. Weil es einfach ein Unterschied ist wie diese Technologien entstanden sind. Wo ich ein bisschen, ja, die Kollegen zum Teil beneide die solche Projekte dann machen müssen, weil sie einfach in einigen eingerosteten Strukturen noch funktionieren müssen, wo irgendwo die Mentalität noch nicht IP-ready ist. Und ja da sind die Amerikaner ganz anders unterwegs. Also die kennen dort dann gar nichts. Sie sind auch finanziell natürlich wesentlich freier und ich glaube es ist ein Unterschied, deshalb habe ich das mit der EU gesagt. Wir sind nicht an EU-konforme Ausschreibungsprozesse gebunden. Und das macht einen riesen Unterschied meiner Meinung nach. Weil, du beschaffst in einem IP-Projekt eigentlich Technologie der neuesten Generation. Und ein Broadcastprojekt geht normalerweise 2, 3 Jahre wenn du ein größeres Projekt hast wie jetzt bei unserem Campus. Das heißt unter Umständen schreibst du heute eine EU-konforme Ausschreibung für einen Switch den du in eineinhalb oder zwei Jahren dann installierst und beschaffst. Und da kommt dir das Wettbewerbsrecht manchmal schon ein bisschen in die Quere, das du eine Herausforderung hast heute etwas zu spezifizieren, das dann in einem Jahr

142

vielleicht mal beschafft wird. Das ist für eine IP/IT-Umgebung ein extrem langer Zeitraum. Und das haben wir zum Glück nicht. Oder nicht ganz so stark.

27 Das stimmt, daran habe ich im Vorhinein gar nicht gedacht, das selbst im deutschsprachigen Raum die Schweiz da ein bisschen anders aufgebaut ist als Deutschland und Österreich.

28 Genau. Also ich habe einen Austausch gehabt mit den Kollegen von der ARD. Das ist schon auch krass. Ich kenne es selber ja eben nur von den Kollegen vom Hörensagen und von einigen ehemaligen Arbeitskollegen aus dem deutschen Raum. Das ist schon auch schwierig in dieser schnelllebigen Zeit etwas zu machen. Also ich kann dir ein Beispiel geben, wir haben einen Switch in der Ausschreibungen eigentlich gehabt, den bestellt, und als die Bestellung dann versendet wurde kam dann die Info, Ja wir haben einen neuen Switchtyp geschickt, die neuere Generation, es ist jetzt ein neues Chassis herausgekommen, das kann jetzt auch 400G. Ja cool, wenn du dann aber einen Konkurrenten hast der da unterlegen ist und dir dann den Juristen vorbeischickt, dann kannst du dann ganz lustige, ja, Sachen verzögern wenn du willst.

29 Was braucht es denn deiner Meinung nach im deutschsprachigen Raum um die Umstellung ein bisschen voranzutreiben? Vielleicht auch in Richtung Herstellerpräsentationen oder Get-togethers, wo die Hersteller das ein bisschen vorantreiben können.

30 Ich würde nicht mal die Hersteller dort in die Pflicht nehmen. Weil die Hersteller die liefern dir problemlos das was du brauchst. Auch im deutschsprachigen Raum hast du viele Hersteller die, oder im europäischen Raum sage ich mal. Ich glaube an den Herstellern scheitert es nicht. Ich glaube es scheitert an uns Broadcastern, die vielleicht nicht immer, ja, gewillt sind jetzt das neueste vom neuesten einzusetzen. Weil es ist halt ein Risiko. Ich kann dir heute noch nicht sagen ob wir die nächsten 5 Jahre in unserem Betrieb keinen Ausfall des Netzwerks haben. Wenn wir das haben, dann sind wir Schwarz auf dem Sender, und nicht nur auf einem Sender, sondern es ist ein großes Netzwerk für 3 Sender. Also dieses Risiko, das schwimmt mit. Und es ist halt einfach schon so, wenn Technologie die du über 15 oder 20 Jahre kennen gelernt hast, die kannst du risikomäßig ganz anders einschätzen und klassifizieren als eine Technologie wo du vielleicht einen externen Consultant brauchst um sie überhaupt zu verstehen. Also ich glaube es beginnt bei uns Broadcastern selber. Sind wir mutig genug auf diese Technologie zu setzen? Weil meiner Meinung nach funktioniert diese Technologie. Es gibt Lösungen für sämtliche Herausforderungen. Nur sind wir bereit und gewillt das auch zu

143

suchen, das aufzuzeigen, und können wir das auch aufzeigen oder kommt dieser normale menschliche Reflex, etwas unbekanntes ist per se einmal ein bisschen kritischer zu betrachten? Und schlussendlich auch, sehen wir den Mehrwert der Technologie. Weil wenn du keinen Mehrwert siehst in der Technologie dann musst du auch nicht diese Technologie wählen, oder? Aber schlussendlich, vielleicht ein anderer Vorteil. Wenn du heute etwas neues baust, und ich rede mal nicht von einem Studio mit 3 Kameras und einem kleinen Mischer und so weiter, sondern ich sage jetzt mal, du musst irgendeinen neuen Standort bauen. Du musst ein Regionalstudio, TV mit 2 Studios, 3 Studios und mehr umbauen. Wenn du heute noch auf SDI setzt dann setzt du ja eine Technologie ein wo du weißt, die nächsten 6, 7 Jahre wirst du die einsetzen müssen. Und wenn du jetzt überlegst, wo investiert ein Hersteller seine Entwicklungsressourcen. Dann wird der sicher nicht mehr seine Entwicklungsressourcen stand heute in der SDI-Technologie einsetzen. Weil das ist absehbar, das mit 4K und 8K SDI nicht mehr das Richtige ist. Also hast du auch dort irgendwann ein Risiko, das du auf eine Technologie setzt die der Hersteller dir zwar heute noch anbietet aber sicherlich intern nicht mehr die größte Entwicklungsabteilung betreiben wird. Aber es ist lustig, die Frage die du stellst, die stellt sich bei uns eben gar nicht mehr. Bei uns ist, wenn es neue Projekte gibt kommt die Frage, ich mache es mit IP, nehme ich jetzt dieses Produkt oder dieses Produkt? Da sind wir glaube ich über den Berg mit dieser Diskussion.

31 Ja, also da kann ich nur aus meiner persönlichen relativ kurzen beruflichen Laufbahn eben erst sprechen. Also das ist bei uns noch ganz anders.

32 Ja das ist, das höre ich von allen möglichen Stellen immer wieder. Da sind wir, ich glaube wir sind einfach wirklich anders was das angeht.

33 Dann noch eine Frage generell zum Campus. Inwieweit, beziehungsweise zu welchem Prozentanteil ist der Campus denn wirklich 2110 aufgebaut? Also wie viel davon ist wirklich 2110 und wie viel sind dann vielleicht Gateways oder andere IP-Technologien?

34 Ich sage es mal anders. Auf dem Ü-Wagen sind es 90% Gateways gewesen, nein es sind 80% Gateways gewesen. Auf dem Campus hat sich genau das umgekehrt, ungefähr 20%. Ich kann es anders sagen. Auf dem Areal selbst, oder eher auf dem Campus selbst, das ist ja ein Campusprojekt aber effektiv ist es ein Neubau. Im Neubau selbst ist eigentlich 90% IP. Also ich habe eigentlich nirgends, mit Ausnahme des Videomischers, aber dieses Beispiel solltest du in deiner Arbeit nicht erwähnen weil das ist einfach eine sehr unglückliche Konstellation des Herstellers gewesen.

144

35 Ok. (lacht)

36 Der Videomischer war in IP bestellt und dann hatten sie ein Problem und konnten nicht liefern. Deshalb ist er jetzt SDI. Mittlerweile kann der auch IP. Von dem her, wir haben eigentlich im Neubau selbst mit Ausnahme der Kamerasignale, welche SDI sind, und dann halt so kleines Zeug, weißt du wie ein Loopplayer, ein Blackmagic Player der dir irgendwie ein Testvideo abspielt, den gibt es halt nicht in IP, haben wir wenige Gateways im Einsatz. Der größte Teil ist IP. Also wenn du in eine Regie hineingehst könnte ich dir jetzt kein Gerät sagen wo ich dir sagen muss, hey hier kommt nicht IP heraus, sondern da ist noch ein Gateway dazwischen. Es sind dann so die kleinen Lösungen, ja, eine Skype-Box wo du irgendein Skype-Interview aufzeichnen kannst, da kommt halt ein SDI-Signal heraus. Also je kleiner die Lösung desto eher kommt SDI heraus. Aber alles was natürlich bestehende Systeme sind auf dem Campus, die sind mit SDI angebunden. Wir haben eine höllische Anzahl an SDI-Gateways. Wir haben 50, 54 Stück a 32 SDI Ports. Das kommt halt davon, weil wir 14 Studios haben auf dem ganzen Areal die wir anbinden. Wir haben für die ganze Übergangszeit den alten Hauptschaltraum, wir haben die gesamte nationale Kontribution, Senderanspeisung, wo alles noch SDI ist und deshalb die Brücke in die alte Welt, die gibt es halt immer noch. Ich kann kurz meine PowerPoint öffnen, ich hab nämlich so eine lustige Folie zu dem Thema.

37 Gerne. Also wenn du etwas hast das du speziell loswerden möchtest, kannst du das gerne auch.

38 Ah ich hab hunderte von Präsentationen. Ich hab mal irgendwie was gemacht zu dem Thema. Ich hab mir mal eine Liste gemacht wie viele Signale wir haben. Wo SDI, wo IP ist. Genau, was habe ich da? Aja genau die Slowmotion Server sind auch in SDI angebunden, aber auch die können es mittlerweile in IP. Nein sonst ist eigentlich alles in IP. Ja vielleicht für dich noch das du dir eine Skalierung vorstellen kannst des Campuses. Ich habe mal so ein paar Zahlen zusammengestellt. Wir reden auf diesem Campus von, ich habe es aufsteigend gemacht, wir haben 500 Sender im Netzwerk die Ancillarydaten produzieren, und rund, warte mal kann ich dir den Bildschirm sharen über Skype, geht das? Nein geht nicht. 500 Sender, ich schicke dir nachher das PowerPoint, dann hast du es auch.

39 Sehr gerne. Danke.

40 500 Ancillarysender, 1000 Receiver, das ist jetzt nicht so eine riesen Zahl. Dann haben wir 750 Videosender im Netzwerk, also Geräte die sage ich

145

mal SDI nach IP in der alten Denkweise wandeln. Also 750 Inputs auf einer Videokreuzschiene und 2300 Outputs auf der Videokreuzschiene. Das sind doch schon einige Signale. Wenn du die dann mal 3G multiplizierst bist du bei 5,1 Terabit an Traffic im Video die in 1080i50 oder bei rund 10 Terabit im Netzwerk bei 1080p50. Ist ja doch eine beträchtliche Zahl. Und wir haben rund 13000 Audiosender und 24000 Audioreceiver im Netzwerk. Also es ist eine schier unendliche Menge an Multicast die da dann irgendwo herumschwirren.

41 IP ist ja generell ein bisschen platzsparender. Also auch physisch. Allein was die Bandbreitenübertragung angeht ist das ja sehr viel effizienter...

42 Ich höre, das sind jetzt zwei Aussagen. Ich würde jetzt sagen, das eine ist der Platzbedarf, wenn wir über physischen Platz reden. Da haben wir ein massives, schlussendlich ist es ein, wir haben ein Rechenzentrum gebaut in diesem neuen Gebäude mit 192 19 Zoll Racks. Von denen brauchen wir im Projekt eigentlich rund 30 Racks. Und auch die sind sehr, sehr viel Luft dazwischen gebaut. Also da können wir locker zwischen zwei Geräten eine Höheneinheit oder sogar 2, 3 Höheneinheiten Luft lassen. Also wir haben in unseren Rackreihen eine Auslastung von 50 oder unter 50 Prozent. Das ist eine massive Reduzierung die diese Technologie mit sich bringt. Das hätten wir nie gedacht, dass das so viel kompakter und kleiner wird gegenüber einer klassischen Architektur. Also um ein Beispiel zu geben, unser Playoutcenter das für 3 TV-Sender das Playout macht braucht mehr Rackplatz als das gesamte neue Gebäude mit 6 Studios, mit Radio, mit Playout, mit Ingest, mit Hauptschaltraum. Es ist kein Verhältnis was wir da gespart haben. Und die andere Aussage von dir bezieht sich meiner Meinung nach eher auf die Bandbreite oder wie viele Signale du transportieren kannst. Da würde ich dir widersprechen. Eigentlich ist es ja 1 zu 1 dasselbe ob du jetzt einen IP Stream hast oder einen 3G-HDSDI- Signal, die Bandbreite bleibt schlussendlich plus minus dasselbe.

43 Das stimmt, ja.

44 Außer du gehst dann irgendwie JPEG XS oder so was komprimiertes was ja dann auch 2110 sein kann.

45 Wir haben jetzt eigentlich alle Themen schon sehr gut abgedeckt.

46 Du kannst auch später noch jederzeit wenn du noch etwas nachfragen willst oder noch mehr Details oder irgendwie ein Schema, Zeichnung, was auch immer du brauchst, einfach noch melden.

47 Sehr nett. Dankeschön.

146

48 (Off Topic)

49 Gut. Ja also wie gesagt, ich bin mit meinen Fragen eigentlich durch. Gibt es für dich irgendetwas bei 2110 das du stark herausheben möchtest, was wichtig ist, oder wo du sagst, daran muss jetzt weiter gearbeitet werden?

50 Es ist nicht 2110 wenn du direkt den Standard nimmst. Aber das Problem ist immer, 2110 musst du in irgendeiner Art und Weise steuern können. Also Stichwort NMOS zum Beispiel. In dem Umfeld hat es noch sehr viele Lücken in der Implementierung seitens der Hersteller. Also der Standard ist eigentlich da. IS-04, IS-05 ist den meisten bekannt. Es geht aber weiter mit IS-6, 7, 8, 9 und da ist die Marktdurchdringung sehr, sehr schlecht wenn nicht gar inexistent. Das führt dazu, deshalb hab ich gesagt, es ist zwar eine Herausforderung, aber wir haben jede irgendwie gemeistert. Wir setzen dann halt nicht NMOS ein sondern haben einen custom Treiber programmiert den der Orchestrator dann nutzen kann um das Gerät anzusteuern. Aber da tut sich noch sehr wenig im Markt, dass sich da irgendwelche gemeinsamen Standards durchdringen, wie sagt man, etablieren. 2110 kann jeder und da ist es auch kein Thema eine Interoperabilität hinzubekommen. Nur interessiert es mich nicht ein Gerät zu kaufen wo ich dann händisch im WebGui die Multicast Adresse eingeben muss. Ich will auch nicht händisch die interne Audiomatrix beschalten, sondern ich will das über NMOS zur Laufzeit dynamisch von meinem Orchestrator machen können. Und diese Orchestrierungsfunktion auf Open Standards, sei es NMOS, da sind die Hersteller noch viel, viel schuldig was da zu liefern.

51 Gut, dann würde ich dich ganz zum Schluss noch einmal bitten in ganz kurzen Sätzen, in fünf Sätzen, zusammen zu fassen woran bei euch im Haus gerade gearbeitet wird und wie der derzeitige Stand ist.

52 Wir sind momentan in der Finalisierung und der ersten Ausbildungstranche für die Inbetriebnahme des Metechno Gebäude. Das gesamte Netzwerk ist betriebsbereit und funktionsfähig und wird ab Juni verwendet für die Postproduktion im Umfeld Sportproduktion sowie der Newsroom wird in Betrieb gehen.

53 Sehr schön. Vielen Dank.

54 Ja. Gern geschehen. Dir dann viel Erfolg beim Schreiben und Präsentieren und was noch alles kommt. (lacht) Und wie gesagt, wenn du noch etwas brauchst oder Fragen hast dann schreib mir eine E-Mail oder versuche mich anzuskypen.

147

E. Interview Stefan Kollinger

1 Gut, dann würde ich Sie für den Anfang gerne bitten Ihre aktuelle Position und Ihren Aufgabenbereich vorzustellen.

2 Ja, Stefan Kollinger, hallo. Referent des Technischen Direktors des ORF. Aufgabenbereich in dem Sinn, Projektbegleitung, Referenzdasein, es ist eine Querschnittsmaterie, von der Planung, also mit der Planung arbeiten, mit dem Betrieb arbeiten, solche Dinge.

3 Dann ganz allgemein. Welchen Bezug haben Sie bis jetzt zum Thema IP und der Implementierung von IP-Technologien?

4 Wir haben aktuell ein großes Projekt, wo das ein großes Thema ist. Das heißt wir, sozusagen, planen die Systemarchitektur für das ORF-Zentrum im Sinne IP-Realtime-Videonetzwerk. Das ist sozusagen der Hauptbezug jetzt, würde ich einmal so sagen.

5 Welche Vorteile bietet Ihrer Meinung nach IP gegenüber SDI?

6 Naja der große Vorteil glaube ich ganz generell ist, dass man sagen kann, IP ist sozusagen formatagnostisch. Ob wir da HD, SD, UHD, 4K, UHD-2, 8K und so weiter, Auflösungstechnisch ist IP formatagnostisch, das ist einmal ein riesen Vorteil im Unterschied zur SDI-Welt. Wollten wir jetzt sozusagen über unsere eben SDI Verkabelung oder Kreuzschieneninfrastruktur ein höheres Format sozusagen produzieren oder abwickeln, das in der Vergangenheit einfach noch gar nicht existiert hat, dann ist das einmal per se nicht möglich. Also HDSDI ist HDSDI. Braucht man mehr, oder braucht man weniger, muss man sozusagen in einer irgendeiner Form eingreifen, Upconversion, Downconversion, oder aber auch Infrastruktur erneuern im Sinne von zum Beispiel 12G-SDI. Damit man eben höhere Bandbreiten auch in dem Sinne verarbeiten kann. Das ist ein riesen Vorteil bei IP und auch ein großes Versprechen bei IP, dass das sozusagen nach oben oder unten skaliert, im Backbone der Infrastruktur sage ich jetzt einmal. Das man sozusagen in der Peripherie stand heute noch ein paar Sachen machen muss und ein bisschen, man sich Workarounds teilweise schaffen muss, ist auch klar. Es ist wie immer ein sich entwickelnder Prozess. Ich glaube der zweite wichtige Punkt auch im Sinne der Digitalisierung und der Abkehr von traditionellen Verbreitungswegen, also ausschließlich dem TV-Verbreitungsweg, der wissen wir alle, ist zumindest seit HD im Grunde, vor allem technisch gesehen, exklusiv 16:9. Breitbildformat sozusagen. Da ist natürlich in der IP-Welt auch die Möglichkeit vorhanden, das man davon abkehrt. Man kann 1:1, man kann 16:9, man kann 9:16 und im Grunde jedes andere

148

beliebige Seitenverhältnis produzieren und dementsprechend auch, im Grunde, vorbereiten oder sich neue Produkte überlegen für auch digitale Verbreitungswege. Thema Smartphone. Wie viel Menschen schauen am Smartphone Videos die in 16:9 produziert worden sind dann mit, sozusagen, aufrechtem vertikalem Handy? Also das heißt da gibt es sicher, da gibt es einiges an Bedarf auch anders zu produzieren. Und das muss natürlich auch die Infrastruktur in irgendeiner Form hergeben. Vor allem in einer großen Infrastruktur. Dann ist glaube ich, technisch ist ein großes Versprechen dieses ganze Thema immer rund um COTS, also Common- of-the-shelf Produkte. Da muss man auch dazu sagen, wir reden da natürlich immer von Datacenter Level an Netzwerkhardware, Netzwerktechnologie, in diesem Bereich. Das heißt wir können jetzt nicht in den MediaMarkt gehen und, keine Ahnung, exemplarisch Netgear-Switches kaufen. Oder irgendwelche semiprofessionelle oder für den Heimbereich gedachte Netzwerktechnologie. Das ist schon Datacenter-Technologie, das heißt das Zeug ist durchaus auch teuer. Das Zeug ist durchaus auch komplex und es ist auch, sozusagen, ein durchaus auch eingeschränkter Vendormarket an dem man sich da bedient. Da gibt es jetzt auch nicht tausende von Herstellern von derartiger Netzwerktechnologie. Wie immer sind mehr, sind manche mehr darauf spezialisiert, manche weniger darauf spezialisiert. Da gibt es durchaus auch Unterschiede. Wie immer gibt es auch unterschiedliche Vorlieben dann bei den Netzwerkexperten auch, auch sozusagen normal. Das ist glaube ich auch ein wichtiger Punkt.

7 Dann in die andere Richtung gefragt. Wo sehen Sie denn derzeit noch die Vorteile von SDI gegenüber IP?

8 Das ist aus meiner Sicht eigentlich ausschließlich der Faktor dass, also wenn man bestehendes Unternehmen hat, dann hat man eine vorhandene Infrastruktur. Mit der kann man ja arbeiten. Und wenn jetzt, sozusagen, kein großer Bedarf vorhanden ist im Sinne weil, weil die Lebenszyklen von Infrastruktur et cetera an das Ende geraten. Und man jetzt zum Beispiel den Technologiewechsel deswegen nicht anstreben muss, dann ist das ein Vorteil das man das heute hat, in Ruhe arbeiten kann und nicht dem Druck ausgesetzt ist jetzt auf IP wechseln zu müssen. Oder die Entscheidung treffen zu müssen, dass wenn man jetzt etwas erneuern muss entweder wieder auf SDI geht oder auf SDI bleibt oder eben den Technologiewechsel anstrebt. Zweiter Vorteil würde ich sagen ist das, sozusagen, operationseitig ein Betrieb und Support natürlich den Status Quo kennt, mit dem Status Quo arbeiten kann, relativ wenig Schulungsbedarf entsprechend besteht und man im Grunde ein funktionierendes Ökosystem, sage ich jetzt einmal, hat. Das ist es im Grunde aus meiner Sicht. Ich sehe da jetzt keine großen, in dem Sinne, technologischen

149

Vorteile SDI gegenüber IP. Was aber nicht so verstanden werden soll, dass man mit IP viele Probleme haben wird, es auch noch immer viele Probleme gibt und das ganze Ding auch natürlich in Entwicklung ist von den Standards her und so weiter.

9 Es ist ja jetzt schon seit ein paar Monaten der erste Ü-Wagen von euch unterwegs,...

10 Genau.

11 ...der voll in IP, oder der mit zumindest IP 2110 angepriesen wurde, unterwegs. Wie sind denn da die ersten Erfahrungen?

12 Ich glaube die wichtigsten Aussagen sind die der Kollegen die den, sozusagen, gebaut und geplant haben, gemeinsam mit dem Generalunternehmer und den Kollegen die das auch betreiben und supporten. Da ist für das Betriebspersonal, egal ob das Bildmeister oder Regisseure et cetera pp. sind, es für den Betrieb relativ, eigentlich keinen Unterschied macht ob jetzt traditionelle Bauweise oder IP-Technologie in dem Sinn. Das ist insofern eine gute Message, weil das Arbeiten einmal ganz normal weiter gehen kann. Im Sinne, wie kann ich meine Gerätschaften bedienen, meine Produktionen abwickeln und so weiter. Das heißt, das hat relativ wenig Impact darauf. Und zweiter wichtiger Faktor ist, es schafft eben durchaus mehr Möglichkeiten wenn man zum Beispiel im Kreativen neue Ansätze verfolgen will, ausprobieren will, solche Dinge. Ein weiterer wichtiger Faktor ist, dass IP relativ große Aufwände mit sich bringt im Sinne der Konfiguration von Geräten. Das ist, muss man eigentlich teilweise auch klar sagen ein Nachteil zur SDI-Welt. Wobei das jetzt gar nicht zwingend damit zu tun hat ob SDI oder IP. Es spielt schon auch eine Rolle aber ein großer Unterschied, ich sage jetzt mal zu dem bekannten Einsatz von Glueparts (???) und so weiter, ist halt das, diese FPGA- basierten Multifunktionsgeräte nenne ich das jetzt einmal, einfach einen enormen Konfigurationsaufwand mit sich bringen. Vereinen dann halt oft vielerlei Funktionen. Also von Multiviewer, Up-Down-Cross-Conversion, Audio Delay, Video Delay, Video Processing, whatever, sozusagen in einem Gerät. Das dann bezogen auf die Signalführung auf IP-Basis. Und der große Unterschied, sozusagen vereinfacht gesagt, IP zu SDI ist ja praktisch dass wir im Grunde ja von RAW Video völlig separierten Video-, Audio-Metadaten, Informationen und Streams reden. Und der Aufwand das alles zu konfigurieren und zu bündeln, die Streamnames zu vergeben und so weiter, da ist sich scheinbar die Industrie einig, ich selbst hab es ja nie konfiguriert, ist sich die Industrie durchwegs einig, dass das ein sehr aufwendiger Prozess ist den man auch nur schwierig mit mehr Ressourcen, also mehr Personal, erschlagen kann. Weil unter Anführungszeichen, es

150

dauert so lange wie es dauert.

13 Falls bekannt, muss jetzt nicht unbedingt beantwortet werden, wissen Sie wie viel in dem Ü-Wagen, weil ich weiß es von anderen Ü-Wägen die mit IP angepriesen wurden, wirklich dann IP sind, oder wie viel darin noch irgendwelche Gateways sind?

14 Nein kann ich jetzt, weiß ich konkret nicht. Anzahl und Verhältnis weiß ich nicht, aber es ist sicher so das, also das kann man allgemein beantworten, es gibt generell für die IP-Technologie stand heute, du brauchst logischerweise ständig Gateways. Du musst ja entweder eine bestehende Infrastruktur anbinden oder du musst in ein wiederum, wieder in eine bestehende Infrastruktur übergeben. Das heißt jetzt einmal, plumpes Beispiel, von dem IP-Ü-Wagen in einen SDI-Ü-Wagen, keine Ahnung. Also es könnte ja sein, dass ein zweiter Ü-Wagen bei einer Produktion ist und Subregie macht oder so, und der nicht auf IP-Basis gebaut wurde. Das gleiche gilt natürlich auch bei ankommenden Leitungen in einem, keine Ahnung, Hauptschaltraum, Produktionsort, wo sozusagen das Signal mit absoluter Sicherheit in einem anderen Format und Standard ankommt als SMPTE 2110. Der Idealfall heute wäre wahrscheinlich, wenn IP dann wäre es wahrscheinlich 2022. Weil auch das sinnvollere Format für Wide Area Network Übertragung. Oder es kommt halt als in irgendeiner Form über Fiber und schlussendlich von optisch auf elektrisch auf SDI wieder. Das heißt da muss man eigentlich immer in irgendeiner Form Gateways einsetzen. Das ist der eine Faktor. Der zweite Faktor ist, dass die, eines der großen Versprechen der IP-Technologie, das sozusagen, weniger Hardware, mehr Software. Das ist so in der Breite noch nicht realisiert in der Industrie, das muss man auch klar sagen. Das heißt dieser, ja ich sag mal Idealfall, im Grunde hast du dein Netzwerkinterface. Netzwerkkabel rein und deine Videosignale und Audiosignale werden verarbeitet, bearbeitet, aufgezeichnet, ausgespielt, was auch immer, das ist so nicht Realität. Das heißt ganz viele Hersteller haben, bauen Geräte die am Ende Gateways eingebaut haben oder sowas wie Matroxkarten, also spezielle Grafik- und Videokarten die in Wirklichkeit auch wandeln. Die wandeln, und viele Geräte arbeiten dann intern eigentlich wieder auf Baseband und am Ein und am Ausgang ist halt dann in Wirklichkeit wieder die Wandlung von oder auf 2110. Also das wird glaube ich noch Jahre dauern. Man muss auch sagen, da sind sich auch viele in der Industrie eigentlich einig, dass der Standard sehr aufwendig ist, sehr viel Ressourcen frisst, weil wir da eben eigentlich von Uncompressed RAW-Video sprechen, das tun wir ja nicht einmal in der SDI-Welt. Das ist ja durchaus ein diskutabler Faktor das man derartig hohe Bandbreiten teilweise, und Bitraten, Auflösungen, et cetera pp. da sich generiert mit IP. Dementsprechend müssen

151

Softwareentwickler, das ist tricky, lassen Sie es mich so sagen. Auch teilweise die Rechnerkapazitäten von Servern und so weiter können das alles gar nicht so handeln wie wir uns das eigentlich alle vorstellen wenn wir ab UHD sprechen. HD Auflösungen sind eigentlich weniger das Problem aber ab UHD wird es, ist es weiterhin schwierig in Wirklichkeit.

15 Wie sieht es denn mit wirtschaftlichen Herausforderungen aus im Gegensatz zu SDI? Bezogen auf laufende Kosten oder eventuell häufiger austauschbare Hardware. IP-Switches müssen ja glaube ich öfters einmal ausgetauscht werden als etablierte Broadcasttechnik.

16 Ja ich glaube da hat sich einfach, müssen, die Frage des Müssens ist schwierig zu beantworten, aber was sich da natürlich ändert, dass wenn man jetzt sagt, man geht immer auf Netzwerktechnologie und da eben auf diese Datacenter, sozusagen Kategorie, weil man da rein muss ab einer gewissen Größe einer Infrastruktur. Dann sitzt man halt plötzlich in so einer Video- und Audioinfrastrukur mit eben so Firmen wie, keine Ahnung, Cisco, Mellanox, Arista, HP, Dell, you name it, sozusagen im Boot. Und diese Unternehmen funktionieren natürlich ganz anders als jetzt diese klassischen Broadcastvendors die keine Ahnung, Kreuzschienen herstellen, die eine lange Laufzeit haben, einmal per se, und aber deren Businessmodell auch auf Invest und dann Service Level Agreements, sag ich einmal ganz vereinfacht, basiert. Und die großen IT Konzernen, die funktionieren da schon anders. Auch weil praktisch die Anforderungen der Nutzer sage ich jetzt einmal, also der IT-Industrie an diese Unternehmen ja ganz andere waren in der Vergangenheit und weiterhin ganz andere sind. Das heißt dieses, die Verdoppelung von Bandbreiten, Verdoppelung von der Leistung des Silicons, also der Chips und so weiter, das geht ja alles viel schneller und viel rasanter im 2, 3, 4, 5 Jahreszyklus als sich, sozusagen, die Broadcastindustrie mit ihren Geräten, Funktionen, diesen Dingen, eigentlich weiter entwickelt. Das heißt im Grunde fahren die ein anderes Businessmodell. Invest, laufende Kosten, Lifecyclemanagement der Hardware selbst. Dann ist das natürlich auch alles viel softwarebasierter auf eine andere Art und Weise als klassische Rundfunktechnik, das ist auch klar. Das heißt man kann das eigentlich gar nicht wirklich vergleichen. Das ist eine andere Welt. Deswegen ist es aber nicht billiger und auch nicht zwingend teurer. Es ist auch oft eine andere Darstellung, es ist oft eine andere Rechnung über die Laufzeit. Das so als Grundaussage.

17 Weil gerade angesprochen, weil die Hersteller das derzeit nicht gewohnt sind, dass sie diese Leistungen bieten müssen. Man kann auch so Sachen wie Synchronisierung, Latenz und so als Herausforderung sehen wenn

152

man die Hardware umstellt oder?

18 Synchronisierung und Latenz auf was bezogen? Synchronisierung im Sinne von Takt, PTP, und...

19 Genau, ja.

20 Ist, lassen Sie es mich so sagen. Es ist scheinbar, das sagen sozusagen die Experten die den Standard mitgeschrieben haben und so weiter. Es ist von essentieller Wichtigkeit, dass die Verteilung des PTPs über Boundary Clocks, über die Switches und so weiter, dass das, das muss funktional zu hundert Prozent sichergestellt sein. Der Standard ist meiner Ansicht nach hochkomplex aber ich bin da logischerweise auch kein Experte in dieser Technologie. Und man merkt schon das nicht jeder Hersteller dann von Endgeräten, jetzt keine Ahnung, das kann die Videokarte sein, das kann aber auch irgendein verarbeitendes Gerät sein, auf dem Niveau mitspielen und alle Punkte dieses Standards auch erfüllen können. Jetzt bin ich nicht in der Lage zu beurteilen warum diese Unternehmen wo das vielleicht zutrifft das entweder noch nicht können oder nie können werden. Also entweder schießt der Standard über das Ziel oder die Firmen sind einfach noch nicht so weit alles zu erfüllen. Manche, das gilt ja nie für alle wenn ich das sage. Insofern, ja richtig, auch wie in der SDI-Welt in Wirklichkeit, Takt, Synchronisierung, sind immer enorm wichtig. Das ist zum Beispiel in der SDI-Welt nicht anders. Wenn Ihr runter geht in den ZGR und den Blackburst beendet, dann wird nicht mehr viel funktionieren. Das ist in IP nicht viel anders. Ich glaube es ist auch ziemlich komplex oder teilweise ist es eine Challenge von IP auf zum Beispiel wieder SDI zu wandeln aufgrund des Taktes. Weil PTP ist natürlich um ein Vielfaches genauer und Jitter bei der Wandlung retour ist da oft wieder einmal ein Problem weil das eigentlich, ja ist einfach nicht das gleiche. Wird da nicht so super exakt gearbeitet kann es da einfach zu Problemen kommen. Latenzen war die Frage bezogen auf was?

21 Naja wir reden ja bei Videosignalen von Echtzeit. Also für uns ist das ja kein Thema das Signale in Echtzeit übertragen werden. Für IT-Kollegen oder ich sage jetzt mal Netzwerkexperten ist Echtzeit jetzt nicht so wichtig. Da ist es erstmal egal wenn irgendwo ein Paket verloren geht, dann wird es eben noch einmal gesendet.

22 Ja.

23 Darauf bezogen. Dass sich da vielleicht die Hersteller von Switches oder dergleicher Hardware ein bisschen umstellen müssen was diese Sache angeht.

153

24 Kann ich so nicht beantworten. Also meine Info ist, dass es eigentlich kein Problem ist und mir sagen alle Kollegen aus aller Welt die mit solchen Projekten schon fortgeschrittener sind, dass das nie ihr Problem war. Und deswegen befinden wir uns auch eigentlich immer in dieser Datacenter Liga an Netzwerktechnologie und Switches. Weil wenn man sich das einmal anschaut welche Datenmengen man da zum Beispiel an Teraflops und so weiter, ich mein es hängt immer von der Dimensionierung ab, man durch diese Technologie, sage ich jetzt einmal plump, durch bringt. Dann ist das jetzt so nicht das Problem. Der Standard muss das ja ohnehin hergeben. Ist mir in dem Sinn als Problem noch nicht geäußert worden. Kann ich jetzt so nicht bestätigen. Aber ich kann mir schon vorstellen, dass es in der Inbetriebnahme und in der Konfiguration vielleicht solche Probleme geben kann und wird.

25 Dann mal wieder eine allgemeinere Frage. In welchen Situationen würden Sie heute IP-Technologie bedenkenlos empfehlen und einsetzen?

26 Bedenkenlos, das ist eine schwierige Frage (lacht). Also bedenkenlos kann man glaube ich einen Technologiewechsel nie anstreben, das einmal als erste Antwort glaube ich. Da muss man sich immer überlegen und sich schon bewusst sein auf was man sich da einlässt. Das ist immer auch irgendwo eine Wette. Also ich sage Ihnen, meine persönliche Meinung ist, dass der Wechsel von Audio, Video, Metadaten, alles was da sozusagen eine Rolle spielt im Broadcastbusiness, der Wechsel dessen von Baseband auf IP, da ist sich eigentlich jeder einig, oder da ist sich die Industrie sehr breit einig, dass das der notwendige und absolut richtige Schritt ist. Ob dieser Standard SMPTE 2110 der Weisheit letzter Schluss ist sind sich nicht alle einig. Und ich glaube das ist auch ein großer Unterschied von Baseband zu IP. Es wird, also es ist bereits und es wird auch in Zukunft ein sich entwickelndes System bleiben und noch mehr werden. Also der Standard ist im Grunde geschrieben worden von, ja SMPTE, und im Grunde haben den Broadcaster geschrieben. Ob das der beste erste Ansatz war, ich weiß es nicht. Aber er ist in großen Teilen, ich sage jetzt einmal vereinfacht, fertig. Das funktioniert auch bewiesenermaßen. Und die weiteren Iterationsschritte sind durchaus hoffnungsvoller. Weil es geht jetzt natürlich logischerweise in die Richtung Compressed. Weil warum sollen wir da jetzt alles uncompressed Video durch die Welt schicken ständig? Compressed spielt natürlich eine Rolle. Wenn ich es jetzt richtig im Kopf habe, JPEG XS spielt da ein großes Thema. Da dahinter stehend was, im Grunde eben praktisch latenzfreie Realtimecodecs und so weiter. Also ich glaube, dass das ein ganz ein wichtiger Weg ist der da eingeschlagen wurde und der uns ganz viel bringen wird in der Zukunft sobald das mehr Realität wird, sage ich jetzt einmal. Das ist sicher ganz wichtig. Weil man

154

darf ja nicht vergessen. Wir sprechen immer, sozusagen, IP-Technologie, und dann ist man ganz schnell bei dem Thema Cloud und so weiter. Also uns muss schon bewusst sein das zum Beispiel der initiale Standard 2110 in dem Sinn, das ist not Cloud ready. Also das funktioniert eigentlich nicht, das widerspricht sich sogar im Grunde. Das ist schon teilweise ein Konflikt den ich da sehe den wir halt lösen müssen. Aber der wird auch gelöst werden. Weil die Welt verändert sich. Und sie verändert sich schneller als es uns manchmal lieb ist, und der Standard wird da nachziehen müssen. Ganz einfach.

27 Dann wieder eine bisschen konkretere Frage an den ORF bezogen. Was sind denn derzeit so die Projekte an denen da gearbeitet wird, bezogen auf IP oder 2110 im Speziellen? Soweit man das sagen darf.

28 Ja ich bin gerade am Überlegen wie ich das sage. Im Grunde ist es was IP angeht im Moment ein Großprojekt sozusagen. In dem wie schon vorher erwähnt im Zuge des Vergabeverfahrens, dieser Ausschreibung, das Ergebnis dessen soll sein praktisch eine fertige, oder die Konzeption der Systemarchitektur für ein IP-Realtime-Videonetzwerk für das ORF-Zentrum das gesamte. Und in der Realisierung soll das Ergebnis sein für sozusagen einen Teilbereich die Realisierung, eine produktive Realisierung mit der Realisierung des notwendigen Backbones dafür. Aber es wird natürlich nicht auf einmal, was weiß ich, alle Regieplätze, die Postproductionanbindungen, alle Studios und so weiter, das kann man natürlich nicht alles auf einmal umstellen. Aber was man schon machen muss, man muss es einmal für das Gesamte konzipieren. Das auch gesamt funktional sein kann. Und dann muss man, sozusagen, portioniert eigentlich starten für die Umsetzung. Und bei uns ist das im konkreten, im Haus wird das mit der Erneuerung des Sendezentrums begonnen.

29 Was kann man denn, also angenommen man ist jetzt in seinen Produktlebenszyklen von sagen wir mal 5 bis 8 Jahren drinnen und überlegt so, Ok in 3 Jahren steht jetzt der nächste große Umbruch im Haus und man möchte auf IP-Technologie umsteigen. Was kann man denn jetzt schon beachten um diesen späteren Umstieg ein bisschen einfacher zu gestalten aus deiner Sicht?

30 Muss ich kurz nachdenken. Ich glaube der mit Abstand wichtigste Punkt ist sich zu überlegen, wie will man in Zukunft arbeiten. Also sozusagen Betriebskonzepte erstellen, so nennt sich das im ORF. Oder Future Model of Operations oder keine Ahnung, je nachdem wie man es nennen will. Ich glaub das sollte eigentlich der Startpunkt sein. Man sollte sich überlegen, wie will man in Zukunft arbeiten und mit wie viel Personal will man in Zukunft arbeiten und wie viel Personal braucht man in welchen Bereichen.

155

Dabei sollte einfließen der Aspekt, welchen Impact hat IP dabei auf mein Betriebsmodell und auf mein Personalmodell und auf sozusagen das Skillset was die Mitarbeiter haben müssen, sollen, werden. Es ist aus meiner Sicht das mit Abstand wichtigste. Der technologische Part ist eigentlich egal. Egal im Sinne, der kann erst darauffolgend in Wirklichkeit erfolgen ansonsten ist es einfach eine technische, sage ich jetzt einmal, Einführung oder Erneuerung oder Umsetzung die relativ wenig Impact haben wird. Außer natürlich diese Umstellung. Aber das ist was die meisten nicht anstreben mit dieser Umstellung, das muss man auch dazu sagen. Die meisten haben relativ große Hoffnungen bei dieser Umstellung, dass sie Kosten senken.

31 Das heißt aus Ihrer Sicht,...

32 Betriebsmodell definieren.

33 Genau.

34 Die Antwort ist sozusagen, das wichtigste vorab ist ein zukünftiges Betriebsmodell zu definieren unter all den Aspekten die diese Dinge mit sich bringen.

35 Also nicht auf Teufel komm raus unbedingt jetzt sofort umsteigen sondern halt,...

36 Nein überhaupt nicht.

37 Überlegen, brauch ich das wirklich und was bringt es mir?

38 Genau. Absolut. Brauch ich keine Veränderung zum Status Quo, warum soll ich jetzt großartig umsteigen auf etwas was mich viel Geld kostet? Vor allem wenn ich vielleicht eine bestehende Infrastruktur habe die eh läuft, also es wäre ja ein Blödsinn. Betriebswirtschaftlich und auch, sozusagen, Riskmanagement, würde ich eine klare Empfehlung dagegen aussprechen. Oder wenn ich es entscheiden müsste, würde ich dagegen entscheiden. Weil warum soll ich das tun? Das wäre ja dann sozusagen ein reiner Fetisch, Technologiefetisch. Aber der mir als Unternehmen oder Mitarbeiter die das umsetzen, keinen positiven Effekt hat. Also werde ich es nicht machen.

39 Ja, du hast es eigentlich schon mit deiner letzten Antwort negiert oder beantwortet, aber was würde es denn brauchen, im deutschsprachigen Raum jetzt speziell, die Umstellung auf IP ein bisschen voranzutreiben? Ein bisschen zu beschleunigen.

40 Also das größte Hindernis aus meiner Sicht ist sozusagen der Markt

156

dessen man sich bedient. Also, wie funktioniert das Broadcastbusiness im Grunde. Praktisch kein Rundfunkunternehmen hat selbst R&D. Die große Ausnahme, im Grunde weltweit, ist die BBC. Die haben, sind ja sozusagen wirklich Technologieführer und haben eine riesen Forschungs- und Entwicklungsabteilung. In Italien die Rai hat glaube ich auch noch, außergewöhnlich viel im Vergleich, aber dann fällt mir schon nicht mehr viel ein, sozusagen Rundfunkunternehmen die dezidiert R&D noch betreiben, selbstständig. Das heißt alle Rundfunkunternehmen bedienen sich eines Herstellermarktes. Und das größte Hindernis ist eigentlich dieser Herstellermarkt. Das heißt, das Versprechen was IP abgibt, und was im Grunde auch die Industrie abgibt im Sinne dieser ganzen Hersteller von Produkten, das ist nicht ganz Realität. Das wird aus meiner Sicht verzögert.

41 Das heißt es werden einem Sachen versprochen die dann so gar nicht Realität sind von den Herstellern, oder...?

42 Nicht so schnell wie gewünscht. Es gibt da ja von der, im Grunde, kennst du die IP-Roadmap?

43 Ja.

44 Und die EBU-,...

45 Die Pyramide.

46 Pyramide, genau. Wenn man es jetzt einmal zum Beispiel daran fest macht und sich da die Zeitachse ansieht der letzten Jahre und die Future- Roadmap. Dann driftet das etwas auseinander. Im Sinne wenn ich dann zum Hersteller XY gehe und sage, Ja so würde ich das gerne machen, oder das hätte ich gern, das wäre der Idealzustand. Dann ist die Antwort ganz oft: "Wir arbeiten daran" oder "Zukünftig wird das so sein", aber heute ist das eigentlich alles ganz viel nicht so. Das kleinste Problem ist immer wieder, nur damit ich es noch einmal erwähne, die Netzwerktechnologie. Die ist das kleinste Problem. Also die Infrastruktur, der Backbone, die Switches und so weiter. Das ist nicht die große Challenge. Vor allem weil man auch relativ wenig von diesen Dingen in dem Sinn nutzt. Also die ganze Intelligenz von diesen Switches, also ich sage es jetzt wirklich ganz plump, im Grunde ist das rein, raus und sozusagen fertig. Da ist jetzt nicht sonderlich viel Intelligenz darin. Weil auch der SDN-Level, also was wird wie geschalten, so auf die Art, das ist ja auch extern in dem Sinn. In der Architektur. Ja, deswegen, meiner Ansicht nach ist es einfach der Herstellermarkt. Der zieht nicht so schnell nach wie er sollte. Gut, jetzt kann man sagen, eh verständlich, weil diese Unternehmen müssen sich dementsprechend auch verändern aber gefühlt zumindest haben das viele verschlafen. Und logischerweise stehen diese Unternehmen auch vor den

157

gleichen Problemen wie viele andere. Sie haben die Mitarbeiter nicht mit dem richtigen Skillset, sie haben zu wenig Entwickler, oder sie haben zu viel Legacy zu Supporten. Also es ist natürlich schwierig. Also da muss man schon auch Verständnis dafür haben. Aber es ist, das Versprechen dauert etwas länger als die Realität. Und man kann natürlich, also teilweise ist es glaube ich durchaus auch im Interesse des Herstellermarktes, dass das etwas länger dauert. Weil man sieht schon, der Markt konsolidiert sich ja. Man hat ja in den letzten Jahren im Grunde auch schon immer wieder, sozusagen, die Firmen kaufen sich gegenseitig auf. Das ist zu beobachten. Es passieren immer mehr Merger. Dadurch werden immer weniger Marktteilnehmer, die einzelnen Firmen werden immer größer, weil diese Unternehmen natürlich wissen, dass sie da wenn sie sich nicht bewegen, in ein immer größeres Problem kommen. Das heißt auf der einen Seite kaufen sie sich auf, sozusagen unter dem Aspekt, also Ressourcen zu kaufen zum Beispiel. Wenn mir sozusagen die Mitarbeiter fehlen mit dem Skillset das ich brauche, na dann kaufe ich mir im Idealfall eine Firma die das hat. Dann kaufen sie sich Kundenstock dazu. Wenn ich meinen Wirkungskreis erweitern will, kaufe ich mir die Firma die unter Umständen in dem Bereich tätig ist wo ich gern tätig sein würde. Und plötzlich bin ich es automatisch. Haben wir jetzt zum Beispiel gesehen mit Riedel und Embrionix aus meiner Sicht. Das ist eigentlich so ein klassisches Beispiel.

47 Ja, stimmt.

48 Die werden in den nächsten Jahren sehr viele, sozusagen, Wandler verkaufen. Das ist sicher so. Und so, oder Vizrt mit NewTek ist aus meiner Sicht auch so ein Beispiel. Hat jetzt teilweise ein bisschen weniger mit IP zu tun, aber auch. Ich meine, die Welt driftet auseinander. Wir werden auf der einen Seite Hochtechnologie Datacenter-Welt bauen und auf der anderen Seite werden wir super semiprofessionelle Heimanwendersituationen haben in der Zukunft. Und alles was dazwischen ist was wir heute so machen, das wird aus meiner Sicht verschwinden. Aber das ist eine Annahme. Ob das so kommt weiß natürlich niemand. Aber man merkt, dass sich viele Firmen einfach darauf vorbereiten, irgendwo. Und sich entsprechend aufkaufen. Und ich glaube es ist durchaus im Interesse der Unternehmen, dass sie natürlich noch mehr, also sozusagen einen Lifecycle, weil man darf natürlich nicht vergessen, viele große Rundfunkunternehmen sind ja in einem ähnlichen Lifecycle. Das heißt große Investitionen finden in einem relativ ähnlichen Zeithorizont immer mal wieder statt. Da liegen jetzt nicht irgendwie 10 Jahre dazwischen. Es ist ja auch kein Zufall, dass viele der großen Rundfunkanstalten jetzt gerade diesen Technologiewechsel schon entweder vollziehen oder gerade anstreben. Weil die Investzyklen halt auch

158

relativ ähnlich sind und auch zumindest zu ähnlichen Zeitpunkten oft ausgelöst werden, oder getroffen werden. Und die Hersteller da, glaube ich, noch einmal, ich will ihnen nichts Böses unterstellen, aber im Grunde müssen sie überleben und Geld verdienen.

49 Das stimmt.

50 Und noch einmal viele Wandler oder Geräte zu verkaufen ist was das angeht kein Nachteil. Das muss aber so nicht in deiner Diplomarbeit stehen (lacht).

51 Weil wir vorher Skillsets und Skills im Allgemeinen angesprochen haben, jetzt von den Herstellern. Wie sieht es denn da bei den eigenen Mitarbeitern aus? Ich meine bei den Operatoren ist es klar, dass sich da nicht großartig etwas tun muss, aber bei den Personen die das Ganze planen und integrieren ist ja doch ein bisschen ein Wandel notwendig. Vor allem die klassischen älteren Broadcastkollegen, nenne ich es jetzt einmal, haben jetzt meistens nicht so das Knowhow was jetzt IP angeht und generell Netzwerktechnik.

52 Wobei ich das gar nicht so als Problem sehe, das sage ich dir auch ganz ehrlich.

53 Gut. Ja.

54 Weil auch die Jüngeren, sozusagen, haben das meiner Ansicht nach auch nicht. Weil, wir kennen es ja auch nicht (lacht). Also, der Standard ist ja auch erst in einer Zeit entstanden wo praktisch, ja der ist ja sozusagen für alle neu, einmal Punkt A. Und Punkt B, dieses ich sage jetzt mal Basic Netzwerkknowhow, ich glaube das haben wir alle irgendwo. Der eine hat es ein bisschen mehr, der andere hat es ein bisschen weniger. Und je nachdem wie lang man, sozusagen, gar nicht mehr operativ in diesen Dingen arbeitet, hat man es natürlich noch einmal viel weniger. Ich zum Beispiel. Ist man natürlich auch relativ schnell heraus aus der Nummer wenn man nichts mehr damit zu tun hat im täglichen Doing. Direkt am Terminal sitzen oder so, oder Codezeilen irgendwo eingeben sozusagen. Ja aber ansonsten, das ist jetzt gar nicht so das große Problem in meiner Wahrnehmung und auch im Feedback was ich immer wieder erhalte. Was zum Beispiel, was für mich ein gutes Beispiel ist, was sich da total verändert und wo es eigentlich noch keine wirklichen Lösungen gibt, ist zum Beispiel Dokumentation. Also du kennst wie ich sag jetzt ein Schaltplan aussieht von deiner Kreuzschiene und so weiter, du weißt wie das aussieht.

55 Ja, klar, genau.

159

56 Wie macht man das für IP? Darauf gibt es eigentlich keine Antwort. Weil, ich sage es jetzt einmal ganz vereinfacht, ein Kabel ist nicht ein Signal. Und wenn wir jetzt, wir reden zum Beispiel dann teilweise im Backbone von 400Gbit Schnittstellen, da kann man sich ausrechnen, jetzt einmal theoretisch einfach nur mal, kann man sich ausrechen wie viel tausende von HD-Signalen oder naja sogar mehrere tausende UHD-Signale, sozusagen, inklusive Audio und so weiter, und Metadaten, man theoretisch dann über eine Schnittstelle bekommt. So, und in welcher Form dokumentiert man das eigentlich sinnvollerweise so dass es A, ein Mensch dann auch wieder lesen kann, man das sich vielleicht auch optisch ansehen kann und irgendwie einen Nutzen daraus zieht. Im Sinne man versteht, Ok, so läuft es, das sind die Signale die da vielleicht irgendwo zu finden sind und all diese Dinge. Und ich glaube da kann zum Beispiel die, oder da muss die Rundfunkindustrie in irgendeiner Form von der IT- Industrie lernen. Weil, sozusagen, die können da nur mehr Knowhow haben. Also da wird man eben einen Weg finden müssen wie beide Welten sich so in irgendeiner Form vereinen, damit schlussendlich eigentlich eine funktionale Dokumentation von dieser Welt eigentlich herauskommt. Das ist zum Beispiel eine Challenge. Dann ist, auf was ich oft hingewiesen werde von Kollegen die produktiv damit arbeiten ist, die Form von Monitoring ist eine ganz andere. Das heißt Telemetriedaten aus deinem Netzwerkbackbone spielen eine viel größere Rolle als Monitoring deiner jetzigen SDI-Infrastruktur. Das ist ein riesen Unterschied. Das sind auch Systeme die ganz anders funktionieren und die liefern dir auch, also Telemetriedaten sozusagen, das sind völlig andere Informationen als wir Informationen aus der Baseband-Welt gewohnt sind. Die muss man lesen können, die muss man verstehen können, die muss man interpretieren können und man muss darauf reagieren können. Und da muss man sicher Knowhow aufbauen im Broadcastbereich. Weil das ist etwas wo die wenigsten damit zu tun gehabt haben. Ich glaube es sind auch die wenigsten so sensibilisiert, dass halt wenn wir von PTP reden, also hochgenaue Taktung von Hardware sozusagen, dementsprechend auch sehr detaillierte Form von eben Telemetriedaten zum Beispiel mit sich zieht. Und man da eben wirklich bis runter in das kleinste Detail dann teilweise muss um sozusagen den Fehler zu finden, sollte ein Fehler gewesen sein, schlussendlich bei der, keine Ahnung, Ausspielung eines Files von irgendeinem Videoserver. Weil es kann ja am Takt liegen. Das sind Dinge die heute zum Teil ja gar nicht gemacht werden in der Rundfunktechnik. Das wird sicher in der klassischen Messtechnik, wird das schon gemacht. Aber ich bezweifle, dass du und deine Kollegen aktuell gerade viele Monitoringdaten euch anseht was die Taktung des Gesamtsystems angeht.

160

57 Das stimmt. So lange da nichts brennt, wird da nichts angesehen.

58 Genau. Und das ist glaube ich schon ein riesen Unterschied zu IP. Das eben dieses Monitoring, also A, du brauchst intensiveres Monitoring, und B, du brauchst eben natürlich tieferes Verständnis dafür. Und du musst schlussendlich dann auch das Knowhow haben im Fehlerfall einzugreifen. Ich glaube es ist auch ein riesen Thema, also die Darstellung dieser Daten. Da gehen auch die Meinungen sehr auseinander, also wie macht man die überhaupt lesbar. Da gehen die Hersteller unterschiedliche Wege. Da gibt es natürlich auch unterschiedliche Vorlieben bei den Menschen die damit arbeiten, eh klar, wie immer. Und da wird man, da ist es sicher auch irgendwann einmal von Vorteil wenn da vielleicht auch irgendeine Art von Industriestandard entsteht oder so. Der jetzt glaube ich, so mein Verständnis, so nicht vorhanden ist.

59 Gut. Also ich sage es dir ganz ehrlich, ich bin eigentlich mit meinen Fragen durch. Wir haben auch relativ viel angesprochen, sehr schön zusammengefasst. Gibt es aus deiner Sicht noch Ergänzungen oder Anmerkungen die jetzt nicht vorgekommen sind die du für wichtig hältst und unbedingt loswerden möchtest wenn es um das Thema geht?

60 Kurz nachdenken. Ja, ich glaube wirklich das wichtigste in dem Kontext ist glaub ich, dass man sich wirklich gut überlegt, was will man damit einfach erreichen. Es ist, aus meiner Sicht besteht einfach eine große Gefahr, dass man sich da rein, dass der reine Technologiewechsel ist im Sinne, ich nenne es jetzt einmal grüne Kabel auf Netzwerkkabel, so auf die Art. Das ist es nicht. Also wenn es nur das ist, dann ist man am falschen Dampfer. Dann kostet es viel Geld und man sollte sich überlegen ob man das tatsächlich macht. Ja, ich glaube das ist es.

61 Gut.

161