RTB Nord – P1: „Videoverﬁlmung im Netz“

Abschlußbericht RTB Nord – P1: „Videoverfilmung im Netz“

1

RTB Nord – P1: „Videoverfilmung im Netz“

Abschlußbericht

Version 1.0, 27. März 1997

Regionales Rechenzentrum für Niedersachsen (RRZN) /Lehrgebiet Rechnernetze und Verteilte System (RVS)Prof. Dr.-Ing. Helmut Pralle

Universität Hannover

Inhalt1 Bezeichnung des Projektes 22 Beschreibung des Projektes 2

2.1 Motivation 22.2 Projektziel 3

3 Durchführung des Projektes 53.1 Personal 53.2 Investitionen 53.3 Studien- und Diplomarbeiten 53.4 Vorträge, Veröffentlichungen 63.5 Nutzung existierender Basisdienste und Software-Tools 7

4 Ergebnisse des Projektes 84.1 Nutzung des Videoaufzeichungsdienstes 84.2 Video-Preview – Online-Publishing von Videos „On Demand“ 134.3 ShowSeq – Preview-Komponente für den lokalen Betrieb 13

5 Zusammenfassung und Ausblick 16

Das Vorhaben wurde aus Mitteln des Bundesministeriums für Bildung, Wissenschaft, Forschung undTechnologie (BMBF) durch den Verein zur Förderung eines Deutschen Forschungsnetzes e. V. (DFN-Verein) finanziert.


Bezeichnung des Projektes 2

1 Bezeichnung des ProjektesProjekttitel: Videoverfilmung im Netz

Kurztitel: RTB Nord – P1

Ansprechpartner: Stephan OlbrichRegionales Rechenzentrum für Niedersachsen (RRZN)/Lehrgebiet Rechnernetze und Verteilte Systeme (RVS),Universität Hannover (Leiter: Prof. Dr.-Ing. Helmut Pralle)

Teilnehmende Einrichtungen: RRZN/RVS, Universität Hannover

Kooperationen: Deutsches Klimarechenzentrum (DKRZ), HamburgGKSS Forschungszentrum GeesthachtInstitut für Meteorologie und Klimatologie, Universität HannoverInstitut für Strömungsmechanik, Technische Universität BraunschweigRechenzentrum der Technischen Universität Hamburg-HarburgRechenzentrum der Universität Hamburg

Projektlaufzeit: 24 Monate (01.10.1994 – 30.09.1996)

2 Beschreibung des Projektes

2.1 MotivationAnwendungen für Computer-Animationen liegen z. B. in Wissenschaft, Werbung und Unterhaltungs-industrie vor. Im technisch-wissenschaftlichen Bereich sind dies häufig Visualisierungen mehrdimen-sionaler Ergebnisdaten aus Experimenten oder Computersimulationen, in welchen durch Variationeines Parameters (z. B. der Zeit) eine Bildsequenz generiert wird. Exemplarisch sei hier auf die Visua-lisierung strömungsmechanischer Berechnungen verwiesen.

Gefordert werden sowohl hohe Bildqualität als auch Synchronisierung zu einem festgelegten Zeitra-ster. Die Spezifikationen des Digitalvideo-Standards CCIR 601 können als Minimalforderungen ange-sehen werden, da für die meisten Anwendungen eine ausreichende Bildqualität sowie Kompatibilitätzum Fernsehstandard geboten werden. Die zum europäischen PAL-Fernseh-Sendestandard konformenCCIR-601-Parameter lauten: 720x576 Pixel/Bild bei 16 bit/Pixel, 25 Bilder/Sekunde – die Abtastratebeträgt 13,5 Mio. Pixel/Sekunde (216 Mbit/s), die durchschnittliche Nettodatenrate 165,888 Mbit/s.Die derzeit verfügbaren Werkzeuge zur interaktiven Animation – hierzu gehören Hard- und Software-Systeme, die z. B. auf Kompressionsmethoden basieren oder General-Purpose-Visualisierungssystememit Animationsmoduln – können diese Kriterien auf bisher üblichen Arbeitsplatzrechnern nicht erfül-len. Als Gründe sind die unzureichende Leistungsfähigkeit in bezug auf Rechengeschwindigkeit undGraphikhardware sowie oftmals fehlende Echtzeit-Funktionalitäten im Betriebssystemkern zu nennen.

Der Einsatz von Standard-Kompressionsverfahren, welche unabhängig vom Bildmaterial signifikanteKompressionsfaktoren aufweisen (z. B. JPEG im lossy mode, MPEG) erweist sich aus folgendenGründen als problematisch:

