Nachdem im letzten Kapitel eine genaue Analyse mit der Erörterung des „State of the Art“ erfolgt ist, beschreibt dieses Kapitel zuerst das technologische Konzept des auf der Basis der vorausgehenden Erörterungen gewählten Lösungsansatzes. Anschließend werden einige Eckpunkte der konkreten Implementierung beschrieben. Eine ausführliche Beschreibung der realisierten Software und ihrer Funktionen befindet sich im Anhang.
Bevor auf die gewählten technologischen Konzepte der einzelnen Komponenten im Detail eingegangen wird, an dieser Stelle zur besseren Übersicht vorab eine Gesamtübersicht der Architektur (siehe Abbildung 120).
Abbildung 120: Anwendungsarchitektur
In der vorliegenden Abbildung 120 erkennt man das Schema dieses Lösungsansatzes. Im Zentrum steht die „TV-Studio-Mixer-Anwendung“. Diese ist in der Lage wahlweise oder gleichzeitig einem Teil der Zuschauer den Live-Videostream über einem Streaming-Server mittels individuellen Unicast-Streams (siehe Kapitel 2.8.3. „Distributionstechniken“) sowie einen anderen Teil durch Benutzen einer „Third-Party-P2P-Awendung“ über ein P2P-Overlay-Netz (siehe Kapitel 2.8.3.5 „Peercasting, das Peer to Peer – Grundprinzip“) zu bedienen. In beiden Fällen ist die Programmplanungsinternetseite selbst über einen entsprechenden Webserver abrufbar. Einerseits werden so für die Zukunft keine vielversprechenden Verbreitungswege verbaut, andererseits bietet dieses Konzept die Möglichkeit z.B. Zuschauer, die etwas gespendet haben über den Streaming-Server „direkt“ und so in besserer Qualität zu bedienen. Gleichzeitig können die anderen Zuschauer über das kostengünstigere P2P-Overlay-Netz angebunden werden.
Kurzfristig ist zu diesem Zweck „Adobe Flash“ klar die beste Alternative im hiesigen Kontext. Später kann einmal über einen Mini-Streaming-Server in Form eines Java-Applets oder einer extra zu installierenden Clientsoftware (z.B. VLC oder GoalBit) über „localhost“ ein über ein „third-party-P2P-Netz“ (wie z.B. „GoalBit“ oder „Tribler“ – siehe Kapitel 2.8.10 „P2P-Streamingprojekte“) empfangenes Live-Video-Streamingsignal zum Flash-Player im Browser geschickt werden. Abgesehen davon, dass hier schon entsprechende Bausteine vorhanden sind, ist dieser „Umweg“ schon alleine deshalb nötig, da man mit Flash schon aus Sicherheitsgründen keine fortgeschrittene Netzwerkkommunikation – wie sie für den Betrieb eines P2P-Netzes nötig ist – realisieren kann.
Zum späteren Hinzufügen interaktiver, d.h. in der Regel anklickbarer, Elemente ist Flash auch eindeutig am Besten geeignet. Mit dieser Wahl werden in dieser Hinsicht auch die besten Voraussetzungen geschaffen. Flash wird aus aktueller Sicht auch innerhalb kürzester Zeit auf nahezu allen wichtigen Mobiltelefon-Plattformen verfügbar sein, d.h. dass auf diese Weise die Live-Streams auch direkt auf Mobiltelefonen betrachtet werden können.
Allerdings ist diese Entscheidung nicht endgültig. Man wird regelmäßig den Markt neu analysieren müssen. Denn vielleicht kann Silverlight bald Marktanteile gewinnen (z.B. durch eine aggressivere Verteil-Technik über den „Windows-Update“-Mechanismus [Mic09j]) und Microsoft wird vielleicht bald die fehlende Unterstützung für Eingabegeräte (Webcams usw.) nachrüsten, um zu Flash aufzuschließen. Da die TV-Studio-Anwendung unabhängig von der Distributionstechnik realisiert wird kann später mit geringem Aufwand zu einer anderen Distributionsweise gewechselt werden.
Als benutzter Streaming-Codec kommt derzeit alleine aus Lizenzgründen eigentlich nur On2 VP6 (ein von Flash unterstütztes Format) in Frage (siehe Kapitel 2.8.5.4 „Codec-Lizenzierungsbedarf“). Besonders da für das derzeit noch überall verwendete, besser optimiertere Format MPEG-4, ab 2010 in vielen Einsatzszenarien Lizenzkosten an die MPEG-LA [MPE09] bezahlt werden müssen.
Aber auch dieser Bereich entwickelt sich dynamisch und wird daher regelmäßig neu analysiert werden müssen. Denn vielleicht wird Microsoft doch einmal das Open-Source-Video-Format OGG im Rahmen der HTML5-Kompatiblilität in seinen Internet-Browser integrieren. Andererseits hat kürzlich Google die Firma „On2“ aufgekauft. Bisher sind allerdings noch keine Konsequenzen aus dieser Übernahme bekanntgeworden. Vielleicht will Google hier dieses Format entsprechend weiterentwickeln um es zu einem ernsthaften „freiem“ Konkurrenten von MPEG-4 werden zu lassen? Voraussetzung hierfür wäre dann allerdings eine Partnerschaft mit Adobe damit zukünftige Flash-Versionen auch diese erweiterte Version unterstützen würden.
Auch hier bleibt es also spannend. Es erscheint besser sich heute nicht auf einen Codec festzulegen und die Architektur so aufzubauen, dass jederzeit ein Wechsel desselben möglich ist.
Bei der Distributionstechnik ist das Internet derzeit sehr im Wandel begriffen. Eine Festlegung auf beispielsweise „nur P2P“ oder „nur Unicast Streaming“ erscheint als nicht sinnvoll. Es hat sich auch gezeigt, dass selbst kommerzielle P2P-Systeme noch nicht die nötige Praxistauglichkeit besitzen. Dies kann sich allerdings ändern, besonders wenn es gelingt in der Zukunft Systeme zu entwickeln, die den Interessen aller Beteiligten (vor allem die der Zuschauer und der Internetprovider) befriedigen können (siehe Kapitel 2.8.10.6 „Tribler“ und Kapitel 2.8.5.5 „Interessen der Internetprovider“).
Deshalb erscheint es als die beste Strategie sich alle Möglichkeiten für die Zukunft offen zu halten um jederzeit flexibel auf sich abzeichnende Entwicklungen reagieren zu können. Denn schließlich könnten Projekte wie „Tribler“ oder „GoalBit“ (siehe Kapitel 2.8.10 „P2P-Streamingprojekte“) schon bald so weit fortgeschritten sein, dass sie sich bereits sinnvoll im Rahmen des Projektes einsetzen lassen.
In einem ersten Schritt ist es von daher ausreichend gängige, in der Regel Flash-basierte, Live-Streaming-Dienste (wie z.B. ustream.tv, siehe Kapitel 2.8.7 „Kommerzielle Live-Streamingdienste“) zu verwenden und diese mit einem entsprechenden Video-Player als Elemente in die Programmplanungs-Webseite zu integrieren.
Für die Implementierung der TV-Studio-Mixer-Anwendung scheint eine Windows-Client-Anwendung basierend auf dem Windows-DirectShow-SDK mit Hilfe des VH-Media-SDKs die beste Lösung darzustellen. Im Vergleich zu einer Implementierung, die mangels geeignetem Cross-Plattform-Video-SDK (siehe Kapitel 2.8.11 „Frameworks zur vereinfachten Videomanipulation“) nur auf Linux lauffähig wäre, erscheint dies immer noch als die geeignete Lösung, denn schließlich benutzen immer noch die meisten Computeranwender weltweit ein Betriebssystem der Windows-Familie. Und alle aktuellen Mac sowie Linux-Computer verfügen oft bereits standardmäßig über die entsprechende Software um Windows-Programme ausführen zu können. Dies ist umgekehrt nur selten der Fall.
Warum nicht in Flash?
Flash-Anwendungen, die im Flash-Client ablaufen, sind im Zugriff auf das Betriebssystem aus Sicherheitsgründen stark eingeschränkt. Deshalb kann die TV-Video-Mixer-Anwendung auch nicht clientseitig mit Hilfe von „Flash“ realisiert werden, da es hier nur mit sehr großem Aufwand an Grundlagenforschung möglich wäre, das gemischte Ausgabevideo wieder als virtuelle Videoquelle anderen Anwendungen zur Verfügung zu stellen. Eine serverseitige Implementierung, wie dies bei den Diensten make.tv und Livestream der Fall ist, kommt schon aus Kostengründen im Rahmen dieses Projektes nicht in Frage.
Andererseits sind Flash-Anwendungen durch die zusätzliche Abstraktionsschicht in der Regel auch etwas langsamer als Anwendungen die direkt auf dem entsprechenden Betriebssystem aufsetzen. Das verwendete VH-Media-SDK (und dessen direkt auf Microsoft-DirectShow aufsetzende Filter) sind in C++ entwickelt worden und so entsprechend im Hinblick auf die Geschwindigkeit optimiert worden.
Warum nicht in Java?
Das „Java Media Framework“ (siehe Kapitel 2.8.1.2 „Sun Java Runtime“) ist veraltet und mangels entsprechender Formatunterstützung müsste man um annähernd den Funktionsumfang und vor allem die Unterstützung aktueller Videoformate wie mit dem VH-Media-SDK zu erreichen sehr viel Grundlagenentwicklung betreiben, d.h. man müsste selber En- und Decoder für diverse neuere Codecs programmieren usw. Dies würde den zeitlichen Projektrahmen bei weitem sprengen. Weiterhin bliebe es auch hier eine größere Herausforderung die Ausgabe zu einer virtuellen Videoquelle zu realisieren. Der Vorteil der plattformübergreifenden Lösung wäre hier auch relativ, denn zumindest die letztgenannte Funktionalität müsste auf jeder Plattform anders realisiert werden.
Wie bereits erörtert (siehe...
