© Admira #2, Photocase.com

Youtube, Myspace & Co. haben es populär gemacht: Flash ist inzwischen das Standardformat für multimediale Inhalte im Netz. Während diese Sites ihre Inhalte per progressivem HTTP-Download anbieten, setzt richtiges Streaming den kommerziellen Flash-Server voraus, den dieser Artikel näher vorstellt.

Nachdem der Streaming-Markt früher zwischen Windows Media, Real und Quicktime aufgeteilt war, versucht nun Adobe mit der Integration der standardisierten Mpeg-4-Formate H.264 und AAC die bereits starke Position von Flash noch weiter auszubauen. Auf Seite der Clients sorgt dafür der frei verbreitete Flash Player für Mac, Windows und Linux. Server-seitig verkauft Adobe seinen Flash Media Server als kommerzielles Produkt, das in der aktuellen Version 3 auch für Linux verfügbar ist [1].

Streaming statt HTTP

Den großen Durchbruch haben Flash-Videos durch die so genannten progressiven Downloads à la Youtube erlangt. Dabei lädt der Client (Flash Player im Browser) Audio- oder Videodaten über HTTP herunter und spielt sie bereits während des Downloads ab. Der Vorteil: Es fallen keinerlei Lizenzkosten für Streamingserver an, da der gesamte Datenverkehr über den Webserver läuft. Außerdem gibt es keine Schwierigkeiten mit Firewalls, da der HTTP-Port 80 ohnehin fast immer freigegeben ist.

Ein richtiger Streamingserver kostet demgegenüber erst einmal Geld, verursacht zusätzlichen Administrationsaufwand und verbreitet die Inhalte über exotische Protokolle wie RTSP, die in der Regel von Firewalls zumindest in Firmennetzwerken geblockt werden.

Es gibt aber einige entscheidende Vorteile: Zunächst werden keine Daten auf die Festplatte des Clients heruntergeladen, ein Stream belegt stattdessen nur einen Teil des Arbeitsspeichers. Während der Wiedergabe lädt der Client einen Datenpuffer (meist etwa 10 Sekunden des Videos) fortlaufend nach, während er die wiedergegebenen Informationen gleich wieder verwirft. Die Navigation in einem Stream ist daher für den Nutzer wesentlich komfortabler, da er bereits unmittelbar nach dem Start bis kurz vor das Ende springen kann, weil der Client dazu ja nur den Puffer nachladen muss. Eine Kapitel-ähnliche Navigation wie bei DVDs ist daher praktisch nur mit einem Streamingserver umsetzbar.

Unter Umständen kann ein Streamingserver damit auch Kosten sparen, da er immer nur den Teil des Videos überträgt, den der Anwender auch ansieht. Bei Youtube beispielsweise lädt der Browser ein 10-Minuten-Video immer komplett herunter, sofern der Nutzer nicht das Browserfenster schließt.

Live-Flash nur mit dem Adobe FMS

Eine Live-Übertragung von Flash-Videos einer Veranstaltung ist nur mit einem Streamingserver möglich. Außerdem kann der Server durch die ständige Kommunikation mit dem Client die verfügbare Bandbreite des Nutzers messen und bei entsprechend encodiertem Material dynamisch bandbreitengerechte Streams ausliefern. Die meisten Streamingserver bringen auch Clustering-Funktionen zur Verteilung der Netzwerklast und Erhöhung der Ausfallsicherheit mit.

Die Logdateien eines Streamingservers enthalten ausführlichere Informationen zur Mediennutzung, als das mit einem Webserver möglich wäre. Zum Beispiel erfassen sie genau die Betrachtungszeiten jedes einzelnen Streams mit dem übertragenen Datenvolumen. Diese Informationen sind für Inhaltsanbieter wie die Deutsche Welle natürlich besonders interessant, für die der Autor im Bereich Streaming Development arbeitet.

