 |
Home / Publikationen / |
|
 |
 |
|
2. Projektbericht mmserv |
|
Hypermedia-Lehreinheiten in der Studentenausbildung - mmserv; Berichtszeitraum: April - September 1995; 01.1.1995 |
Hypermedia-Lehreinheiten in der Studentenausbildung - mmserv3 Zweiter Zwischenbericht3.1 Beschreibung der ArbeitsaufgabenWesentliches Ziel der zweiten Phase des Projektes (12.94-06.95) war zunächst die Beschaffung und Inbetriebnahme der mmserv-Umgebung gemäß der in der ersten Projektphase erstellten Konzeption für den netzweiten Einsatz des Multimedia-Servers, der Kommunikationskomponenten sowie der auf Server- und Client-Seite benötigten Hard- und Software. Die Erneuerung der Innerhousevernetzung des Fachbereichs sowie die Aufnahme des Testbetriebs auf der ATM-Verbindung zur ZEDAT konnten im Frühjahr '95 realisiert werden, wobei umfangreiche Tests der bestehenden Konfiguration der aktiven Netzkomponenten (Router, Switches etc.) derzeit vorbereitet werden. Die derzeitige technische Konfiguration des MM-Servers bzw. der MM-Workstation, die beide zu Beginn der Phase 2 des Projektes beschafft und installiert werden konnten, verdeutlicht folgende Übersicht:
Der MM-Server (SGI Challenge DM) läuft nach wie vor im lokalen Testbetrieb. Derzeit wird dort das gesamte Bild- und Videomaterial verwaltet, welches den MM-Clients (Autorenarbeitsplätze) über NFS-basierte Verbindungen im lokalen TokenRing-Netz zur Verfügung gestellt wird. Ein ATM-Interface (ForeSystems) wurde zusätzlich installiert, konnte aber wegen Konfigurationsproblemen noch nicht in Betrieb genommen werden. Dies soll bis Ende September '95 jedoch erfolgen. Die MM-Workstation (SGI Indigo2) verfügt derzeit über die nachfolgend dargestellte Software- ausstattung und Medienfunktionalität:
Auf der MM-Workstation wurden unter Einsatz dieser und einiger anderer Softwarepakete umfangreiche Tests zur Videodigitalisierung und -bearbeitung durchgeführt. Hierbei war insbesondere die Konvertierung MJPEG-encodeten Videomaterials nach MPEG von Interesse, da der MJPEG-Algorithmus zwar klare Vorteile gegenüber MPEG in Bezug auf die Qualität des digitalisierten Materials hat, das Playback von MJPEG-Streams auf PC-Seite derzeit jedoch noch nicht durch entsprechende Hardware unterstützt wird. Für die Tests standen Tools von SGI (interaktive MJPEG-Encodierung und Einzelbildextraktion), vom San Diego Supercomputer Center (v.a. joborientierte Einzelbildbearbeitung), vom Berkeley Multimedia Lab (joborientierte MPEG-Encodierung) sowie von North Valley Research (interaktive und joborientierte MPEG-Kompression) zur Verfügung. Die Tests wurden mit dem verfügbaren S-VHS-Videomaterial der MM-Prototypanwendung Der Schlüssel zum WRZ durchgeführt. Ausgangspunkt war eine 10-Sekunden-Sequenz in PAL-Auflösung (250 Frames). Identische Sequenzen wurden bereits früher von der ZEAM mit Hilfe der Optibase-Lösung direkt in MPEG kodiert und auf der vorhandenen SPEA Showtime Plus-Karte präsentationsfähig gemacht. Auf diese Weise konnten gute Qualitätsvergleiche angestellt werden. Als Beurteilungshilfe wurden - lineare Extrapolationsfähigkeit vorausgesetzt - die ermittelten Werte auf eine 10-minütige Videosequenz hochgerechnet:
Die schließlich erzeugten MPEG-Files benötigen zwischen 2,5 und 3 MB Festspeicherplatz. Die ermittelten Zeiten gelten für lokale Speicherzugriffe; ob und inwiweit Netzzugriffe einen Engpaß darstellen muß noch getestet werden. Auffällig sind - abhängig von dem verwendeten Rasterformat - die unterschiedlichen Speicherplatz- und Rechenzeitanforderungen. Eine erste Qualitätseinschätzung: Der MPEG-Datenstrom ist unter den verwendeten Parametern beim Playback auf der SPEA Showtime Plus stabil, Video und Audio verhalten sich synchron. Gegenüber der Kodierung bereits verkleinerter Einzelbilder erscheint es günstiger, zunächst große Einzelbilder (768x576 SGI-MJPEG) zu extrahieren und diese anschließend während der MPEG-Kompression zu verkleinern (352x264). Die NVR-Kompression ermöglicht darüberhinaus ein "Smoothing" beim Rezising. Dies ist insofern günstig, als der MPEG-Algorithmus auf der Berechnung und Speicherung von Bildabschnittsveränderungen basiert und daher bei der Verarbeitung "unruhigen" Video-Ausgangsmaterials die schlechte Qualität auch in das digitale Output transportiert. Das Smoothing trägt hier wesentlich zur Unterdrückung derartiger Bildmängel bei. Die Farbbrillianz (und damit auch der subjektiv wahrgenommene Bildkontrast) des auf der Optibase-Lösung produzierten MPEG-Materials ist deutlich größer als die der SGI-Lösung. Durch Erhöhung der Helligkeit und Farbsaturation der TIFF-Einzelbilder um ca. 10% konnten jedoch Qualitätsannäherungen erreicht werden. Die folgende Grafik veranschaulicht nochmals die Vorgehensweise vom analogen Input bis zum digitalen Output:
Ein erstes Fazit: Die digitale Videoproduktion mit Hilfe der Einzelbildextraktion und -kodierung ist möglich und produziert akzeptable Ergebnisse. Der Ressourcenaufwand ist jedoch beträchtlich. Anhand der ermittelten Performancewerte läßt sich leicht errechnen, wieviel Gigabyte an Massenspeicher und wieviel Tage Rechenzeit die MPEG-Kodierung längeren Videomaterials erfordern. Hinzu kommt, daß nicht alle Programme batchfähig sind. Lediglich eine einfache Bildnachbearbeitung und die MPEG-Kompression lassen sich ohne Überwachung durch den Anwender ausführen. Für einen unmoderierten Gesamtdurchlauf müßte zumindest noch für die Einzelbildextraktion eine Lösung gefunden werden. Die SGI-Tools zur Bildbearbeitung sind leistungsfähiger als die Shareware von SDSC, aber nur interaktiv zu nutzen und damit an dieser Stelle nur bedingt einsetzbar. Die Tests haben deutlich gezeigt, daß die Qualität des analogen Ausgangsmaterials entscheidende Bedeutung für die Güte des Endprodukts hat. Die spätere digitale Verwendung der Videos sollte Konsequenzen bereits für die Aufnahme haben. Letzte Anpassungen/Optimierungen sollten beim Frame-Grabbing geschehen. Spätere Bildnachbereitungen sind zwar möglich, erfordern aber enorme Ressourcen und benötigen für gute Ergebnisse auch entsprechend aufwendige Image- bzw. Video-Editingsoftware. Der Weg über die Berkeley-Lösung erscheint weiterhin sehr attraktiv: bei dem Encoder handelt es sich um Shareware, die auch als Quellcode vorliegt. Somit ließen sich auch andere Rechner, z.B. der ZEDAT einsetzen. Das BRTB-Projekt VISUAL (Wissenschaftliche Visualisierung, ZIB) hat diesen multiprozessorfähigen Video-Encoder darüberhinaus für den Einsatz auf der Cray-T3D modifiziert. Dies würde - theoretisch - drastisch verbesserte Produktionsalternativen bzgl. der Rechenzeiten bedeuten. Der Transfer der dann vorextrahierten Einzelbilder (z.B. RGB-Format) zum ZIB sowie der erzeugten MPEG-Files von dort zurück zum WRZ könnte über die neue, schnelle ATM-Verbindung des BRAIN realisiert werden. Die nächsten Schritte:
Auf der Seite der PC-basierten Systeme wurden gemäß der in Phase 1 des Projektes erarbeiteten Feinspezifikation (vgl. 1. Zwischenbericht mmserv/DIALECT) jeweils 5 Autoren- bzw. 18 (ursprünglich geplant: 5) Client-Arbeitsplätze beschafft. Deren technische Ausstattung kann der folgenden Grafik entnommen werden:
Die zunächst beim Einbau der MPEG-Decoder-Hardware (SPEA Showtime Plus) in die PCI-Slots der Pentium-PCs aufgetretenen Kompatibilitätsprobleme konnten mittlerweile durch verbesserte Treiberunterstützung und ein ROM-Upgrade der Pentium-PC's behoben werden. Die vorläufig produktionsreife Softwareausstattung der MM-Autoren- und MM-Clientarbeitsplätze läßt sich wie folgt beschreiben:
Nach wie vor bestehen große Schwierigkeiten in der NFS-Anbindung der PCs an die beiden UNIX-Maschinen. Bei den Tests mit Produkten unterschiedlicher Hersteller (IBM TCP/IP f. DOS 2.1.1, Sun PCNFS, WATTCP) zeigte sich, daß die Art des Adaptersupports (NDIS, Packet/Socket) keineswegs ausschlaggebend ist. Das Problem liegt darin, daß die Parametrisierung aller Produkte nur einen begrenzten Read-/Write-Size von ca. 8 Kb zuläßt, der keine konstanten Transferraten und damit auch keinen störungsfreien Ablauf der zeitkritischen MPEG-Datenströme ermöglicht. Zur Zeit wird deshalb der Einsatz von RPC (z.B. DFN-RPC) erwogen, um einen schnelleren Netzzugriff auf die Filesysteme der Workstation und des Servers zu ermöglichen. Eine weitere Aufgabe der zweiten Projektphase war, den Markt für kommerziell angebotene, wirtschaftswissenschaftliche Lehrsoftware und -videos zu analysieren, um ggf. geeignete Produkte einem kleinen Kreis von Anwendern zu Testzwecken zugänglich zu machen. Bei der Bewertung standen besonders die Multimedialität, Verständlichkeit, inhaltlicher Schwierigkeitsgrad sowie die Unterstützung verschiedener Lernniveaus im Vordergrund. Die so gewonnenen Erkenntnisse gingen schließlich - gemeinsam mit den Erfahrungen aus der Erstellung der Prototyp-Applikation Der Schlüssel zum WRZ - in die in Phase 3 des Projektes zu erstellenden Grob-, Fein- und Dramaturgischen Konzepte für die Applikationen Marketing - Diffusionstheorie und Steuern in der Investitionsrechnung ein. Stand der Applikation Marketing - Diffusionstheorie: Die semantische Struktur der im Verlauf der dritten Projektphase zu erstellenden ersten Lehreinheit Marketing - Diffusionstheorie gliedert sich in folgende Blöcke auf:
Nach einigen vorbereitenden Gesprächen konnten schließlich Prof. M. Kleinaltenkamp, Prof. A. Kuß (ehem. Fernuni Hagen, jetzt FUB) und Prof. Weiber (Universität Trier) hierfür gewonnen werden. Während der 20minütigen Diskussion übernahm Prof. Kleinaltenkamp die Moderation, während seine Kollegen das Thema kontrovers erörterten. Durch die Einbindung dieses Expertengesprächs in die Lehreinheit will das Team dem interessierten Studenten die Möglichkeit einräumen, sich ergänzend zum Lerneffekt intensiver mit den Problematiken derartiger Prognosemodelle auseinanderzusetzen. Wie bereits bei der Erstellung der Prototypanwendung Der Schlüssel zum WRZ wurden die fertigen Filmsequenzen mit Unterstützung der ZEAM in den dortigen Studios zunächst digital nachbearbeitet und anschließend mittels spezieller Hard- und Software (OptiBase Lab) und unter Zuhilfenahme von Schnittlisten als MPEG-Streams digitalisiert. Noch während der laufenden Postproduktion begann im WRZ der Storyboard-Erstellungsprozeß durch die Fachautoren und Programmierer. Diese wurden mit dem Ziel konzipiert, als Leitfaden für die weitere Medienproduktion und Programmierarbeit zu dienen, und enthalten einen dafür eigens entwickelten, reduzierten Pseudocode zur Beschreibung aller in der Applikation vorgesehenen Objekte (Video, Grafik, Text) und Ereignisse. Für die Blöcke Fallinformationen und Simulationsmodell sind die Storyboards bereits fertiggestellt (vgl. oben). Eine weitere Aufgabe besteht derzeit in der Durchführung ergänzender Bild- und Motivrecherchen und der Evaluation hierfür geeigneter Produktionsmethoden (Scannen, Nachbearbeitung). Da insbesondere die Produktion anspruchsvollen Grafikmaterials für Frame-Hintergründe bzw. die animierte Präsentation aufbereiteten Zahlenmaterials als zeit- und personalintensive Vorgänge anzusehen sind, werden zusätzlich Recherchen der hierfür relevanten Dienstleistungsangebote durchgeführt. In Vorbereitung sind z.Zt. grafische Browser und verschiedene Maskenlayouts, die gestalterisch in engem Bezug zu den Inhalten der Applikation stehen müssen. Im Juli dieses Jahres wurde dann ein Team aus Programmierern und Fachautoren gebildet, welches im August nach Abschluß des größten Teils der Videoproduktion mit den Implementierungsarbeiten begann. Auf Basis der vorhandenen Storyboards konnten zunächst die Module Fallinformationen und Simulationsmodell sowie die zentrale Navigationskomponente und das Error-Handling umgesetzt werden. Die Verwaltung der zentralen Datenobjekte (Forms, Grafiken, Videos, Hypertexte etc.) sowie die Zugriffssteuerung zu Design- und Laufzeit erfolgt über ein relationales DB-System. Mit der Fertigstellung eines ersten präsentationsfähigen Prototypen wird Mitte Oktober dieses Jahres gerechnet. Stand der Applikation Steuern in der Investitionsrechnung: Das Konzept der Applikation sieht eine Aufteilung in die folgenden logischen Blöcke vor:
Im Mai dieses Jahres begann das Fachautorenteam um Prof. Kruschwitz mit der Konzeptionierung der zweiten Pilotapplikation zum Thema Steuern in der Investitionsrechnung. Hier sind Grob- und Feinkonzept bereits erstellt; die Endredaktion des Dramaturgischen Konzeptes und der Beginn der Ausschreibungsphase für die Videoproduktion sind für Anfang Oktober dieses Jahres vorgesehen. Eine erste lauffähige Version soll zum Ende dieses Jahres vorliegen.
3.2 Erreichte Ziele3.2.1 Ergebnisse/Erkenntnisse(a) Videoproduktion/Postproduktion Wie auch bei der Produktion des Filmmaterials für die Anwendung Der Schlüssel zum WRZ wurde auch im Verlauf der Arbeiten an der Lehreinheit Marketing - Diffusionstheorie erneut deutlich, daß weniger die filmtechnische Umsetzung als vielmehr die Integration lernrelevanter Inhalte in ein zu Motivationszwecken konzipiertes Spielfilmszenario z. T. erhebliche Probleme bereitet. Obwohl die zu transportierenden Fakten - am Beispiel des semantischen Blockes Fallinformationen - durch die Fachautoren beim Skripting sehr genau festgelegt und beschrieben worden waren, kam es doch während der Erstellung des Drehbuches immer wieder zu Abstimmungs- und Verständnisproblemen in der Zusammenarbeit mit dem hierfür beauftragten Dienstleister. Der Grund ist hauptsächlich darin zu suchen, daß dieser sich mit einer bis dato für ihn völlig fremden Thematik auseinandersetzen mußte und Schwierigkeiten hatte, diese in die szenische Gestaltung und die Dialoge geeignet einfliessen zu lassen. Obwohl die Qualität des filmischen Materials angesichts der eingesetzten finanziellen und personellen Ressourcen insgesamt als zufriedenstellend bezeichnet werden kann, erscheint es geboten, vor allem die Drehbücher von Personen erstellen zu lassen, die neben der rein technischen Kenntnis der Verfahrensweisen und Aspekte der Videoproduktion auch über Erfahrungen im wirtschaftswissenschaftlichen Bereich verfügen. Bei der Postproduktion und anschließenden Digitalisierung des Filmmaterials konnten - verglichen mit dem Material, welches für die Prototypanwendung zur Verfügung stand - erhebliche Fortschritte erzielt werden. Die ZEAM verfügt mittlerweile neben gut ausgestatteten Studios auch über ein digitales Online-Schnittsystem auf Macintosh-Basis (AVID) als auch über eine neue Version der OptiBase Digitalisierungs-Software. Mittlerweile können alle dort erzeugten MPEG-Streams auf der am WRZ eingesetzten Hardware (SPEA Showtime Plus) in guter Bild- und Audioqualität abgespielt werden, wobei auch höhere Kompressionsraten von >200kbps keine Probleme bereiten. (b) MPEG-Hardware Tests mit MPEG-Adaptern anderer Hersteller (u.a. Matrox Marvel II), die sich technisch und vor allem preislich von der SPEA-Lösung unterschieden, konnten keine signifikant besseren Ergebnisse als diese liefern. Einige der Teststellungen wiesen sogar trotz ihres relativ hohen Preises erhebliche Schwächen speziell in Bezug auf die Steuerbarkeit des Abspielvorgangs auf. Auf Basis dieser Erfahrungen empfahl das WRZ der Humboldt Universität, ihren MM-PC-Pool ebenfalls mit SPEA-MPEG-Adaptern auszurüsten. (c) Konzeptionierung der Lehreinheiten Die Idee, ökonomische Theorien und Konzepte mit Hilfe filmischer Elemente zu verdeutlichen bzw. den Anwender auf die Applikation 'einzustimmen', erfordert eine sehr intensive Zusammenarbeit zwischen Fachautoren, Multimedia-Ingenieuren und Skript-Schreibern. Bei der Erstellung der Grob-, Fein- und Dramaturgischen Konzepte der zu realisierenden Lehreinheiten wurde darauf Rücksicht genommen, indem die Gesamtheit der Erkenntnisse und Erfahrungen aus der Prototyp-Realisierung in die Entwurfsphase der ersten Lehreinheiten eingeflossen sind. Durch das Bemühen, die einzelnen Schritte der Entwurfsphase weitgehend zu standardisieren sowie die Informationen im Rahmen der Feinkonzepte zu strukturieren und in Form semantischer Einheiten zu modularisieren, konnte der anschließende Prozeß der Storyboarderstellung stark vereinfacht werden. Ein interessanter Aspekt ist in diesem Zusammenhang, inwieweit sich die o.g. Prozesse durch ein "verteiltes" Arbeiten, beispielsweise mittels MMC, noch weiter optimieren lassen im Sinne verbesserter Abstimmung der Autoren untereinander oder signifikant verkürzter Erstellungsdauern. (d) MM-Autorensysteme In diesem Bereich waren die wohl eindeutig negativsten Erfahrungen zu verzeichnen. Das für die Implementierung der Prototyp-Anwendung eingesetzte Multimedia ToolBook 3.0 konnte den gesetzten Anforderungen schon nach kurzer Zeit nicht mehr gerecht werden. Die Media-Funktionalität erwies sich als unzureichend, sobald es darum ging, die Wiedergabe von MPEG-Videos zu steuern und neigte darüberhinaus bei simultaner Darstellung mehrerer Medien innerhalb desselben Frames zu Instabilität (Lockups, GPF's etc.) Die enthaltene Skriptsprache war nicht leistungsfähig genug, eine komplexere Navigation zu realisieren, wie sie für MM-Applikationen, die einen "Wissensraum" abbilden sollen, in dem sich der Anwender frei bewegen kann, unabdingbar sind. Da das Alternativprodukt Authorware 3.0, welches gemeinsam mit dem Director 4.0 eine bessere Mediafunktionalität und Programmierbarkeit verspricht, bislang noch nicht verfügbar ist, wurde auf Visual Basic 3.0 als Entwicklungsumgebung zurückgegriffen. Ein wesentlicher Grund für diese Entscheidung lag in der Vielfalt der angebotenen add-ons und der Existenz gut dokumentierter Programmierschnittstellen zu Microsoft's MCI-Interface bzw. anderen Programmiersprachen und DB-Systemen. (e) User Interface-Design Es hat sich als vorteilhaft erwiesen, die Festschreibung eines endgültigen grafischen Konzeptes für die Gestaltung von Basismasken, Menüstrukturen, Gestaltung und Plazierung zentraler Steuerstrukturen etc. möglichst lange hinauszuzögern, um die Kreativität und Experimentierfreudigkeit der Autoren und Programmierer nicht durch verfrühte Festlegungen einzuschränken. (f) Netztransport Da eine Hochgeschwindigkeitsanbindung über das BRAIN bislang nur zwischen dem WRZ und dem RZ der HUB, aber noch nicht von dort zum FB WiWiss der HUB besteht, konnten noch keine Tests zu Datendurchsatz bzw. Netzlast beim Transport zeitkritischer MPEG-Datenströme zwischen den beiden Lokationen durchgeführt werden. Hinzu kommt, daß das ATM-Interface des MM-Servers zwar physisch vorhanden ist, aber noch nicht in Betrieb ist (Konfigurationsprobleme). Die Netzanbindung auf Seiten der HUB soll bis Ende 1995 komplettiert sein. Die Inbetriebnahme des ATM-Interfaces des MM-Servers wird innerhalb der nächsten zwei Wochen ab Datum des Berichtes erfolgen; hier steht das WRZ mit den Lieferanten (SNI/Controlware) und der ZEDAT in Kontakt. Erste Tests im LAN des WRZ (NFS über 16Mbit TokenRing) brachten nicht die gewünschten Resultate. Nach wie vor zeigt sich, daß die unter NFS konfigurierbaren Paketgrößen von ca. 8KB nicht ausreichen, um einen gleichmäßigen Datenstrom zu erzeugen, wie er für das synchrone Abspielen der MPEG-Streams (Video- und Audiostream) erforderlich ist. Von bisher drei auf der Client-Seite getesteten DOS/Windows-NFS-Produkten, die über NDIS- (IBM TCP/IP) bzw. Packet-Treiber (Sun's PCNFS, FTP's PC/TCP) auf den Netzwerkadapter zugreifen, konnte keines eine Verbindung zum MM-Server herstellen, die einen störungsfreien Ablauf der MPEG-Videos gestattete. Sobald die schnelle Netzverbindung zum FB WiWiss der HUB hergestellt ist, werden die Tests auf diese Strecke ausgeweitet.
3.2.2 Veröffentlichungen, Vorträge, Präsentationen usw.Das Projektteam beteiligte sich mit einem Vortrag und einer korrespondierenden Vorführung der Prototypanwendung Der Schlüssel zum WRZ an der Einweihungsfeier des BRAIN am 28.06.95 in der Humboldt Universität. Ferner nimmt das Team an den Treffen des Arbeitskreises Verteiltes Lehren und Lernen teil; das nächste Treffen findet am 20.10.95 in Nürnberg statt. Um die Universitätsöffentlichkeit und insbesondere die Studierenden und Dozenten am Fachbereich WiWiss der FU-Berlin über Inhalte und Fortgang des Projektes zu informieren, wird halbjährlich eine Informationsveranstaltung angeboten.
|
