© xsc.hu, Inka Johnson

Firmen und Privatkunden, die mit Linux Video übers Internet streamen wollen, verirren sich schnell im Dschungel der Codec-Alphabete. Auch die Softwarelandschaft ist unübersichtlich.

Grundsätzlich gibt es zwei verschiedene Möglichkeiten, Videos übers Internet zu verteilen: die Datei komplett herunterladen, dann ansehen. Oder Streaming, bei dem die Zuschauer praktisch sofort etwas zu sehen bekommen, sobald die ersten Pakete eingetroffen sind. Vom Streaming gibt es wieder zwei Varianten, die sich darin unterscheiden, ob der gesendete Stream auf Anfrage eines Clients neu startet (On Demand) oder ob er zu einer bestimmten Zeit abläuft, egal wann Zuschauer einsteigen (Live-Stream).

Codec-Suche

In beiden Fällen muss der Anbieter des Stream mehrere technische Entscheidungen treffen. An erster Stelle steht das verwendete Video- und Audio-Format. Je nach Kontext kann es unterschiedliche Dinge beschreiben, die meist in einem Topf landen, zum Beispiel die eigentlichen Video- und Audio-Codecs, aber häufig auch das so genannte Container-Format. Apples Quicktime ist zum Beispiel ein Container-Format, das unterschiedliche Codecs wie Sorensen enthalten kann. Es gibt auch über die Technologien hinweg keine einheitliche Terminologie, so steht “Mpeg” tatsächlich für Codec und Container.

Die Auswahl des Codec sollte nach Meinung des Autors am Anfang der Überlegungen stehen. Mehrere Aspekte sind dabei wichtig, auch das primäre Zielpublikum des Streaming. Handelt es sich zum Beispiel in erster Linie um technikaffine Linux-User, die wohl kaum Schwierigkeiten mit der Installation von Mplayer & Co. haben, bietet sich ein ziemlich weites Feld an verfügbaren Codecs. Gehören Windows- und Mac-Benutzer dazu, stehen zwar schon einige Codecs von Haus aus zur Verfügung (bei Windows WMV, auf dem Mac Quicktime), andere müssen die User allerdings von Hand nachinstallieren.

Je nach Einsatzzweck sind zweitens auch lizenzrechtliche und juristische Aspekte wichtig. Wer nur für Freunde und Familie einen Webcam-Stream aus dem Hobbykeller überträgt, wird sich kaum um eventuell verletzte Lizenzen kümmern. Anders sieht es beim kommerziellen Einsatz aus. Auch wenn Encoder für alle möglichen Codecs unter Linux frei zur Verfügung stehen, nähert man sich bei ihrem Einsatz einer rechtlichen Grauzone. Sämtliche Mpeg-Technologien sind beispielsweise in irgendeiner Weise patentiert.

Je nach Format müssen Hersteller ihre Encoder oder Decoder beim Mpeg-Konsortium [1] lizenzieren, schon weil die Lizenzgebühr sich normalerweise nach der verkauften Stückzahl richtet – kein Weg für die Programmierer freier Software. Ähnliches gilt für praktisch alle brauchbaren Codecs. Wer sich kommerzielle Encoder-Software besorgt, zum Beispiel von Mainconcept [2], ist zumindest hier aus dem Schneider.

Real-Server

Am längsten im Streaming-Geschäft ist die Firma Real Networks [3], die nicht nur Encoder-, Player- und Streaming-Software verkauft, sondern sogar eigene Codecs entwickelt hat. Entsprechend ihrer mittlerweile gut zehn Jahre dauernden Entwicklung liefern die Real-Codecs sehr gute Video- und Audioqualität im Verhältnis zur verbrauchten Bandbreite. Auch die Server- und Encoder-Tools sind ausgereift und recht stabil.

Nur handelt es sich durchgehend um proprietäre Technologie, die auf Client-Seite die Installation von Realplayer voraussetzt. Zwar hat Real im Zuge der allgemeinen Open-Source-Mode vor einigen Jahren auch Teile ihrer Software unter eine freie Lizenz gestellt. Die proprietären Codecs ließen sie aber aus.

Für Rich-Media-Präsentationen interessant: Real implementiert auch den SMIL-Standard, der Streams mit verschiedenen Medien vorsieht, zum Beispiel als Text (und nicht etwa als Video) kodierte Schrift. Der Real-Encoder (Produktname ist Producer) liest einige Videoformate und erzeugt daraus Real-Dateien, sogar für unterschiedliche Bandbreiten vorbereitet. Fürs Live-Streaming liest er analoges Video von V4L-Geräten, digitales DV über Firewire beherrscht er nicht. Wer die Real-Produkte selbst ausprobieren möchte, findet auf der Website jeweils Free-Varianten, die in unterschiedlicher Weise beschränkt sind, zum Beispiel lässt der freie Helix-Server nur 20 gleichzeitige Streams zu.

Von Apple: Darwin

