Llkdu, Emkdu und OpenJPEG oder: was ist was und wozu braucht man es?

In allen Diskussionen um den Emerald-Client wird auch immer wieder über die Emkdu.dll diskutiert, viele wissen nicht wirklich, wozu diese gebraucht wird noch was sich hinter diesen verschiedenen Begrifflichkeiten wie OpenJPEG und Llkdu verbirgt. Ich will hier einmal das Knäuel ein wenig aufdröseln.

Die Basis von allem: JPEG2000.

Second Life basiert auf 3D-Objekten, die mit Texturen beliebigen Inhalts überzogen werden können. Da diese Texturen viel Bandbreite bei der Übertragung und auf Seiten Linden Labs dauerhaft Speicherplatz benötigen, war beim Design von Second Life eines der Ziele gewesen, einen Standard zu wählen, der möglichst viel Information bei möglichst wenig Speicherbedarf abbilden kann.

Man kennt diese Problematik bereits aus dem WWW, dort ist JPEG das verbreitetste Kodierungsverfahren für Bilder aller Art. Wichtig dabei ist, dass JPEG Bilder verlustbehaftet komprimiert, das bedeutet, es gehen je nach Qualität mehr oder weniger gut sichtbar Informationen verloren. JPEG basiert dabei auf verschiedenen Kodierungsschritten, wobei das Herz ein aus der Mathematik bekanntes Verfahren namens diskrete Cosinus-Transformation darstellt

Nun entstand JPEG aber im Jahr 1992 und seitdem blieb die Welt nicht stehen, im Laufe der Zeit entstanden bessere Verfahren als dieses. Bei der Konzeptionierung von Second Life entschied man sich für JPEG2000 als den Standard aller Bilder. JPEG2000 ist jünger als JPEG, damit technisch weiter und komprimiert Bilder besser. JPEG2000 ist rechenintensiver im Vergleich zu JPEG und basiert auf dem Verfahren der diskreten Wavelet-Transformation, zudem ist es teilweise von Softwarepatenten geschützt.

Kurz: alle Bilder, die wir in Second Life sehen, basieren auf dem Bildstandard JPEG2000. Da dieser sich bisher bis auf einige Nischenbereiche kaum durchgesetzt hat, muss der Viewer die benötigten Grundfunktionen zum De- und Kodieren dieses Standards selber mitbringen. Dies geschieht mit Hilfe einer Programmbibliothek, die die dazu benötiigten Funktionen bereitstellt.

Auftritt: OpenJPEG!

OpenJPEG ist eine Opensource-Implementierung des JPEG2000-Standards, die unter der BSD-Lizenz steht. OpenJPEG ist dabei solide programmiert, aber was die Kodierungs- und Dekodierungsgeschwindigkeit anbelangt die langsamste Variante. Dafür ist die Benutzung von OpenJPEG kostenlos und damit ist es die Standardbibliothek aller alternativen Viewer, die diese zur Darstellung von Texturen benutzen. Der Vollständigkeit halber sei erwähnt, dass es mit JasPer noch eine weitere OSS-Implementierung des Standards gibt, die im Viewer aber nie Verwendung fand.

Schneller: LLkdu!

Die industriell genutzte Standardimplementierung in C++ von JPEG2000 stammt aus dem wenig bekannten Softwarehaus Kakadu Software. Der Autor ist dabei einer der Urheber dieses Standards. KDU im Dateinamen ist dabei nichts anderes als die Abkürzung für „Kakadu“ und LL steht für Linden Lab.

Diese Implementierung des JPEG2000-Standards ist dabei um Längen schneller arbeitend als OpenJPEG, dafür aber kein Opensource und zum Einsatz in Software ist eine saftige Lizenzgebühr fällig. Linden Lab liefert seinen Viewer standardmäßig mit Kakadu als Bibliothek aus, und das Ergebnis macht sich in spürbar schnelleren Ladezeiten der Texturen bemerkbar.

Noch schneller: Emkdu!

Einer der Entwickler von Emerald, Phox Modularsystems, lizenzierte bei Kakadu ebenfalls deren Bibliothek in einer neueren Variante als Linden Lab das tat und baute darum seine eigene Variante namens Emkdu.dll. Die Lizenz zur nicht kommerziellen Nutzung der Bibliothek kostet dabei im Jahr 250 US$, und es machte sich in einer nochmals leicht schnelleren Geschwindigkeit beim Laden der Texturen bemerkbar.

