Mit dem Regensburger Marathon-Cluster durch's Ziel
Rechenaufgaben des Clusters
Hubert Feyrer, Mai 2001

Rechenaufgaben des Clusters

Die eigentliche Rechenaufgabe des Regensburger Marathon-Clusters bestand aus zwei Schritten:
  1. Aufsplitten der MPEG-Sequenzen in Einzelbilder
  2. Zusammenfügen der Einzelbilder zu einem Zieldurchlauf-Film im MPEG-Format
Image: (click to enlarge!)


Neben ein paar Vorbereitungs- und Zwischenschritten bestand die eigentliche Aufgabe des Marathon-Clusters aus zwei Schritten

Vorarbeiten zum Rechenjob

Am Zieleinlauf standen zwei Videokameras des Regionalsenders TVA und zeichneten den Zieleinlauf auf. Wenn das Band (90min) der ersten Kamera zu Ende ging schaltete sich die zweite Kamera ein, mit einem Overlap von ca. 5 Minuten. Dies ergab 5 Stunden Bildmaterial im Sony Betacam Format.

Die insgesamt 4 Videobänder wurden anschliessend mittels eines Sony Betacam MAZ Gerätes und eines unter Windows 98 laufenden PCs mit einer Hauppage PVR mit Hardware MPEG Encoder Karte in einzelne MPEG-Sequenzen zerlegt. Jede Sequenz bestand aus 11 Minuten Filmmaterial bei 25 Frames pro Sekunde, einer Bildauflösung von 352x288 und einer Farbtiefe von 24 Bit, was zu einer durchschnittlichen Datenmenge von ca. 110 MB führte. Die einzelnen Sequenzen wurden dann mit FTP auf einem via 100MBit und Crossconnect-Kabel angeschlossenen Rechner unter RedHat Linux 7.1 übertragen. Dort wurden die einzelnen Sequenzen mit mkisofs und cdrecord auf jeweils eine eigene CD gebrannt.

Schritt 1: Aufsplitten der Sequenzen

Für das Zerlegen der Sequenzen wurden die schnellen 1GHz Maschinen der FH gewählt. Nach dem einlegen der CD mit einer Sequenz wurde diese mit Hilfe des Scripts "create_dir.pl" in Einzelbilder zerlegt, die auf dem zentralen NFS-Server gespeichert wurden. Die 11 Minuten MPEG-Video einer Sequenz wurden mit Hilfe des Programms "dumpmpeg" in ca. 45 Minuten in jeweils ca. 16500 Einzelbilder im JPEG-Format zerlegt. Jedes Einzelbild war dabei ca. 24KB gross, was pro Sequenz zu ca. 400MB an Einzelbild-Daten führte.

Das vom Script "create_dir.pl" aufgerufene Programm "dumpmpeg" wurde für den Marathon-Cluster modifiziert, da es in seiner ursprünglichen Form nur Bilder im BMP-Format erzeugt, was jedoch zu zu grossen Einzelbildern geführt hätte, und darüberhinaus von der Software des zweiten Schritts nicht gelesen werden kann. Deshalb wurde der Quellcode des Open-Source Programms dumpmpeg so modifiziert, dass es nach dem Abspeichern von jeweils 250 Bildern (10 Sekunden Film) diese mittels der netpbm Tools von BMP nach JPEG konvertierte. Die Konvertierung durch die netpbm-Tools ist zeitaufwendig, jedoch standen dem auf den SDL- und smpeg-Bibliotheken basierte dumpmpeg keine Routinen zur Verfügung, die ein direktes Abspeichern als JPEG erlaubt hätten. Ein Wegoptimieren der fork()- und exec()-Aufrufe durch Code aus den netpbm-Tools viel leider dem Zeitdruck zum Opfer.

Die zweite Veränderung an dumpmpeg stellte das Verzeichnis dar, in dem das Programm die erzeugten Bilder ablegte. Anstatt alle Bild in einem Verzeichnis abzulegen wurde für jeweils 250 Bilder ein eigenes Verzeichnis angelegt, was die Zugriffszeiten noch verbesserte.

Zwischenschritt: Bilddaten in Bild-Datenbank eingeben

Für die weitere Berechnung im zweiten Schritt wird für jede Sequenz die genaue Start- und Endzeit benötigt, und die jeweil zugehörigen Dateinamen des ersten und letzten JPEG-Bildes. Diese Daten werden in einer Mysql-Datenbank auf dem Job Control Rechner abgelegt. Weiterhin wird aus diesen Daten die wirkliche Bildrate ermittelt, da z.B. durch Schwankungen der Bildrate in Folge von Wärme das MAZ-Gerät nicht konstant 25 Bilder liefert. Eine leichte Varianz könnte sich hier im Verlauf von 5 Stunden Filmmaterial erheblich aufschaukeln und zu unbrauchbaren Resultaten führen, wenn später die exakten Bilddaten einer bestimmten Zeit benötigt werden.

Schritt 2: Erzeugen der Einlauf-Videos