Mit dem Einsatz des Flash Media Server (FMS) lassen sich die Vorteile eines Streamingservers mit den Stärken des Flash-Formats verbinden. Der Flash Player ist für alle drei wesentlichen Plattformen (Windows, Linux, Mac OS) in aktuellen Versionen mit identischem Funktionsumfang verfügbar und hat eine hohe Verbreitung von über 90 Prozent aller Internet-fähigen Computer. Mit der Flash- oder Flex-Entwicklungsumgebung lassen sich inzwischen sehr leistungsfähige Anwendungen entwickeln.

Im Wesentlichen gibt es zwei verschiedene Editionen des FMS 3. Zunächst den Flash Media Streaming Server 3: Er kostet 995 US-Dollar und kann Flash- und Mpeg-4-Videos sowie MP3-Dateien streamen. Der Flash Media Interactive Server zum Preis von 4500 US-Dollar bietet zahlreiche ergänzende Features: Er kann zum Beispiel geclustert werden und unterstützt Server-seitiges Skripting. Das ist nützlich, um interaktive Videochat-Anwendungen zu realisieren oder um von den Nutzern per Webcam aufgezeichnete Videos auf dem Server zu speichern. Zudem lässt sich der Interactive Server über eigene in C++ geschriebene Plugins erweitern, auch unterstützt er die Benutzer-Authentifizierung per LDAP.

Die kostenfreie Developer Edition entspricht im Funktionsumfang dem Interactive Server, ist aber auf zehn gleichzeitige Nutzer beziehungsweise Netconnections beschränkt. Hintergrund: Der Flash Player baut Netconnections (bidirektionale Verbindung für die Steuerung des Streams) zum Server auf, um anschließend per Netstream-Objekt (unidirektionale Verbindung) Audios oder Videos zum Client zu streamen (Abbildung 1).

Abbildung 1: Der Flash Media Server im Zentrum der Streaming-Welt. Als Grundlage für die Produktion dient der Media Encoder, zum Anschauen der Flash Player.

Adobe hat das Lizenzmodell des FMS drastisch überarbeitet. Während bei früheren Versionen die Lizenzen nach einer bestimmten Nutzeranzahl berechnet wurden (FMS 2 bediente beim Preis von 5500 US-Dollar maximal 100 gleichzeitige Nutzer), sind die aktuellen Versionen nicht mehr eingeschränkt.

Es gibt zwei Alternativen zum Flash Media Server: das Open-Source-Projekt Red5 [2] sowie den kommerziellen Wowza Media Server. Letzterer bietet im Wesentlichen alle Features des Flash Media Interactive Server, aber zu dem deutlich geringeren Preis von 995 US-Dollar. Beide Server beruhen auf Reverse Engineering beziehungsweise einer Eigenentwicklung des Streamingprotokolls.

Glaubt man den diversen Internetforen wie zum Beispiel [3] und berücksichtigt dabei die eher Open-Source-freundliche Grundhaltung von Adobe, lässt sich mit einiger Vorsicht davon ausgehen, dass Adobe die Patentansprüche auf das Protokoll wahrscheinlich nicht juristisch durchsetzen wird.

Ports und Protokolle

Der FMS 3 setzt für die Datenübertragung der Streams das proprietäre und von Adobe patentierte Protokoll RTMP (Real-Time Messaging Protocol) ein. Der Datenverkehr läuft über den Port 1935. Außerdem beherrscht der FMS 3 die Verschlüsselung per SSL (genannt RTMPS), in diesem Fall nutzt er den SSL-Port 443. Neu ist die Verschlüsselung über RTMPE (encrypted), die laut Adobe schneller funktionieren soll als SSL und die Grundlage für die Entwicklung von Streaming-Anwendungen mit digitalem Rechtemanagement ist.

Um Probleme mit Firewalls zu umgehen, kann der FMS die Streams auch über Port 80 ausliefern. Dabei tunnelt er die RTMP-Pakete in HTTP. Durch die Tunnelung entsteht natürlich Daten-Overhead, allerdings steht dieser Overhead in keinem Verhältnis zu dem zu erwartenden Ärger, wenn der Stream beim Endnutzer nicht funktioniert. Schließlich dürfte der Port 1935 nur in den wenigsten Firewalls freigegeben sein. Daher streamt zum Beispiel die Deutsche Welle alle Flash-Streams über Port 80.