Er baute in die Bibliothek dann auch eine Funktion ein, die den Dateipfad samt Windows-Titel vom Emerald-Viewer in den Metadaten der Avatartextur versteckten, das ist inzwischen nicht mehr der Fall, aber war auch der Anstoß für viel Kritik.

Fazit

Emerald funktioniert bisher mit Emkdu, Llkdu und OpenJPEG, ansonsten jeder Viewer zumindest mit Llkdu oder OpenJPEG. Die Bibliotheken sind dabei beliebig austauschbar; wer z.B. im Verzeichnis von Emerald die emkdu.dll löscht und den Viewer neu startet, dann nutzt der die noch vorhandene openjpeg.dll und gut ist es.

Wer wirklich auf der sicheren Seite sein will, der sollte momentan nur OpenJPEG oder LLkdu nutzen bis die Turbulenzen um Emerald geklärt sind.

Mehr Spaß mit Emerald

Linden Lab hat sich in world mit den Entwicklern von Emerald getroffen und denen gesagt, was nun getan werden muss, damit Emerald nicht bald geblockt wird. Die Liste der Änderungswünsche von Seiten LLs scheint dabei lang zu sein und wird in Bälde veröffentlicht, sobald sie sich darüber klar sind, wie das umgesetzt werden könnte. Bisher ist Emerald nicht gesperrt, der Zugriff weiter erlaubt und Emerald hat nun zwei Wochen, daran zu arbeiten.

Einige Details am Rande sind dabei bereits interessant:

  • LL will, dass emkdu.dll nicht mehr verbreitet wird und sie geben dem als Zeichen von Good Will erst einmal nach. Ebenso hat Linden Lab etwas gegen die Benutzung von llkdu.dll im Emerald an sich. Zukünftige Versionen von Emerald werden also out of the box wohl nur noch OpenJPEG benutzen.
  • Es kann sein, dass in den nächsten Tagen der Zugriff aufs Grid mit einigen älteren Emerald-Versionen gesperrt wird. Dies würde jedoch erst dann geschehen, wenn auf der Seite von Emerald neuere Versionen als Ersatz angeboten werden.

Ich höre die nächsten Schreie und Gerüchte der Marke „Emerald ist gesperrt, waaah!“  jetzt schon, wenn diese Sperrungen älterer Versionen erst einmal aktiv sind. Wir sollten uns alle besser warm anziehen!

Emerald und der Rest

Der Emerald-Viewer hat in der recht kurzen Geschichte seiner Existenz bereits eine sehr turbulente Vergangenheit hinter sich gebracht. Er ist inzwischen der beliebteste aller alternativen Viewer geworden, inoffiziellen Schätzungen zufolge nutzt jeder dritte Avatar diesen täglich und demzufolge einfach eine Macht.

Nun hat das Team um den Viewer eine dokumentierte unrühmliche Historie verschiedener mehr oder minder grober Taten auf dem Kerbholz, die in der Summe einfach einen mehr als nur die Stirne runzeln lassen. Das beginnt mit CDS, geht weiter über die Onyx-Bots, dann die Geschichte mit Emkdu.dll und letztendich die DDoS-Attacke auf den Server von Hazim Gazov, der allerdings auch alles andere als ein Waisenknabe ist. So oder so aber, es zählt die Absicht, und diese war eindeutig, ihm zu schaden, es macht eine Sache nicht einfach entschuldbar zu sagen „Ich gab dem eine Ohrfeige, weil er mir zuerst eine gab!“

Es ist einfach eine Sache gewesen, die dem Entwicklerteam des beliebtesten alternativen Viewers nicht hätte passieren dürfen und einer LLC erst recht nicht. Das fand übrigens auch Philip Rosedale, der CEO von Linden Lab und haute mal sofort eine Mail an alle Second Life Nutzer raus, in der auch er das Treiben von Fractured Crystal eindeutig als DDoS bezeichnete. Emerald ist damit als Viewer erstmal in der Ecke des Boxrings, gerade noch so durch den Gong gerettet vor dem anzählen und tankt vielleicht Kraft.

Das Nervige an Diskussionen um Emerald und dem Verhalten dessen Entwickler ist dabei allerdings, dass es eine ganze Reihe von Fanboys gibt, denen es scheiß egal ist, welche Kacke und wie viel Mist die Entwickler sonst noch so abgezogen haben mögen, denn es ist doch alles nicht so schlimm, sie hätten doch nur Spaß gemacht, und und und… kurz: denen ist so ziemlich fast alles schnurz, Hauptsache sie haben ihr Lieblingsspielzeug Emerald auch weiterhin und wehe, Linden Lab wird mal wirklich böse und blockiert den Zugang damit.