Ähnlich wie Real hat es auch Apple angestellt: Von ihrem Quicktime-Streaming-Server gibt es eine freie Auskopplung namens Darwin Streaming Server [4], dem die Quicktime-Komponenten fehlen. Ganz nutzlos ist der Server aber nicht, denn er ist immerhin noch in der Lage, Mpeg 4 zu streamen, dessen Codec recht gute Qualität liefert. Anders als bei Real gibt es von Apple weder ein umfangreiches kommerzielles Angebot für Linux-User, noch einen Encoder.

Die Standardlösung fürs Streaming mit dem Darwin-Server ist, die von Cisco-Mitarbeitern geschriebene Mpeg4IP-Suite zum Encoden zu verwenden. Mit ihr, wie auch mit den unter Linux sonst verbreiteten Encodern Mencoder, Transcode, Ffmpeg oder VLC lassen sich aus vielen Videoformaten Mpeg-4-Dateien erzeugen. Mpeg4IP bringt außerdem einen Live-Encoder mit, der von V4L-Geräten analoges Video liest und Mpeg 4 ausgibt. Eine einfache Lösung für DV-Video gibt es damit nicht.

Flumotion

Anders beim freien Flumotion-Server [5] der Firma Fluendo, die seit längerem versucht im Multimedia-Bereich unter Linux mit freier Software Geld zu verdienen. Einige ihrer Mitarbeiter sind Core-Entwickler des Gstreamer-Projekts, das die Multimedia-Infrastruktur für Gnome bereitstellt. Fluendo arbeitet auch an lizenzierten Technologien wie DVB und Mpeg, die irgendwann als kommerzielle Plugins des Flumotion-Servers zur Verfügung stehen sollen.

Die freie Variante bringt aber schon einiges mit, was für ambitionierte Streaming-Projekte genügt. Als Input verarbeitet Flumotion sowohl V4L als auch DV, deckt hier also die meisten Geräte bereits ab. Leider ist der Server nicht ganz einfach zu installieren, weil er unter anderem Gstreamer, Gstreamer-Python, Python-GTK und Twisted-Pakete voraussetzt und das noch in einer Kombination von Versionen, die nicht in jeder Distribution installiert sind.

Flumotion besteht aus den beiden Komponenten Worker und Manager sowie einem Admin-Frontend (Abbildung 1) mit Setup-Wizard. Der Worker kümmert sich um das Encoding und schickt die Video- und Audiodaten an den Manager, der das Connection Handling und das Streaming übernimmt. Nicht schön: Für jeden Stream benötigt der Manager einen neuen Port, sodass sich die Portnummern immer danach richten, wie viele unterschiedliche Streams der Server anbietet. Einige Tipps zum Live-Streaming von der Kamera bis zur Software gibt Flumotion-Entwickler Andy Wingo in seinem Blog [6].

Abbildung 1: Der freie Flumotion-Server streamt im Theora-Format und verarbeitet analoges wie auch digitales Video.

Theora

Der freie Flumotion kennt nur eine Codec-Familie, die aber für alle, die nach einer freien Lösung suchen, ohnehin die einzige Option ist. Beide Codecs stammen von der Xiph-Foundation [7], die sich auch genau dies zum Ziel gesteckt hat, nämlich freie Alternativen zu den von Patenten belasteten modernen Codecs zu implementieren. So ist für Audio die Xiph-Erfindung Vorbis qualitativ und von der Encoding-Effizienz vergleichbar zu MP3. Meist firmiert Vorbis unter dem Kürzel des Ogg-Containers.

Für Video konnten die Xiph-Programmierer auf eine Schenkung der Firma On2 zurückgreifen. Die hat ein unwiderrufliches Recht zur Nutzung ihres VP3-Codec erteilt, das auch eventuelle Patentansprüche einschließt. Daraus wurde der Codec Theora, der qualitativ zwar nicht ganz mit Mpeg 4 oder H.264 mithalten kann, aber auch bei niedrigen Bitraten akzeptable Ergebnisse liefert, vergleichbar mit Divx 3.

Weil juristische Bedenken fehlen, enthalten praktisch alle Distributoren beide Codecs. Problemkinder sind Windows- und Mac-Plattformen, wo sie meist fehlen. Für Windows existiert eine Directshow-Implementation der Xiph-Codecs, die sich in die Codec-Infrastruktur integriert [8]. Für den Mac gibt es eine entsprechende Quicktime-Komponente [9].

Die meisten Probleme mit Codecs auf der Client-Seite umgeht das Cortado-Applet von Fluendo, das in Java implementierte Decoder für Vorbis und Theora mitbringt. Das Applet funktioniert in der Praxis überraschend gut und gibt den Stream auch auf weniger gut ausgestatteten Systemen ruckelfrei wieder. Nur auf dem Mac läuft die Wiedergabe im Zeitlupentempo.

Icecast

Für eine hauseigene Streaming-Lösung entschied sich der Autor letztlich für den Icecast-Server [10], der in Version 2 Theora-Streams beherrscht. Ein Grund ist Icecasts Fähigkeit, Encoder-Streams an so genannten Mountpoints entgegenzunehmen, die alle über denselben Host und Port erreichbar sind – besser als die Port-Vielfalt bei Flumotion. Auch die von Andy Wingo beschworene Wizardry [6] ist überflüssig: Schon nach nur einer Änderung in der Icecast-Konfiguration ist der Server bereit zum Theora-Streaming. Da errichtet die Einstellung des Flumotion-Pakets viel höhere Hürden, trotz – teilweise auch wegen – seines Administrations-GUI.