• Insbesondere für die hochqualitative technisch-wissenschaftliche Visualisierung führen dieseverlustbehafteten Methoden zu einer in vielen Fällen unzulässigen Verfälschung der Darstellung.Dies ist hauptsächlich auf die besonderen Signaleigenschaften der verwendeten künstlichen Bil-der – insbesondere Graphiken – zurückzuführen, welche sich deutlich von digitalisierten Real-bildern unterscheiden, für die die genannten Kompressionsverfahren ausgelegt sind – es tretenz. T. starke, hochfrequente Anteile durch abrupte Farb-/Helligkeitsübergänge im Ortsbereich auf,die z. B. durch Linien- oder Füllflächen-Graphiken verursacht werden.

• Die Realisierung von Codecs für die oben genannten Verfahren auf heutigen Standard-Arbeits-platzrechensystemen erfolgt im wesentlichen in Software, wobei die CPU-Leistung derzeit nichtausreicht, um die oben genannten CCIR-601-Randbedingungen (z. B. mit MPEG-2) einzuhalten.


Beschreibung des Projektes 3

Sobald standardmäßig auf allen Plattformen entsprechend hochwertige JPEG- bzw. MPEG-Hardware-Codec-Subsysteme verfügbar sind, können sich derartige Verfahren an Stelle der hierbetrachteten Offline-Videoaufzeichnung durchsetzen.

Wegen der genannten Einschränkungen im Online-Simulations- und Visualisierungsbetrieb werdenleistungsfähige Systeme zur qualitativ hochwertigen Offline-Videoaufzeichnung benötigt. Um denAnwender von der Beschaffung, Installation, Einarbeitung und Bedienung der hierfür erforderlichenSpezialgeräte und damit verbundenen relativ hohen Kosten zu entlasten, werden diese Geräte üblicher-weise in zentralen Einrichtungen zur Benutzung angeboten. Der Anwender muß daher im allgemeinennach terminlicher Abstimmung zur Videoverfilmung seinen gewohnten Arbeitsplatz verlassen, um imVideostudio tätig zu werden.

Gewünscht wird jedoch ein komfortabler Fernzugriff auf die Videoressourcen sowie möglichst hoheProduktivität. Beides kann durch einen batch-artigen Zugriff über ein Kommunikationsnetz erreichtwerden, also durch das Angebot eines verteilten Videoproduktionsdienstes.

Im wissenschaftlich-technischen Bereich – einem der Hauptanwendungsgebiete, beispielsweise fürdie Visualisierung von Ergebnissen aus aufwendigen Simulationsrechnungen – werden häufig Szena-rien in leistungsfähigen Netzen eingesetzt. Eine räumlich entfernte Aufzeichnungseinheit läßt sichdadurch auf natürliche Weise integrieren.

2.2 ProjektzielEin Videoaufzeichnungssystem, welches den im vorigen Abschnitt erläuterten Anforderungen genügt,wird am RRZN/RVS seit 1990 betrieben1. Die Konfiguration der am RRZN installierten Video-Verfil-mungsanlage – vor Projektbeginn – ist inBild 1 dargestellt. Vom Anwender generierte Steuer- undBild-Dateien – seit Anfang 1996 auch Audio-Dateien – werden über das TCP/IP-basierte BSD-lpr/lpd-Protokoll, welches ursprünglich zum entfernten Drucken entwickelt wurde, zum Video-Serverübertragen. Dieser zeichnet die Bild- und Ton-Daten – script-gesteuert, auf der Basis der Steuer-Datei– auf Videocassette in Studio-Qualität (Betacam-SP) auf. Die Videocassette erreicht den Nutzerschließlich auf dem Postwege.

1. siehe auch http://www.rrzn.uni-hannover.de/Grafik/Ausgabe/Video/

Digitale Realtime-Videodisk

Betacam-SP-Videorecorder

Video-ServerWorkstation

Betacam-SPKassetten-Archiv

Realtime-Analog-VideoRasterbilder

Video-Verfilmungsanlage am RRZN

Workstation(oder Terminal für entfernten Zugriff)

Rechner für Bild- und Steuerdatei-Bearbeitung im entfernten Zugriff,z. B. Rechner am RRZN:- Vektorrechner S400- Sun-Cluster UniCS- HP-Cluster

Videokassette

lpr -Pvideo steuerdatei bilddatei

Bild-datei

Steuer-datei I n t e r n e t

Vom RRZNzugestellteVideokassette

zum Benutzer

Bild 1: Konfiguration der Video-Verfilmungsanlage am RRZN