Falls der Server auf einem System installiert wird, auf dem bereits ein Apache-Webserver läuft, steht der Port 80 natürlich nicht für den Streamingserver zur Verfügung. Dann ist es sinnvoll, jedem Server eine eigene (virtuelle) Maschine zuzuweisen oder alternativ jeden Server über ein eigenes Netzwerkinterface mit individueller IP-Adresse zu betreiben.

Features und Formate

Neben dem attraktiveren Lizenzmodell hat Adobe gegenüber Version 2 des FMS auch zahlreiche funktionale Verbesserungen vorgenommen: Adobe verspricht drastische Performance-Verbesserungen (besonders unter Linux) von bis zu 200 Prozent. Ein einziger Server soll nun in der Lage sein, die Streams an etwa 1200 Clients gleichzeitig auszuliefern. Über Process Scopes können die einzelnen Anwendungen auf mehrere Prozesse verteilt werden.

Eine wichtige Erweiterung ist die Unterstützung der standardisierten Mpeg-4-Formate H.264 (Videocodec) und AAC-HE/AAC-LC (Audiocodecs). Das Containerformat der Dateien ist dabei unwesentlich, unterstützt werden MP4, MOV, 3GP und weitere. Ein großer Vorteil: Diese Dateien eigenen sich zugleich als Video-Podcast zum Download für Feedreader und mobile Endgeräte, zum Beispiel für den I-Pod.

Videos mit älteren Mpeg-4-Videocodecs wie Div X oder Xvid funktionieren allerdings nicht mit dem FMS 3 – laut Adobe wäre die Installationsdatei des Flash Player sonst zu groß geworden. Der Flash Player dekodiert die neuen Videoformate seit Version 9.115, die im Dezember 2007 erschienen ist. Genaue Angaben zur Unterstützung der neuen Formate finden sich unter [4].

Außerdem beherrscht der FMS 3 die Videocodecs Sorenson Spark (ab Flash Player 7) sowie On2 VP6 (ab Flash Player 8). Im Audiobereich sind es der wenig bekannte Codec Nellymoser (ab Flash Player 7) sowie der De-facto-Branchenstandard MP3. Prinzipiell ließe sich der FMS 3 also auch als MP3-Streamingserver nutzen. Die Streams sind aber dann dem Flash Player vorbehalten. Die zahllosen Streaming-fähigen Mediaplayer (VLC, Winamp, I-Tunes, …) können mit diesen Streams aufgrund des proprietären Protokolls nicht umgehen.

Ein großer Vorteil des FMS 3 im Zusammenspiel mit dem Flash Player ist die Möglichkeit, Millisekunden-genaue Sprungmarken zu setzen. Normalerweise kann der Anwender in einem Video nur zwischen den Vollbildern eines Films navigieren. Aktuelle Videocodecs setzen aber bei der Encodierung so genannte Zwischenbilder ein, das sind Bilder, die anhand der Differenzinformationen der vorhergehenden und nachfolgenden Vollbilder berechnet werden. Das Verhältnis in einem Video beträgt dabei durchaus 1:125 oder höher, das heißt, dass auf ein Vollbild 125 Zwischenbilder kommen. Der FMS 3 generiert im Zusammenspiel mit dem Flash Player automatisch ein Vollbild, egal zu welchem Einzelbild der Nutzer springt oder spult.

Aufbau des FMS

Der FMS ist in vier Ebenen gegliedert. Zunächst der Server selbst, dessen Einstellungen der Admin global konfigurieren kann. Der Server darf mehrere so genannte Adaptoren beinhalten, denen sich zum Beispiel verschiedene Domains oder IP-Adressen zuweisen lassen. Jeder Adaptor kann wiederum mehrere virtuelle Hosts enthalten. Virtuelle Hosts sind nützlich, um ähnlich dem Homeverzeichnis unter Linux verschiedenen Benutzern eigene Ordner zuzuweisen.

