Der Bayerische Rundfunk (BR) arbeitet neuerdings mit einer der modernsten technischen Broadcast-Einrichtungen in Europa. Ohne viel Aufsehen zu erregen wurde das neue digitale Sendezentrum in München Freimann (SZFM) in den letzten Monaten sukzessive in Betrieb genommen. Am 28. März war dann offizieller Start.
Mit den ersten Planungen hatte der BR bereits 1996 begonnen. Im Frühjahr 2001 gab es schließlich eine erste öffentliche Projekt-Ausschreibung. Die musste aus formalen Gründen jedoch wieder zurückgezogen werden. Im Mai 2002 wurde schließlich erneut das Gesamtprojekt ausgeschrieben und im September 2002 erfolgte dann die Vertragsunterzeichnung mit dem Systemhaus T-Systems, das als Generalunternehmer den Bau des Sendezentrums realisieren sollte. Als Subunternehmer dabei und verantwortlich für die Bereiche Automation sowie Video- und Audiotechnik war Studio Hamburg Media Consult International (MCI), ein Tochterunternehmen des NDR.
Als ursprünglicher Fertigstellungstermin war laut Vertrag der 7.6.2004 vorgesehen. Insgesamt arbeitete T-Systems bei dem Großprojekt mit rund 100 Lieferanten und Partnern zusammen.
Das SZFM-Projekt war nötig geworden, weil die alte Betriebszentrale (BZ) des BR in Freimann schon seit 1987 im Einsatz und vom technischen Konzept und den Betriebsanforderungen her längst nicht mehr zeitgemäß war. Geplant wurden deshalb die Erneuerung der sendetechnischen Einrichtungen, der Ersatz der technischen Einrichtungen der alten BZ und die technisch-organisatorische Neustrukturierung der Betriebsabläufe in einem Neubau. Außerdem beschloß man die Umstellung des Fernseharchivs auf Servertechnologie und Robotic-Systeme. Das alte Bandarchiv sollte durch ein in die Gesamtstruktur des Fernsehens integriertes und vernetztes Digitalarchiv ersetzt werden.
Neben der Realisierung eines zentralen Speichersystems, eines digitalen Archivsystems und der Anbindung von Videoservern und Schnittsystemen an das zentrale Speichersystem waren für den BR insbesondere auch die Interaktion der Automation mit dem Material- und Ressourcenmanagement sowie dem zentralen Speicher und dem Archivsystem und eine ausreichende Netzwerkbandbreite für Fileübertragungsprozesse von zentraler Bedeutung.
Auch der EB-Bearbeitungsbereich im SZFM wurden im Laufe des Projekts sukzessive erneuert. Heute sind dort 40 Avid MediComposer Adrenalin-Schnittplätze und sechs Unity-SANs im Einsatz.
Das Investitionsvolumen bei Bau und Technik inklusive Digitalarchiv, Schnittsystemen und der Realisierung aller nötigen Change Requests beziffert der BR auf rund 60 Mio. Euro.
Maßgeblich für die Entwicklung des Projekts war die Formatentscheidung des BR im Jahr 2000. Um filebasiertes Arbeiten zu ermöglichen, wählte man für den HighRes-Bereich MPEG2 IMX (50 Mbit/s) und das Datenaustauschformat MXF, für den LowRes-Bereich MPEG1 (1.5 Mbit/s).
Mittelfristiges Ziel des BR ist es, auf Basis des neuen digitalen System auch komplett bandlos arbeiten zu können. Die Entscheidung darüber, welches Akquisitionsformat künftig eingesetzt werden soll, wird voraussichtlich im Frühjahr nächsten Jahres fallen.
Zentralspeicher von Omneon
Der Zentralspeicher im SZFM sollte ursprünglich mit einem SGI-System realisiert werden. Das funktionierte jedoch nicht. Es erfolgte daher ein Wechsel auf Omneon-Server.
Im Zentralspeicher existieren nun drei Omneon-Knoten mit insgesamt 84 Ports von denen gleichzeitig entsprechend viele SDI-Streams abgegeben werden können. Die Knoten sind bestimmten Aufgabenbereichen zugeordnet: Knoten eins mit 31 Ports dem Rohmaterial (hierüber laufen alle Ingestvorgänge und Überspielungen), Knoten zwei mit 30 Ports dem Produktionsmaterial und Knoten drei mit 23 Ports dem Transfermaterial (hierüber läuft das komplette Sendematerial). Die Omneon-Knoten werden auch für Studiozuspielungen benutzt. Das heißt, von diesen Knoten werden Zuspielbeiträge ins Studio gespielt und der Mitschnitt wieder auf dem Knoten aufgezeichnet.
Die Speicherkapazität auf den Omneon-Knoten reicht für insgesamt ca. 2.000 Stunden IMX-Material (einmal 600 und zweimal 700 Stunden).
Die Einspielung von SDI High-res-Material auf den Zentralspeicher erfolgt an mehreren Ingest-Stationen über die zentrale Kreuzschiene (ZKS) in Echtzeit. Gleichzeitig wird automatisch Low-res-Material auf dem Browse-Server für die Weiterverarbeitung im Content-Management-System generiert. Via GigabitEthernet bzw. FTP (File Transfer Protocol) ist der Zentralspeicher,mit dem Bearbeitungsbereich (AVID-Schnitt-Systeme), dem Archiv (Robotic) und den Senderservern vernetzt. Jedes File wird als Objekt in der Automation und dem CMS registriert und kann dort mit Metadaten angereichert und auch wieder recherchiert werden.
Alle wichtigen Produktions- und Videoserversysteme sind zusätzlich über SDI-Verbindungen miteinander vernetzt. Mittelpunkt bildet dabei ein Kreuzschienensystem
der Fa. ProBel, welches von einem BFE-Kreuzschienen Controller gesteuert wird.
Bei dem Browse-Server handelt es sich um ein NAS-System auf welchem sowohl die Endoder /Transoder (schreibend) auch als die Streamserver des CMS-Essence-Managements Zugriff (lesend) haben..
Als Interface zwischen der Avid-Unity-Umgebung zum Zentralspeicher und Archivsystem setzt der BR auf die Medway-Software von Marquis. „Avid konnte bei Projektbeginn die nötigen Schnittstellen nicht bereit stellen. Wir waren deshalb gezwungen, ein anderes Unternehmen dafür zu suchen“, sagt BR-Fachgruppenleiter Fernseh-Planung Dipl.-Ing. Herbert Gerstmayr. Marquis Medway-Software biete heute indes eine sehr komfortable Lösung mit einigen Alleinstellungsmerkmalen.
Bei den drei Omneon-Knoten gibt es laut BR bereits absehbare FTP-Engpässe. „Wir versuchen deshalb, das System von der Nutzung her zu optimieren. Man kann halt nicht zu viele verschiedene Dinge gleichzeitig machen. Wir haben auch bestimmte Zeitfenster für den Archivtransfer eingerichtet, um in der übrigen Zeit keine Engpässe beim Browsing zu haben. Das schränkt natürlich etwas ein, läßt sich aber auf organisatorische Ebene durchaus regeln“, meint Gerstmayr.
Außerdem haben die BR-Planer eine weitere Problemlösung für den reibungslosen Filetransfer entwickelt. Um den Zentralspeicher-Bandbreitenbedarf zu reduzieren wird alles, was den MXF-Transfer zur Unity-Umgebung betrifft, statt über die Omneon-Knoten nun über ein extra FTP-Server (NAS-System) geleitet. Der heißt beim BR Unity Import Server. „Es waren natürlich auch noch diverse Anpassungen der Marquis Software Medway nötig bis sie auch mit dem FTP-Server kommunizieren konnte. Aber in der Zwischenzeit funktioniert das reibungslos“, berichtet der Leiter des Sachgebiets „Systemplanung Archive“ Dipl.Ing (Fh) Wolfgang Englmaier.
Nur im Havariefall sei der FTP- gegenüber dem Omneon-Server im Nachteil. Schließlich habe er keine Video-Ports. „Für den Medway Havariefall könne aus dem Omenons immer noch per SDI auf die AVIDS transferriert werden. Das CMS stellt nämlich neben einer XML-Import Referenzdatei für Medway auch immer eine AAF-Datei (Advanced Authoring Format) bereit. Und die kann direkt vom Avid-System geladen werden. Im Hintergrund gelangt dann das Material per BVW-Steuerung der Omneon-Ports in die AVID-Systeme“ erklärt BR-Projektingenieur Englmaier.
Das System-Architektur-Modell im SZFM ist dreischichtig aufgebaut. Zwischen der Speicher-Ebene (mit Archiv, dem Browse-Server und dem Omneon-Zentralspeicher) und der Applikationsebene (mit Bearbeitung, Produktion und CMS) liegt eine Transport- und Steuerschicht die sowohl durch Automations- als auch von CMS-Komponenten realisiert wird. Bestellvorgänge über die CMS-Applikation werden über das CMS-Transfermanagement direkt an das Archivspeichersystem (DIVA von Frontporch) weitergleitet. Dieses steuert dann den High-res Transfer vom Datenband auf die Videoserver. Nach erfolgreichem Transfer stellt das CMS die oben erwähnten Import-Referenzdateien für Medway bzw. Avid bereit. Bei Materialtransfers aus dem Archiv in Richtung Sendeserver ist das CMS nicht beteiligt. Hier steuert die Automation über sog. Transmission-Lists den Restore aus dem Archivspeichersystem. Ebenso werden derzeit noch alle Archivierungsvorgänge über die Harris-Automation initiiert.
„Die Harris Automation steuert daneben alle Ingest und Playout Vorgänge. Einspielungen in den Zentralspeicher werden darüber vorgenommen. Die Harris-Applikation legt beim Ingest einen eindeutigen Filenamen fest, der dann sofort im ganzen System einschließlich dem CMS zur Verfügung steht und auf welchen durchgängig referenziert wird“, erklärt Englmaier. Die transparenten Behandlung der von der Harris-Automation gelieferten Metadaten über alle Workflows hinweg war nach Angaben von Gerstmayr eine besonders schwierige Aufgabe bei der Realisierung des SZFM-Projekts.
Bestellvorgang
Ein BR-Redakteur kann jetzt im CMS das komplette Material im Archivsystem und im Zentralspeicher in Low-res sichten und browsen. Er sammelt dort das benötigte Material und löst dann eine Bestellung aus. Sie kann komplette Objekte beinhalten aber auch Schnittlisten. Die Bestellung wandert als nächstes zur Archiv-Abteilung und wird hier von einem sogenannten Order Dispatcher auf ihren lizenzrechtlichen Status hin überprüft (anhand der im CMS geführten Ampelfarben) Ist das Material rechtlich unbedenklich (grün) wird die Bestellung automatisch zum nächsten Prozessschritt durchgeleitet. Ist ein Teil einer Bestellung indes rot Teil markiert, muß der Order Dispatcher die Rechtesituation erst klären oder die Bestellung aus dem Vorgang löschen.
Den nächsten Schritt im CMS erledigt der BR mit dem Transfer Manager. Mit diesem CMS-Softwaretool von Blue Order werden alle Transferaufträge gesteuert, aktiviert und frei gegeben. Aktivierte Transfers werden, wie oben bereits erwähnt, an das Archivsystem mit der DIVA-Middleware DIVAchive von Front Porch Digital weitergeleitet. Dieses kopiert dann die MXF-Files in Abhängigkeit des angegebenen Zielsystems auf den FTP-Server oder auf den Zentralspeicher.
Die XML-Datei ist quasi die Schnitt- oder Playliste (EDL) der Bestellung und kann per Drag- and Drop nicht nur einem der sechs Unity-Systeme sondern hier auch noch zusätzlich einem speziellen Workspace zugeordnet werden. Das „Droppen“ der EDL auf einen Workspace veranlaßt Medway das Material von den Omneon-Knoten oder dem Unity-Import-Server in die AVID-Welt zu transferrieren. Aus der EDL wird von Marquis weiterhin eine AVID-konforme Sequenz generiert und in einer BIN abgelegt.
Das heißt, man kann seinen Rohschnitt aus dem CMS im Avid 1:1 weiter bearbeiten. Das gibt es momentan sonst nirgendwo. Meines Wissens lassen sich zwar Einzelfiles importieren aber nicht der komplette Schnitt, – vor allem wenn darin Archivmaterial und Material auf den Videoservern gemischt vorliegt „, betont Englmaier.
„Im CMS hat jeder Benutzer, jeder Redakteur, seine eigene Arbeitsumgebung, ähnlich einem Ordner, an die er seine für ihn relevanten Objekte (Files) virtuell bindet.Er kann also eine Materialsammlung anlegen, seine EDLs speichern und diese dann zu einem beliebigen Zeitpunkt in Auftrag geben, bzw. das High-res-Material, das damit verbunden ist, bestellen. Das System bildet darüber hinaus noch weitere Workflow-Funktionalitäten ab. Wir sind dabei, die hier noch weiter zu optimieren“, erklärt Englmaier.
Der BR ist derzeit dabei, die Media Archive Software 2.9 auf die Version 3.2 aufzurüsten.
Für die Encodierungs- bzw Transkodierungssysteme nutzt der BR D.A.V.I.D.-Komponenten. Dabei handelt es sich um den Indexer (Transcoder) und den Ingester (Encoder). „Wir haben uns für D.A.V.I.D. entschieden, weil wir überzeugt waren, dass das Unternehmen in der Lage ist MXF/IMX (D10) Files fehlerfrei zu verarbeiten. sagt der BR-Projektingenieur.
Robotic-Archivsystem
Das neue Datenband-Archivsystem des BR befindet sich im Untergeschoß des SZFM. Es besteht aus zwei Bandrobotern vom Typ SUN (ehemals STK 9310). Jedes System (Site A und B) hat maximal 6.000 Stellplätze, derzeit bestückt mit je 1000 200 GB Kassetten.Aus Redundanzgründen liegt auf beiden identisches Material.
Vom Zentralspeicher wird das Material zunächst auf Site A abgelegt. Eine Kopie wandert gleichzeitig auf Site B. Beim Restore wird jedoch von beiden Sites gleichzeitig zurückgespielt. „Wenn jetzt zehn Anforderungen von der Automation oder dem CMS kommen, dann kann jeweils eine Site die Hälfte der Anfragen bearbeiten. Es findet automatisch eine Lastverteilung statt. Das erhöht die Performance“, erklärt BR-Projektingenieur Englmaier. Die Lastverteilung des Archivsystems erledigt die DIVA-Middleware..
Beim BR geht man davon aus, dass im neuen Fernseharchiv pro Jahr rund 5.000 Stunden neu produziertes Material gespeichert werden. Darunter sollen sich ca. 2.500 Stunden Neuproduktionen, 500 Stunden Euronews-Material und ca. 1.800 Stunden Cleanfeeds befinden. Letztere sind die Zuspielbeiträge. „Für die Wiederverwertung ist meist das Cleanfead-Material ohne Bauchbinden und Logo für den Redakteur interessant. Das heißt wir speichern z. B. den Sendungsmitschnitt der Rundschau und zusätzlich das vorhandene Cleanfeed-Material für die Wiederverwertung“, erklärt Englmaier.
Zudem soll in dem neuen Archiv die Bestandssicherung von Video-Band-Material erfolgen. Geplant ist, innerhalb von sieben Jahren, eine passive Bestandssicherung von ca. 16.000 Stunden und eine aktive Bestandssicherung von ca. 31.000 Stunden zu realisieren. Zudem soll das Archiv auch der filebasierten Bestandsicherung von Filmmaterial dienen. Der BR verfügt noch über viele 16mm-Filme.
Eine Hochrechung des Speicherbedarfs der nächsten zehn Jahre geht davon aus, das pro Jahr 10.000 bis 14.000 Programm-Stunden dazu kommen. Ab dem siebten Jahr nach Inbetriebnahme des Archivs soll die Bestandssicherung abgeschlossen sein. Dann wird mit nur noch 6.800 Stunden pro Jahr gerechnet. Nach zehn Jahren hätte der BR dann rund 113.000 Stunden Material im Archiv. Dafür wären dann etwa vier Petabyte (vier Millionen Gigabyte) Speicherplatz nötig. Das bedeutet, dass die Speicherkapazität sukzessive aufgerüstet werden muß. Englmaier: „Die in der Regel wirtschaftlichste Vorgehensweise ist es, immer die neueste Laufwerkstechnologie einzusetzen – sobald diese stabil läuft..,Heute erreicht man durch den Umstieg auf die nächste Generation eine Verdoppelung der Speichertiefe..“ Beim Einsatz der heutigen 200 GByte Datenspeicher wären bei einer angenommenen Speichermenge von 10.000 Programm-Stunden nach einem Jahr schon 1.750 Slots und die insgesamt verfügbaren 6.000 Slots im Robotic schon nach drei Jahren fast alle belegt. „Also muß man rechtzeitig auf die nächste Tapegeneration zum Beispiel mit 500 GByte Speicher umstellen. Neben günstigeren Speichermedien hat man dann auch gleich neuere und performantere Technik im Einsatz.
Anfang nächsten Jahres rechnen wir beim BR damit, eine neue Drivetechnologie einzusetzen“, erklärt Englmaier.
Im Robotic System ist die aktuelle Ausbaustufe so, dass pro Site 1.000 Slots mit Datenbändern gefüllt und 5.000 noch frei sind. Pro Library gib es sechs Datenlaufwerke, die gleichzeitig Datenbänder lesen und schreiben können.
An das Archiv-Speichersystem ist ein Videoarchiv-Server von Omneon angeschlossen. Dieser kleine Knoten mit 100 Stunden Speicher, sechs SDI- und zwei FTP-Ports gehört nicht zum Hauptspeicher. Auf ihm wird auch nicht produziert. Primär wird dieser Omneon-Server für Ausspielvorgänge genutzt. „Wenn wir neuproduziertes Material nur noch filebasiert speichern, müssen wir davon auch Bänder generieren können. Ein Grund hierfür ist die Tatsache, daß eine großer Teil des Programmaustausches innerhalb der ARD weiterhin über Bänder erfolgt. Also kopieren wir das File vom Archivspeichersystem auf den Video-Archivserver, der mit zwei Flexicarts verbunden ist. Über diese erfolgt dann die Ausspielung auf Band“, erklärt Englmaier. Künftig soll der Omneon Videoarchiv-Server jedoch auch genutzt werden, um darüber Material in das Archiv einzuspielen.
Ursprünglich sollte das Archivprojekt in zwei Schritten realisiert werden. Zunächst sollte ein Basisarchiv mit Minimalanforderungen gebaut werden, das dann im zweiten Schritt zur maximalen Ausbaustufe geführt werden sollte. „Auf Grund der langen Laufzeit und der wachsenden Anforderungen waren wir gezwungen, wesentlich mehr Funktionalität als geplant zu realisieren. Somit besitzt der BR heute ein fast vollständig in den Produktionsprozess integriertes Archiv. Neue Anforderungen begründet durch neue Produktionsformen und Formate erfordern immer mehr Flexibiltät „seitens der Software aber auch auch vom Menschen, der sie noch bedienen können muss“ berichtet Englmaier….,
Eckhard Eckstein (MB 05/07)