Beschreibung des Projektes 4

Das Systemmodell des Produktionsprozesses ist inBild 2 abgebildet.

Damit wird – primär für Nutzer in den Instituten der Universität Hannover – eine Routinedienstlei-stung angeboten. Aufträge zur Videoverfilmung werden dabei aus verschiedenen Arbeitsumgebungenheraus generiert, z. B. von Arbeitsplatzrechnern im universitären Datennetz oder vom VektorrechnerSiemens S400/40 – inzwischen abgelöst durch ein VPP300-System – des RRZN. Die Erfahrungen derbisherigen Nutzer, beispielsweise aus dem Institut für Meteorologie und Klimatologie, durch ani-mierte Bildwiedergabe zeitabhängige bzw. mehrdimensionale Phänomene beurteilen zu können, sindäußerst positiv bewertet worden.

Daher wurde mit diesem Projekt das Ziel verfolgt, diese Dienstleistung über das lokale Netz hinausnutzbar zu machen. Da die für einen sinnvollen Betrieb der vor Projektbeginn verfügbaren Aufzeich-nungsanlage erforderliche Bandbreite im Kommunikationsnetz bei ca. 2 Mbit/s lag, wurde der Pilotbe-trieb für Partner imRTB Nord geplant. Dadurch sollte es Wissenschaftlern von ihrem Arbeitsplatz inHamburg, Bremerhaven oder Braunschweig aus ermöglicht werden, Videoverfilmungsaufträge überdas Netz zur Bearbeitung nach Hannover zu schicken.

Spool-Dateien

lpd

sendmail

Videoproduktion

Log-Dateien Video-Sequenz(Rasterbilder)

Videocassetten-Archiv

TrennungScript-

Compilation

Rendering,Konvertierung,

Transfer

Schnitt/Überspielung

User-Id.

Script

Bilder

Schnittsteuerung

Rendering-

Steuerung

Videoverfilmungsserver

Auftrag

Status

Videocassette

Protokoll

Auftrag

Protokoll

Videocassette

Kom

mun

ikat

ions

netz

Anwender

Post-dienst

Bild 2: Systemmodell des im Videoverfilmungsserver realisierten Produktionsprozesses


Durchführung des Projektes 5

Die Voraussetzungen dafür (Arbeitsplatzrechner, lpr/lpd-Software) sind im wesentlichen überall ver-fügbar. Dennoch waren folgende Arbeiten zu erledigen:

• Schulungs- und Beratungsleistungen für neue Anwender,

• Auswahl, Beschaffung und Installation eines RTB-Videoservers im RRZN,

• Betrieb, Bedienung des RTB-Videoservers,

• Postdienst zur Verteilung der erzeugten Videocassetten,

• Realisierung von effizienzsteigernden Maßnahmen, wie z. B. Preview-Techniken:

– Video-Preview – Online-Publishing von Videos „On Demand“ (sieheKap. 4.2),– ShowSeq – Preview-Komponente für den lokalen Betrieb (sieheKap. 4.3).

Darüber hinaus sollte der Videoverfilmungsdienst weiteren Wissenschaftlern, auch außerhalb desRTB Nord – d. h. insbesondere im B-WiN, DFN-weit als Werkzeug zur Verfügung gestellt werden.

3 Durchführung des Projektes

3.1 PersonalAn dem Projekt waren die folgenden Personen beteiligt:

• Projektleitung

– Prof. Dr.-Ing. Helmut Pralle

• Wissenschaftliche Mitarbeiter

– Dipl.-Ing. Lutz Grüneberg– Dipl.-Ing. Steffen Heinze– Dr.-Ing. Fritz Hüsemann– Dipl.-Ing. Stephan Olbrich

• Wissenschaftliche Hilfskräfte

– Alexander von Berg– Claus Eikemeier– Ralf Einhorn– Wolfgang Pfuhl

3.2 InvestitionenZur Durchführung des Projektes wurden die folgenden Investitionen getätigt:

Videoproduktionsserver

• UNIX-Workstation: Sun SparcStation 20/612, 20“-Farbmonitor, ATM-Interface, 64 MB Haupt-speicher, 1 GB Systemdisk, 8 GB Festplattenerweiterung.

• Digitale Realtime-Videodisk: DVS Pronto, incl. D/A-Wandler (D1-Seriell – Betacam-YUV).

• Betacam-SP-Schnittvideorecorder: Sony PVW 2800 P.

• S-VHS-Schnittvideorecorder: Sony SVO 9800 P.