Praktische Pipes

Als Encoder für Icecast bietet sich »ffmpeg2theora« an [11], der aus allen Formaten, die »ffmpeg« lesen kann, Theora-Dateien erzeugt. Schreibt man diese nach Stdout, liest das Tool »ogg_fwd« sie von dort und schickt sie an den Server. Um das Live-Video von einer DV-Kamera einzulesen, benutzte der Autor das Kommandozeilenprogramm »dvgrab«. So entsteht, zwar auf der Command Line, aber trotzdem überschaubar, eine komplette Encoding-Pipeline:)

dvgrab --format raw - | ffmpeg2theora -V 150 -f dv -x 320 -y 240 -o /dev/stdout -| oggfwd IP-Adresse Port Passwort Mountpoint.ogg

Während im Flumotion-Interface traurig dreinblickende Icons beklagen, dass eine Komponente aus unbekannten Gründen nicht funktioniert, bekommt der Icecast-Admin hier wenigstens noch unmittelbares und meist brauchbares Feedback. Oft handelt es sich dann um ein Permission-Problem beim Video-Device oder bei der Server-Authentifizierung.

Ähnliche Lösungen sind auch mit anderen Linux-Video-Tools möglich. So sind ja die meisten Transcoder wie Mencoder, Ffmpeg oder Transcode in der Lage, ihre Daten nach Stdout auszugeben. Ffmpeg kann sogar selbst streamen, aber allein die Kommandozeilenhilfe umfasst 20 Bildschirmseiten und viele Seiten Dokumentation im Web sind veraltet. Ähnliches gilt auch für VLC, das viele als überlegene Lösung anführen: Gab es früher einen »vlcserver« – wie viele Webseiten belegen -, streamt heute der VLC-Client selbst. Das GUI, das er mitbringt, hilft nur begrenzt weiter, selbst einfache Kommandozeilen umfassen oft mehrere Zeilen, ganz zu schweigen von der Syntax mit runden, eckigen und geschweiften Klammern.

Hier gilt es, prinzipiell zu überlegen, ob man eine Lösung, die out of the Box funktioniert, einer Bastel-Lösung vorzieht, die zwar am Ende nicht schlechter sein muss, aber eben eine Menge Fummelei bedeutet, also Zeitaufwand.

Zu Protokoll

Außer bei den Codecs unterscheiden sich die vorgestellten Streaming-Lösungen in den verfügbaren Netzwerkprotokollen. Real hat hier, dank der langen Erfahrung, am meisten zu bieten. Der Server beherrscht mehrere Protokolle, die Clients vom selben Hersteller natürlich auch, beide Seiten verstehen sich also bestens. Von Haus aus verwenden sie das proprietäre RDT, die Clients beherrschen aber auch das standardisierte RTSP-Protokoll (Real Time Streaming Protocol) beziehungsweise RTP (Real Time Protocol), das sich besonders gut für Multimediadaten eignet. Es setzt auf UDP auf und schert sich nicht um eventuelle Paketverluste.

Von den vorgestellten Servern beherrscht derzeit nur der Darwin Streaming Server RTP/RTSP, alle anderen setzen auf HTTP. Leider ist HTTP nicht gerade ideal für Streaming, denn sobald durch Paketverluste Aussetzer entstehen, schaukelt sich der Effekt noch hoch, weil die verlorenen Pakete neu übertragen werden. Hier wäre es besser, einfach die Verluste zu ignorieren und so gut und schnell wie möglich weiterzustreamen.

Damit sich beispielsweise Ogg/Theora in RTP-Paketen übertragen lässt, muss nicht nur der Server überhaupt RTP implementieren, sondern erst einmal klar sein, wie Ogg überhaupt in RTP-Pakete einzubetten ist. An dieser so genannten Payload-Spezifikation arbeiten die Entwickler schon eine Weile, aber ein Ende ist noch nicht abzusehen.

Für jeden etwas

Bleibt am Ende doch wieder nur die Qual der Wahl? Für alle, die auf eine freie Streaming-Lösung angewiesen sind: Nein, ihnen stehen als beste Optionen für Video-Streams sowieso nur der freie Theora-Codec in Kombination mit Flumotion oder Icecast plus Ffmpeg2theora offen. Wer sich wenig um Patente, aber viel im Interoperabilität schert, sollte einen Blick auf den Darwin Streaming Server werfen, der mit Mpeg4Live auch live streamen kann.

Wer größere Geldbeträge investieren darf, findet vielleicht bei Real den optimalen Streaming-Server, für den es wenigstens für alle Plattformen kostenlose – wenn auch nicht freie – Clients gibt. Eine knappe Übersicht über die vorgestellten Programme gibt Tabelle 1.

Copyright © 2002 Linux New Media AG)