Die letzte Ebene schließlich sind die Applications, also die eigentlichen Anwendungen. Standardmäßig sind für jeden virtuellen Host die beiden Applications »live« und »vod« vordefiniert, also je eine für Live- und On-Demand-Streams. Der Anwender darf beliebig viele Applications aufsetzen.

Praxis: Videos für den FMS

Um einen eigenen Videostream anzubieten, sind neben dem Server zunächst passend kodierte Videos erforderlich. Für die Videokompression hat sich unter Linux das sehr flexible und performante Tool »ffmpeg« bewährt, das mit nahezu allen Videoformaten umgehen kann. Aus Platzgründen sollen hier nur stichpunktartig die Installation sowie eine Beispiel-Kommandozeile zur Encodierung von FMS-3-gerechtem Video mit den aktuellen Codecs H.264 und AAC-LC dargestellt werden.

Alle Installationsschritte und Anwendungen dieses Artikels beziehen sich auf ein frisch installiertes Ubuntu 7.10 (Gutsy Gibbon). Es bietet in der Paketverwaltung eine aktuelle Version von »ffmpeg« an. Um die benötigten Codecs zu verwenden, ist es leider trotzdem notwendig, direkt eine frische Version der Sourcen aus dem SVN-Repository zu ziehen und händisch zu übersetzen:

apt-get install subversion
svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

Zur Installation fehlen noch einige Codec-Bibliotheken, die das Ubuntu-Multiverse-Repository führt:

apt-get install faac faad libfaac-dev libfaad2-dev

Wegen der Lizenzpolitik der Mpeg Licensing Association gibt es in der Regel keine fertigen Installationspakete für Mpeg-4-Videocodecs. Laut deren Lizenz fallen für den Vertrieb solcher Encoder Lizenzgebühren an. Ähnliches gilt für MP3. Den Quelltext des MP3-Encoders Lame gibt es bei Sourceforge. Es fehlt noch ein H.264-Videocodec – dafür eignet sich die freie Implementierung x264 aus dem Videolan-Projekt:

apt-get install nasm
svn co svn://svn.videolan.org/x264/trunk x264
./configure --enable-pic --enable-shared
make
make install

Die Überprüfung erfolgt hier am besten über »x264 -help«. Damit sind alle benötigten Hilfstools vorhanden – bleiben noch Kompilierung und Installation von »ffmpeg« selbst:

./configure --enable-libmp3lame --enable-libfaac --enable-libfaad --enable-libx264 --enable-gpl --enable-small

Den Rest erledigen »make« und »make install«. Beim Testaufruf beschwert sich »ffmpeg« über eine fehlende Bibliothek »libmp3lame«. Ein Aufruf von »ldconfig« als Administrator beseitigt die Fehlermeldung, »ffmpeg« sollte beim nächsten Aufruf die möglichen Encoding-Optionen und Parameter ausgeben. Die Beispielsyntax für die Kompression eines FMS-3-gerechten Videos lautet wie folgt:

ffmpeg -y -i input.mpg -vcodec libx264 -acodec libfaac -r 25 -s 384x288 -aspect 4:3 -vb 350000 -ac 1 -ar 32000 -ab 64000 output.mp4

Die Bitrate des Videos liegt hier bei etwa 414 KBit/s. Bei der Kalkulation der Bitrate sollten Admins etwa 20 Prozent Overhead einplanen, der für den Austausch von Informationen zwischen Client und Server anfällt.

Installation des Servers

Die Developer Edition des FMS 3 kann nach der Registrierung bei Adobe heruntergeladen werden (Zip-Datei, 155 MByte). Offiziell ist der FMS 3 wie alle vorherigen Versionen nur für Red Hat Linux zertifiziert.

Das gepackte Installationsarchiv bringt auch die Windows-Installationsdatei »FlashMediaServer3.exe« mit, sie ist natürlich überflüssig und kann daher gleich gelöscht werden. Nach dem Entpacken lohnt sich ein Blick in das Documentation-Verzeichnis. Die mitgelieferte Doku ist erfreulich detailliert. Unter »Sample Code« finden sich auch einige nützliche Codebeispiele für die Flash-Entwicklungsumgebung.