3.3 Studien- und DiplomarbeitenIm Rahmen des Projektes wurde eine Studienarbeit angefertigt:

• Einhorn, R.: „Realisierung einer ‚Online-Preview‘-Komponente für die Videoproduktion inBreitbandnetzen“, RRZN/RVS, 1996.(http://www.rvs.uni-hannover.de/arbeiten/studien/sa-reinhorn.html)



3.4 Vorträge, Veröffentlichungen, CeBIT-Exponate,DFN-ArbeitskreisTeilergebnisse des Projekts wurden wie folgt präsentiert:

• Vorträge

– Olbrich, S.: P1-Zwischenberichte auf den RTB-Nord-Treffen.– Olbrich, S.: Seminar „Videoverfilmung im Netz“ für Nutzer im RTB Nord, 24.03.1994,

RRZN, Universität Hannover.– Olbrich, S.: „Videoverfilmung im Netz“, DFN-Arbeitskreis „Visualisierung und Simula-

tion“, 22.09.95, RRZN, Universität Hannover.– Olbrich, S.: Seminar „Videoverfilmung im Netz – Multimedia und Visualisierung“,

Rechenzentrum der Technischen Universität Hamburg-Harburg, 17.10.1995.(http://www.tu-harburg.de/rzt/rzinfo/info4_95/node6.html)

– Olbrich, S.: „Videofilm-Produktion über den ‚Data Highway‘“, AVS/UNIRAS User‘s Mee-ting, 22.03.1995, Neuss.

– Olbrich, S.: „RTB Nord: P1 – Videoverfilmung im Netz“, 1. Treffen des DFN-Arbeitskrei-ses „Informationsdienste“ im Rahmen des HDN-Symposiums, 06.12.1995, Berlin.(http://www.rtb-nord.uni-hannover.de/veroeffentlichungen/HDN-Symposium.html)

• Veröffentlichungen

– Olbrich, S., Pralle, H.: „Verfilmung von Multimediadaten in einem verteilten System“. In:it+ti – Informationstechnik und Technische Informatik, 1/97.(Manuskript: http://www.rtb-nord.uni-hannover.de/veroeffentlichungen/it-ti-0197/)

– Olbrich, S., Pralle, H.: „Videoverfilmung im Netz“, DFN-Mitteilungen 37, März 1995.(http://www.rtb-nord.uni-hannover.de/dfn/mitteilungen/html/heft37/R7/R7.html)

– RRZN: „Online-Preview für die RRZN-Videoproduktion“. In: RRZN-BenutzerinformationBI 293, 12.07.1996.(http://www.rrzn.uni-hannover.de/BIs/Jahrgang96/BI293/bi293-9.html)

– RRZN: „ShowSeq Echtzeit-Animation im AVS-Frame-Sequence-Format“. In: RRZN-Benutzerinformation BI 293, 12.07.1996.(http://www.rrzn.uni-hannover.de/BIs/Jahrgang96/BI293/bi293-10.html)

• CeBIT-Exponate

– CeBIT 1995, RRZN/RVS-Präsentation auf dem Gemeinschaftsstand der NiedersächsischenHochschulen: „Video-Produktion über den ‚Data Highway‘“.

– CeBIT 1996, RRZN/RVS-Präsentation auf dem Stand des DFN-Vereins:„Videoproduktion im Netz“.

• DFN-Arbeitskreis

– Das Sprecheramt des am 06.12.1995 in Berlin initiierten DFN-Arbeitskreises „Informati-onsdienste“ wurde von einem Projektmitarbeiter übernommen.



3.5 Nutzung existierender Basisdienste und Software-ToolsEs wurden u. a. folgende Komponenten eingesetzt:

• Basisdienste

– Email– Lpr/lpd (Client/Server)– WWW (Client/Server)

• Public-Domain-Software

– Aladdin Ghostscript– Berkeley-MPEG-Encoder– ImageMagick– Netpbm-Tools– Sam Leffler‘s TIFF-Tools– SDSC Image Tools– sox

• Kommerzielle Software

– Steuerungssoftware zum DVS Pronto (Digitale Realtime-Videodisk):Bibliotheken und Kommandozeilen-Tools

• RRZN/RVS-Entwicklungen

– Videoproduktions-Serversoftware (Videoaufzeichnung, Videopreview; siehe auchKap. 4.2)– cgm2ppm (Konverter von CGM-Binär- oder Klartextformat nach PPM)– ppm2ccc (Konverter von PPM-Format in das Color-Cell-komprimierte AVS-Frame-

Sequence-Format)– ShowSeq (Previewer für Rasterbild-Sequenzen im AVS-Frame-Sequence-Format; siehe

auchKap. 4.3)


Ergebnisse des Projektes 8

4 Ergebnisse des Projektes

4.1 Nutzung des Videoaufzeichungsdienstes

In Tabelle 1 sind die Namen – d. h. Internet-Adressen – der Rechner aufgelistet, die den Videoverfil-mungsdienst bis Ende 1996 genutzt haben. Daneben ist die jeweilige Anzahl der Aufträge aufgeführt.

Auf den anschließend dargestellten Diagrammen (Bild 3 bisBild 10) sind die charakteristischen Datenaus allen Verfilmungsaufträgen der vergangenen Jahre bis Oktober 1996 ausgewertet worden.

Als extern werden dabei Auftraggeber (Rechner) bezeichnet, welche sich örtlich außerhalb der Uni-versität Hannover befinden. Eine Besonderheit stellt der in Brauschweig installierte Rechnersaen-ger.strm-bs.uni-hannover.de dar. Dieser ist aus Performance-Gründen innerhalb der hannoverschenDomainuni-hannover.de konfiguriert worden.

Tabelle 1: Namen der externen Auftraggeber (Internet-Adressen) und jeweilige Jobanzahl

Hostname Jobanzahl

avalon.ZIB-Berlin.DE 4

aventurin-fddi.ZIB-Berlin.DE 2

aventurin.ZIB-Berlin.DE 1

conny.rz.tu-harburg.de 2

dvsun1.GKSS.DE 1

dvsun2.GKSS.DE 1

edvs11.AWI-Bremerhaven.DE 13

edvsg1.AWI-Bremerhaven.DE 5

gandalf.sc.cs.tu-bs.de 1

grafs21.ZIB-Berlin.DE 17

gwdp98.gwdg.de 4

gwdu22.gwdg.de 1

hubble.strm.ing.tu-bs.de 3

ifsaix8.schiffbau.uni-hamburg.de 68

ifsaix9.schiffbau.uni-hamburg.de 9

laurel.dkrz.de 1

mufus.rz.tu-harburg.de 1

pbsun9.GKSS.DE 7

pfsun1.GKSS.DE 6

saenger.strm-bs.uni-hannover.de 46

saenger.strm.ing.tu-bs.de 17

sun0.rz.fh-wolfenbuettel.de 4

ufer.ZIB-Berlin.DE 4

wmgi01.gkss.de 4



1/90

2/90

1/91

2/91

1/92

2/92

1/93

2/93

1/94

2/94

1/95

2/95

1/96

2/96

0

10

20

30

40D

aten

volu

men

[in

GB

ytes

]

CGMBINGROUTPSYUVCCIR601SEQCGMCLTRLAHAPS

Formate

Stand: 10/96

Durchschnitt:ca. 16 GB/Halbjahr

Datenvolumen pro Halbjahr

Bild 3: Datenvolumina je Halbjahr, aufgeteilt nach Dateiformaten

1/90

2/90

1/91

2/91

1/92

2/92

1/93

2/93

1/94

2/94

1/95

2/95

1/96

2/96

0

500

1000

Anz

ahl A

uftr

äge

CGMBINGROUTPSYUVCCIR601SEQCGMCLTRLAHAPS

Formate

Stand: 10/96

Durchschnitt:ca. 400 Auftr./Halbjahr

Bearbeitete Aufträge (pro Halbjahr)

Bild 4: Auftragsanzahl je Halbjahr, aufgeteilt nach Dateiformaten



CGMBIN CGMCLT GROUT HAPS PS RLA SEQ YUVDatenformat

0

50

100

150

200

Jobg

röß

e [in

MB

]

0.0

0.5

1.0

1.5

Max

imal

e J

obgr

öße

[in G

B]

Durchschnittliches Jobvolumen

Bild 5: Durchschnittliche Datenvolumina je Job bei verschiedenen Dateiformaten

CGMBIN CGMCLT HAPS RLA SEQ YUVDatenformat

0

100

200

durc

hsch

nittl

. Anz

ahl

0

5

10

15

Max

. Anz

ahl [

in T

aus

end]

Durchschnittliche Frame-Anzahl (je Job)

Bild 6: Durchschnittliche Frame-Anzahl je Job



500 1000

Anzahl Frames

-2

0

2

4

Fra

mea

nzah

l dur

ch K

lass

enbr

eite

(lo

g10)

Häufigkeit der Anzahl Frames pro Job

Bild 7: Häufigkeitsverteilung der Jobgröße (Frame-Anzahl je Job, Ausschnitt bis 1500)

50 100 150 200 250

Anzahl Frames

5

10

15

20

25

Fra

mea

nzah

l dur

ch K

lass

enbr

eite

Häufigkeit der Anzahl Frames pro Job

Bild 8: Häufigkeitsverteilung der Jobgröße (Frame-Anzahl je Job, Ausschnitt bis 300)



2 3 4 5 6 7 8 9

Jobgröße [in Bytes, log10])

0

100

200

300

Anz

ahl A

ufträ

ge

1 MB 1 GB

Häufigkeit verschieden großer Jobs

Bild 9: Häufigkeitsverteilung der Jobgröße (Datenvolumen je Job)

2/92 1/93 2/93 1/94 2/94 1/95 2/95 1/96 2/96

Halbjahr

100

200

300

400

Film

län

ge

in

Min

Intern

Extern

Auftraggeber

Erzeugte Filmlänge

Bild 10: Gesamte erzeugte Filmlänge je Halbjahr



4.2 Video-Preview – Online-Publishing von Videos „On Demand“Im Rahmen einer am RRZN/RVS betreuten Studienarbeit zum Thema „Realisierung einer ‚Online-Preview‘-Komponente für die Videoproduktion in Breitbandnetzen“1 ist eine neue Dienstleistung ent-standen, die seit Anfang des Jahres 1996 – zunächst im Testbetrieb – produziert. Analog zu dem bishe-rigen Verfahren verschickt der Anwender von seinem Arbeitsplatzrechner einen Video-Produktionsauftrag. Dieser besteht aus einer Steuerdatei sowie einer oder mehreren Bild- und Ton-Dateien, die mittels BSD-Druckprotokoll – basierend auf TCP/IP – an den RTB-Videoproduktionsser-ver (video.rrzn.uni-hannover.de ) übermittelt werden.

Neben der bislang unterstützten Warteschlange „video “, über die auch weiterhin Videocassetten derTypen VHS, S-VHS und Betacam-SP erzeugt werden, ist eine neue namens „video_preview “ ein-gerichtet worden. Werden Aufträge an diese Queue übergeben, so generiert der Videoserver aus denBilddaten einen digitalen Videofilm im MPEG-1-Format (ISO-Standard). Dieser wird nach Beendi-gung des Produktionsvorgangs auf einem integrierten WWW-Server2 angeboten. Mittels WWW-Browser (z. B. Netscape) und MPEG-Plugin (oder externem Player) können auf diese Weise produ-zierte Videos dann jederzeit weltweit im Internet präsentiert werden.

4.3 ShowSeq – Preview-Komponente für den lokalen BetriebEs wurde ein Viewer entwickelt, mit dem auf UNIX-Workstations Animationen, die im DateiformatAVS-Frame-Sequencevorliegen, auf einem X-Display in Echtzeit präsentiert werden können:Show-Seq. Die auf hohe Effizienz und Portabilität ausgelegte Implementierung erfolgte in C, die graphischeNutzeroberfläche setzt auf X-Windows und OSF/Motif auf (siehe auchBild 12). Durch die Anwen-

1. http://www.rvs.uni-hannover.de/arbeiten/studien/sa-reinhorn.html2. http://video.rrzn.uni-hannover.de/preview/mpegs/

lprlpd

WWW-Server

MM Storage

DocServ

(Verteilte) ServerstrukturAuftraggeber

Netscape

Local Copy

Viewerz. B.:

mpeg_play

DocShow

Nutzer

httpd

WWW-Browser

Erweiterungsmöglichkeit: Spezial-Client/Server

Bild 11: Video-Preview-Szenario: Online-Publishing „On Demand“

+Convert



dung der Shared-Memory-Extension des X-Protokolls bzw. den Einsatz der Silicon-Graphics-GL-Gra-phikschnittstellen wird erreicht, daß die Bildsequenzen – je nach Plattform – auf die jeweils optimaleWeise auf dem jeweiligen Bildschirm dargestellt werden.

Zur Generierung vonAVS-Frame-Sequence-Animationen dient ursprünglich das AVS-Ausgabe-Modulwrite frame sequence. Dieses ist Bestandteil des VisualisierungsproduktsAVS Animator. Um einebatch- bzw. script-basierte Generierung aus anderen vorhandenen Bildformaten zu ermöglichen,wurde zusätzlich der Konverterppm2ccc entwickelt, der das verbreitete PPM-Format (PortablePixmap, aus dem Netpbm- bzw. Pbmplus-Toolkit) in die Color-Cell-Compression-Variante des AVS-Frame-Sequence-Formats überführt. Damit können automatische Prozeßketten aufgebaut werden, dieeine Erzeugung aus nahezu beliebigem Bildmaterial ermöglichen, z. B. aus CGM (ISO 8632, Compu-ter Graphics Metafile) über den RRZN/RVS-Konvertercgm2ppm.

Eine Color-Cell-komprimierte AVS-Anima-tion mit einer Auflösung von 640x480 Pixelkann – bedingt durch den geringen Rechen-aufwand bei der Decodierung – auf aktuellenRechnern mit mehr als 25 Bildern/Sekunde –entsprechend einer Datenrate von 15,6 Mbit/s(ca. 2 bit/pixel) – abgespielt werden. Diesentspricht etwa den Randbedingungen desFernsehstandards, so daß hiermit ein Werk-zeug fürVideo-Preview am Arbeitsplatzrech-ner zur Verfügung steht. Dagegen bietenMPEG-basierte Verfahren schlechtere Bild-qualität bezüglich der Auflösung und desAuftretens von Artefakten bzw. Bewegungs-unschärfen (siehe auchTabelle 2). Erst wennDekompressionshardware zum Einsatz derar-tiger Verfahren auch für höhrere Auflösungenzur Standardausstattung von Arbeitsplatz-rechnern gehört, können sich diese für dietechnisch-wissenschaftlichen Ergebnisprä-sentation durchsetzen.

Bild 12: Rasterisierte CGM-Datei (Strömungssimu-lation, Institut für Meteorologie und Klimatologie)

Die beiden weiteren – im Gegensatz zur Color-Cell-Compression verlustlosen – CodierungsvariantendesAVS-Frame-Sequence-Formates –No Compression bzw.Runlength Compression – können eben-falls mit ShowSeq dargestellt werden. Aufgrund der dabei erforderlichen relativ hohen Datenvoluminabzw. Rechenaufwände werden dabei jedoch bei weitem nicht die o. g. Bildraten erzielt. In jedem FallsorgtShowSeq dafür, daß ggf. Bilder übersprungen werden, um im Mittel das angeforderte Zeitrastereinzuhalten. Die zeitliche Spezifikation erfolgt entweder über die Vorgabe einer konstanten Bildrateoder über eine einfache Scriptdatei, mit Hilfe derer z. B. Standbilder, Zeitlupen und Zeitraffersequenzweise definiert werden können.

Optional werden vonShowSeq auch Audio-Daten im Raw-Format synchron abgespielt. Die Erstellungvon Audio-Raw-Dateien kann z. B. mitsox – einem Public-Domain-Audio-Konverter – erfolgen.

Wird die Aufzeichnung einer solchen Animation auf Video-Cassette (VHS, S-VHS oder Betacam-SP)gewünscht, so kann die AVS-Frame-Sequence-Datei, neben weiteren Bildformaten, wie z. B. Post-Script, CGM, Abekas-YUV, Wavefront-RLA, direkt an den Videoproduktionsdienst des RRZN/RVSversandt werden. Auch Vertonungsaufträge werden vom RRZN/RVS-Videoserver unterstützt – dabeiwerden alle Audio-Formate akzeptiert, die auch mitsox verarbeitet werden können.

In der folgendenTabelle 2 sind die Vor- und Nachteile der Verfahren MPEG-1 und Color Cell Com-pression (CCC) für zwei verschiedene Szenarien anschaulich gegenübergestellt.



a. Digitalisierte Betacam-Aufzeichnung vom 18. März 1996.b. Rasterisierte CGM-Bilddaten (Institut für Meteorologie und Klimatologie, Universität Hannover).

Tabelle 2: Vergleich: MPEG-1 / Color Cell Compression (CCC)

Szenario 1: B-WiN-Eröffnung a Szenario 2: Strömungsvisualisierung b

MP

EG

-1 (

320x

240)

, 2fa

ch-Z

oom

CC

C (

320x

240)

, 2fa

ch-Z

oom

Col

or C

ell C

ompr

essi

on (

640x

480)


Zusammenfassung und Ausblick 16

5 Zusammenfassung und Ausblick

Das RTB-Nord-Projekt „P1 – Videoverfilmung im Netz“ hatte zum Ziel, den am RRZN/RVS primärfür die Universität Hannover etablierten Regeldienst für weitere Anwender im Weitverkehrsnetz anzu-bieten, die Nutzung zu unterstützen und zu optimieren. Die Auftragsabgabe erfolgt dabei über Netzdurch Übermittlung von Steuer-, Bild- und Ton-Dateien mittels TCP/IP-basiertem lpr-Protokoll, d. h.analog zum entfernten Drucken.

Zunächst wurden die vorhandenen Geräte – „Videoserver“, bestehend aus einer Workstation, einemdigitalen Realtime-Videodisk sowie mehreren hochwertigen Videorecordern – verwendet. Im Verlaufdes Projektes wurde eine neue Konfiguration geplant, beschafft, installiert und schließlich erfolgreichin Betrieb genommen. Durch das allgemein anwendbare Betriebskonzept der RRZN/RVS-Videopro-duktionsanlage war eine Portierung auf die hier benötigten neuen Rechner- und Videogeräte-Plattfor-men ohne größere Schwierigkeiten möglich.

Bedingt durch die höhere Leistungsfähigkeit der Komponenten – z. B. von Sun Sparc 10/30 auf SunSparc 20/612 (2 Prozessoren) – sowie verbesserter Kommunikationseigenschaften – z. B. von SCSI-1(Peak-rate: 5 MByte/s) zwischen Sun und Digital-Videodisk (Abekas A60 bzw. DVS Pronto) auf Fast/Wide-SCSI (20 MByte/s) – und breitbandiger Datennetz-Einbindung – von 10 Mbit/s Ethernet auf155 Mbit/s ATM – konnte die Videoproduktion um den Faktor 3–5 beschleunigt werden.

Die Nutzung durch Anwender aus dem Bereich des RTB Nord war geringer als die Schätzungen, vondenen bei Planung und Spezifikation des Projektes ausgegangen wurde. Auch mehrfache Versuche,dieses – für den Nutzer unentgeltliche – Angebot bekanntzumachen, konnten diese Situation nicht ver-bessern. Die Nutzer, welche den Dienst in Anspruch nahmen, erzielten jedoch im wesentlichen ohnegroßen Aufwand hochwertige Ergebnisse. Wie inKap. 4.1 gezeigt wurde, trugen „externe“ Anwendersignifikant zum Gesamtdurchsatz – z. B. insgesamt produzierte Filmlänge – bei.

Der grundsätzliche Nachteil der ursprünglichen Betriebsweise, daß der Postweg beim Einsatz imWeitverkehrsbereich den überwiegenden Anteil zur Turnaround-Zeit beiträgt, konnte durch einigeVerbesserungen zum Teil beseitigt werden. Dazu zählen verschiedene Status-Anzeigen1, ein netz-ori-entierter „Video-Preview“-Service – statt einer Videocassette wird hier wahlweise eine digitale Reprä-sentation im MPEG-1-Format erzeugt und auf einem integrierten WWW-Server bereitgestellt2 – sowieWerkzeuge für lokales Preview – mit Hilfe des Viewers „ShowSeq“ – am Arbeitsplatzrechner.

Insgesamt kann gesagt werden, daß das Betriebskonzept – i. w. aus dem Jahre 1990 – weiterhin denAnforderungen entspricht. Im langjährigen Mittel werden ca. 800 Produktionsaufträge pro Jahr bear-beitet. Die Ergebnisse dienen häufig dem Erkenntnisgewinn in Forschung und Entwicklung sowie alsRohmaterial für die Präsentation gegenüber der interessierten Öffentlichkeit. Seitdem Anfang 1996Online-Erweiterungen eingeführt wurden, wird die Produktion von Videocassetten nicht mehr injedem Fall in Auftrag gegeben. Neben der dadurch erzielten Optimierung eröffnet sich hier die Mög-lichkeit einer eigenständigen automatisierten Produktionsmethode für Online-Videos, d. h.Online-Publishing On Demand.

Der Dienst wird als Standard-Dienstleistung im Produktionsbetrieb des RRZN angeboten und kann imB-WiN genutzt werden.

Zukünftig wünschenswert wären Erweiterungen

• zur Online-Präsentation von vertonten Videos „on the fly“, d. h. mit Hilfe von „streamed conti-nuous media“-Diensten auf der Basis skalierbarer Verfahren bis hin zur qualitativ hochwertigenunkomprimierten Übertragung sowie

• zur Anbindung von Datenbank- und Archiv-Systemen mit dem Ziel der Entwicklung eines gene-rellen Videoproduktions-, Retrieval- und Delivery-Dienstes.

1. Siehe http://video.rrzn.uni-hannover.de/status/2. Siehe http://video.rrzn.uni-hannover.de/preview/mpegs/

RTB Nord – P1: „Videoverﬁlmung im Netz“

Documents

Transcript of RTB Nord – P1: „Videoverﬁlmung im Netz“