Ende Februar haben wir tatsächlich angefangen, uns Gedanken über Speed-Dating mittels Webcam zu machen. Vor allem mussten wir entscheiden, auf welcher technischen Grundlage wir die Sache aufziehen wollten. Die erste Idee war natürlich Flash. Damit kann man relativ einfach und in sehr kurzer Zeit eine Video-Lösung zusammenschustern. Man sollte sich nur über die Folgen, nämlich die spätere Skalierung und die damit verbundenen Kosten, im Klaren sein. Damit meine ich noch nicht einmal die Kosten für die Flash-Server, denn dafür gibt es z.B. mit red5 oder AVChat günstige und brauchbare Alternativen. Das eigentliche Problem sind die Kosten für den Serverpark und vor allem für die Bandbreite bzw. für den Traffic.

Bei einer Lösung auf Basis von Flash laufen schließlich alle Videostreams über unsere Maschinen, d.h. bei vielen gleichzeitigen Sessions müssen wir für entsprechende Skalierung auf mehrere Server sorgen. Außerdem müssen wir die entsprechende Bandbreite bzw. das Transfervolumen bezahlen, und das ist beim Streamen von Videosessions nicht gerade gering. Aufgrund der recht niedrigen Anforderungen bei der Umsetzung war Flash schon sehr attraktiv, doch die Skalierungs- und Kostenproblematik hat letztendlich den Ausschlag gegeben, denn weder wir noch ein potentieller Investor wollen unnötig Geld verpulvern. Eine andere Lösung musste also her.

Wenn man die Video- und Audio-Sessions nicht über einen eigenen Serverpark abwickeln will, bleibt als Alternative nur noch eine Direktverbindung zwischen den Teilnehmern nach dem Vorbild von Skype^TM oder diverser Online-Games übrig. Das ist technisch deutlich aufwendiger als Flash, denn

• man benötigt ein eigenes Programm, das auf die Webcam zugreifen kann und den Datenstrom z.B. in Form eines RTP-Streams verschicken kann
• das Programm muss auch den Datenstrom von der Gegenseite empfangen und wiedergeben können
• die Anwendung muss sich in Form eines Plugins in einer HTML-Seite einbinden lassen
• das Programm sollte zumindest mit einem Großteil der NAT und Firewalls zurecht kommen
• die Entwicklung der ersten Version soll nicht Jahre dauern

Am elegantesten wären native Plugins für die diversen Browser unter Windows, Mac und Linux. Verworfen haben wir die Lösung zwar nicht, doch aus Zeitgründen auf später verschoben. Stattdessen haben wir uns zuerst für Suns Java Media Framework (JMF) entschieden, um damit ein Streaming-Applet zu entwickeln. Auch wenn die JMF-API schon seit einigen Jahren nicht mehr aktualisiert wurde und das Framework häufig als zu kompliziert kritisiert wird, verliefen die ersten Tests recht positiv. Außerdem gab es noch einen Pluspunkt für JMF, nämlich die Verwandschaft mit der Mobile Media API (MMAPI) der Java 2 Micro Edition. Viele JMF-Ideen sind in die MMAPI eingeflossen, d.h. sollte unsere Video-Lösung mit JMF funktionieren, wäre eine Portierung auf mobile Endgeräte durchaus denkbar.