Leider gibt es einen Bug des FMS 3 im Zusammenspiel mit dem Linux-Kernel 2.6.9-42, bei dem Performance-Probleme dazu führen, dass der Server maximal 500 Verbindungen gleichzeitig zulässt. Adobe empfiehlt daher für den Einsatz des FMS 3 den Kernel 2.6.9-22.

Unter Ubuntu teilt der Installer dem Anwender mit, die Distribution werde nicht unterstützt. Es gibt aber ein Patch von Markus Bertheau [5], das die Inbetriebnahme auch unter Ubuntu ermöglicht. Die Installation des Patch erledigen die folgenden Kommandos, im Installationsverzeichnis »FMS_3_0_0_r1157« ausgeführt:

apt-get install patch libnspr4-dev
wget http://www.bluetwanger.de/~mbertheau/flash-media-server-3-ubuntu.patch
patch -p1 < flash-media-server-3-ubuntu.patch

Die eigentliche Installation startet der Admin mit dem Kommando »./installFMS«. Die Abfrage der Seriennummer lässt sich überspringen. Daraufhin installiert sich die Developer Edition. Die Fragen nach Installationsverzeichnis, Streaming- und Administrationsport sind am besten mit den vorgegebenen Einstellungen zu beantworten, die nach der Eingabe von Nutzernamen und Passwort des Administrators folgenden am besten mit Ja.

Daraufhin startet der Flash Media Server als Daemon. Kopiert der Anwender nun das vorher mit »ffmpeg« erstellte Video in das Verzeichnis »/opt/adobe/fms/applications/vod/media«, steht es damit auch gleich als Stream zur Verfügung (Abbildung 2).

Abbildung 2: In der so genannten Administration Console des Flash Media Server kann der Flash-Admin die zu streamenden Mediendaten verwalten.

Der Befehl »./server stop«, im Installationsverzeichnis ausgeführt, hält den Server an. Wie von anderen Serverprogrammen gewohnt, stehen auch die Befehle »./server start« sowie »./server restart« zur Verfügung.

Unter Linux gibt es derzeit leider keine Möglichkeit, Livestreams für den FMS 3 zu generieren. Adobe bietet mit dem Flash Media Encoder 2 ein kostenloses Tool für Windows an, das Eingangssignale einer Kamera verarbeitet und als Datenstrom an den FMS 3 überträgt. Immerhin lässt sich die aktuelle Version komplett per Kommandozeile steuern.

Zu diesem Tool gibt es lediglich zwei und zudem kostenpflichtige Alternativen. Zunächst eine professionelle, teils Hardware-basierte Lösung von Digital Rapids sowie die Software On2 Flix live, die ebenfalls nur für Windows erhältlich ist und mit einer Lizenzgebühr von 999 US-Dollar pro Jahr auch nicht gerade billig ausfällt.

Der Flash Media Encoder funktioniert theoretisch mit allen Directshow-kompatiblen Geräten, in der Praxis gibt es allerdings oft Probleme mit Treibern. Unter [6] gibt es eine Liste mit Aufnahmegeräten, die von Adobe auf Kompatibilität getestet wurden. Darunter finden sich auch einige DV-Kameras.

Video-Kompatibilität

Mit dem Tool »flvcheck« lässt sich prüfen, ob der FMS 3 eine FLV- oder MP4-Videodatei streamen kann. Es steht nach der Installation des Servers im Verzeichnis »/tools«:

./flvcheck -f /opt/adobe/fms/applications/vod/media/output.mp4

Wenn als Ausgabe »passed« erscheint, sollte die Datei mit dem FMS harmonieren. Fehler sind meist auf fehlende Metadaten zurückzuführen, da einige Encoder diese leider nicht richtig setzen (zum Beispiel fehlende »duration«-Angabe). Ein Aufruf von »flvcheck –fixmeta« behebt das Problem.

Load-Testing mit Bordmitteln

