Studienarbeit Oliver Buschjost

Transcription

Fakultät für Elektrotechnik, Informatik und Mathematik
Institut für Informatik
Fachgebiet Didaktik der Informatik
Markierungs- und Schnittwerkzeug
zur videounterstützten Analyse von
Kommunikationsszenarien
Machbarkeitsstudie, Konzeption und
prototypische Umsetzung
Studienarbeit
zur Erlangung des Grades
Bachelor of Computer Science
vorgelegt von
cand. Dipl.-Inform. Oliver Buschjost
Grevestr. 3
33098 Paderborn
Matr.Nr. 6147229
Betreuer
Prof. Dr. phil. Johann S. Magenheim
Prof. Dr. Hans Kleine Büning
15. November 2006
Eidesstattliche Erklärung
Hiermit versichere ich, die vorliegende Studienarbeit ohne Hilfe Dritter und nur
mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen,
die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde
vorgelegen.
Paderborn, den 15. November 2006
..............................
Oliver Buschjost
Zusammenfassung
Oft gibt es unterschiedliche Sichtweisen auf komplexe Situationen; wahrgenommen wird jedoch nur die eigene und damit höchst subjektive Sicht. Für die objektive Evaluation von Unterrichtssituationen kann die parallele Wiedergabe der
Handlung aus verschiedenen Perspektiven aufschlussreich sein. Dieses Review erlaubt die verbesserte Vermittlung des Unterrichtsstoffs.
Die vorliegende Arbeit untersucht Technologien für Videoschnitt, -kompression
und -streaming im Rahmen der prototypischen Umsetzung eines solchen Werkzeugs. Zweck der Anwendung ist die Annotation relevanter Videosequenzen. Diese werden anschließend, zur besseren Analyse, aus dem Gesamt-Video extrahiert
und speziell aufbereitet.
Nach der Analyse einer bestehenden Anwendung werden Konzepte zur Realisierung erarbeitet und auf ihre Umsetzbarkeit hin untersucht. Die Implementierung
stützt sich dabei unter anderem auf folgende Techniken: Frameserver, H.264Videokompression, RTSP-Streaming, SMIL, DirectShow und Scriptsprachen innerhalb einer in C# programmierten .NET Anwendung.
Inhaltsverzeichnis
1 Einleitung
1
1.1
Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Die vorhandene Anwendung
5
2.1
Szenario der Nutzung durch Anwender . . . . . . . . . . . . . . . .
5
2.2
Probleme und Einschränkungen . . . . . . . . . . . . . . . . . . . .
6
3 Die neuen Konzepte
9
3.1
Die Ziele des neuen Konzeptes
3.2
Videostreaming-Technologien . . . . . . . . . . . . . . . . . . . . . 10
3.3
3.4
4.2
9
3.2.1
Microsoft Windows Media . . . . . . . . . . . . . . . . . . . 10
3.2.2
Realmedia-Format . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3
MPEG4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Konzept mit Videostreaming für Markierung . . . . . . . . . . . . 12
3.3.1
JAVA-Anwendung . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2
Webbasierte Anwendung . . . . . . . . . . . . . . . . . . . . 13
3.3.3
Windows-Anwendung mit DirectShow . . . . . . . . . . . . 14
3.3.4
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Konzept mit Netzwerkdateisystem für Markierung . . . . . . . . . 15
3.4.1
Videoschnitt . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.2
Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Die Realisierung
4.1
. . . . . . . . . . . . . . . . . . . .
19
Details der Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1
Synchronisations-Tool . . . . . . . . . . . . . . . . . . . . . 20
4.1.2
Annotations-Tool . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.3
Videoschnitt-Dienst . . . . . . . . . . . . . . . . . . . . . . 23
Verwendete Technologien . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1
C#
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2
Microsoft DirectShow . . . . . . . . . . . . . . . . . . . . . 28
4.2.3
SMIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.4
AviSynth . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.5
VirtualDubMod
. . . . . . . . . . . . . . . . . . . . . . . . 33
v
vi
Inhaltsverzeichnis
4.3
4.2.6
FAAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.7
x264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.8
GPAC MP4Box . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.9
NetSpell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Verknüpfung der externen Tools im Konvertierungslauf . . . . . . . 36
5 Zusammenfassung und Ausblick
5.1
Erweiterungs- und Optimierungsmöglichkeiten
Abbildungsverzeichnis
Listings
Literaturverzeichnis
39
. . . . . . . . . . . 39
I
III
V
1 Einleitung
An der Universität Paderborn findet im Rahmen der Lehrerausbildung das Seminar
Methoden des Informatikunterrichts in Theorie und Praxis statt. Ziel
dieses Seminars ist es, den angehenden Lehrern das notwendige Wissen zur Planung und Durchführung ihres Unterrichts zu vermitteln. Ein wichtiger Teil dieses
Seminars ist die praktische Durchführung einer Unterrichtseinheit mit einer anschließenden ausführlichen Analyse.
In der Lehre ist es wichtig, sich seines Verhaltens und der dadurch bei den
Schülern hervorgerufenen Reaktionen und Emotionen bewusst zu sein und dieses
auch gezielt einsetzen zu können. Der Lehrer steht, als für den Schüler exponierte Persönlichkeit und Vorbild, unter ständiger Beobachtung durch die Klasse. In
der klassischen Lehrerausbildung wird diese Unterrichtssituation geübt unter Aufsicht des eigenen Lehrers, evtl. des normalerweise für diese Stunde vorgesehenen
Lehrers und am Ende durch Prüfer.
In diesem Szenario hat man selber nur eine sehr beschränkte und vor allem
subjektive Sicht: die Reaktionen der Schüler sieht man nur eingeschränkt (vor
allem in Phasen des Tafelanschriebs, während des Auf- oder Umbaus von Unterrichtsmaterialien oder der Konzentration auf ein Schülergespräch) und das
eigene Verhalten bekommt man nur aus der Ich-Perspektive zu sehen. Durch dieses stark eingeschränkte Blickfeld fällt die Selbstbeurteilung ziemlich schwer und
das Schülerverhalten ist unter Umständen nicht direkt erklärbar.
Mit diesem Problembereich beschäftigt sich das Projekt
Visualization of Lear-
ning and Teaching Strategies with Multimedia in Teacher Education, kurz
ViLM[Mag99]. Im Rahmen dieses Projektes, welches den Einsatz von Multimedia
in der Lehre fördern will, wird seit 1998 erfolgreich das gleichnamige Tool ViLM
eingesetzt, um den angehenden Lehrern eine bessere Selbsteinschätzung zu geben,
eine ausführliche Review-Phase zu ermöglichen und eine Basis zu schaffen, um
unter den Lehramtsstudenten eine Diskussion über bestimmte interessante oder
kritische Situationen zu führen.
Die Durchführung dieser entsprechenden Unterrichtseinheiten und die Nachbereitung, was selbstverständlich nur mit Einwilligung der betroffenen Schüler unter
Schutz ihrer Persönlichkeitsrechte und Beachtung der relevanten Datenschutzauflagen erfolgt, läuft nach einem festen Schema ab, dessen Kern die Aufnahme des
1
2
Einleitung
Unterrichtsgeschehens aus den zwei Hauptperspektiven darstellt: der Sicht der
Schüler auf den Lehrer sowie der Sicht des Lehrers auf die Schüler.
In der Nachbereitung des Unterrichts befasst sich der angehende Lehrer intensiv
mit den Aufzeichnungen, was durch verschiedene Faktoren erschwert wird. Eine
Ansicht der Perspektiven nacheinander ist wenig sinnvoll und ein gleichzeitiges
Betrachten auf zwei nebeneinander stehenden Fernsehgeräten unpraktisch. Vor
allem, da die beiden Videos durch das Aufstellen der Kameras und den Start
der Aufnahmen nicht synchron zueinander laufen. Dies ließe sich zwar bei dem
Start der Wiedergabe korrigieren, aber spätestens beim Spulen im Film ginge die
Synchronisation wieder verloren. Oft sind auch nur Teile des gesamten Videomaterials für die Auswertung wirklich relevant. Hier kommt nun das Tool ViLM ins
Spiel, welches den synchronen Zugriff auf beide Perspektiven ebenso ermöglicht,
wie direkt einzelne Phasen zu markieren und mit weiterführenden Informationen
sowie den verwendeten Unterrichtsmaterialien anzureichern.
Anlass für diese Arbeit waren Probleme bei dem Einsatz des bestehenden ViLM
Tools sowie neue Anforderungen. So sind zur Zeit die aufbereiteten Daten nach
dem Export in HTML nicht mehr nutzbar und das Tool benötigt eine ganz spezielle Umgebung, um lauffähig zu sein. Neue Anforderungen sind unter anderem
der automatische Schnitt der Videodaten in einzelne Phasen und die Möglichkeit
der Verbreitung von ausgesuchten Inhalten über das World Wide Web.
1.1 Aufbau der Arbeit
Die Arbeit ist in vier Teile gegliedert. An ihrem Anfang steht die Analyse der
Ist-Situation inklusive Erläuterung der Nutzung. Es folgt ein großer Teil, der das
Ziel der Entwicklung beschreibt und die diesem Ziel im Weg stehenden Probleme.
In diesem Teil wird auch die Abänderung des Konzeptes hin zu einem Realisierbaren Konzept beschrieben. Der dritte Teil befasst sich mit der Realisierung und
den dabei eingesetzten Technologien. Zum Schluss gibt es einen Ausblick über
Erweiterungsmöglichkeiten der realisierten Lösung.
1.2 Vorgehensweise
Einarbeitung. Die Einarbeitungsphase umfasst die Erarbeitung der für die Erstellung der Arbeit notwendigen theoretischen und praktischen Grundlagen. Die
hierfür nötigen Informationen wurden durch Literaturrecherche zusammengetragen und durch die Analyse der vorhandenen Anwendung und Arbeitsabläufe erworben.
Kapitel 1 • Vorgehensweise
Problemanalyse. Bei der Problemanalyse wurde mit den Verantwortlichen über
die bestehende Anwendung und die Probleme im Praxiseinsatz gesprochen.
Konzeption.
Bei der Konzeption wurde nun aufbauend aus den Informationen
der Problemanalyse, neuen Anforderungen und Wünschen ein Ideal-Konzept entwickelt. Dieses saubere, universelle Konzept erwies sich bei genauer Analyse der
möglichen Technologien als nicht umsetzbar und wurde nun in einem iterativen
Prozess unter Einbeziehung der Verantwortlichen in ein umsetzbares Konzept
abgewandelt, das genügend Vorteile im Vergleich zur bestehenden Lösung bietet
und modern und gut erweiterbar ist. Ein großer Teil der Informationen entstammt
den technischen Handbüchern der untersuchten Technologien.
Umsetzung. In dieser Phase wurde die praktische Umsetzung des Konzeptes
vorgenommen inklusive Installation und Inbetriebnahme in der Zielumgebung im
Netz der Universität Paderborn. Dabei wurde auch darauf geachtet, unnötige
Dinge nicht erneu implementieren zu müssen, sondern bestehende Komponenten
und Technologien wiederzuverwenden.
3
4
Einleitung
2 Die vorhandene Anwendung
Die vorhandene Anwendung für die Auswertung von Unterrichtsszenarien entstand im Rahmen des ViLM Projektes seit 1998. Sie dient der multimedialen
Evaluation in der universitären Lehrerausbildung.
Die Anwendung wurde zur Erzielung von Plattformunabhängigkeit in der Programmiersprache JAVA verfasst und nutzt XML zur Speicherung der Annotationen. Es besteht zusätzlich die Möglichkeit, weitere Unterrichts-Materialen (z.B.
PDF-Dokumente, Bilder, Videos) in das Projekt einzufügen. Nach der Arbeit ist
eine Aufbereitung der Daten als Web-Seite mit eingebetteten Videos und Download der zusätzlichen Materialien möglich.
Die Herangehensweise an die Problemstellung und das aktuelle Bedienkonzept1
der Software hat sich in der Praxis in der Lehre der
Arbeitsgruppe Didaktik
der Informatik2 an der Universität Paderborn bewährt. Allerdings ist die dem
Werkzeug zugrunde liegende Technik nicht mehr auf dem neusten Stand und es
weist auch ein paar Mängel im Software-Design auf. Dies führt zu (mittlerweile
sehr deutlichen) Einschränkungen in der Effizienz und der Benutzbarkeit des
Werkzeugs, welche eine Neuentwicklung notwendig machen.
2.1 Szenario der Nutzung durch Anwender
Als Erstes finden die üblichen Unterrichtsvorbereitungen statt. Zusätzlich gibt es
nun allerdings noch ein paar weitere Dinge zu erledigen. Da die Aufnahmen in
verschiedenen Unterrichtsräumen stattfinden, muss vor dem Unterricht für eine
passende Positionierung der Kameras gesorgt werden. Hier ist es wichtig darauf
zu achten, dass alle relevanten Inhalte im Bild sind, die Kameras gleichzeitig
aber nicht zu stark auffallen oder gar das Unterrichtsgeschehen irgendwie behindern. Des Weiteren ist die Akustik nicht immer optimal, so dass die Kameras
unter Umständen mit speziellen Mikrofonen ausgestattet werden müssen, um das
Geschehen einfangen zu können. Es gibt während des Unterrichts Personal an
den Kameras, sodass die einmal gewählten Perspektiven auch in Hinsicht auf
die Nutzung weiterer Materialien wie z.B. Overhead-Projektoren oder Beamern
anzupassen sind. Eine weitere wichtige Einschränkung ist, dass sich das Blick1
Es fanden mehrfach Überarbeitungen der Benutzeroberfläche statt, nachdem sich die ursprüngliche Version als nicht praxistauglich erwies.
2
URL: http://ddi.uni-paderborn.de/
5
6
Die vorhandene Anwendung
feld der Kameras zwingend überschneiden muss. Diese Vorraussetzung ist Folge
von dem Wunsch zur Synchronisation der Videos. In der Praxis wird mit einer
der Nachbildung der vom Film bekannten Klappe durch die menschlichen Arme
gearbeitet.
Nach dem Unterrichtsende werden die Videodaten von den Betreuern in das
MPEG-1-Format konvertiert und auf einem Server des Lehrstuhls bereitgestellt.
Die Studierenden synchronisieren nun das Video und fügen die Annotationen und
Materialien hinzu, wobei bei einem neuen Annotationsprojekt die Synchronisation erneut durchgeführt werden muss.
Am Ende des Aufbereitungsprozesses steht der Export der Daten in HTML mit
eingebetteten Videos, um eine einfache Präsentation der Inhalte auch ohne das
ViLM-Tool zu ermöglichen. Die Besprechung der Stunde erfolgt wahlweise unter
Zuhilfenahme des Exports oder direkt im ViLM-Tool.
2.2 Probleme und Einschränkungen
Das bestehende Werkzeug kann nur MPEG-13 Video-Daten mit entsprechenden
Einschränkungen bei der Bildqualität im Vergleich zu modernen Kompressionsverfahren (bei identischem Bandbreitenbedarf) verarbeiten. Die zu verarbeitenden Videos sind vom Tool auf eine Bildauflösung von 320x240 Pixeln beschränkt
und der Anwender arbeitet mit der Anwendung in einer festen Fenstergröße. Eine
Nutzung großer, hochaufgelöster Bildschirme bringt also keinen Vorteil für den
Anwender.
Die aktuell in der Evaluation der Lehre eingesetzten Kameras liefern bereits
MPEG-2-Daten4 in entsprechend besserer Qualität (und auch Auflösung). Dies
führt dazu, dass die anfallenden Videodaten einen zeitaufwendigen und verlustbehafteten Konvertierungslauf in ein veraltetes Format benötigen, bevor mit der
Annotation begonnen werden kann.
Obwohl in JAVA entwickelt, ist das in Abbildung 2.1 dargestellte Werkzeug defacto nur unter Windows und in einer ganz speziellen Umgebung lauffähig: Es
ziehen sich fest-kodierte Pfade durch die komplette Anwendung, Konfigurationsund Datendateien sowie den HTML-Export: Eine Ausführung ist nur möglich,
wenn die Anwendung aus dem Ordner S:\vilm\ gestartet wird. Dies stellt eine
gravierende Einschränkung der Nutzbarkeit dar. Des Weiteren muss zur Nutzung
der JAVA-Anwendung auch das
Performance Pack des JAVA Media Frame-
work (JMF) unter Windows installiert sein. Die Installation kann nur ein Administrator vornehmen. Eine korrekte Auslieferung der HTML-Exporte über einen
Webserver ist aufgrund der oben angesprochenen Pfadangaben nicht möglich. Ein
3
4
ISO-Standard: ISO/IEC 11172-2:1993
ISO-Standard: ISO/IEC 13818-5:2005
Kapitel 2 • Probleme und Einschränkungen
Abbildung 2.1: Aktuelle ViLM Anwendung (mit Fehlermeldung beim Öffnen
von Materialien)
weiteres Hindernis dafür ist die Art der Referenzierung der Videos: die eingebetteten Videoplayer im HTML-Export verlinken direkt auf die kompletten mehrere
hundert Megabyte großen Videodateien.
Ein weiteres Problem entwickelte sich durch Änderungen an dem im HTMLExport benutzen Active-X-Control des Microsoft Windows Media-Players: seit
den letzten Sicherheitsupdates ist ein doppeltes Einbinden5 in eine HTML-Seite
nicht mehr möglich, wodurch die HTML-Exporte nun unbrauchbar sind, da sogar
in der Zielumgebung eine Nutzung nicht mehr möglich ist. In Abbildung 2.2 ist
so ein aktueller HTML-Export zu sehen.
Als letztes Problem sei genannt, dass die Implementation bezüglich der angehängten Materialien sehr wählerisch ist (es ist nicht möglich, so populäre Dateiformate
wie PDF, RTF oder GIF zu nutzen). Es treten auch Stabilitätsprobleme beim
Verarbeiten der eigenen Daten auf, die sich dadurch äußern, dass die gespeicherten Annotationen nicht wieder gelesen werden können.
An der Anwendung wurden bereits mehrfach Veränderungen vorgenommen, um
die Benutzeroberfläche für eine intuitive Bedienbarkeit weiterzuentwickeln. Dabei
wurde die Erfahrung gemacht, dass sich der Code nicht gut warten und erweitern lässt. Aufgrund der gravierenden Probleme, der Erfahrungen aus vorherigen
5
für die zwei parallelen Sichtweisen auf das Unterrichtsgeschehen
7
8
Die vorhandene Anwendung
Abbildung 2.2: Aktueller HTML-Export
Änderungen und nach einer Analyse des vorhandenen Source-Codess erschien der
Aufwand für eine Weiterentwicklung des vorhandenen Tools unangemessen hoch.
Aus diesen Gründen fiel die Enscheidung für eine Neuentwicklung des ViLMTools und es wurde mit der Analyse der Anforderungen an ein neues System
begonnen.
3 Die neuen Konzepte
3.1 Die Ziele des neuen Konzeptes
Die neue Umsetzung soll das Werkzeug nicht nur technologisch auf den aktuellen
Stand der Technik bringen und für den Anwender die Ergonomie bei der Benutzung verbessern, sondern auch neue Funktionalität und (sofern realisierbar) eine
weitgehende Plattformunabhängigkeit von dem System des Anwenders bieten.
Die Idee des neuen Konzeptes ist, einen zentralen Steaming-Server zu benutzen,
der die Video-Daten sowohl einem Markierungs-Werkzeug als auch später den
Endanwendern im Web-Browser zur Verfügung stellt.
Bei der Umsetzung soll bevorzugt auf frei verfügbare Technologien ohne große
Lizenzkosten gesetzt werden und natürlich auch eine einfache Bedienbarkeit für
die Anwender im Vordergrund stehen.
Video-Streaming Um die Daten für diesen Anwendungsfall korrekt übermitteln
zu können, müssen die Videodaten zusammen mit den Audiodaten multiplexed1
werden. Streaming wird oft nur verwendet, um Videodaten seriell wiederzugeben.
Es soll auch bei der Markierung auf den Streaming-Server zugegriffen werden, damit der Benutzer vor der Nutzung des Tools keine entfernten Netzwerklaufwerke
mounten muss. Dadurch wird in diesem Szenario bei der Markierung allerdings
jederzeit Zugriff auf beliebige Positionen (Zeitpunkte) im Stream benötigt. Die
Notwendigkeit ergibt sich daraus, dass der Anwender bei der Markierung schnell
bestimmte Positionen im Datenstrom anspringen möchte und nicht seriell (auch
nicht mit erhöhter Geschwindigkeit) die komplette Aufnahme ansehen. Der Zugriff wird außerdem bei der Wiedergabe der geschnittenen Videos benötigt, wenn
dies nur virtuell on-the-fly2 geschehen soll. Aus diesem Grund ist es zusätzlich
notwendig, in der Datei regelmäßig Zeitstempel zu setzen, um einen Zugriff auf genaue Positionen zu realisieren. Es spezifizieren bereits mehrere Steaming-Formate
dieses notwendige Feature und es sind bereits Steaming-Server verfügbar, die dieses implementieren.
1
Blockweise Verschachtelung von Video- und Audiodaten, damit diese quasi gleichzeitig zur
Verfügung stehen.
2
Dieses Vortäuschen des Schneidens während der Wiedergabe erspart Festplattenplatz und
reduziert den Zeit- und Rechenaufwand vor der Veröffentlichung. Es soll für den Anwender
transparent erscheinen, als ob ein entsprechend geschnittener Film vorliegt.
9
10
Die neuen Konzepte
On-the-fly Selektion
der markierten
Inhalte aus dem
kompletten VideoDatenstrom
Markierung der
Video-Daten
Plattformunabhängig
Firewall Streaming
Video-Kodierung
für Streaming
Streaming
Wiedergabe der
aufbereiteten Inhalte
Internet
MPEG-2
Streaming-Server
Abbildung 3.1: Ziel-Architektur des neuen Systems
3.2 Videostreaming-Technologien
Als Erstes werden die unterschiedlichen Möglichkeiten für Videostreaming mit
ihren Vor- und Nachteilen betrachtet. Dabei sind sowohl die Erstellung bzw.
Aufbereitung des Videomaterials als auch Eigenheiten des Datenformats selber
und der zur Betrachtung notwendige Player relevant.
3.2.1 Microsoft Windows Media
Microsoft bietet unter dem Namen Windows Media Video (WMV) einen Videocodec mit passendem Containerformat3 (Advanced Streaming Format, ASF) und
Audio-Codec (Windows Media Audio, WMA) zum Streaming an. Dieses ist von
Haus aus nur unter einem Windows-Server produzier-, stream- und abspielbar.
Es gibt allerdings bereits OpenSource-Programme, die dieses Format auch auf
Linux und OS X abspielen können4 .
3.2.2 Realmedia-Format
Ein weiterer großer Kandidat im Videostreaming-Markt wird von der Firma Realmedia hergestellt. Es gibt den Player für Windows, Macintosh und (in einer veralteten Version) für Linux. Das von Realmedia initiierte Open-Source Projekt
3
Video- und Tonspuren sind unabhängig von einander komprimiert. Um für ein Video nur eine
Datei handhaben zu müssen, werden diese Daten in einem Container gespeichert. Dieser sorgt
auch für die Synchronisation von Video und Ton, da beide getrennte Taktzeiten haben. Hier
gibt es eine Vielzahl an Formaten mit unterschiedlichen Möglichkeiten wie z.B. mehreren
Tonspuren zu einer Videospur.
4
Es handelt sich hier um die ffmpeg Bibliothek (http://ffmpeg.mplayerhq.hu/) und den
VLC-Player (http://www.videolan.org)
Kapitel 3 • Videostreaming-Technologien
Helix-Player5 liefert ebenso keine Implementierung der aktuellsten RealmediaFormate für Linux, wie die ffmpeg-Bibliothek, welche zumindest ältere Versionen
dekodieren kann. Es gibt das Tool zur Erstellung von Realmedia-Dateien in einer kostenlosen Variante. Um die Daten zu streamen ist allerdings in der Praxis
eine kostenpflichtige Server-Anwendung6 nötig, welche für Windows, Linux und
Solaris verfügbar ist.
3.2.3 MPEG4
MPEG4 hat als offener Industrie-Standard eine gute Verbreitung auf allen denkbaren Betriebssystemen erreicht. Seine große Verbreitung verdankt es den anderen sehr populären Formaten seines Standardisierungs-Gremiums, der Moving
Picture Experts Group (MPEG), vor allem dem Audioformat MP3 und dem bei
DVDs verwendeten MPEG2.
Es bietet sich an, bei MPEG4 den Teil MPEG-4/AVC, besser bekannt unter dem
Namen H.264, zu verwenden. H.264 bietet bei gleicher Bitrate weit bessere Bildqualität bzw. erlaubt bei Beibehaltung der Qualität eine Reduzierung der Bitrate.
Diese Effizienzsteigerung wird durch höhere Rechenlast erkauft. In unserem Ansatz ist höhere Rechenleistung weit günstiger als Bandbreite, daher bietet sich
H.264 als Codec an.
Um MPEG-4-Daten zu streamen, wird noch ein Übertragungs-Protokoll benötigt.
Hier empfiehlt sich das Realtime Streaming Protokoll (RTSP). Es gibt verschiedene Produkte am Markt, die dieses implementieren. Als OpenSource-Lösung ist
hier der Apple Darwin Streaming Server, der zusätzlich für andere Plattformen
als OS X verfügbare Bruder des Quicktime Streaming Servers, interessant.
3.2.3.1 Apple Darwin Streaming Server
Der Darwin Streaming Server (DSS) von Apple war der erste frei verfügbare
RTSP/RTP Streaming-Server, der eine große Anzahl unterschiedlicher Formate
wie H.264, MPEG-4 und 3GPP7 unterstützt. Der DSS wird von Akamai8 , einem
großen Unternehmen zur Lastverteilung und Beschleunigung der Distribution
von Online-Inhalten, zur Verbreitung von Quicktime und MPEG-4 StreamingInhalten sehr erfolgreich eingesetzt[Inc99].
5
https://player.helixcommunity.org/
Die kostenlose Version ist auf nur fünf Clients beschränkt
7
3rd Generation Partnership Project; eine Kooperation von verschiedenen Firmen, um Videoformate für den Mobilfunk (UMTS, GSM) zu standardisieren. Es wird unter anderem im
Multimedia Messaging Service (MMS) verwendet, benutzt MPEG-4, H.264 und AAC als
Codecs und hat Ähnlichkeit mit dem MP4-Containerformat.
8
http://www.akamai.com
6
11
12
Die neuen Konzepte
3.2.4 Fazit
Aufgrund der gewünschten Plattformunabhängigkeit und unter Berücksichtigung
der anfallenden Kosten bleibt von den verschiedenen Videostreaming-Formaten
nur MPEG4 mit Streaming über das RTSP-Protokoll übrig. Diese bieten, dadurch
dass es offene Standards sind, eine weitaus größere Unterstützung durch fertige
Tools, was sich durch mehr Flexibilität und Möglichkeiten positiv auf das Konzept
auswirkt.
3.3 Konzept mit Videostreaming für Markierung
Auf Basis der Entscheidung für MPEG4 und RTSP stehen mehrere Möglichkeiten
zur Implementation bereit. Intuitiv fällt bei Plattformunabhängigkeit der Blick
zuerst auf einen webbasierten Ansatz bzw. auf die Programmiersprache JAVA.
Aufgrund der Probleme mit diesen beiden im Folgenden beschriebenen Ansätzen,
wurde auch eine Windows-Anwendung für das Markierungs-Werkzeug in Betracht
gezogen.
3.3.1 JAVA-Anwendung
Eine rein JAVA basierte Lösung benötigt externe Bibliotheken, um MPEG4 Daten wiederzugeben. Mit dem von SUN gratis vertriebenen Java Media Framework
(JMF)9 lassen sich nur in dem veralteten Format MPEG1 gespeicherte Daten wiedergeben. Es existiert von der Firma IBM ein Plugin für das JMF, mit welchem
sich MPEG4 Daten abspielen lassen. Dieses implementiert allerdings nur einen
geringen Teil des Standards, wird nicht weiterentwickelt und unterstützt kein
Streaming.
Es existiert allerdings von IBM eine weitere MPEG4-Implementation für JAVA:
IBM Toolkit for MPEG-410 . Dieses kommerziell vertriebene Toolkit wird allerdings für den Bereich Forschung und Lehre über die IBM Academic Initiative11
gratis lizensiert. Diese Erweiterung basiert nicht auf dem JMF und bietet eine fast
vollständige Implementation des Standards - inklusive Streaming-Unterstützung
mit Hilfe des RTSP.
Probleme dieser Lösung Im Praxistest erwies sich dieser Ansatz leider als wenig überzeugend. Es gab keine Möglichkeit, innerhalb der gestreamten Datei zu
navigieren. Außerdem waren die ersten zehn Sekunden bei einer Wiedergabe per
Streaming stets nicht erkennbar. Es war stattdessen sichtbar, wie sich aus den
9
Das JMF wird in der bestehenden Lösung eingesetzt
http://www.alphaworks.ibm.com/tech/tk4mpeg4
11
http://www-304.ibm.com/jct09002c/university/scholars/academicinitiative/
10
Kapitel 3 • Konzept mit Videostreaming für Markierung
von zu starker Komprimierung bzw. fehlenden Daten bekannten Blockartefakten
langsam ein klares Bild aufbaut. Auch anders und häufiger gesetzte Zeitstempel
und Vollbilder (so genannte I-Frames) brachten keine Verbesserung.
In Ermangelung anderer nativer MPEG4-Codecs für die JAVA-Plattform ist dieser Ansatz nicht umsetzbar.
3.3.2 Webbasierte Anwendung
Video-Darstellung und -Schnitt sind mit HTML-Bordmitteln nicht möglich. Neben statischen Seiten gibt es die Möglichkeit der Einbindung von externen Plugins
in Webseiten und weitere Interaktion lässt sich mit Hilfe von AJAX12 realisieren.
Windows-Media-Player Dem Windows-Media-Player fehlt es für diese Anwendung an Verfügbarkeit für andere Plattformen. Außerdem ist dieser nicht von
Haus aus in der Lage MPEG4 abzuspielen, was zu Problemen bei vielen Anwendern führen würde. Es müssten von den Anwendern weitere Codecs und Demuxer
installiert werden. Dieses stellt vor der Nutzung einer Web-Anwendung eine große
Hürde dar.
Flash-Player
Der Flash-Player der Firma Macromedia13 wird im Web häufig ge-
nutzt. Laut einer von der Firma Adobe im Juni 2006 in Auftrag gegebenen Studie
[Inc06] ist der Flash-Player, mit einer Installationsquote von 97.3%, zur Zeit das
am häufigsten installierte Browser Plugin. Seine Verbreitung liegt damit weit vor
JAVA (88%), dem Windows-Media Player (84.8 %), Quicktime (66.1%) oder dem
Realplayer (54.6%). Auf den Seiten des bekannten Socialising Network Youtube14
und bei dem Ex-Konkurrenten15 Google-Video16 können die Möglichkeiten sofort
getestet werden. Das Streaming von Videos klappt recht gut. Es findet ein Puffern
der Daten statt, um Schwankungen der Übertragungsbandbreite zu kompensieren. Eine Navigation ist allerdings nur innerhalb der gepufferten Daten und auch
dort nur eingeschränkt möglich.
Die Werkzeuge zur Nutzung der Flash-Plattform sind kommerziell und diese werden benötigt, um die Video-Möglichkeiten auszuschöpfen. Es befinden sich allerdings OpenSource Standalone Video-Player auf Flash-Basis17 in Entwicklung
12
Asynchronous JavaScript and XML; Eine Technik, um durch Client-Seitig ablaufendes JavaScript und die asynchrone Übertragung von Daten (in XML [oder vermehrt auch JSON]
kodiert) zum Server und zurück eine schnelle Interaktion des Anwenders mit der Anwendung zu erlauben, ohne für jede Anfrage die komplette Seite neu übertragen und rendern zu
müssen
13
http://www.macromedia.de; Während dieser Arbeit von der Firma Adobe (http://www.
adobe.de) übernommen
14
http://www.youtube.com
15
Es wurde während der Arbeit die Übernahme von Youtube durch Google gestartet
16
http://video.google.com/
17
Flash Video Player: http://jeroenwijering.com/?item=Flash Video Player
13
14
Die neuen Konzepte
und die ffmpeg-Bibliothek ist bereits in der Lage, das spezielle FLV-Videoformat
(welches auf MPEG4-Kodierung basiert) zu verarbeiten und zu erstellen. Damit wäre der Flash-Player eine Alternative, um die fertig geschnitten Videos zu
präsentieren.
Quicktime
Das von der Firma Apple18 gratis vertriebene Quicktime-Plugin ist
für die wichtigsten Plattformen verfügbar19 und lässt sich über eine reichhaltige
API [Inc00] fernsteuern. Neben dem eigenen Dateiformat beherrscht Quicktime
auch MPEG4 in einem RTSP-Stream sowie die Synchronized Multimedia Integration Language (SMIL). Mit Hilfe von SMIL wäre eine Synchronisation von
zwei Videostreams direkt über Zeitstempel möglich. Bei Tests dieser Lösung traten allerdings auch Probleme mit der exakten Ansteuerung von Positionen im
Stream auf, so dass eine Nutzung nicht möglich war.
3.3.3 Windows-Anwendung mit DirectShow
Ein weiterer Ansatz, um Streaming nutzen zu können, war, auf die Plattformunabhängigkeit des Markierungs-Tools zu verzichten und ein nur unter Windows
lauffähiges Programm mit Nutzung von DirectShow20 zu verwenden. Allerdings
traten auch bei diesem Ansatz die bereits bekannten Probleme der Ansteuerung
von Positionen im Stream auf. Des Weiteren ist es nur nach Installation einer Vielzahl von freien Codecs möglich, den per RTSP übertragenen MP4-Datenstrom
korrekt zu dekodieren, da dafür standardmäßig keine passenden Codecs mitgeliefert werden.
3.3.4 Fazit
Es gibt mit diesem Ansatz zu viele Probleme bei der praktischen Umsetzung.
Das größte Hindernis liegt bei dem Streaming der Videodaten. Die StreamingProtokolle bieten zwar prinzipiell die Möglichkeit innerhalb der Datei zu springen
und diese nicht in einem Durchlauf komplett anzusehen, allerdings hakt es in
der Praxis noch stark. Natürlich spielt hier auch das Netzwerk eine große Rolle,
da aufgrund der Kompression zusätzliche Daten vor der eigentlich gewünschten
Position übertragen werden müssen. Die Kosten für viele kommerzielle Lösungen,
die dieses Problem trotzdem nicht lösen, sind auch recht hoch.
18
http://www.apple.com
Für OS X und Windows unter http://www.apple.com/quicktime/download/ sowie für Linux
unter http://heroinewarrior.com/quicktime.php3
20
DirectShow war früher Teil der Programmier-Bibliothek DirectX (http://www.microsoft.
com/directx/) ist mittlerweile aber direkt in die Windows-API übernommen worden. Es
handelt sich um eine Schnittstelle für Audio- und Video-Codecs zur Integration in Windows
sowie um die definierte Schnittstelle für die Seite der Anwendungen, damit diese, ohne die
genutzten Codecs im Detail zu kennen, Audio- und Video-Content verarbeiten können.
19
Kapitel 3 • Konzept mit Netzwerkdateisystem für Markierung
Aufgrund dieser Probleme mit dem komplett auf Streaming basierten Konzept,
wurde dieses als nicht realiserbar angesehen und im folgenden überarbeitet.
3.4 Konzept mit Netzwerkdateisystem für Markierung
Es gibt zwei große Punkte, die im Vergleich zum vorhergehenden Konzept einer
Änderung bedurften.
Als Erstes wurde der Einsatz von Streaming zum Videoschnitt entfernt, da sich
dieses als kritischster Punkt erwies. Ersetzt wurde das Streaming durch den Einsatz eines Netzwerkdateisystems zum Zugriff auf die Rohdaten. Das Netzwerkdateisystem erlaubt einen direkten Zugriff auf einzelne Positionen in den VideoDaten.
Als Nächstes wurde die Plattformunabhängigkeit bei der Markierung aufgegeben.
Dies resultierte aus den Problemen mit der JAVA-Plattform (vor allem aufgrund
der starken Einschränkung bezüglich der verwendbaren Video-Codecs) und des in
das neue Szenario nicht sinnvoll integrierbaren webbasierten Ansatzes. Es besteht
weiterhin die Möglichkeit der alternativen Umsetzung mit Hilfe eines Systems auf
Basis von C++, Open-Source Video-Biblotheken wie z.B. libavcodec21 und plattformunabhängigen GUI-Toolkits, wie z.B. QT22 oder wxWidgets23 . Diese Art der
Umsetzung wurde allerdings aufgrund des zur Implementierung erforderlichen
hohen Zeitaufwandes bei der plattformunahängigen C++-Programmierung nicht
weiter verfolgt24 .
Im Abbildung 3.2 ist die aktualisierte Ziel-Architektur des Systems dargestellt.
Das verwendete Netzwerkdateisystem spielt in diesem Fall nur eine untergeordnete Rolle, es muss nur auf einem Windows-System verfügbar sein und den blockweisen Zugriff auf die Dateien zulassen. Es bieten sich hierfür zum Beispiel das
Andrew Filesystem (AFS) oder das Common Internet File System (CIFS)25 an.
Bei diesem Szenario wird nun direkt mit dem Kamera-Ausgangsmaterial gearbeitet und nach der Markierung erfolgt ein Schnitt in die erstellten Phasen mit
anschließender Konvertierung in ein streamingfähiges Format. Der echte Schnitt
der Videos wurde erforderlich, da die genaue Positionierung im Videostrom bei
den aufbereiteten Daten die selben Probleme bereitet wie bei der Markierung per
Streaming.
21
Die Leistungsfähigkeit dieser Bibliothek ist unter anderem durch den VLC media player (http:
//www.videolan.org), der auf dieser aufsetzt, bekannt
22
http://www.trolltech.com/products/qt
23
http://www.wxwidgets.org/
24
Es wurde vorher auch durch Tests mit Hilfe von VLC und Mplayer (ebenfalls auf libavcodec aufsetzend) festgestellt, dass auch dieser Ansatz die Markierung per Streaming nicht
ermöglicht
25
Umgangssprachlich besser bekannt als Windows Datei-Freigabe
15
16
Die neuen Konzepte
Markierung der
Video-Daten
Wiedergabe der
geschnittenen,
aufbereiteten Inhalte
MPEG-2
Netzwerk-Dateisystem
Sc
h
tun nitt un
gf
ür d Au
Str fbe
ea
min reiFile-Server
g
Streaming
Firewall
Internet
Streaming-Server
Abbildung 3.2: Ziel-Architektur mit Nutzung eines Netzwerkdateisystems für
die Markierung und automatischem Videoschnitt
Vorteile Durch die erst nach der Markierung stattfindende Komprimierung für
das Streaming ist während der Annotation die volle Bildqualität des Ausgangsmaterials verfügbar. Es gibt auch keine Notwendigkeit, die Videos mehrfach aufzubewahren - im Gegensatz zu dem ersten Ansatz, bei dem man neben den zu
streamenden Videos auch das Ausgangsmaterial aufbewahren würde. Außerdem
fällt bei diesem Szenario durch das Verschieben der Neukomprimierung keine
große Wartezeit vor dem Markieren an.
Nachteile Die vor der Markierung eingesparte Wartezeit verlagert sich weiter
nach hinten: nun gibt es Wartezeit nach der Annotation der Daten, bis diese fertig
geschnitten und für das Streaming aufbereitet zur Veröffentlichung bereitstehen.
Je nachdem wie oft (z.B. durch nachträgliche Korrekturen) geschnitten wird, kann
es insgesamt länger dauern. Wenn es zu einem Set Videos sehr viele Annotationen
und damit überlappende Phasen gibt, so können Teile der Videos redundant auf
der Festplatte zum Streaming vorliegen.
3.4.1 Videoschnitt
Es gibt unterschiedliche Ansätze, um Videodaten zu schneiden. Ein Problem bei
der Verarbeitung der Videodaten stellt die verzahnte Speicherung von Audiound Videodaten dar. Eine andere Schwierigkeit ist, dass durch die heutige starke
Komprimierung von den meisten Bildern nur Teile vorhanden sind, die erst mit
anderen Bildern zusammengefügt das Bild ergeben.
Kapitel 3 • Konzept mit Netzwerkdateisystem für Markierung
3.4.1.1 MPEG4 in MP4-Container
Das Tool MP4-Box26 ermöglicht den Schnitt von im Dateisystem vorhandenen
MP4-Daten. Dazu nimmt es als Parameter die Laufzeit bis zur gewünschten
Stelle in Sekunden an. Ein Schnitt ist allerdings nur an den Random-Access
Points im Datenstrom möglich. Aus diesem Grund vergrößert das Tool den Ausschnitt, um keine gewünschten Daten abzuschneiden. Im Test lag das Tool bei
den Schnittpositionen bis zu zehn Sekunden von den gewünschten entfernt. Auch
Veränderungen bei der Kodierung des Ausgangsmaterials bezüglich der Random
Access Points brachten keine Reduzierung auf tolerierbare Fehler.
3.4.1.2 Schnitt mit Neukomprimierung
Für den Schnitt mit anschließender Neukomprimierung des Videos bietet sich das
Tool AVISynth27 an. Dabei handelt es sich um einen sogenannten Frameserver.
Ein Frameserver dient dazu, Einzelbilder aus einem Videodatenstrom bereitzustellen. Man kann sich die vom Frameserver gelieferten Daten wie eine klassische
Kinofilmrolle vorstellen: viele einzelne Vollbilder, die schnell abgespielt den Film
ergeben.
Der große Vorteil bei der Arbeit mit einem Frameserver ist, dass bildgenau geschnitten werden kann und keine Rücksicht auf die Kodierung des Bildes in der
Ursprungsdatei28 nehmen muss. Neben diesem Vorteil wird eine hohe Flexibilität
erreicht: die Einzelbilder werden nicht platzverschwenderisch auf die Festplatte
geschrieben, sondern bei Bedarf on-the-fly aus den Videodaten generiert. Diese
Generierung läuft meist scriptgesteuert ab und erlaubt gleichzeitig viele Operationen, wie zum Beispiel Bildoptimierungen, vorzunehmen. AviSynth bringt
hierfür eine eigene flexible Scriptsprache mit. Aktuell ist die stabile Version 2.5
verwendbar. Der Nachfolger (Version 3.0) bringt einige große Änderungen an der
Scriptsprache und dem Plugin-Konzept mit sich, ist allerdings noch in der Entwicklung und bisher nicht produktiv einsetzbar.
Ein weiterer wichtiger Vorteil liegt darin, dass die nachgeschalteten Anwendungen
unabhängig von den Eingabedaten stets einen für sie nutzbaren Videodatenstrom
bekommen. Durch die Nutzung von Microsofts DirectShow zum Import der Daten
in AviSynth und dessen Erweiterungsmöglichkeiten um weitere Codecs bekommt
26
http://gpac.sourceforge.net/
http://www.avisynth.org
28
Bei heutigen hochkomprimerenden Videocodecs sind Vollbilder, sogenannte I-Frames, die
Ausnahme. Sie existieren, um eine bessere Navigation innerhalb der Datei zum Spulen zu
ermöglichen. Die Mehrzahl der Bilder ist nur zu einem Bruchteil gespeichert: nämlich genau
die Differenz zum vorhergehenden Bild (Prediction-Frames, P-Frames) genommen werden
muss. Zur weiteren Reduzierung der Datenrate gibt es auch Bilder, die zusätzlich die Differenz zum nachfolgenden Bild kodiert haben (Bidirectional-Frames, B-Frames). Durch dieses
System liegen die Frames in den Videostreams nicht mehr korrekt serialisiert vor, sondern
den B-Frames im Film folgende I- und P-Frames müssen im Datenstrom vorher übertragen
werden.
27
17
18
Die neuen Konzepte
die Anwendung nun eine Flexibilität, die mit den anderen Szenarien nicht ohne
Weiteres hätte erreicht werden können: Sämtliche Video- und Audiokompressionsverfahren, die mit dem Windows MediaPlayer abspielbar sind, können als
Eingangssignal verwendet werden.
Durch das Nachschalten weiterer Programme ist die Komprimierung mit jedem
unter Windows vorhandenen Codec möglich.
Um das Zielformat - für den Darwin-Streaming-Server nutzbare Daten - zu erhalten, bietet sich die Komprimierung der Videodaten in H.264 mit dem freien
Codec x26429 an. Für den Ton, der im AAC (Advanced Audio Coding) Format
vorliegen muss, kann die Konvertierung mit Hife von faac30 erfolgen.
Anschließend würden die Video- und Audiodaten durch das Tool MP4-Box in
den MP4 Container verpackt.
3.4.2 Fazit
Der direkte Schnitt von vorher erstellten MP4-Dateien erwies sich als nicht sinnvoll nutzbar. Die Realisierung dieses Konzeptes scheint - bei Nutzung des Schnittes mit Neukomprimierung - möglich zu sein und ausreichend Vorteile gegenüber
der bestehenden Anwendung zu bieten, auch wenn im Bezug aus das Streaming
zur Markierung Abstriche gegenüber dem vorherigen Konzept in Kauf genommen
werden müssen. Aus diesem Grund wird dieses Konzept nun verwendet, um die
prototypische Implementierung vorzunehmen.
29
30
http://developers.videolan.org/x264.html
http://www.audiocoding.com/
4 Die Realisierung
Die Anwendung wird dem Konzept mit Netzwerkdateisystem (Kapitel 3.4) folgend implementiert. Dabei wird die Variante mit Videoschnitt durch die Nutzung eines Frameservers umgesetzt. In diesem Kapitel befinden sich Details zu
der Umsetzung, den dabei verwendeten Technologien und Anwendungen und zu
wichtigen während der Umsetzung getroffenen Entscheidungen.
4.1 Details der Umsetzung
In der Umsetzung des Tools wurde auf eine Dreiteilung der Aufgaben gesetzt.
Als Erstes wurde der langwierige Videoschnitt- und Konvertierungsprozess in
einen Windows-Dienst ausgegliedert. So kann diese Aufgabe automatisiert ohne
Benutzeraufsicht, -interaktion oder auch nur -anmeldung erfolgen. Der nächste
Teil, der in eine separate Anwendung ausgelagert wurde, betrifft die Synchronisation der Videos. Es handelt sich hierbei um eine Aufgabe, die nur einmalig
ausgeführt werden muss, bisher aber bei jeder Benutzung des bestehenden Tools
anstand. So ergeben sich nun die folgenden drei Teile:
1. Synchronisations-Tool
2. Annotations-Tool
3. Videoschnitt-Dienst
Um weiteren Nutzen aus der Abspaltung der Synchronisation zu ziehen, werden
von dem Synchronisations-Tool Projektverzeichnisse angelegt. Diese enthalten alle zur Annotation nötigen Daten, verwalten alle auch später anfallenden Daten
und können beliebig viele verschiedene Annotationen zu einem Set Videos aufnehmen. In Abbildung 4.1 ist der Aufbau dargestellt. Eine Kommunikation zwischen Synchronisations-Tool und Annotation-Tool gibt es nur indirekt über die in
das Projektverzeichnis geschriebenen, in der Datei vilm.xml abgelegten, Daten.
Zwischen dem Annotations-Tool und dem Schnittwerkzeug gibt es eine ausgiebige auf .NET-Remoting basierende Kommunikation, welche den auszuführenden
(den Schnitt und Export betreffenden) Code in das Annotations-Tool über die
Scriptschnittstelle CS-Script nachlädt. Dadurch stehen den Endanwendern nach
einem Update des Schnittwerkzeuges sofort alle neuen Möglichkeiten offen und
es gibt bei der Kommunikation keine Versionsprobleme.
19
20
Die Realisierung
Projekt
Cut
Materialien
Video
vilm.xml
Abbildung 4.1: Aufbau des Projektverzeichnisses
Abbildung 4.2: Screenshot des Synchronisations-Tools
4.1.1 Synchronisations-Tool
Das in Abbildung 4.2 dargestellte Synchronisations-Tool ist auf wenige Möglichkeiten reduziert. Diese Beschränkung des Funktionsumfangs ist durch die Spezialisierung des Tools gewollt. Es besteht die Möglichkeit, ein neues Projekt anzulegen und vorhandene Projekte zu laden und zu verändern. Die zu synchronisierenden Videos werden in das Projektverzeichnis kopiert, sobald der Anwender sie
dem Projekt hinzufügt. So können die Videos sogar - geeignete Treiber der Kameras vorausgesetzt - direkt von den Kameras dem Projekt hinzugefügt werden.
4.1.2 Annotations-Tool
In dem Annotations-Tool sind im Vergleich zur vorherigen ViLM-Anwendung ein
paar Möglichkeiten hinzugekommen. In Abbildung 4.3 ist es gezeigt. Die neuen
Funktionen umfassen unter anderem die Integration von Vorschaubildern, um
eine bessere Übersicht über die Videos zu enthalten. Diese Option lässt sich auch
Kapitel 4 • Details der Umsetzung
Abbildung 4.3: Screenshot des Annotations-Tools
abschalten, um mehr Platz für die Eingabe der Annotationen zu bekommen.
Eine weitere neue Funktion betrifft die Integration einer Rechtschreibkorrektur
für die Eingabe der Annotationen, um die direkte Eingabe in der AnnotationsAnwendung zu erleichtern.
Das Fenster der Annotations-Anwendung ist, wie auch das des SynchronisationsTools, frei in der Größe veränderbar. Die Anzeige der Videos skaliert dabei ebenso
mit wie die restlichen Elemente der Bedienungsoberfläche.
Die Materialien lassen sich jetzt bequem auch nach dem Hinzufügen zu einem
Projekt bearbeiten. Es ist nun nicht mehr nötig, den Umweg über den WindowsExplorer zu gehen - stattdessen genügt ein Doppelklick, um die dem Dateityp
zugewiesene Standard-Anwendung zu starten.
Bei der Implementation des Exports in das Annotations-Tool wurde auf Flexibilität geachtet. Es befindet sich kein für den Export nötiger Code in der Anwendung. Der Sourcecode wird bei Bedarf vom Videoschnitt-Dienst per .NET
Remoting (siehe Kapitel 4.2.1.1) angefordert und dann durch die Scriptsprache
CS-Script (Kapitel 4.2.1.2) zur Ausführung gebracht. Der Ablauf des Exports ist
in Abbildung 4.5 dargestellt. Das ausgeführte Export-Script bietet so immer den
21
22
Die Realisierung
Abbildung 4.4: Screenshot des Controls ZzzzRangeBar
aktuellen Funktionsumfang des Schnitt-Servers an und kann durch CS-Script die
benötigten Daten zur Ausführung übergeben bekommen.
Für die Umsetzung des Annotations-Tools wurde über eine veränderte Bedienungsoberfläche im Bereich der Zeitanzeige des Videos nachgedacht. Bisher wurde immer ein einzelner Slider über einer Zeitleiste eingesetzt. Für die Markierung
von Phasen erschien die Nutzung einer Zeitleiste mit zwei Slidern (einer für die
Start- und einer für die Ende-Markierung) interessant. Es existieren dafür bereits
mehrere fertige GUI-Controls, unter anderem die ZzzzRangeBar1 , welche in Abbildung 4.4 zu sehen ist. Der Vorteil ist, dass nun Start, Ende und Dauer einer
Phase auf einen Blick erfasst und einfach verändert werden können. Bei Tests hat
sich allerdings herausgestellt, dass die Bedienung für die Anwender verwirrend ist,
da es bei der Benutzung im Annotations-Tool nicht nur um die Markierung der
Phasen geht, sondern auch das Abspielen der Videos gleichzeitig damit gesteuert
wird. Die direkte Steuerung war mit diesem Control nicht mehr möglich, da sich
aus Sicht des Anwenders die Position und Größe der Phase veränderten, wenn sich
einer der beiden Slider bewegte, um die aktuelle Position im Video darzustellen.
Desweiteren war es nicht erkennbar, an welcher der beiden markierten Positionen
sich das oberhalb angezeigte Video befand. Auch ein Springen im Video zu der
Position des gerade verschobenen Sliders erwies sich als als wenig intuitiv.
Eine Lösung für einen Teil der Probleme schien die Idee, der ZzzzRangeBar einen
dritten, farblich abgesetzten und anders geformten, Slider hinzuzufügen, um damit die aktuelle Position im abgespielten Video zu markieren. Allerdings wurde
damit die Bedienung in der Praxis weiter verkompliziert. Das Endergebnis war
der Verzicht auf eine Änderung der Bedienung in diesem Bereich zugunsten des
bewährten einfachen Sliders und zusätzlichen Buttons, um die aktuelle Position
als Start bzw. Ende einer Phase festzulegen.
Die eingegebenen Annotationen werden in einer XML-Datei im Projektverzeichnis abgelegt. Als Dateiendung wurde .ann gewählt. Diese Dateiendung scheint
sehr wenig genutzt zu sein2 . Aus diesem Grund kann sie gefahrlos mit dem
Annotations-Tool verknüpft werden, um mehr Bedienkomfort zu erhalten.
1
2
http://www.codeproject.com/cs/miscctrl/zzzzrangebar.asp
Recherchen fanden nur drei wenig verbreitete Nutzungen: Annotationen zu Windows 3.x Hilfedateien, ein russischer FidoNet-Client namens King-FIX (http://www.king-fix.da.
ru/) und das Linux-Toolkit Karma (http://www.atnf.csiro.au/computing/software/
karma/) welches im Astronomie-Bereich zur Visualisierung eingesetzt werden kann
Kapitel 4 • Details der Umsetzung
Annotation
Benutzer
Export Dialog
aufrufen
Optionen wählen
& Export starten
über Abschluss
informieren (eMail)
23
ViLMSplitMovie
Dialogfenster Script
abrufen
Script ausführen
Video-Schnitt
starten
Job vormerken
Schnitt und
Konvertierung
Abbildung 4.5: Zusammenspiel von Annotations-Tool und Videoschnitt-Dienst
4.1.3 Videoschnitt-Dienst
Der Videoschnitt-Dienst wurde als Windows-Dienst implementiert. Dieses bringt
eine Menge Vorteile im Vergleich zu einer ständig laufenden Konsolen-Anwendung
mit sich. Ein Windows-Dienst kann unter anderem bei dem Hochfahren des
Rechners automatisch starten, ohne dass ein Benutzer sich am Server anmelden
muss. Die Kommunikation des Dienstes mit dem Administrator erfolgt über die
Windows-Ereignisanzeige. Dort wird ein eigenes Protokoll für den Schnittdienst
angelegt, in welches Informationen über verarbeitete Jobs und aufgetretene Fehler
geschrieben werden. Für die Konfiguration des Dienstes wird der unter .NET vorgesehene Weg über die Anwendungskonfigurationsdatei genommen. Dort müssen
unter anderem die Pfade zu einigen der in Kapitel 4.2 beschriebenen Tools konfiguriert werden. Hier findet auch die Konfiguration eines SMTP-Servers3 statt,
mit dessen Hilfe der Schnittserver die Anwender per eMail über die Abarbeitung
ihrer Jobs informiert.
In Abbildung 4.5 ist das Zusammenspiel von Annotations-Tool und VideoschnittDienst dargestellt.
3
Das Simple Mail Transfer Protocol ist der Internetstandard zum Übertragen von eMails. Der
Videoschnitt-Dienst unterstützt hierbei die Benutzerauthentifizierung per SMTP-Auth und
verschlüsselte Übertragung per SSL. Sofern .NET das SSL-Zertifikat nicht überprüfen kann
(z.B. ein selbst-signiertes Zertifikat, welches nicht in Windows eingetragen wurde), wird ein
Fehler ausgegeben und es findet kein Versand statt
24
Die Realisierung
4.2 Verwendete Technologien
In diesem Kapitel werden wichtige bei der Umsetzung verwendete Technologien und Tools angesprochen. Es werden Gründe für die Wahl dargelegt und ein
Überblick über die Möglichkeiten gegeben. Auf die Benutzung der Tools wird mit
Ausschnitten aus dem Sourcecode eingegangen. Am Ende des Kapitels wird in
Sektion 4.3 gezeigt, wie die vielen einzelnen zum Videoschnitt benutzen Tools
verknüpft werden, um die gewünschte Funktionalität zu liefern.
4.2.1 C#
Nachdem durch die Nutzung von Microsofts DirectShow schon eine Bindung an
die Windows-Plattform bestand, lag es nahe, auf die moderne .NET Plattform
zu setzen, um von der guten Integration und vielen bestehenden Komponenten
zu profitieren. Die Wahl fiel auf die Sprache C#, da diese bereits am längsten zur
.NET Familie gehört und damit gut ausgereift ist, es eine große Menge Literatur
gibt und diese für den Programmierer leicht zu handhaben ist. Diese Entscheidung hat sich im Verlauf der Umsetzung bewährt und für eine zügige Realisation
gesorgt. Die Unterstützung durch die Programmierumgebung Visual-Studio 2005
erwies sich als sehr komfortabel, vor allem im Bereich der visuellen Oberflächen
und dem Debugging.
4.2.1.1 .NET-Remoting
Die Kommunikation von Annotations-Tool und Videoschnitt-Server erfolgt über
.NET Remoting. Dabei handelt es sich um ein direkt in .NET eingebautes Verfahren zur Kommunikation in verteilten Anwendungen und ermöglicht, ähnlich
wie unter JAVA das Remote Method Invocation (RMI), eine einfache Implementation.
Die Übertragung von Objekten ist möglich, sofern die zugrunde liegenden Klassen als serialisierbar4 markiert sind. Eine andere Möglichkeit besteht darin, auf
Objekte zuzugreifen, die nur in der anderen Anwendung existieren. Auf diese wird
über einen automatisch zwischengeschalteten Proxy zugegriffen. Ein sehr einfaches Objekt für den letzteren Anwendungsfall ist in Listing 4.1 dargestellt. Diese
Klasse, welche als einfache Demo keinen Code zur Fehlerbehandlung enthält,
macht nichts anderes, als den Inhalt der Datei
demo.txt bei Erstellung einer
Objekt-Instanz aus dem Dateisystem zu lesen und in einer Variable verfügbar zu
machen.
4
Als Serialisierung wird das Abbilden des aktuellen Objekt-Zustandes in eine Form bezeichnet,
aus der das Objekt später originalgetreu reproduziert werden kann.
Kapitel 4 • Verwendete Technologien
25
namespace RemoteObjects
{
public c l a s s R e m o t e S c r i p t : MarshalByRefObject
{
public S t r i n g t e x t = ” ” ;
public R e m o t e S c r i p t ( )
{
i f ( F i l e . E x i s t s ( ”demo . t x t ” ) )
{
t e x t = F i l e . ReadAllText ( ”demo . t x t ” ) ;
}
else text = ” Fehler aufgetreten ” ;
}
}
}
Listing 4.1: Objekt für .NET Remoting
Diese Klasse wird nun durch den in Listing 4.2 gezeigten Code für den externen
Zugriff vorbereitet. Das Listing enthält hier als Beispiel festkodierte Werte. In
der Realität sollten diese natürlich alle konfigurierbar gehalten werden. Als Erstes wird hier der Server angewiesen, über das TCP-Protokoll auf dem Port 4444
auf Anfragen zu warten. Als Nächstes wird genau festgelegt, welche Klassen alle
nach außen veröffentlicht werden und unter welchem Namen. Hier wird der Bezeichner
Klasse
RemoteScript bekannt zu machen. Dies geschieht in dem Verfahren
ViLMSplitMovieScriptHandler verwendet, um die oben dargestellte
SingleCall. Es gibt bei .NET Remoting drei unterschiedliche Verfahren für
den Objekt-Zugriff.
Diese sind:
SingleCall Objekte vom Typ SingleCall existieren nur für die Dauer von einem
einzelnen Aufruf. Sie werden für diesen beim Eintreffen erzeugt und beim
Beenden wieder zerstört
Singleton Ein Singleton-Objekt existiert nur ein einziges Mal und bedient mehrere Aufrufe. Es speichert aus diesem Grund Zustandsinformationen und
kann auch dazu dienen, um eine Datenbasis für mehrere Client-Aufrufe zu
teilen.
Client-Activated Hierbei handelt es sich um Objekte, die zwar auf dem Server
liegen, aber von den Clients einzeln explizitit per new()-Operator angelegt
werden. Es wird dann jedes Mal auf dem Server ein neues Objekt erzeugt
und genau diesem Client zugewiesen. Diese Objekte können auch Zustandsinformationen speichern und können z.B. gut verwendet werden, um rechenintensivere Aufgaben dem Server zu überlassen. Ein anderes Szenario wäre
die Nutzung für Aufgaben, die Zugriff auf einen sehr großen Datenbestand
benötigen um Auswertungen vorzunehmen, und diese nur an den Server
performant angebunden werden können.
26
Die Realisierung
TcpChannel c h a n n e l = new TcpChannel ( 4 4 4 4 ) ;
ChannelServices . RegisterChannel ( channel ) ;
R e m o t i n g C o n f i g u r a t i o n . Re g i s t e r W e l l K n o w n S e r v i c e T y p e ( typeof ( R e m o t e S c r i p t ) , ”
V i L M S p l i t M o v i e S c r i p t H a n d l e r ” , WellKnownObjectMode . S i n g l e C a l l } ;
...
ChannelServices . UnregisterChannel ( channel ) ;
Listing 4.2: Sourcecode, um einen .NET Remoting Server online zu stellen
Die Wahl der Objekt-Art hängt direkt von dem vorgesehen Einsatzzweck ab. Um
mit in der entfernten Anwendung laufenden Objekten zu arbeiten, wird der Code
aus Listing 4.3 benötigt. Als Erstes wird nun wieder ein TCP-Verbindungs-Objekt
erstellt. Dieser sogenannte Kanal bekommt aber erst beim Aufruf der Server- Anwendung das Ziel übergeben. Dieses ist in einem
Connection-String kodiert,
der noch einmal das Protokoll, den Zielserver und Port sowie den für die Klasse
Remote-Script vorgegebenen Namen beinhaltet. Interessant ist hier die Tatsache,
dass das Objekt vom Aufruf her in der Client-Anwendung erstellt wird. Wirklich
erzeugt wird das Objekt allerdings auf dem Server und deshalb wird die Datei
demo.txt auch aus dem Dateisystem des Servers und nicht dem des Clients
ausgelesen. Dies geschieht allerdings unsichtbar für den Client, der auf das Objekt
remoteScript fortan zugreifen kann. Als letztes muss der Channel wieder
freigegeben werden.
TcpChannel c h a n n e l = new TcpChannel ( ) ;
ChannelServices . RegisterChannel ( channel ) ;
R e m o t e S c r i p t r e m o t e S c r i p t = ( R e m o t e S c r i p t ) A c t i v a t o r . GetObject ( typeof (
RemoteScript ) , ” tcp : / / l o c a l h o s t :4444/ ViLMSplitMovieScriptHandler ” ) ;
MessageBox . Show ( r e m o t e S c r i p t . t e x t ) ;
ChannelServices . UnregisterChannel ( channel ) ;
Listing 4.3: Sourcecode, um einen .NET Remoting Client mit einem Server zu
verbinden
4.2.1.2 CS-Script
Bei CS-Script5 handelt es sich um eine Scriptsprache auf Basis von C#, um
Anwendungen flexibel erweitern zu können. Bei der Nutzung von CS-Script in
einem C#-Sharp Projekt kann das Scripting in der selben Sprache geschehen,
in der die Anwendung entwickelt wurde. CS-Script kann allerdings auch in jedes
andere .NET Projekt integriert werden. Ein sehr interessanter Aspekt von CSScript ist, dass die Sprache nicht interpretiert wird, wie es in Scriptsprache sonst
meist üblich ist. Beim Laden vor der Ausführung wird das Script ganz normal
in die Common Intermediate Language (CIL)6 kompiliert, wie jede andere .NET
5
6
http://www.csscript.net/
Die Common Intermediate Language (CIL) hieß früher Microsoft Intermediate Language
(MSIL) und ist der Zwischencode, den Microsoft bei .NET nutzt, um ihn in der Laufzeit-
27
Sprache auch. Dadurch gibt es keinen aus der Nutzung einer Scriptsprache resultieren Performanceverlust, wie er bei interpretierten Scriptsprachen auftritt,
sondern nur eine kurze einmalige Verzögerung für den Kompiliervorgang (dank
Caching der Kompilate). Es kann auch jede Anwendung einfach in ein Script
überführt werden oder umgekehrt.
CS-Script wurde eingesetzt, um in der Annotations-Anwendung den ExportDialog bei jedem Aufruf frisch vom Server zu holen. So ist es möglich, den Clients
einfach, ohne sie aktualisieren zu müssen, neue Funktionen des Servers (vor allem
im Bereich von Optionen bezüglich Formaten und Bildqualität) zur Verfügung
zu stellen.
Der Aufruf eines CS-Scripts ist in Listing 4.4 dargestellt. Dort wird der Code
aus der Datei
Objekt
Export.cs eingelesen und kompiliert. Dieser steht nun in dem
helper zur Verfügung und Methoden des Scripts können ausgeführt
werden. Die Invoce-Methode bekommt als ersten Parameter die auszuführende
Methode übermittelt und alle folgenden Parameter werden an die aufgerufene
Methode durchgereicht. Hierbei können Objekte aller sowohl dem Script als auch
dem aufrufenden Code bekannten Klassen übergeben werden. In diesem Beispiel
erwartet das (in Listing 4.5 gezeigte) Script einen String als Parameter, um diesen
Text als Titel des erzeugten Dialog-Fensters zu setzen.
using CSScriptLibrary ;
try
{
AsmHelper h e l p e r = new AsmHelper ( C S S c r i p t . Load ( ” Export . c s ” , n u l l , t r u e ) ) ;
h e l p e r . I n v o k e ( ” ViLMExport . ShowExport ” , ” Export−Optionen ” ) ;
}
c a t c h ( E x c e p t i o n ex )
{
MessageBox . Show ( ex . T o S t r i n g ( ) ) ;
}
Listing 4.4: C#-Code um ein CS-Script auszuführen
Dem CS-Script fehlen zusätzliche Informationen über Assemblies. In Visual-Studio
werden diese getrennt verwaltet und zur Kompilierzeit hinzugefügt und ausgewertet. Damit eine CS-Script-Datei eigenständig ohne weitere Informationen
lauffähig ist, versucht CS-Script die benötigten Assemblies aus den (durch die
using-Anweisung bekannten) Namespace-Namen herauszufinden. Da dies nicht
immer möglich ist, lassen sich zusätzliche Informationen direkt im Script hinzufügen. Der Kommentar in Zeile fünf des Scripts ist eine Anweisung an CSScript, die DLL RemoteObjects.dll zu laden. In dieser befindet sich der direkt
danach genutzte Namespace
RemoteScript .
umgebung Common Language Runtime (CLR) auszuführen. Die CIL ist äquivalent zum
Bytecode in JAVA und die CLR zu der Java-Virtual Machine.
28
Die Realisierung
using
using
using
using
// c s s
using
System ;
System . ComponentModel ;
System . Drawing ;
System . Windows . Forms ;
r e f e r e n c e RemoteObjects . d l l ;
RemoteScript ;
c l a s s ViLMExport : Form
{
p r i v a t e System . Windows . Forms . Button b u t t o n 1 ;
p u b l i c ViLMExport ( S t r i n g t i t l e )
{
t h i s . b u tt o n1 = new System . Windows . Forms . Button ( ) ;
t h i s . b u tt o n1 . Text = ” Export s t a r t e n ” ;
t h i s . b u tt o n1 . C l i c k += new System . EventHandler ( t h i s . b u t t o n 1 C l i c k ) ;
t h i s . C o n t r o l s . Add( t h i s . b u t t o n 1 ) ;
t h i s . Text = t i t l e ;
}
p r i v a t e v o i d b u t t o n 1 C l i c k ( o b j e c t s e n d e r , EventArgs e )
{
MessageBox . Show ( ”C#−S c r i p t i n A c t i o n ! ” ) ;
}
s t a t i c p u b l i c v o i d ShowExport ( S t r i n g t i t l e )
{
u s i n g ( ViLMExport d l g = new ViLMExport ( t i t l e ) ) d l g . ShowDialog ( ) ;
}
}
Listing 4.5: C#-Code um CS-Script auszuführen
Falls der als Script zu verwendende Code über mehrere Dateien verteilt ist (z.B.
durch die Verwendung von Visual-Studio als GUI-Designer), so müssen zusätzliche
Dateien dem Haupt-Script bekannt gemacht werden. Dies geschieht über den Befehl
//css import Datei.cs, wobei auch zusätzliche Optionen wie das Umbe-
nennen von Namespaces möglich sind.
Die Nähe von CS-Script zu normalem .NET Code erweist sich auch beim Debugging als sehr nützlich. So kann der Script-Code direkt mit dem normalem
Anwendungs-Code zusammen im .NET Debugger wie z.B. Visual-Studio mit analysiert werden.
4.2.2 Microsoft DirectShow
Eine Möglichkeit für den Zugriff auf DirectShow wird vom .NET Framework
nicht direkt mitgeliefert. Es kann aber über die Interoperablitäts-Funktionen von
C# auf das COM-Interface7 von DirectShow zugegriffen werden. Dieses wird in
der IDL (Interface Definition Language) beschrieben. Das Listing 4.6 importiert
die IDL-Dateien aus dem Software Development Kit (SDK) und exportiert die
7
Component Object Model;
29
benötigten Interfaces in eine Typ-Bibliothek auf die - nach einer Konvertierung
in eine Common Language Runtime-Assembly8 - von .NET aus zugegriffen werden kann. Die hierfür nötigen Befehle sind im Listing 4.7 zu sehen. Nach diesen
Vorbereitungen kann mit der DirectShow-API direkt gearbeitet werden.
import ”devenum . i d l ” ;
...
import ” vmrender . i d l ” ;
[
uuid ( B82EFBF0−2FA0−4bcc −89D7−5E8E06051586 ) ,
h e l p s t r i n g ( ” Vilm Video t y p e l i b r a r y ” )
]
l i b r a r y VilmTypeLib
{
i m p o r t l i b ( ”STDOLE2 . TLB” ) ;
interface
interface
...
interface
interface
IGraphBuilder ;
IMediaControl ;
IVMRMixerControl ;
FilgraphManager ;
};
Listing 4.6: IDL-Code um DLLs für C# zu erstellen
SET DXSDKPath=” C: \Programme\ M i c r o s o f t V i s u a l S t u d i o .NET 2003\ Vc7\
PlatformSDK \ I n c l u d e ”
midl / I ”%DXSDKPath%” / I ”%DXSDKPath%\DShowIDL” v i l m . i d l
tlbimp vilm . t l b
Listing 4.7: Batch-Datei um IDL-Code zu C# DLLs zu kompilieren
DirectShow ist intern sehr modular aufgebaut. Mit Graphen kann moduliert werden, was genau ablaufen soll. Jeder Knoten in dem Graphen, ein sogenannter Filter, hat mindestens eine Verknüpfung für Input und Output, um sich mit anderen
Filtern verbinden zu lassen. In Abbildung 4.6 ist ein solcher Graph beispielhaft
für die Wiedergabe eines MPEG-I Videos dargestellt. Natürlich ist es nicht praktikabel, diese Graphen einmal fest zu erstellen, da schon kleine Änderungen (zum
Beispiel ein anderer Audio-Codec) einen neuen Graphen verlangen. Für Standardfälle, wie die Wiedergabe von Videos, gibt es eine große Zahl an Graphen,
die von Microsoft gleich mitgeliefert wird. Auch neue Treiber und Codecs können
weitere Graphen mitbringen und zur Verfügung stellen. So profitieren gleich alle
Anwendungen davon. Im Klartext heißt dies, dass jedes Videoformat, welches im
Windows Media-Player, welcher auch auf DirectShow aufsetzt, abspielbar ist9 ,
auch mit diesem Tool verarbeitet werden kann.
8
9
In .NET sind alle Komponenten in Assemblies organisiert
Sonderfälle wie per DRM geschützte Dateien sind davon ausgenommen
30
Die Realisierung
Quelldatei
MPEG-I Stream Splitter
Video
MPEG Video
Decoder
Video Renderer
MPEG Audio
Decoder
Default
DirectSound Device
Audio
Abbildung 4.6: DirectShow Graph zum Abspielen von Videos
4.2.3 SMIL
SMIL, aktuell ist die Version 2.1, wurde als Multimedia-Sprache entworfen, um
Multimedia-Präsentationen in Browsern (ohne die Nutzung von Plugins) zu ermöglichen. Leider existieren in den aktuellen Browsern noch keine Implementierungen. Die Media-Player Quicktime und Realplayer besitzen bereits eine Unterstützung für ältere Versionen von SMIL. Zum Teil mit eigenen proprietären
Erweiterungen. Die aktuelle Version bietet viele praktische Neuerungen und durch
die Verzahnung mit anderen Standarts wie SVG10 wird sich die Verbreitung von
Implementationen wahrscheinlich verbessern. Die Entwickler von Mozilla sind
bereits dabei, mit dem SVG-Suport auch SMIL zu integrieren.
Mit SMIL ließen sich die Annotationen perfekt aufbereitet im Web präsentieren.
Die Ereignisse, Beschreibungen von Phasen und Materialien ließen sich zu den
gewünschten Zeitpunkten korrekt neben den Videos einblenden. Die Formate
Real-Text und Real-Pix sind Erweiterungen von der Firma Realmedia und bieten
Möglichkeiten zur Animation (Einblendefekte etc) von Text und Bildern. Dieses
ist aber für unsere Anwendung nicht nötig. Das Einblenden von HTML-Seiten,
wie es zum Standard gehört, ist hingegen sehr gut nutzbar.
In Listing 4.8 ist ein beispielhaftes SMIL-Dokument abgedruckt, welches die in
Abbildung 4.7 dargestellte Ausgabe erzeugt. Hier laufen zwei Videostreams synchron ab und rechts daneben wird die kontextabhängig passende Information
eingeblendet. Diese Informationen können alles beinhalten, was eine HTML-Seite
ermöglicht, inklusive Formatierung per CSS. Das SMIL-Dokument ist in mehrere
Teile gegliedert. Im HEAD-Bereich befindet sich, neben META-Informationen wie
Autoren, Copyright und Titel-Angaben, welche im Beispiel zur Übersichtlichkeit
entfernt wurden, vor allem die Layout-Definition. Diese bestimmt in dem Knoten
root-layout die Größe und das Aussehen der kompletten Anzeigefläche. Als
Nächstes werden einzelne Regionen innerhalb der kompletten Fläche mit Größe
und Position festgelegt, welche später über ihre eindeutige ID angesprochen werden können. In dem BODY-Bereich der Datei geht es um den Ablauf der Datei.
10
Scalable Vector Graphics; ein XML basiertes, offenes Vektorgrafik-Format mit Animationsmöglichkeit
31
Im Grunde gibt es zwei verschiedene Arten: parallel oder sequentiell wiederzugebende Informationen. Diese können in beliebiger Form geschachtelt werden.
Neben dieser statischen Wiedergabe gibt es auch ein Event-Modell, um auf Ereignisse wie Mausklicks, Tastendrücke, Start bzw. Ende von einzelnen Teilen oder
fixen Zeitpunkten in der Echtzeituhr, wie zum Beispiel Sylvester, zu reagieren.
Dieses wird in unserem Anwendungsfall allerdings nicht benötigt. Die interessante
Anwendung durch Klick auf die gelisteten Ereignisse zu der Position im Stream
zu springen, ist durch die in Kaptel 3.3.2 beschriebe Problematik des Zugriffs auf
beliebige Positionen im Stream nicht möglich. Die eingebundenen Videos laufen
so lange wie in der Datei kodiert. Zusätzlich eingeblendete Daten wie Bilder der
Texte, welche keine eigene Laufzeit besitzen, können über verschiedene Attribute gesteuert werden. In dem verwendeten Attribut
dur (eine Ablürzung für
duration = Laufzeit) ist die Anzeigedauer kodiert.
<s m i l>
<head>
<l a y o u t>
<r o o t −l a y o u t width=” 960 ” h e i g h t=” 256 ” background−c o l o r=” b l a c k ” />
<r e g i o n i d=” v i d e o ” l e f t =” 320 ” top=” 0 ” width=” 320 ” h e i g h t=” 256 ”
f i t =” f i l l ” background−c o l o r=” b l a c k ” z−i n d e x=” 3 ” />
<r e g i o n i d=” t e x ” l e f t =” 0 ” top=” 0 ” width=” 320 ” h e i g h t=” 256 ” f i t =”
f i l l ” background−c o l o r=” w h i t e ” z−i n d e x=” 3 ” />
<r e g i o n i d=” v i d e o 2 ” l e f t =” 640 ” top=” 0 ” width=” 320 ” h e i g h t=” 256 ”
f i t =” f i l l ” background−c o l o r=” b l a c k ” z−i n d e x=” 3 ” />
</ l a y o u t>
</ head>
<body>
<par>
<v i d e o s r c=”A. Gamers . Day . T r a i l e r . mp4” r e g i o n=” v i d e o ” f i l l =”
f r e e z e ” />
<s e q>
<t e x t s r c=” t e x t 1 . html ” t y p e=” t e x t / html ” r e g i o n=” t e x ”
f i l l =” f r e e z e ” dur=” 5 s ” />
f i l l =” f r e e z e ” dur=” 10 s ” />
f i l l =” f r e e z e ” dur=” 5 s ” />
</ s e q>
<v i d e o s r c=”A. Gamers . Day . T r a i l e r . mp4” r e g i o n=” v i d e o 2 ” f i l l =”
f r e e z e ” />
</ par>
</ body>
</ s m i l>
Listing 4.8: SMIL Beispielcode
Der Quicktime-Player ist zur Zeit nur in der Lage SMIL 1 zu verarbeiten und
unterstützt auch keine Anzeige von HTML innerhalb eines SMIL-Dokuments.
Eine sehr gute SMIL 2.1 Implementierung ist der freie Ambulant Player11 . Dieser
11
http://www.cwi.nl/projects/Ambulant/
32
Die Realisierung
Abbildung 4.7: Wiedergabe des SMIL-Dokumentes
ist für alle wichtigen Plattformen - und zusätzlich für PDAs und eine Beta-Version
als Browser Plugin für Firefox12 - verfügbar.
4.2.4 AviSynth
Um den Frameserver AviSynth zu programmieren, steht eine mächtige Scriptsprache zur Verfügung. Im Folgenden wird die Ausgabe eines Teilstückes (inklusive
Skalierung auf die Zielgröße) eines Videos vorgenommen. Dies wird so im Schnitt
angewendet, um den nachfolgenden Tools, welche den Ton und das Bild komprimieren, die passenden Teilstücke aus der Datei bereitzustellen. Da in DirectShow
keine framegenaue Ansteuerung möglich ist, sondern der Zugriff über Zeitangaben
läuft, findet in dem Script, in Listing 4.9 abgedruckt, als erstes eine Umrechnung
in Frames statt. Im nächsten Schritt wird das Bild in die Zielauflösung heruntergerechnet und danach wird der Farbraum für die nachgeschaltete Komprimierung
angepasst. Zum Schluss findet das Anfertigen des eigentlichen Ausschnittes aus
der Datei statt.
c l i p = DirectShowSource ( ”C: \ P r o j e k t \ Video \ N a S t S i c h t a u f L . mpg” )
start1 = 87.45
s t a r t 1 = c e i l ( s t a r t 1 ∗ Framerate ( c l i p ) )
ende1 = 153
ende1 = c e i l ( ende1 ∗ Framerate ( c l i p ) )
b r e i t e = 352
hoehe = 288
r e s i z e d = Lanczos4Resize ( c l i p , b r e i t e , hoehe )
c o l r g b = ConvertToYV12( r e s i z e d )
Trim( c o l r g b , s t a r t 1 , ende1 )
Listing 4.9: AviSynth Script zur Extraktion von Videosequenzen anhand von
Zeitstempeln mit gleichzeitiger Auflösungsreduzierung
Es ist mit AviSynth auch möglich, mehrere Videos zu einem zu vereinen. Dieses
ist relevant, wenn nicht auf SMIL zur Präsentation gesetzt wird, sondern nur
12
Der bekannte Open-Source Web-Browser der Mozilla Foundation ist unter
http://www.mozilla.com/firefox/ erhältlich
33
eine einzelne Videodatei am Ende stehen soll. Es ist auch das Einblenden von
Schriften und Logos möglich sowie das Erzeugen von Animationen (interessant für
Quellenangaben und Copyright-Hinweise, falls aufbereitete Videos weitergegeben
werden sollen). Es wäre sogar möglich, große Teile der Annotationen direkt in
das Video zu schreiben. In Listing 4.10 ist der Code zu sehen, um zwei Videos zu
einem zusammenzufügen und eine animierte Textnachricht darüber einzublenden.
c l i p L e f t = DirectShowSource ( ” N a S t S i c h t a u f L . mpg” )
c l i p R i g h t = DirectShowSource ( ” N a S t S i c h t a u f S . mpg” )
StackHorizontal ( c l i p L e f t , c l i p R i g h t )
Animate ( 0 , 1 0 0 , ” s u b t i t l e ” , ” U n i v e r s i t ä t Paderborn − D i d a k t i k d e r I n f o r m a t i k ”
, 2 4 0 , 1 5 0 , 0 , 1 5 0 , ” A r i a l ” , 0 , $FF0000 , ” U n i v e r s i t ä t Paderborn − D i d a k t i k d e r
I n f o r m a t i k ” , 7 0 , 1 5 0 , 0 , 1 5 0 , ” A r i a l ” , 6 0 , $FF0000 )
Listing 4.10: AviSynth Script zum Verschmelzen von zwei Videos zu einem
Auch wenn Avisynth sich bei der Verarbeitung von Videos nur zwischen andere Tools zwischenschaltet und keine eigene Ausgabe auf Hardware generiert, so
wird bei Nutzung des (in dieser Implementation verwendeten) DirectShowSource
Input-Filters zur Dekodierung der Videos zwingend ein Audio-Treiber benötigt.
Die Ursache liegt bei der automatischen Erstellung der DirectShow-Graphen und
ließe sich durch manuelle Erstellung von diesen verhindern. Im Normalbetrieb ist
diese Eigenheit nicht tragisch, da viele Server heutzutage durch in den Chipsatz
integrierte Soundmodule über die nötigen Treiber verfügen. Problematisch wird
es durch eine Eigenheit des Remote-Desktop von Windows: Sobald eine Verbindung per Remote-Desktop zum Server besteht, wird das komplette Soundsystem
durch Treiber des Remote-Desktop überschrieben13 . Diese Treiber werden von
DirectShow allerdings nicht akzeptiert und das Einlesen der Videos in AviSynth
schlägt fehl. Zusammen mit der Eigenschaft von AviSynth, Fehlermeldungen sofern möglich- als Video zu rendern, hilft es nicht, die Audiospur zu deaktivieren,
um zumindest auf die Bildinformationen Zugriff zu haben. Durch diese Konstellation ist es nicht möglich, AviSynth-Scripte per Remote-Desktop zu debuggen. Es
ist zwingend notwendig, sich direkt an den Rechner zu setzen oder Alternativen
wie das Virtual Network Computing (VNC) einzusetzen.
4.2.5 VirtualDubMod
Das Videoschnitt-Tool VirtualDub14 , welches ursprünglich für die interaktive Bedienung programmiert wurde, besitzt eine flexible Skriptsprache und ein PluginSystem mit einer reichhaltigen Auswahl an Video-Filtern. Es wäre in der Lage
gewesen, die Videoschnitte anstelle von AviSynth vorzunehmen, wenn es mehr Videoformate lesen könnte und kann auch als Frameserver für andere Programme
13
Unabhängig davon, ob in der Remote-Desktop-Session die Soundwiedergabe abgestellt wurde
oder auf dem Server oder dem Client erfolgen soll
14
http://www.virtualdub.org/
34
Die Realisierung
agieren. Die Scriptsprache von VirtualDub ist allerdings mehr auf die BatchVerarbeitung von Dateien ausgerichtet und schlechter zu lesen. Aufgrund einer
Beschränkung auf AVI15 als Containerformat konnten allerdings unter alleiniger
Nutzung von VirtualDub weder Eingabe noch Ausgabe wie benötigt realisiert
werden.
VirtualDubMod16 ist eine separat weiterentwickelte Sammlung von Modifikationen an VirtualDub. Dieses sind unter anderem die Möglichkeit, MPEG2 als Eingabeformat zu nutzen und eine verbesserte Unterstützung von AviSynth.
In der realisierten Anwendung wird VirtualDubMod nur dazu verwendet, um aus
dem Videodatenstrom die Tonspur zu extrahieren und als WAV abzuspielen. Das
hierfür nötige kurze Script ist in Listing 4.11 einzusehen. Dieser Zwischenschritt
ist nötig, da Audioencoder in der Regel keine AviSynth-Scripte lesen können.
VirtualDub . Open ( ” A v i S y n t S c r i p t . a v s ” , ” ” , 0 ) ;
VirtualDub . stream [ 0 ] . SaveWAV( ” Tonspur . wav” ) ;
Listing 4.11: VirtualDubMod Script zur Audioextraction
Weil sich die Informationen über die zu verarbeitenden Dateien bei VirtualDub
im Script befinden, gestaltet sich der Aufruf des Tools (Listing 4.12) recht einfach.
VirtualDubMod . e x e / s c r i p t . v c f /x
Listing 4.12: Aufruf von VirtualDubMod mit einem Script
Ein Problem gibt es, wenn VirtualDubMod aus einem anderen Programm heraus
automatisiert aufgerufen wird. Bei dem ersten Start unter einem neuen WindowsBenutzeraccount muss eine Dialogbox, in welcher auf die Lizenzbedingungen hingewiesen wird, manuell bestätigt werden. Dies wird problematisch, wenn VirtualDub von einem System-Dienst aufgerufen wird. Aus diesem Grund ist es wichtig,
dass der Dienst während der ersten Ausführung von VirtualDubMod das Recht
Datenaustausch zwischen Dienst und Desktop zulassen besitzt. Hierbei ist zu
beachten, dass der Austausch nur an lokal angemeldete Administratoren weitergegeben wird und somit ein Zugriff per Remote-Desktop zum akzeptieren nicht
ausreicht.
4.2.6 FAAC
Der Freeware Advanced Audio Coder17 (FAAC) wird verwendet, um die im WAVFormat vorliegenden Audiodaten in das benötigte AAC-Format umzukodieren.
Dabei werden die Audiodaten bereits in einen MP4-Container verpackt, um diese später direkt mit den Videodaten mischen zu können. Es wird eine geringe
15
Audio Video Interleave, ein früher von Microsoft eingeführtes Containerformat
http://virtualdubmod.sourceforge.net/
17
http://www.audiocoding.com/
16
35
Variable-Bitrate von durchschnittlich 56 kBit verwendet, um mehr Bandbreite
für die Videos zur Verfügung zu haben. Ein Zieldateiname muss nicht verwendet
werden. Bei dem in Listing 4.13 dargestellten Aufruf landen die Daten in einer
Datei mit dem Namen
audio.mp4.
f a a c . e x e −b 56 −w a u d i o . wav >n u l
Listing 4.13: Aufruf von faac zur Audiokompression
4.2.7 x264
Um die Videodaten in das gewünschte Format zu konvertieren, wird der bereits
angesprochene frei verfügbare Video-Codec x264 verwendet. Da dieser von den
Autoren nur im Source-Code vertrieben wird, wurde die Binärversion von der
Webseite x264.nl verwendet.
Die Konvertierung findet zur Zeit mit einer festgelegten Bitrate von 300kBit
statt, damit bei zwei gleichzeitig übertragenen Videos mit jeweils 356 kBit (inklusive Ton) auch bei einem kleinen DSL-Anschluß mit 768 kBit noch etwas
Bandbreite übrig bleibt. Auf die kleinen DSL-Light-Anschlüsse mit nur 384 kBit
Übertragungsrate in Richtung Anwender konnte aufgrund der resultierenden viel
geringeren Bildqualität keine Rücksicht genommen werden.
x264 . e x e −−b i t r a t e 300 −−p r o g r e s s −−no−p s n r −−q u i e t −−o u tp u t ou t p u t . 2 6 4
i n p u t . a vs
Listing 4.14: Aufruf von x264 zur Videokompression
Bei dem Aufruf von x264 (Listing 4.14) werden Parameter gesetzt, welche für geringere Textausgaben auf der Konsole sorgen (–quit), bestimmte nicht benötigte
Informationen zum Vergleich mit der H.264 Referenzimplemetierung unterdrücken
(–no-psnr) oder Informationen über den Fortschritt ausgeben (–progress).
4.2.8 GPAC MP4Box
Die zur Verfügung stehenden Audio- und Videodaten müssen nach der Komprimierung mit dem korrekten Codec noch im MP4-Containerformat verpackt werden. Dafür wird das Tool MP4Box verwendet. Dieses bekommt neben den Rohdaten noch die Informationen über die Bildwiederholrate des Videos (-fps 25.000),
welche 25 Bilder pro Sekunde beträgt, und bei den Audiodaten zusätzlich die
Sprache der Tonspur übergeben (:lang=deu). Es besteht die Möglichkeit, weitere
Tonspuren, z.B. einen zusätzlichen Audiokommentar, hinzuzufügen. Der Parameter -hint dient dazu, das Video um für das RTSP-Streaming nötige zusätzliche
Informationen zu erweitern.
36
Die Realisierung
MP4Box . e x e −f p s 2 5 . 0 0 0 −add i n p u t . 2 6 4 −add i n p u t . m4a : l a n g=deu −new o u tp u t .
mp4 >n u l
Listing 4.15: Aufruf von MP4Box zur Erstellung des Containers
4.2.9 NetSpell
Bei NetSpell18 handelt es sich um eine frei verfügbare Bibliothek zur Rechtschreibprüfung. Es werden bereits Wörterbücher für viele Sprachen mitgeliefert.
Die für diesen Anwendungsfall wichtigsten Sprachen - Deutsch und Englisch sind im Lieferumfang enthalten. Für eine Erweiterung um weitere Wörter oder
ganze Sprachen stehen Funktionen und Tools bereit.
Die Bedienungs-Oberfläche des NetSpell-Systems lässt sich durch eine XMLKonfigurations-Datei einfach in weitere Sprachen übersetzen.
4.3 Verknüpfung der externen Tools im
Konvertierungslauf
Das Zusammenspiel der verschiedenen Tools zur Audio- und Videoverarbeitung
ist in Abbildung 4.8 dargestellt. Diese Abbildung ist eine Detailansicht von den
Abläufen, die in Abbildung 4.5 als
Schnitt und Konvertierung zusammenge-
fasst dargestellt sind. Die Ausführung der einzelnen Schritte erfolgt in der aktuellen Implementation sequentiell, obwohl teilweise eine parallele Ausführung
möglich wäre (siehe auch die Erweiterungsmöglichkeiten in Kapitel 5.1). Der AviSynth Prozess muss leider sowohl für die Video- als auch für die Audiokompression
zum Schnitt aufgerufen werden, da es zu viel Speicherplatz kosten würde, wenn
in einem Schritt mit der Audio-Extraktion auch die Videodaten unkomprimiert
auf Festplatte geschrieben würden. Das zur Videokompression eingesetzte x264
ist auch nicht in der Lage die Audiodaten abzuspeichern. AviSynth könnte schon
im DirectShow-Input die Dekodierung auf Audio-Daten zu begrenzen, aber in
diesem Fall ist ein Schneiden der Daten mittels der Trim()-Funktion nicht mehr
möglich. Aus diesem Grund werden zwei komplette AviSynth Durchläufe während
der Konvertierung genutzt.
Zur Zeit beginnt der Schnitt mit der Extraktion der Audiodaten. Als Nächstes
wird das Video-Bild neu komprimiert (und anhand der im Export-Dialog vorgenommen Angaben - z.B. eine Änderung der Auflösung - überarbeitet). Nach der
folgenden Kodierung der Audiodaten in das AAC-Format werden die Audio- und
Videodaten in den MP4-container verpackt.
18
http://www.loresoft.com/Applications/NetSpell/default.aspx
Kapitel 4 • Verknüpfung der externen Tools im Konvertierungslauf
ViLMSplitMovie
Extraktion der
Audiodaten
Zuschneiden
der Videodaten
Videodekompression
Video in
H.264
Audio in
AAC
Verpacken
als MP4
VirtualDubMod
AviSynth
DirectShow
x264
FAAC
MP4Box
Abbildung 4.8: Ablauf des Schnittprozesses inklusive Konvertierung in ein zum
RTSP-Streaming kompatibles MP4-Format
Als letzter Schritt im Schnittprozess kann die fertige Datei nun in den Ziel-Ordner
verschoben werden. Nach dem Löschen der temporären Dateien wird die SMILDatei erzeugt. Zusätzlich wird der passende Code zum Abspielen innerhalb einer
HTML-Datei, unter Nutzung des Quicktime-Players, im selben Verzeichnis abgelegt.
37
38
Die Realisierung
5 Zusammenfassung und Ausblick
Die am Anfang der Arbeit gesetzten Ziele wurden mit der Entwicklung eines
umsetzbaren, den Anforderungen entsprechenden, Konzeptes und der Implementation von diesem erreicht. Im Laufe dieses Prozesses wurden viele der Videokompression und -bearbeitung zugrunde liegenden Technologien evaluiert. Die aktuelle Implementation ist bereits gut verwendbar, aber als Prototyp naturgemäß
noch nicht perfekt.
Während der Implementierung wurden manche in der vorhandenen Anwendung
benutzten Begriffe abgeändert. Dies geschah, um den Fokus der Implementation
etwas von ihrer Ursprungsanwendung, der Evaluation in der Lehrerausbildung,
zu entfernen.
Der Grund liegt darin, dass dieses Konzept der Evaluation auch in anderen Bereichen gut eingesetzt werden kann. Als aktuelles Einsatzgebiet wären zum Beispiel
Kurse zur Vorbereitung von Bewerbungsgesprächen denkbar - oder auch der Einsatz in der Wirtschaft, um Verkäufer bezüglich Ihres Auftretens zu schulen.
Es gibt, außer einer Erweiterung des Einsatzhorizonts, natürlich auch viele Möglichkeiten,
um die prototypische Implementation dieses Konzepts weiter zu verbessern. Ein
paar Anregungen und Ansätze hierfür sind im Folgenden zu finden.
5.1 Erweiterungs- und Optimierungsmöglichkeiten
Es gibt durch die offene Entwicklung des Systems zahlreiche potentielle Erweiterungsmöglichkeiten. Zur Zeit fehlt noch ein Verwaltungstool für die zu Schnitt
und Komprimierung anstehenden Jobs. Es kann passieren, dass Jobs durch die
Anwender mehrfach übermittelt werden, da diese noch überarbeitet wurden. In
diesem Fall wird die aktuelle Implementation beide Jobs abarbeiten und der
später verarbeitete wird die Dateien des vorherigen überschreiben, sofern die
Phasen noch identische Namen haben. Hier könnte mit einem Verwaltungs-Tool,
das Jobs löschen kann, Abhilfe geschaffen werden. Eine weitere interessante Erweiterung wäre die Möglichkeit, einzelne Jobs zu priorisieren, damit wichtige Jobs
bevorzugt verarbeitete werden.
Es besteht die Möglichkeit, die Bildqualität der geschnittenen Dateien bei konstanter Bitrate zu erhöhen. Dafür ist der einmalige Einsatz von CPU-Zeit während
der Komprimierung und Nutzung weiterer Encoding-Durchläufe (N-Path Enco-
39
40
Zusammenfassung und Ausblick
ding) notwendig. Die Unterschiede bei Nutzung eines zweiten Durchlaufs sind mit
bloßem Auge sichtbar.
Um den Durchsatz an Jobs zu erhöhen, bietet es sich an, die Verarbeitung zu parallelisieren. So ließe sich innerhalb eines Jobs zum Beispiel die Kompression der
Audiodaten gleichzeitig mit der Kompression der Videodaten durchführen, um
Mehrprozessorsysteme besser auszulasten. Es ließen sich natürlich auch mehrere
Jobs gleichzeitig abarbeiten, sofern die Ressourcen des Servers (hier wird neben
der CPU auch eine große Portion I/O Last1 erzeugt) ausreichen. Eine verbesserte Auslastung der Server ließe sich unter Umständen auch durch Wechseln des
H.264-Codecs von x2642 hin zu ELDER4X2643 erreichen.
In der aktuellen Implementation wird wenig Aufwand zur Präsentation der geschnittenen Videos getrieben. Die erstellten beispielhaften SMIL und HTML Dateien dienen als Vorlage für die eigene manuelle Integration. Eine automatische
Aufbereitung der Daten in komplexeren SMIL Code inklusive Präsentation von
Ereignissen und Materialien (ähnlich zu dem in Kapitel 4.2.3 dargestellten) ließe sich natürlich auch durchführen. Ebenso wäre eine automatische Bestückung
eines Streaming-Servers mit den erstellten Dateien möglich. Zur Zeit werden die
Videos in den erstellten SMIL-Dateien per HTTP referenziert. Dieses funktioniert
gut, da hierbei kein Spulen nötig ist und die Player die Daten schon während der
Übertragung abspielen. Die automatische Bestückung eines Streaming-Servers
wäre allerdings die sauberere Lösung.
Weitere Möglichkeiten bestehen in der Nutzung der Flash Plattform zur Präsentation der fertigen Daten. Der Vorteil gegenüber SMIL besteht in der höheren Verbreitung der zur Ansicht nötigen Browser-Plugins. Der Nachteil wäre ein deutlich
erhöhter Aufwand, um die Präsentation zu erstellen. Dies wäre allerdings einmaliger Entwicklungsaufwand, da sich durch die Programmierung per Action-Script
ein individueller Player entwickeln lassen würde, der aus XML-Dateien die nötigen
individuellen Informationen der Phasen ausliest und aufbereitet anzeigt. In diesem Fall würden auch bestehende Schnitte von Neuerungen im PräsentationsProgramm profitieren.
Auch die Nutzung einer Template-Engine zum Erstellen der Batch-Dateien und
Programm-Skripte wäre sinnvoll. Damit ließen sich Änderungen an Schnitt, Komprimierung und Export viel schneller vornehmen. Benötigt wird in diesem Fall
eine mächtige Template-Sprache, ähnlich der für PHP enwickelten SMARTYEngine4 . Die Template-Engine sollte in der Lage sein, Berechnungen durchzuführen
1
abhängig von den verwendeten Ausgangsmaterialien. Besonders stark bei kaum oder unkomprimiertem Video wie im DV-Format
2
nutzt bereits Multithreading, allerdings skaliert er nicht besonders gut
3
parallEL encoDER for X264, http://www.funknmary.de/bergdichter/projekte/index.
php?page=ELDER
Ein sich in Entwicklung befindlicher 2-Pass Encoder, der zur Parallelisierung das Aufsplitten
der Eingangsdaten, gleichzeitige Komprimierung und anschließendes Zusammenfügen nutzt
4
http://www.smarty.org
Kapitel 5 • Erweiterungs- und Optimierungsmöglichkeiten
(diese werden benötigt um Positionen, Größen und Zeitangaben umzurechnen).
Ebenso werden auch Kontrollstrukturen benötigt, um zum Beispiel bei der Aufbereitung über die Annotationen zu iterieren.
Sehr naheliegend wäre auch die Unterstützung von mehr Optionen beim Export.
Vor allem bezüglich Qualität und Bitrate der erstellten Dateien. Wobei hier darauf geachtet werden muss, noch eine einfache Bedienung zu gewährleisen. Dies
könnte durch das Zusammenfassen von unterschiedliche Konfigurations-Optionen
zu Profilen erreicht werden. Denkbar wären hier ein Profil für das Streaming im
Web und ein anderes mit höherer Qualität, welches für die Wiedergabe auf TV
Geräten per SVCD oder DVD optimiert ist. In manchen Anwendungs-Szenarien
mag die Besprechung in einer großen Gruppe vor dem Fernseher angebracht sein,
oder dass die Teilnehmer die Stunde mit nach Hause bekommen.
41
42
Abbildungsverzeichnis
2.1
Aktuelle ViLM Anwendung (mit Fehlermeldung beim Öffnen von
Materialien) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Aktueller HTML-Export . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1
Ziel-Architektur des neuen Systems . . . . . . . . . . . . . . . . . . 10
3.2
Ziel-Architektur mit Nutzung eines Netzwerkdateisystems für die
Markierung und automatischem Videoschnitt . . . . . . . . . . . . 16
4.1
Aufbau des Projektverzeichnisses . . . . . . . . . . . . . . . . . . . 20
4.2
Screenshot des Synchronisations-Tools . . . . . . . . . . . . . . . . 20
4.3
Screenshot des Annotations-Tools . . . . . . . . . . . . . . . . . . . 21
4.4
Screenshot des Controls ZzzzRangeBar . . . . . . . . . . . . . . . . 22
4.5
Zusammenspiel von Annotations-Tool und Videoschnitt-Dienst . . 23
4.6
DirectShow Graph zum Abspielen von Videos . . . . . . . . . . . . 30
4.7
Wiedergabe des SMIL-Dokumentes . . . . . . . . . . . . . . . . . . 32
4.8
Ablauf des Schnittprozesses inklusive Konvertierung in ein zum
RTSP-Streaming kompatibles MP4-Format . . . . . . . . . . . . . 37
I
II
Listings
4.1
Objekt für .NET Remoting . . . . . . . . . . . . . . . . . . . . . . 25
4.2
Sourcecode, um einen .NET Remoting Server online zu stellen . . . 26
4.3
Sourcecode, um einen .NET Remoting Client mit einem Server zu
verbinden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4
C#-Code um ein CS-Script auszuführen . . . . . . . . . . . . . . . 27
4.5
C#-Code um CS-Script auszuführen . . . . . . . . . . . . . . . . . 27
4.6
IDL-Code um DLLs für C# zu erstellen . . . . . . . . . . . . . . . 29
4.7
Batch-Datei um IDL-Code zu C# DLLs zu kompilieren . . . . . . 29
4.8
SMIL Beispielcode . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.9
AviSynth Script zur Extraktion von Videosequenzen anhand von
Zeitstempeln mit gleichzeitiger Auflösungsreduzierung . . . . . . . 32
4.10 AviSynth Script zum Verschmelzen von zwei Videos zu einem . . . 33
4.11 VirtualDubMod Script zur Audioextraction . . . . . . . . . . . . . 34
4.12 Aufruf von VirtualDubMod mit einem Script . . . . . . . . . . . . 34
4.13 Aufruf von faac zur Audiokompression . . . . . . . . . . . . . . . . 35
4.14 Aufruf von x264 zur Videokompression . . . . . . . . . . . . . . . . 35
4.15 Aufruf von MP4Box zur Erstellung des Containers . . . . . . . . . 36
III
IV
[Aja06]
JavaScript und AJAX. Galileo Computing, 2006.
[Avi06]
AviSynth Manual.
http://www.avisynth.org/index.php?page=
AviSynthManual – Zugriff am 20. September 2006, 2006.
[BR04]
Dick C.A. Bulterman and Lloyd Rutledge. SMIL 2.0 - Interactive Multimedia for Web and Mobile Devices. X.media.publishing. Springer,
ISBN: 3-540-20234-X, 2004.
[Cor06] Microsoft Corporation.
Windows media format sdk.
http:
//msdn.microsoft.com/library/default.asp?url=/library/
en-us/dnwmt/html/WMFormat 9 SDK Intro.asp – Zugriff am 20.
September 2006, 2006.
[DAS02] Mark Russinovich David A. Solomon. Inside Microsoft Windows 2000.
Microsoft Press Deutschland, 2002.
[Doh05] Michael Dohmen. Multimediale Evaluation in der Informatiklehrerausbildung. In A.H. Hilligus and H.-D. Rinkens, editors, Zentren für Lehrerbildung — Neue Wege im Bereich der Praxisphasen, pages 181–190.
2005.
[DP06]
Hajo Schulz Dirk Primbs. Weniger ist mehr - Software entwickeln für
eingeschränkte Benutzerrechte. c’t magazin für computer und technik,
(23-2006):214ff, November 2006.
[Gun00] Eric Gunnerson. C Sharp - Die neue Sprache für Microsofts .NETPlattform. Galileo Press, 2000. ISBN: 3898421074.
[HS98]
A. Rao Netscape R. Lanphier RealNetworks H. Schulzrinne, Columbia U. Rfc2326 - real time streaming protocol (rtsp). Technical report,
IETF, 1998.
[Inca]
Apple Computer Inc. Darwin Streaming Server. http://developer.
apple.com/opensource/server/streaming/index.html – Zugriff am
14. Mai 2006.
[Incb]
Sun Microsystems Inc. Java(tm) media framework (jmf) specification
2.0 final release. http://java.sun.com/products/java-media/jmf/
– Zugriff am 23. September 2006.
[Inc99]
Akamai Technologies Inc. Apple and Akamai Reveal Apple Investment to Cement Strategic Agreement. http://www.akamai.com/html/
about/press/releases/1999/press 081899c.html – Zugriff am: 02.
November 2006, 08 1999.
V
VI
[Inc00]
Apple Computer Inc.
Inside Macintosh: QuickTime Reference.
http://developer.apple.com/documentation/QuickTime/
REF/QT41 HTML/QT41WhatsNew-72.html – Zugriff am 20. September
2006, 2000.
[Inc05a] Apple Computer Inc.
SMIL Scripting Guide for QuickTime.
http://developer.apple.com/documentation/quicktime/
Conceptual/QTScripting SMIL/QTScripting SMIL.pdf, 06 2005.
[Inc05b] RealNetworks Inc. Helix software developer’s guide. https://common.
helixcommunity.org/nonav/2003/HCS SDK r5/helixsdk.htm – Zugriff am 23. September 2006, 03 2005.
[Inc06]
Adobe Systems Incorporated. Flash Player Statistics. http://www.
adobe.com/products/player census/flashplayer/ – Zugriff am 15.
Oktober 2006, 2006.
[IR04]
Mario Szpuszta Ingo Rammer. Advanced .NET Remoting. APress,US,
2004.
[Koc01] Daniel Koch. Praxisbuch XHTML. Addison-Wesley, 2001.
[Koc06] Daniel Koch. Wiederkehr des Lächelns - SMIL 2.1 mit neuen und erweiterten Funktionen. iX, (08-2006):144ff, 2006.
[Küh06] Andreas Kühnel. Visual C# 2005. Das umfassende Handbuch. Galileo
Press, 2006.
[Mag99] Johannes Magenheim. Vilm: Visualization of learning and teaching
strategies with multimedia in teacher education. In Piet Kommers and
Griff Richards, editors, Proceedings of World Conference on Educational
Multimedia, Hypermedia and Telecommunications 1999, pages 1593–
1594, Chesapeake, VA, 1999. AACE.
[Mic]
R Server 2003 R2 Platform SDK.
Microsoft Corporation. Windows
[MP406] (GPAC) MP4Box Documentation, 2006.
[Pes03]
Mark D. Pesce. Programming Microsoft DirectShow for Digital Video
and Television. Microsoft Press A Division of Microsoft Corporation
One Microsoft Way Redmond, Washington 98052-6399, 2003. ISBN:
0-7356-1821-6.
[Ric04]
Iain E. G. Richardson. H.264 and MPEG-4 video compression. Wiley,
2004.
[Vir05]
VirtualDubMod Help.
in VirtualDubMod Distribution http://
virtualdubmod.sourceforge.net/, 2005.
[Zot06a] Dr. Volker Zota. Flash for Video. c’t magazin für computer und technik,
(21-2006):216f, 2006.
[Zot06b] Dr. Volker Zota. Videosynthese. c’t magazin für computer und technik,
(08-2006):190ff, 2006.

Studienarbeit Oliver Buschjost

Transcription

Similar documents

Preprint - Medienwissenschaft Universität Bayreuth

PDF, 134,5 KB - Fachgebiet Audiokommunikation

Die Anfänge der Industrialisierung in Großbritannien

Vom Dokument zum PDF-File - Rechenzentrum

Komoot hat Routenplanung und Sprachnavigation

Vertriebsorganisation Hersteller Produktname

Th. Feuerstack et al.: Die kleine HTML

CAD-Konvertierung: Motivation, Probleme und Lösungen Das

Bachelorarbeit

Seiten 1 bis 6, PDF, 125 KB

DVD Architect Studio Kurzanleitung

Trotz alledem - Liederlexikon

- Pathé Films AG Zürich

7-PDF Maker Benutzerhandbuch

WinEdt-Minikurs Web Version