Nachdem im ersten Schritt alle Bilder aller Sequenzen als Einzelbilder auf dem NFS-Server abgespeichert wurden, werden sie nun zu einzelnen kleinen Filmen vereint. Ziel ist, dass jeder Läufer anhand seiner Startnummer seinen persönlichen Durchlauf durch's Ziel ansehen kann, und - durch den Marathon-Cluster vorab berechnet - jeder Läufer ein eigenes MPEG bekommt. Von den gestarteten knapp 7000 Läufern gingen insgesamt ca. 5500 durch's Ziel. Es existierten drei Diszipline: Marathon (42km), Halbmarathon (21km) sowie Speedskating (21km), und es wurden getrennt für Herren und Damen Ergebnislisten mit der Zieldurchlaufzeit geführt. Ausgehend von dieser Zieldurchlaufzeit und dem zugehörigen Bild wird dann zwei Sekunden zum letzten Bild des Films vorgegangen, und ab diesem dann rückwärts 150 Bilder in ein temporäres Arbeitsverzeichnis kopiert. Die 150 Bilder stehen hier für 6 Sekunden a 25 Bilder.


Ausgehend von der Zieldurchlaufzeit werden die Bilder des Zielvideos ermittelt

Abschliessend kommen noch sechs Frames mit gleichem Inhalt, die ebenfalls in das Arbeitsverzeichnis kopiert werden. In eine vorgefertigten Maske mit den Logos der Sponsoren der Zieleinlaufsvideos wird mit Hilfe des Programms "convert" (Teil von ImageMagick) der Name des jeweiligen Läufers, seine Startnummer, die Zeit, Plazierung und die Disziplin geschrieben, damit diese am Ende des Zieleinlaufsfilms angezeigt werden.


Maske für den Abspann mit und ohne Daten

Neben dem Zieleinlauf-Film wurde zusätzlich noch das Bild des exakten Zieleinlaufs gesichert, und wiederum mittels "convert" Name des Läufers, Zeit, Plazierung und Disziplin eingetragen.


Beispiel Zielfoto

Das Zusammenrechnen des Films aus den einzelnen Bildern im temporären Verzeichnis wurde mit dem Programm mpeg_encode gemacht. Durch eine Parameterdatei wurde festgelegt wo das temporaere Verzeichnis war, welche Bilder daraus zu einem Film zusammengerechnet, und welche Client-Rechner diese Aufgabe übernehmen sollten. mpeg_encode startete dann auf jedem Client eine Berechnung für ein paar Bilder, um die Geschwindigkeit der einzelnen Knoten abschätzen zu können. Anschließend wurden dann die verbleibenden Bilder entsprechend auf die einzelnen Konten verteilt, die die Bilder dann via NFS lasen und die berechneten Teilfilme auch via NFS wieder an den Haupt-Prozess zurücklieferten, der die Teile dann vereinigte und das Ergebnis als eine MPEG-Datei ablegte. All dies führt das frei verfügbare Programm ohne jegliches Zutun automatisch aus, so dass hier sehr viel manuelle Arbeit (und mögliche Fehler) verhindert werden.

Die von mpeg_encode verwendete Parameterdatei lag für jeden der vier Subcluster vor, so dass die Ergebnisliste jeder Disziplin auf jedem Subcluster berechnet werden konnte - je nachdem wo gerade Rechenzeit frei war. Das Job-Scheduling wurde hier per Hand gemacht. Insgesamt existierten sechs Diszipline:

Marathon-Damen: 148 Finisher
Marathon-Herren: 1268 Finisher
Halbmarathon-Damen: 893 Finisher
Halbmarathon-Herren: 2469 Finisher
Speedskating-Damen: 202 Finisher
Speedskating-Herren: 521 Finisher

Die Ergebnislisten pro Disziplin lagen als CSV-Dateien vor, die durch ein perl-Script in ASCII-Dateien zerlegt wurden. Diese dienten dann wiederum dem perl-Script "mpeg250_pic.pl" als Eingabedatei. Für jeden Läufer wurden aus der Eingabedatei Name, Plazierung und v.a. die Zielzeit bekannt. Mit Hilfe der Bild-Datenbank war dann berechnet, innerhalb welcher Sequenz der Läufer lag, und es konnte das zugehörige Bild zum Zieldurchlauf errechnet werden. Dieses wiederum diente als Referenzpunkt für die 150 Bilder des Zieldurchlauf-Films, wie oben beschrieben. Nachdem die Bilder mitsamt des Abspanns im temporären Arbeitsverzeichnis abgelegt waren waren dann die Rechner des jeweiligen Clusters mit der Berechnung des MPEGs gefordert, und der Zielfilm wurde anschliessend zusammen mit dem Zielfoto in einem eigenen Verzeichnis Archiviert.

Image: (click to enlarge!)


Vom Job Control Rechner aus wurden die Subcluster mit den zu berechnenden Bildsequenzen versorgt, die auf dem NFS Server abgelegt waren.

Das von "mpeg250_pic.pl" gestarteten mpeg_encode startete die Jobs auf den einzelnen (Sub)Cluster-Rechnern via rsh, um hier eine aufwendige Authentifizierung via ssh zu umgehen. Da das Zusammenrechnen eines einzelnen MPEGs zwischen 3 und 8 Sekunden dauerte wäre der Overhead der SSH-Authentifizierung, der in der Grössenordnung von ca. 2 Sekunden lag, zu sehr ins Gewicht gefallen, ohne irgend einen Vorteil zu bringen.

Abschliessend hier zwei Beispiel-Videos: Marathon Damen, Marathon Herren.

>>> Erfahrungen


Copyright (c) 2001 Hubert Feyrer