Im Gegensatz zu anderen Streamingservern wie Darwin oder den Windows Media Services verfügte der FMS bisher nicht über ein echtes Tool für Lasttests. Klassische Load-Testingtools versagen hier, da sie das RTMP-Protokoll nicht unterstützen. In der aktuellen Version des FMS ist mit »FMSCheck« nun ein Tool enthalten, das automatisierbare Lasttests ermöglicht. Es befindet sich im Unterverzeichnis »tools«:

./fmscheck --host localhost --allapps --parallel 10 --auser Username --apswd Password --stagger 2 --logfile test.log

Dieses Kommando führt maximal zehn aller verfügbaren FMS-3-Anwendungen parallel aus. Das Ergebnis des Tests speichert das Tool in der Datei »test.log«. Der Parameter »–app« bietet die Möglichkeit, auch gezielt einzelne Anwendungen zu testen:

./fmscheck --host localhost --app vod --play sample.flv any 30 --timeout 360

Hier führt der Checker die vordefinierte Anwendung »vod« mit dem Video »sample.flv« aus. Das Video läuft 30 Sekunden lang ab. Eine solche Kommandozeile lässt sich nun in eine Schleife eines Bash-Skripts einbinden, um beliebig viele Instanzen eines bestimmten Videos parallel aufzurufen. Optimal ist es, mehrere Instanzen des Skripts von verschiedenen Rechnern aus unterschiedlichen Netzen aufzurufen.

Betrieb und Administration

Der FMS 3 bringt ein so genanntes Administration API mit, über das Flash-Entwickler eigene Anwendungen zur Ausgabe von Informationen und zur Administration des Servers schreiben können. Eine in Flash realisierte Oberfläche steht bereits nach der Installation des Servers zur Verfügung:

firefox /opt/adobe/fms/fms_adminConsole.htm

Dort kann sich der Administrator mit dem bei der Installation vergebenen Nutzernamen und Passwort anmelden. Falls die Anwendung lokal abläuft, genügt als Serverangabe »localhost«, auf einem entfernten Rechner ist der Servername um den Port 1111 zu ergänzen. Um die Anwendung auf einem Webserver zur Verfügung zu stellen, genügt es, die beiden Dateien »fms_adminConsole.swf« und »fms_adminConsole.htm« in das Docroot zu kopieren.

Konfiguration des Servers

Zu jeder Ebene des Flash Media Server gibt es eine eigene XML-basierte Konfigurationsdatei. Eine Ausnahme bildet die globale Konfigurationsdatei »fms.ini«. Diese und noch weitere Dateien der obersten Ebene (»Server.xml«, »Logger.xml«, »Users.xml«) liegen im Installationsverzeichnis unter »conf«.

Die Einstellungen in der »Logger.xml« (Erstellung der Logfiles) sowie in der »Users.xml« (Verwaltung, Administratoren) sind weitgehend selbsterklärend. Alle verfügbaren Einstellungen für die Konfiguration sind detailliert unter [7] nachzulesen. Nach jeder Änderung in einer Konfigurationsdatei muss der Admin den Server neu starten.

Sicherheit

Standardmäßig lässt der FMS jede Verbindung von außen zu – das ist in der Praxis aber eher unerwünscht. Mit

vi /conf/_defaultRoot_/_defaultVHost_/Vhost.xml
<Allow>dw-world.de, linux-magazin.de</Allow>

sind nur noch Zugriffe von [dw-world.de] und [linux-magazin.de] zugelassen. Ebenso sollte man das Administrations-Interface auf diese Weise sichern:

vi /conf/Server.xml
<AdminServer>
<Allow>dw-world.de, linux-magazin.de</Allow>
</AdminServer>

Eine weitere Sicherheitsstufe bietet die neue Funktion »SWF Verification«, bei der der Server nur die Zugriffe voreingestellter Player zulässt. Nachteil: Der Admin muss bei jedem Update eines Players daran denken, die neue Version ebenfalls einzutragen, da sonst die Verbindung fehlschlägt. Mit

vi /conf/_defaultRoot_/_defaultVHost_/Application.xml
<SWFVerification enabled="false">
<SWFFolder>/root/players</SWFFolder>
</SWFVerification>

sind nur jene Player zugelassen, die auch in dem Verzeichnis »/root/players« aufgeführt sind.