Sollte das so kommen, was durchaus auch möglich ist, dann werden diese Mannen darüber entsetzt aufschreien, wie böse doch Linden Lab ist, den Zugang zu sperren. Dabei würde dann nur geflissentlich die Historie übersehen, überhaupt und und und…

Ich frage mich manchmal wirklich, was da eigentlich hätte noch geschehen müssen, damit so ein Fanboy wirklich mal die Taten der Entwickler kritisch bewertet. Vermutlich könnten bei den Meisten die Entwickler sogar Atommüll und dergleichen im Keller des Hauses laden, ohne dass es sie stören würde. Interessante Zeiten sind das.

Umso besser aber, das zumindest Linden Lab endlich mal wenn auch zur Unfreude der Fanboys aufgewacht ist, den Entwicklern zeigt, wer der Herr im Ring ist und diese nun an die Kantare nimmt. Es war ein Warnschuss vor den Burg der Entwickler, der in der bisherigen Deutlichkeit und Schnelligkeit einmalig in der Geschichte Second Lifes ist.  Hoffentlich trägt es Früchte in der Form, dass es einen Emerald befreit vom bisherigen Drama-Team gibt, der dann in Zukunft nur noch durch eines glänzt: Stabilität und innovative Features. Wenn ich mir aber anschaue, wer weiterhin dort mitarbeitet, dann habe ich daran meine Zweifel.

Überdies ist es eine gewaltige Lektion in Sachen Medienkompetenz, die Mehrheit der Leute scheint inzwischen unfähig zu sein, klar formulierte Mitteilungen noch richtig zu verstehen oder sich selbst darüber richtig zu informieren. Die Falschmeldungen um Emerald geistern momentan quer durch alle Gruppen in SL und es nervt einfach nur noch tierischst.

Rezzingtest von Emerald, Imprudence und Viewer 2.0

Ich habe gerade ein wenig mit dem Client von Wegame herumgespielt, das ist mal eine nette Sache. Er zeichnet unter Windows völlig kostenlos Videos auf, die man danach beliebig kodieren und bearbeiten kann, was braucht man mehr, um Youtube mit Second Life Videos zu füttern.

Mir war mal danach, ein wenig die Geschwindigkeit zu testen, mit denen unterschiedliche Viewer dieselbe Sim rezzen. Mein Wahl fiel dabei auf die Sim "Stiletto Moody Bare", da es dort sehr viele Sculpties gibt und auch ansonsten der Viewer naturgemäß dort ordentlich zu tun hat. Die Einstellungen waren dabei in allen Viewern in der Grafik auf "Hoch", die Sichtweite auf 96 m dabei beschränkt und als Bandbreite in jedem Viewer 1.000 kbit/s eingetragen. Da als CPU hier ein Quadcore von Intel unter Windows 7 sein Werk tut, wurde zudem noch "Run Multiple Threads" aktiviert. Damit man es einigermaßen vergleichbar ist, wurde vor jedem Viewerstart der Cache gelöscht, der Avatar auf einer anderen Sim eingeloggt, dann zu der Testsim teleportiert und in etwa eine Minute direkt nach dem Teleport dorthin aufgezeichnet.

Damit hat man in etwa eine Ahnung, wie flott welcher Viewer die Szenerie rezzed – ganz vergleichen kann man es nie, da die Anzahl der dortigen Avatare immer ein wenig anders war und auch die Bewegung, aber man bekommt so schon einen guten Eindruck.

Als erstes führte ich den Test mit dem aktuellen Emerald Viewer in der Version 1.23.5.1632 durch. Er war für mich der Viewer, der am gemütlichsten zur Arbeit ging, wie man auf dem Video hier gut sehen kann:

Als nächstes testete ich den Imprudence 1.3-b2, der trotz einer langsamereren JPEG-2000-Bibliothek (Openjpeg 1.3) und seines offiziellen Status als Betaversion im Vergleich zu Kakadu bei Emerald einen äußerst flotten Eindruck machte:

Als letztes dann den aktuellen Viewer 2.0 von Linden Lab selber, auch der arbeitete äußerst flott, vielleicht noch einen Tick schneller als der Imprudence:

Fazit: wer auf eine gute Geschwindigkeit beim Rezzen wert legt, der ist mit Emerald in der aktuellen Version am schlechtesten bedient, andere Viewer arbeiten da (zumindest für mich) eindeutig besser.