[Datenschleuder] [70]    live vom 16C3: the "streaming media broadcast project"

live vom 16C3: the "streaming media broadcast project" von Tom Lazar <tom@tomster.org> wer hat´s gemerkt? richtig: im buzzword-titel fehlt eins: "internet". und tatsächlich sind gestreamte videodaten im internet bei derzeit üblichen bandbreiten nach wie vor ein reichlich sinnentleertes unterfangen. was aber, wenn ein 100Mbit LAN mit über 1000 clients zur verfügung steht..? auch wenn - zugegebenermassen - die aussicht darauf, das congress-netz als high-bandwidth-spielwiese zu missbrauchen vater des gedankens war, kamen auch praktische aspekte hinzu: wenn wir das videosignal aus den drei vortragsräumen ins LAN stellten, könnte man (theoretisch) von jedem rechner aus (insbesondere unten im hackcenter) live nachsehen, was für vorträge gerade liefen - und zwar ohne in selbige reinzuplatzen... der zweite nützliche nebeneffekt: wenn die filme sowieso schon digital vorlagen, könnte man sie auch als archiv "missbrauchen" (der bisher übliche karton voller videotapes wurde diesem anspruch nur sehr rudimentär gerecht...). falls jemand beispielsweise an zwei zeitgleich ablaufenden vorträgen interessiert war, könnte er/sie sich einen vorort anschauen und den zweiten anschliessend per ftp herunterladen. serviles zur verfügung standen drei g4 Power Macintosh rechner mit video-in karte. theoretisch hätte sogar eine einzige maschine ausgereicht: als nach einigem herumexperimentieren die ideale kombination aus codec, bildgrösse, framerate und abspielverhalten feststand, lag die cpu-last der server im mittel bei 25-30%. leider warf aber die fehlende konfigurierbarkeit der verwendeten broadcast software der rechenpower und den vier pci-slots des g4 einen dicken knüppel zwischen die beine. doch nicht nur das: der "sorenson broadcaster" bot zwar eine unschlagbare mischung aus streamgrösse und bildqualität (interessanterweise nicht mit dem hauseigenen vorzeige-format "sorenson video", das auch von apple gerne zum angeben benutzt wird, sondern mit dem "guten alten" H.263 codec) und war innerhalb weniger minuten komplett konfiguriert, aber leider auch bis unter die halskrause voll mit bugs. die versionsnummer "1.0" war eine frechheit sondergleichen. "alpha mit feature-freeze" wäre passender gewesen. dazu später mehr. proprietäres der sorenson broadcaster "verpackt" den video- und audiostream mit einem quicktime-header, was (in unserem fall) eigentlich nicht zwingend notwendig war, da nur nicht-proprietäre codizes verwendet wurden. das hatte den unangenehmen nebenenffekt, dass clientseitig nur quicktime-unterstützte betriebssysteme in frage kamen, was die auswahl auf MacOS und die diversen windows plattformen eingrenzte. der vorteil: das quicktime paket enthält auch einen player in form eines browser-plugins, d.h. sowohl die verteilung der multicast-adressen und der notwendigen streaming-parameter als auch das eigentliche abspielen konnten mittels <EMBED>-tag http-basiert auf einer gewöhnlichen html-seite erfolgen. bei installiertem plug-in reichte ein klick auf eines der "GIF-dummies" der projekt-site und die vorstellung ging sofort los - siehe screenshot. (den framebuffer konnten wir aufgrund der idealen netzbedingungen gefahrlos auf null herunterschrauben.) ersichtliches das ganze klappte erstaunlich gut: die jungs vom NOC hatten für alle subnetze multicast bereitgestellt und selbst auf einem 233 MHz iMac konnten alle drei streams mit jeweils 320 x 240 pixel bei butterweichen 25 frames per second gleichzeitig abgespielt werden. ein rundgang im hackcenter am zweiten tag förderte dann auch mehr als nur einen als fernseher umfunktionierten webbrowser zutage. auch die iMac-terminals vor der aula fanden zeitweise regen zuspruch - ruckelfreie videobilder auf denen man (mitunter, mitunter…) sogar die schrift auf den overhead-folien entziffern konnte waren eben doch etwas anderes als die animierten briefmarken, die man sonst von websites mit streaming video kennt… debiles ganz anders sah die sache allerdings beim angestrebten archivaufbau aus. ursprünglich war gedacht, die aufzeichnung des streams auf den drei maschinen einfach den ganzen tag über durchlaufen zu lassen, um dann in der nacht auf den nächsten tag die einzelnen vorträge aus den riesendateien herauszuschneiden. das fand ich - neben dem angenehmen effekt, nicht nach jedem veranstaltungsblock rauf ins videostudio rennen zu müssen - auch deshalb furchtbar schlau, weil ich dadurch flexibel auf verspätungen und änderungen reagieren konnte. theoretisch, zumindest. in der praxis passierte montag (dem ersten tag) abends erstmal folgendes: auf zwei der maschinen quittierte der server den "stop"-befehl für den aufzeichnungsvorgang zunächst mit einem lapidaren "could not complete the request, because an error occurred". (übrigens eine meiner absoluten lieblingsfehlermeldungen des MacOS, wenn auch weit abgeschlagen von "not enough memory to display the", aber ich schweife ab…) die trotz dieser meldung entstandenen filme hatten dann aber zum glück die volle aufzeichnungslänge von immerhin neun stunden - allerdings nur auf der audiospur… der videoteil zeigte nach ein paar minuten nur noch ein schickes graues standbild. zum glück aber war wenigstens der stream der dritten maschine heil und vollständig - nur dass der tolle sorenson broadcaster beim nächsten programmstart ungefragt(!!) die bisherige aufzeichnungsdatei überschrieb und innerhalb von sekunden einen 700 MB film unwiderruflich in wenige KB verwandelte. alles in allem also eine ziemlich magere ausbeute für den ersten tag. lediglich die (später stattfindende) tron-veranstaltung wurde anstandslos und vollständig für die nachwelt erhalten. wie sich herausstellte, hat die serversoftware ein problem mit grösseren dateien - ein umstand, der bei den wenigen zeitlich möglichen probeläufen leider nicht zutage trat.. während das broadcasten den ganzen congress über problemlos weiterlief (von vereinzelt auftretenden allgemeinen netzwerkfehlern mal abgesehen), geriet das abspeichern der aufgezeichneten streams zu einem lotteriespiel mit fünfzigprozentiger gewinnchance… konservatives da videochef frank und die kamera- und mikrofon-engel trotz des beengten chaos im videostudio ganze arbeit geleistet hatten, hat die mehrzahl der aufzeichnungen durchaus dokumentationscharakter. vor allem die aufzeichnungen aus der aula, wo mit zwei kameras und mehreren saalmikros gerarbeitet wurde, vermitteln einen recht brauchbaren eindruck nicht nur davon, was vorgetragen wurde, sondern auch wie die stimmung im saal war. deshalb wurde beschlossen, zumindest teile der missglückten streamaufzeichnung von den svhs-bändern manuell nachzudigitaliseren. bei typischen dateigrössen von 120 bis 200 mb schied leider die möglichkeit aus, eine master-cd mit allen filmen zu brennen, die dann bei bedarf kopiert und verschickt werden könnte. deshalb möchten wir interessierten folgendes anbieten: unter http://tomster.org/chaos/16c3-video/form.html könnt ihr einerseits per webformular eine wunschliste von filmen zusammenstellen, die ihr gerne digital vorliegen hättet und andererseits kundtun, ob ihr euch die monsterbrocken auch per ftp herunterladen würdet. bei ausreichendem interesse könnten dann z.b. cd-compilations mit den meistgewünschten filmkombinationen gemastert werden, die dann bestellt werden können und/oder filme zum download angeboten werden. zukünftiges beim nächsten congress wird natürlich alles besser :-) das MacOS wird dann womöglich tatsächlich multitasking, shell-zugriff und scripting vorweisen; falls sorenson bis dahin nicht mit einer 2.0 version des broadcasters aufwartet, die den namen auch verdient, bleibt vielleicht wenigstens genügend zeit, eine open source variante unter MacOS X lauffähig zu machen. damit würden dann z.b. features wie datenbankgesteuertes aufzeichnen und benennen der streams möglich (eine art vps, wo verspätungen und änderungen zentral erfasst und gepostet werden können; der download aufgezeichneter streams könnte unmittelbar nach veranstaltungsende direkt aus dem congress-fahrplan heraus und mit voller LAN-geschwindigkeit auf den mitgebrachten rechner erfolgen). denkbar wäre auch ein "sauberer" stream, der auch von nicht-proprietären playern abgespielt werden kann. oder mp3 als format für den audiotrack. oder unterschiedliche streamvarianten für LAN/CD-archiv und internet-broadcast/ftp download. oder, oder, oder… naja, mal sehen… :-) <tom>

[Datenschleuder] [70]    live vom 16C3: the "streaming media broadcast project"