Performance

Bei Systemen mit viel Arbeitsspeicher empfiehlt es sich, den »FLVCache« zu erhöhen. Je höher der Wert, desto mehr FLV-Dateien kann der FMS 3 direkt aus dem Arbeitsspeicher des Servers streamen, ohne sie erst von der Festplatte zu laden. Standardmäßig steht dieser Wert auf 500 MByte. Die Einstellung

vi /conf/fms.ini
SERVER.FLVCACHE_MAXSIZE=3072

erhöht den Cache auf 3 GByte – das ist der Maximalwert für Linux-Systeme, unter Windows sind es 2 GByte. Die Einstellung wirkt sich natürlich nicht auf Livestreams aus. Ebenso sollte der Admin in der »Server.xml« den Cache auf einen maximalen Prozentsatz des Arbeitsspeichers setzen. Mit

vi /conf/Server.xml
<FLVCacheSize>33</FLVCacheSize>

belegt der Cache maximal 33 Prozent des Arbeitsspeichers, kombiniert mit dem »FLVCache« braucht der Server also sinnvollerweise minimal 9 GByte RAM.

Ein Stream ist letztlich auch nur eine Reihe von Datenpaketen. Ihre Größe ist konfigurierbar – je größer die Pakete, desto geringer die CPU-Last, aber desto höher auch die Latenz. Bei überwiegend längeren Videos sollte der Admin den Standardwert von 4096 Bytes zumindest verdoppeln. Mit der folgenden Einstellung sind minimal 128 Bytes, maximal 65536 Bytes zulässig:

vi conf/_defaultRoot_/_defaultVHost_/Application.xml
<OutChunkSize>8192</OutChunkSize>

Standardmäßig beendet der FMS keine Verbindung von selbst, das heißt, wenn ein Nutzer noch ein Browserfenster offen hält, das ein Video geladen hat, bleibt die Verbindung zwischen Client und Server bestehen. Um diese Verbindungen nach einer bestimmten Zeit automatisch zu schließen, muss in der »Server.xml« folgende Einstellung stehen:

vi /conf/Server.xml
<AutoCloseIdleClients enable="true">
<CheckInterval>60</CheckInterval>
<MaxIdleTime>1200</MaxIdleTime>
</AutoCloseIdleClients>

Damit sucht der FMS 3 alle 60 Sekunden nach inaktiven Verbindungen. Sobald der Nutzer länger als 1200 Sekunden (20 Minuten) keine Daten angefordert beziehungsweise empfangen hat, schließt der Server die Verbindung.

Versionen und Bandbreite verhandeln

Kommunikation und Aufbau der Session zwischen FMS 3 und Flash Player erfolgen über das AMF (Actionscript Message Format). Flash Player 9 und FMS 3 nutzen dabei die aktuelle Version AMF 3, ältere Server und Player verwenden AMF 0. Wer zum Beispiel einen Videoplayer, der noch mit einer älteren Flash-Version (Actionscript 1 oder 2) entwickelt wurde, zusammen mit dem FMS 3 nutzen will, sollte das Datenformat Server-seitig auf AMF 0 umstellen:

vi /opt/adobe/fms/conf/_defaultRoot_/_defaultVHost_/Application.xml
<NetConnection>
<ObjectEncoding>AMF0</ObjectEncoding>
</NetConnection>

Alternativ kann der Flash-Entwickler das Datenformat in der Flash-Entwicklungsumgebung über die Eigenschaft »NetConnection.objectEncoding« setzen.

Standardmäßig ermittelt der FMS beim Verbindungsaufbau die Bandbreite des Clients – das ist eine nützliche Funktion, um zum Beispiel zwischen verschiedenen Qualitätsstufen eines Videos zu verzweigen. Wer diese Erkennung aber nicht benötigt, kann sie auch abschalten, um die Latenz etwas zu verringern:

vi /conf/_defaultRoot_/_defaultVHost_/Application.xml
<BandwidthDetection enabled="false">

Der FMS legt alle Logfiles im standardisierten W3C-Format im Unterordner »logs« ab. Per Default erstreckt sich die Logrotation über fünf Logdateien. Diese Einstellung lässt sich in der »/conf/Logger.xml« ändern.

Das Access-Log erfasst alle Zugriffe mit Error-Codes und ausführlichen Informationen wie zum Beispiel der Session-Dauer und der Summe der übertragenen Daten. Das Admin-Log protokolliert Zugriffe über das Administrations-API, also etwa die mitgelieferte Admin-Console. Die Core-, Master- und Edge-Logfiles sind nur für einen Verbund mehrerer verteilter Server interessant. Logfiles für die einzelnen Applications liegen im Unterverzeichnis der Anwendung und sammeln Informationen, die nützlich zum Debuggen Server-seitiger Skripte sind.

Flash Player in der Webseite

Encoder und Server sind nun zwar fertig konfiguriert und funktionstüchtig, es fehlt aber noch der Player. Dafür empfiehlt sich der freie FLV Player [8] von Jeroen Wijering (Abbildung 3). Er unterstützt alle Streaming- und Download-Protokolle für Flash-Video und lässt sich auch ohne die Flash-Entwicklungsumgebung umfassend konfigurieren. Für eine Anpassung des Designs beziehungsweise funktionale Änderungen oder die Entwicklung eines eigenen Players ist aber eine Vollversion von Adobe Flash notwendig, die wiederum gibt es jedoch nur für Windows und Mac OS X.

Abbildung 3: Der FLV-Player von Jeroen Wijering ist für nicht kommerzielle Projekte frei verwendbar.

Nach dem Entpacken des Archivs ist der Player fast schon einsatzbereit. Es genügt, die Dateien ins Docroot des Webservers zu kopieren. Danach fügt der Admin einer HTML-Datei einen Code-Abschnitt ähnlich dem in Listing 1 hinzu, der das Video einbindet.

01 <embed src="http://localhost/path_to_player/mediaplayer.swf"
02 width="512" height="404" allowscriptaccess="always" allowfullscreen="true"
03 flashvars="height=404&width=512&file=rtmp://127.0.0.1/vod&id=mp4:
04 output.mp4&searchbar=false" />

Die Parameter sind größtenteils selbsterklärend. Der Src-Pfad muss natürlich stimmen, damit der Browser die SWF-Datei des Players findet. Es folgen Breiten- und Höhenangaben des Videos. Der Serverpfad wird über die Variable »file« angegeben und verweist im Beispiel auf die vordefinierte Anwendung »vod«. Der eigentliche Dateiname steht in der Variablen »id«, bei Mpeg-4-Dateien ist unbedingt »mp4:« voranzustellen. Erst danach folgt der Dateiname.

Am Rande sei noch bemerkt: Bei FLV-Dateien ergänzt der Flash-Server die Datei-Endung automatisch, bei anderen Dateiformaten allerdings nicht. Für das Streamen eines Flash-Videos genügt als Variable für die Datei »sample.flv« einfach »sample«.

Für Streaming über HTTP ist im Serverpfad statt »rtmp« einfach »http« zu schreiben. Sicherheitshalber sollte hinter dem Domainnamen beziehungsweise der IP-Adresse noch die Angabe »:80« folgen, um die Datenübertragung über Port 80 zu erzwingen. Zur komfortablen Generierung des Quelltextes bietet Wijerings Website unter [9] auch einen kleinen Generator an, der über ein recht einfaches Formular den Quelltext mit den Parametern des Players erzeugt.

Zukunftssicher

Mit der aktuellen Version des FMS steht ein leistungsfähiger und bezahlbarer Streamingserver für das populärste Internet-Videoformat zur Verfügung. Installation und Administration erfordern zwar etwas Aufwand, der sich aber zumindest für mittelgroße und größere Inhaltsanbieter bezahlt macht. Mit H.264 und AAC beherrscht er zwei standardisierte und leistungsfähige Mpeg-4-Codecs. Für eine möglichst hohe Abwärtskompatibilität sollte man aber heute noch den etwas älteren VP6-Codec im Zusammenspiel mit MP3 einsetzen. (ofr)