Streamingtechnologie des OnDemand Spieledienstes „OnLive“ unter Berücksichtung des Cloud-Computings
Aus Winfwiki
|
Hausarbeit | |
| Hochschule: | Hochschule für Oekonomie & Management |
| Standort: | Düsseldorf |
| Studiengang: | Bachelor Wirtschaftsinformatik |
| Veranstaltung: | IT-Infrastruktur |
| Betreuer: | Dipl-Inf. (FH) Christian Schäfer |
| Typ: | Hausarbeit |
| Themengebiet: | IT-Infrastruktur |
| Autor(en): | Daniel Wittrock |
| Studienzeitmodell: | Abendstudium |
| Semesterbezeichnung: | |
| Studiensemester: | 3 |
| Bearbeitungsstatus: | in Arbeit |
| Prüfungstermin: | 31.01.2011 |
| Abgabetermin: | 30.01.2011 |
Inhaltsverzeichnis |
1 Eineitung
In der heutigen Gesellschaft ist das OnDemand-Geschäft so stark angezogen, wie damals das Web 1.0. Im Bereich der Webanwendungen herrscht derzeit noch eine gewisse Goldgräberstimmung, wozu auch das Streamen von medialen Inhalten gehört. Nach vielen Online-Videotheken wie maxdome o. ä gibt es nun auch die Möglichkeit, dem Kunden interaktive Streams in Form von Spielen anzubieten.
Zunächst galt dies für kleinere Webspiele, heute bahnen sich jedoch schon große und komplexe Spiele den Weg über das Netz zu den Konsumenten. Die Rede ist vom "Cloud-Gaming".
Das Cloud-Gaming soll die neue Form des Spielens werden. Unterstützt wird es mit den fortschrittlichsten Servern und Kompriemierungsmethoden die es zur Zeit gibt.
1.1 Ausgangssituation
Ausgangspunkt für die Erstellung dieser Hausarbeit ist die Veröffentlichung des Streamingdienstes OnLive. Dieser Dienst wirft das Konzept des starren Medien Streamings um und stellt sich den neuen Herausforderungen des aktiven Content-Streamings. Gerade in Zeiten der zunehmenden Neuentwicklungen auf dem Bereich des Internet-Streamings und der Ausweitung der Spieleplattformen zeigt sich, dass das Streamingkonzept noch lange nicht am Ende seiner Möglichkeiten ist. Außerdem zeigt sich in vielen Punkten, dass heutzutage immer mehr Firmen auf den Trend des Streamings aufspringen.
1.2 Zielsetzung
Ziel dieser Hausarbeit ist es, die aktuellen Möglichkeiten des Streamings anhand von OnLive vorzustellen und die grundlegenden Anwendungsmöglichkeiten aufzuzeigen. Hierzu werden in Kapitel zwei zuerst einige der theoretischen Grundlagen erläutert, bevor in den folgenden Kapiteln die wesentlichen Instrumente und Merkmale von OnLive dargestellt werden. Das letzte Kapitel beschäftigt sich im Anschluss mit der kritischen Würdigung der erreichten Ziele und gibt einen Ausblick auf noch offene Fragen.
2 Streaming Technologie
Streaming ist der Oberbegriff und bezeichnet die aus einem Computernetzwerk empfangenen und gleichzeitig wiedergegebenen Audio- und Videodaten. Der Vorgang selbst wird auch als Streaming bezeichnet.
Streaming-Medien bilden damit das Internet-Äquivalent zu Rundfunktechnologien wie Radio und Fernsehen. Programmformate sind beispielsweise Internetradio oder Webfernsehen. Auch das beliebte Live-Streaming von Fußballübertragungen aus dem Web fällt in diese Kategorie. Man unterscheidet dabei verschiedene Formate, die von unterschiedlichen Firmen ins Leben gerufen wurden.
2.1 Codecs und Container
CODECS
MPEG – Moving Pictures Expert Group 1988 wurde die MPEG-Gruppe gegründet und stellte eine gemeinsame Arbeitsgruppe von ISO und IEC dar. Die Gruppe legt Dateiformate und Verfahren zum platzsparenden Komprimieren und Speichern von Multimediadaten in hoher Qualität fest. Folglich würde das in Abschnitt 1 angesprochene einheitliche Dateiformat nicht lange auf sich warten lassen. Der MPEG-Standard teilt sich in MPEG-1, MPEG-2, MPEG-3, MPEG-4, MPEG-7 und MPEG-21, wobei MPEG-7 und MPEG-21 hier nicht betrachtet werden sollen.[1]
Einer der bekanntesten Streaming-Dienste ist YouTube. YouTube verbreitet mittels Web-Streams audiovisuelle Inhalte über das Internet. Die Technologie dieser Web-Streams basiert grundlegend auf der Entwicklung der angesprochenen Audio- und Videoformate.
Der MPEG-2 Standard Da sich der MPEG-1 Standard als großer Erfolg entpuppte, begann man gleich nach der Veröffentlichung an den Nachfolgern MPEG-2, MPEG-3 und MPEG-4 zu arbeiten. MPEG-1 war auf das Format der CD zugeschnitten und unterstützte lediglich den progressiven (zeilenweise, Bildpunkt für Bildpunkt) Bildaufbau. Die MPEG-Gruppe sah sich dann Anfang der 90er Jahre zunehmend dem Druck der Medienindustrie ausgesetzt, die ein Verfahren forderten, welches die herkömmlichen Fernsehstandards (PAL und NTCS) komprimieren sollte. Zudem sollte mit dem MPEG-2-Standard eine bessere Bildqualität erzielt und die Möglichkeit einer Skalierbarkeit geschaffen werden, um unterschiedliche Bedingungen für unterschiedliche Leistungsklassen von Nutzern zu schaffen. Dadurch kann mit MPEG-2 bis heute alles - von der einfachen Videokonferenz bis zum hochauflösenden HDTV - dargestellt werden.[2]
Der H.264 Codec
Der H.264/AVC Codec alias H.264, alias Advanced Video Coding (AVC) oder alias MPEG-4 Part 10. Er wurde 2003 veröffentlicht, danach fanden einige Änderungen und Updates statt. Das Konzept stammt von den früheren Standart MPEG-2 und MPEG-4 ab und bietet Potenzial für eine höherer Effizienz der Compression und Flexibilität auf die Anwendungen. Der Standard H.264/AVC ist ein offener Standard, was bedeutet, dass prinzipiell jeder Hersteller einen H.264/AVC-Kodierer und –Dekodierer bauen könnte. Die typischen Anwendungen sind z. B. Streaming. [3]
Dabei wird das Video mit dem H.264 Codec codiert, um einen Bitestream zu erzeugen. Dieser wird über das Netzwerk zu einem Decoder geschickt, um das Material zu Decodieren und auf einem Client abgespielt. Der gesamte Prozess läuft wie im Bild beschrieben ab.
CONTAINERFORMATE
Die Datenformate Quicktime Movie, AVI, Real Video und DIVX werden als Containerdatenformate bezeichnet, da diese in der Lage sind, mehrere Datenformate zu unterstützen. Es ist möglich, Video, Audio und Textinformation gemeinsam und synchronisierbar in einer Datei abzulegen.
AVI - auch Audio Video Interleave (AVI) - ist ein von Microsoft definiertes Video-Containerformat, das von dem für Windows 3.1 eingeführten RIFF (Resource Interchange File Format) abgeleitet ist. „Audio Video Interleave” bedeutet, dass Audio- und Videodaten ineinander verzahnt, also „interleaved”, abgespeichert werden (Siehe auch Interleaving). – quelle wikipedia
2.2 Cloud Gaming
Das Cloud Gaming gab es schon länger in den Köpfen der Firmen. Es war ein schon längst überfälliger Schritt das Streamen von Inhalten so zu gestalten dass der Benutzer mit ihnen interagieren kann. Dazu soll es möglich sein, völlig unabhängig von der jeweiligen Hard- und Softwarestruktur Spiele auf dem Gerät zu spielen, ohne dass dazu eigene Rechenleistung verwendet wird. Außerdem soll es die bisherige Methode ablösen Spiele zu kaufen und zu installieren. Bisher konnten jedoch aufgrund von technischen Barrieren oder Patentstreitigkeiten noch keine potentiellen Ergebnisse erzielt werden. Zwei Firmen haben sich dabei in den Vordergrund gestellt: OnLIVE und Gaika stellen derzeit erstmals Ihre Technologie und Möglichkeiten unter Beweis. Die Technologie soll es ermöglichen, dass erste richtige Cloud Gaming umzusetzen.
3 Streaming Anbieter
OnLive - Cloud Gaming
OnLive trat 2008 zum ersten Mal auf der Games Developer Conference in San Francisco in Erscheinung und kündigte an, mittels Streaming nahezu jede Spieleplattform leistungsunabhängig auf Fernseher, Windows-Computer und Macs streamen zu können. Der Kopf des Unternehmens, Steve Perlman, ist ebenfalls Gründer von QuickTime und WebTV. Er hat die Lösung: Dank eines speziellen Algorithmus soll die Latenz nicht nur maximal eine Millisekunde betragen, sondern es sollen auch Server, sowohl auf der Ost- und Westküste der USA, als auch ein weiteres Datencenter im mittleren Westen installiert werden. "Wenn man nun in Australien spielen will", sagt Perlman, "dann kann man zwar jedes Spiel durchaus spielen, allerdings sieht man dann eine minimale Verzögerung." Weitere wichtige Köpfe sind Tom Paquin, Hauptentwickler des Netscape Navigator, sowie John Spinale, der bei Eidos und Activision seine ersten Lorbeeren in der Produktentwicklung verdiente, und Paul V. Weinstein, der früher MySQL mitentwickelte und betreute.
Gaika - Cloud Gaming
Gaika ist der größte Konkurrent. Firmenchef Dave Perry möchte mit seiner Firma das Konzept „Streaming auf jedem Device mit einem Bildschirm“ umsetzen. Zum jetzigen Zeitpunkt allerdings sind sehr wenige Informationen zu seinem Dienst bekannt. Nur, dass das Unternehmen doppelt so viele Rechenzentren zur Verfügung stellen will wie OnLIve, konnte man bereits lesen. Gaika will durch Investitionen des Risikokapitalgebers Triplepoint Capital, der bereits große Server-Netzwerke für Unternehmen wie YouTube und Facebook finanziert hat, und mithilfe von Limelight Networks, die zu den größten Playern im Bereich der sogenannten Media Delivery Networks gehören, das angestrebte Ziel erreichen.
Multiview Streaming Plattformen
Zu den Multiview Streaming Plattformen zählen Microsoft, Apple, Adobe und noch einige mehr. Die drei Großen (Microsoft, Apple,Adobe) bieten Plattformen an, um Inhalte darüber zu Streamen. Jüngst hat Apple in sein iTunes-Konzept auch die Plattform des digitalen Videostreamvertriebs aufgenommen. Dadurch kann Apple seine Medien auf jedes internetfähige Gerät bringen und nativ auf nahezu jedes Apple Produkt.
4 Die Technologie des Cloud Gamings
4.1 Anforderung an den Server
4.1.1 Anforderung an die Hardware
Die Server des OnLive-Dienstes wurden nicht bekannt gegeben. Am Rande der Pressekonferenz kam das Gerücht auf, dass OnLive auf Dell-Server setzt. Dieses Gerücht ist bis heute unbestätigt. Es besteht aber die Möglichkeit, dass es sich hierbei um optimierte Server der Firma NVIDIA handelt. Diese bieten die sogenannten „Tesla“-Systeme an. Es würde auch gut zum zeitlichen Rahmen passen, da diese Server erst zur zweiten Jahreshälfte 2010 erschienen sind. Die Merkmale dieser Server sind:
Liefert eine Clusterleistung, die 1/20 des Stromverbrauchs und 1/10 der Kosten von Nur-CPU-Systemen auf der Grundlage der neuesten Quad-Core-CPUs entspricht.
- Bis zu 6 GB GDDR5-Speicher pro Grafikprozessor
Erlaubt schnelleren Zugriff auf größere Datensätze.
- NVIDIA Parallel DataCache™
Beschleunigt verschiedene Algorithmen die zur Kompression genutzt werden wie z.b Ray-Tracing.
- NVIDIA GigaThread™ Engine
Maximiert den Durchsatz durch schnelleres Umschalten des Kontextes. Ansynchroner Datentransfer Treibt die Systemleistung in die Höhe, weil auch dann Daten übertragen werden, während gleichzeitig Berechnungen stattfinden.
- High-Speed-Datenübertragung mit PCI-Express 2.0
Maximiert die Bandbreite zwischen dem Hostsystem und den Tesla-Prozessoren. Ermöglicht Tesla-Systemen das Zusammenspiel mit praktisch jedem PCIe-konformen Hostsystem mit einem freien PCIe-(x8 oder x16 )Steckplatz.[4]
Damit ist es möglich mehrere Server zu einem Cluster auszubauen, das nennt sich laut NVIDIA „RS-Plattform“.
Dieses umfasst ein NVIDIA® Tesla™ RS Grafikprozessor-basiertes Serversystem mit RealityServer Software. Das Tesla RS System ist flexibel konfigurierbar: von einem kleinen System mit 8 Tesla Grafikprozessoren für die Zusammenarbeit kleiner Arbeitsgruppen bis hin zu großen Systemen mit 100 Tesla Grafikprozessoren, über die große Kundenzahlen über das Internet bedient werden können. Da die grafische Leistung der Spiele mittlerweile enorm ist, wäre dieses Serverarchitektur besonders für den Einsatz bei OnLive geeignet.
Darüberhinaus bietet der Tesla RS-basierte Cluster allen Anwendern die Interaktion mit komplexen, fotorealistischen 3D-Modellen und Umgebungen und liefern außerdem über zehnmal mehr Leistung als CPU-basierte Cluster. NVIDIA RealityServer mit iray Rendering-Technologie verfügt über die innovative parallele NVIDIA® CUDA™ Prozessorarchitektur und 240 parallele Recheneinheiten pro Tesla Grafikprozessor und überträgt fotorealistische Streams. Dies ist ein weiteres Indiz für eine Nutzung der NVIDIA-Server, da es die Möglichkeit bietet, den Stream mit interaktiven Inhalten (was Spiele betrifft) an jedes internetfähige Gerät weiterzugeben.
4.2 Anforderung an den Client
4.2.1 Anforderung an die Hardware
Obwohl behauptet wird, dass die Spiele auf jeder Hardware funktionieren, werden trotzdem noch Anforderungen an die Hardware gestellt. Bei OnLive sind sie minimal: Netbook (atomCPU) 1 GB Ram und einer 3 MBit/s schnellen Verbindung.
Optimal: Für das optimale Spielerlebnis setzt OnLive als Client-Hardware einen Dual-Core Cpu mit 2 GB Ram und einer 5 MBit/s schnellen Verbindung voraus. Damit sollen Spiele in einer Auflösung von 1280x720 möglich sein.[5]
4.2.2 Anforderung an die Software
Die Software basiert nicht wie Gaikas Technologie auf Flash, sondern verlangt die Installation eines weiteren Programms. Dieses Programm macht die Kommunikation mit dem Server möglich. Die Software soll auch auf dem iPad von Apple funktionieren, wobei es jedoch nicht möglich ist selbst zu spielen, sondern das Geschehen auf dem Server „live“ mitzuverfolgen. [6]
4.2.3 Anforderung an das Netzwerk
Die klassischen Online-Games sind oft auf kleine Datenmengen optimiert. Meist aufgrund der Logik, dass kleine Pakete mit geringer Latenz befördert werden. Beim Cloud-Gaming allerdings strömen umfangreiche Video- und Audiodaten vom Server zum Client. Das bedeutet, dass eine konstante Bandbreite sowie eine geringere Latenz bestehen müssen. Die OnLive-Server senden mit etwa 700KByte/s, was mit einer schon fast zum Standard gehörenden 6MBit/s Leitung zu bewältigen ist. Vorsicht ist allerdings mit einem WLan-Anschluss geboten: zwar übersteigt die gesendete Leistung den relativen Ansprüchen, aufgrund der Schwankungen im Signalverlauf ist es aber möglich, dass das Cloud-Game „ausgebremst“ wird. Deshalb sollte im WLan das WMM eingesetzt werden. Dieses sorgt für die nötige QoS im Heimfunkbereich.
5 Funktionsweise des OnLive-Dienstes
5.1 Hardware OnLIve
Hardware des OnLive-Dienstes
Die „Box“Die Hardware die von Onlive ausgegeben wird, beinhaltet eine Box und ein Gamepad. Die Box besteht aus einem aus Kunststoff gefertigtem Gehäuse. Als Anschlüsse besitzt diese Box
- Usb,
- Hdmi out
- Komponentenkabel Ausgang
- Stereo Audio Ausgang
- S/PDIF optischen Ausgang
- Ethernet Schnittstelle
Die Box unterstützt bis zu 4 Wireless Controller, Maus und Tastatur, sowie Bluetooth. Sie beinhaltet die Möglichkeit das Videosignal selbstständig aufzubereiten bzw. durch den proprietären Codec zu encoden, was im Gegensatz zum Client auf Rechnerbasis „kleine“ Vorteile bringt. Die Box ist flexibler als ein PC und benötigt weniger Strom. Über die Ausstattung innerhalb der "blackbox" gibt es derzeit noch keine genauen Angaben. Die Abmaße sind im Vergleich zu einem iPhone relativ klein. Im Gegensatz zu herkömmlichen Konsolen laufen OnLive Boxen außer Konkurrenz, da diese Boxen ausschließlich dem Streamen aus der OnLive-Cloud dienen. Es ist nicht möglich damit noch etwas anderes zu machen.
Die Spiele die für Onlive herauskommen sind
- Defense Grid Gold
- F.E.A.R. 2: Project Origin
- King's Bounty: Armored Princess
- Ninja Blade
- Prince of Persia
- Puzzle Chronicles
- Saw
- Tom Clancy's H.A.W.X.
- Tomb Raider: Underworld
- Unreal Tournament III: Titan Pack
- Wheelman
- World of Goo
5.2 Server Client Prinzip
In der Grafik sieht man den genauen Ablauf der Vorgänge, die bei dem Spielen in der Cloud vorgehen.
Zunächst wird ein Spiel auf dem Server gestartet. Für dieses Spiel übernimmt der Client mittels Eingabegerät die Kontrolle. Die Kommandos die der Client zum Server abschickt werden erst codiert und dann gestreamt. Der Server empfängt die Steuerkommandos und fügt sie ins Spielgeschehen ein. Das Spiel selbst wird vom Server zur Übertragung an den Client codiert. Diese Codierung wird in zwei separate Vorgänge aufgeschplittet. Die Video-/Audio-Codierung wird danach in einen gemeinsamen Stream durch das Netz geschickt und landet beim Client, der die Signale mittels Decoder entschlüsselt und auf dem Bildschirm wiedergibt.
Bei OnLive ist der Server eine Server-Farm, die die Anfragen aus dem Netz kontinuierlich bearbeiten. Der Decoder auf der Clientseite ist bei OnLive entweder ein Computer (Mac/Windows/Linux) oder eine von OnLive selbst entwickelte Konsole.
5.3 Komprimierungsverfahren
Die Kompressionsmethoden des OnLive-Dienstes sind leider nicht im Detail dokumentiert. Aus diesem Grund stelle ich lediglich die zurzeit möglichen Methoden dar.
Im Gegensatz zu einem Audio- oder Videostream, den man sich im Internet anschaut, kommt es bei GOD auf die Kompression an. Die gezeigten Bilder/Töne/Bewegungen laufen beim GOD in Echtzeit ab. Die Kompression ist nötig, da die Bandbreite im Internet sehr beschränkt ist. Der Spieler, der z. B. einen Rennwagen über einen Parcour treibt, muss ein sehr genaues Feedback zu seinen Eingaben bekommen. Hier kommt es auf eine sehr niedrige Latenz an, wie sie z. B. bei einer Skype Telefonie erforderlich ist. Dadurch ergeben sich zwei grundlegende Möglichkeiten die Videosignale zu übertragen.
-Den gesamten Videostrom zum Client übertragen: Dazu würde sich der derzeitige Videostandart MPEG-4 AVC (besser bekannt auch als H.264) zur Kompression eignen. Der Codec besitzt eine sehr gute Codierungseffizienz. Zurzeit ist es aber nicht möglich alle Eigenschaften zu nutzen, da H.264 viel Zeit bei der En-/Decodierung benötigt und dies ein KO-Kriterium bei der Datenübertragung in Echtzeit ist. Deshalb wurde der Codec durch den Hauptentwickler Jason Garett-Glaser so optimiert, dass die Leistung des Encodings erhöht wurde und nun auf einem Core-i7 läuft, wodurch eine Latenz von unter zehn Millisekunden, bei einer Auflösung von 800x600 erreicht werden kann.
-Eine weitere Möglichkeit ist das Grafik- Streaming: Hierbei werden, statt den gesamten Videostrom zu übertragen, nur die Grafikbefehle zum Client übertragen und ausgegeben. Der Vorteil ist hierbei, dass die daraus schlussendliche Bitrate vom anzuzeigenden Bildschirm abhängt. Der Nachteil ist jedoch, dass der Client eine starke Grafikkarte benötigt, um die Grafikbefehle latenzfrei umzusetzen. Das Streaming-Protokoll hinter dieser Methode leitet sich von dem X-Windows-Model ab. Dieses Model findet häufig unter Linux seine Anwendung. Um die Latenzzeiten hierbei zu begrenzen, wurden verschiedene Optimierungen hinzugefügt, die berücksichtigen, dass Computerspiele häufig einfach vorhersagbare Zustände des Grafikkontextes abfragen. Hinzu kommt noch ein intelligentes Caching-Konzept. Dadurch lassen sich drastische 80 Prozent der Datenrate sparen. [7]
Die Techniken leiten sich von denen der „klassischen Verfahren" zur Kodierung ab, wie z. B. der
- Einfache Techniken
Dabei beschränkt man sich auf die Reduktion der Bildinformation. So wird bei einer sogenannten Truncation die Farbtiefe des vorhandenen Bildes gesenkt, wobei es zu einem ersten Verlust der gegebenen Information kommt. Ein zusätzliches einfaches Verfahren was häufig eingesetzt wird, ist das Lauflängenverfahren. Hierbei werden ohne Informationsverlust nachfolgende auftretende, gleiche Farbflächen zusammengefasst.
- Interpolative Verfahren
Bei dem interpolativen Verfahren wird aus einer Teilmenge von Bildpunkten die noch fehlenden reduzierten Bildpunkte berechnet. Hierbei handelt es sich um eine äußerst effiziente und flexible Technik, da sich viele Bereiche des Bildes meistens über lange Zeit kaum ändern. Es könnten sogar komplette Zwischenszenen innerhalb eines Spiels oder Videos interpoliert werden, da sich oftmals nur wenige Objekte in einer Szene bewegen. Die Komprimierung hierbei kommt dadurch zustande, dass nur Abweichungen vom Zwischenbild zum interpoliertem Zwischenbild gespeichert werden.
- Statische Codierung
Bei der statischen Codierung wird grundsätzlich verlustfrei codiert. Hierbei wird die statistische Verteilung der Werte der vorkommenden Bildpunkte ausgenutzt, um häufiger vorkommende Bildpunkte mit Codes geringerer Bitlängen und weniger häufig vorkommende Bildpunkte mit Codes größerer Bitlängen zu codieren. Ein sehr bekanntes Beispiel hierfür ist die Huffmann-Codierung.
- Bewegungsvorhersage
Dabei handelt es sich um eine Reihe von verschiedenen Verfahren. Auch hier wird, wie bei den anderen Techniken, die überflüssige Bildinformation ausgenutzt. Bei einer Bewegung eines Objektes innerhalb eines Bildes, indem sich der Hintergrund kaum verändert ist die einzige Veränderung die Position bestimmter Bildpunkte. Durch die Helligkeitsänderung und deren Ursache innerhalb einer Bildfolge, gibt es Verfahren die diese erkennen, und dadurch eine Komprimierung erreichen.
5.4 Datenvolumen
Datenvolumen OnLive hat während des Spielens einen Downstream von über 700 KBytes/s und einen Upstream von 10 KBytes/s. Das sind Pro Stunde 2,5 GB Datenvolumen. Zum Vergleich dazu World of Warcraft: dieses Spiel benötigt weitaus weniger Datenvolumen. Im Downstream beschränkt es sich auf 35 Kbytes/s. Grund dafür ist natürlich die Installation aller nötigen Daten auf der Festplatte.
Ein weiteres Beispiel bietet HDTV. Es wird mit einer Farbtiefe von 8-Bit und bis zu 1920x1152 Bildpunkten mit 60 Herz Bildwiederholungsfrequenz und 4:2:2-Subsampling dargestellt. Dies ergibt eine Datenrate von 1920*1152*60*8+960*1152*60*(8+8) = 1,19Gbps.
5.5 Netzwerkstruktur
Eine Netzwerkverbindung kann auf zweierlei Weise schnell sein oder langsam sein. Die Bandbreite gibt an, wie viele Bytes pro Sekunde durch die Leitung gehen. Die Latenz sagt aus, wie lange die einzelnen Pakete unterwegs sind. Die klassischen Online-Spiele sind so optimiert, dass sie ein geringes Datenvolumen erzeugen. Das ist aber wiederum nur möglich, da diese Spiele auf den Rechnern des Spielenden installiert werden. Die Spiele-Engines der einzelnen Spiele tauschen in nur kleine Datenpakete aus, wie z. B. Geschwindigkeit, Sichtrichtung oder auch Mauskoordinaten. Daher spielt die benutze Bandbreite keine primäre Rolle - für diese Spiele ist nur die Latenz ausschlaggebend.
Zur Latenz tragen alle Verbindungen wie Netzwerke, Funkverbindungen, Router, Switches usw. bei. In Kupfer- oder auch Glasfaserverbindungen beträgt die Datengeschwindigkeit ca 300.000 km/s. Somit stellen 200 Kilometer Kabel etwa 1ms zusätzliche Latenz dar. Etwas größer ist dabei der Einfluss der Bandbreite auf die Laufzeit. So braucht ein Datenpaket von 1,5 KB rechnerisch 3ms um durch eine 4 MBit/s DSL-Leitung zu gelangen, wobei die Latenzen auf „echten“ Kabeln höher als der rechnerische Wert sind. Das liegt zum Teil an dem Overhead auf der Leitung sowie an den verwendeten Codierungstechniken. DSL–Leitungen haben zurzeit eine Latenzzeit von 20 bis 40 ms. Eine weitere Hürde kommt hinzu, da der Spieleprovider oft in einem anderen Netz als der Empfänger sitzt. Damit die benötigten Datenpakete nun die Netze wechseln können, um zum Client zu gelangen, müssen sie entweder durch einen sogenannten "Peering Point“ oder durch weitere Netze von anderen Providern. Dabei geben die Carrier vor, welche Netze wo und wie miteinander verbunden sind. Das wiederum kann auch zum Problem werden, da nicht alle Routen umsonst sind. Oft ist die Nutzung der Carrier-Strecken kostenpflichtig. Daher entscheiden sich einige Provider ihre Router so einzurichten, dass nicht die kürzeste Strecke genommen wird – was die Latenz auch niedrig halten würde - sondern die günstigste. Die günstigsten Strecken haben jedoch oft eine hohe Latenz. Das Optimum ist, wenn Server und Client im gleichen Netz eines Providers stehen. Dadurch ist die eine geringe Anzahl an Hops gegeben, die sich positiv auf die Latenz auswirkt und somit die Qualität des Netzes verbessert.
Eine Solche Methode bzw. Vorgehensweise gibt es bereits: CDN – Content Distribution Networks/Content Delivery Network. Das CDN besteht aus einem Initialserver, auf dem der Inhalteanbieter die zu verteilenden Inhalte ablegt. Meist handelt es sich um gemietete Server. Hinzu kommen die sogenannten Replica-Server, die Kopien dieser Inhalte vorhalten – was Sicherungszwecken dient - und schließlich aus einem Distributionssystem, das die gespeicherten Inhalte auf den Replica-Servern verteilt. "Die Daten werden transparent im Netz so vorgehalten, dass die jeweilige Auslieferung entweder möglichst schnell geht (Performance-Optimierung) oder möglichst wenig Bandbreite verbraucht (Kosten-Optimierung), oder beides zugleich.“ Im Grunde genommen ist dies der Kerngedanke des Cloud-Computings. Denn der Client bezieht seine Daten nicht von einem speziellen Server, sondern der Anbieter weist ihm einen Server zu, der zu seiner Position am günstigsten liegt. Wichtig für die Latenz ist also nicht nur die Netztstruktur. [8]
Als einen weiteren Faktor kommen die „Knotenpunkte“ hinzu. Die TTL der Datenpakete auf den Routern ist nicht konstant, sondern hängt vom restlichen Datenverkehr (Traffic) ab. Die normalen Routen, wie sie im Hausgebrauch vorkommen, leiten Ihre Daten so weiter, wie sie sie erhalten haben - also nach dem FIFO Prinzip. In den Routern der Provider kommen aber mehrere Pakete simultan an. Diese entscheiden dann aufgrund der Datenpaketseigenschaften welches Paket Vorrang hat. Bei dieser Behandlung spricht man von einer QOS-Einstellung. Damit wird sichergestellt das z. B. ICMP-Pakete schneller transportiert werden. Diese sind wichtig zur Fehlererkennung in Netzwerken. Allerdings behandelt jeder Carrier diese Einstellung nach eigenem Ermessen.
Beim Streaming fließt der Datenstrom normalerweise durch mehrere solcher Carrier-Netze. Der Betreiber hat keinerlei Einfluss darauf, dass seine Datenpakete eine hohe Priorität bekommen. Daher ist die gesamte Latenz von der räumlichen Entfernung zwischen Server und Client, und weniger von der eingesetzten Infrastruktur des Netzwerkes dazwischen abhängig. Wieweit eine solche Entfernung ist, kann man mithilfe eines tracroutes bestimmen. Die Faustregel dabei ist: je weniger Hops, desto niedriger die Latenz. Speziell bei einem Dienst wie OnLive ist das sehr wichtig, da die Signale der Steuerung sehr schnell übertragen werden müssen.
6 Fazit
Der Trend, alles in eine Cloud auszulagern ist nicht neu, aber die Technologie die eingesetzt wird ist es. Möglich macht es die heutige Industrie - die Rechenkapazität ist schneller und effektiver als vor 5 Jahren. Trotzdem stellt sich die Frage: Cloud oder Lokal? Im Zusammenhang mit OnLive sind die Probleme sichtbar. Die hohe Latenz oder die möglichen Verbindungsabbrüche. Hinzu kommt, dass nicht jeder Konsument über eine ausreichende Netzwerkanbindung verfügt - sei es aus Kostengründen oder aus geografischer Sicht. Viele Provider sind auch einfach nicht in der Lage, Bandbreiten zu garantieren und das stellt die größte Hürde für OnDemand-Streaming-Angebote.
Dagegen stehen die ausgereiften Konsolen. Sie bieten alles: Multiplayer, Singleplayer, gute Grafik, schnelle Eingaben. Aber auch sie besitzen ihre Grenzen - und eine fängt schon mit dem Preis an. Für die Anschaffung einer Konsole muss man etwa 200 € einkalkulieren. Dieser Preis beinhaltet jedoch keine Spiele.
Hier bietet OnLive einen klaren Vorteil. Entscheidet man sich für den Dienst, kann man sich aus der Bibliothek der Spiele bei OnLive diese leihen. Ein cleveres Geschäftsmodell. Rechnet man die Mietgebühren gegen den Kauf physikalischer Spiele CDs, so gewinnt das Leihspiel. Nur kann der Käufer bzw. der Mieter keinen Gewinn mehr aus dem Spiel erzielen, der er nicht der Eigentümer ist.
Auch die Gechäfftsmodelle anderer Unternehmen werden so in Frage gestellt. So z. B. das des Unternehmens Gamestop. Diese haben sich darauf spezialisiert, gebrauchte Spiele zu verkaufen. Das wird in Zukunft dann nicht mehr funktionieren. Positiv ist aber die Entwicklung der Streaming-Technik zu sehen - denn schon jetzt ist es möglich, sich über spezielle Dienste HD-Inhalte streamen zu lassen.
Wenn die Zukunft hält was sie verspricht, wird es möglich sein, auf jedem Gerät das Maximum an Qualität herauszuholen, unabhängig davon, wo wir uns befinden. Das Spielerlebnis an sich wird sich zwar dadurch nicht verändern, doch die Möglichkeit diese auf jedes mögliche Endgerät zu streamen, ist es eine erfolgsversprechende Revolution.
7 Abkürzungsverzeichnis
| Abkürzung | Bedeutung |
|---|---|
| AVC | Alternate Frame Rendering |
| AVI | Arithmetic Logical Unit (Arithmetisch Logische Einheit) |
| API | Application Programming Interface |
| CDN | Content Distribution Network |
| CUDA | Compute Unified Device Architecture |
| DSL | Digital Subscriber Line |
| GPU | Graphics Processing Unit |
| GOD | Games On Demand |
| HDTV | High Definition Television |
| NTSC | National Television Systems Committee |
| OpenCL | Open Computing Language |
| PAL | Phase Alternating Line |
| QoS | Quality of Service |
| SHA-1 | Secure Hash Algorithm 1st |
| TTL | Time To Live |
| WMM | Wireless Multimedia Extensions |
8 Anhänge
8.1 Fußnoten
- ↑ Video-Codecs Von Ralf Biebeler
- ↑ Video-Codecs Von Ralf Biebeler
- ↑ he H.264 Advanced Video Compression Standard Von Iain Richardson
- ↑ www.nvidia.com
- ↑ http://www.golem.de/1007/76581.html
- ↑ http://www.golem.de/1007/76581.html
- ↑ http://www.burosch.de/shop_content.php?coID=76
- ↑ http://de.wikipedia.org/wiki/Content_Distribution_Network
9 Quellen
Internet:
| Nvidia Website (2010) | NVIDIA.: Tesla Server http://www.nvidia.de (Zugriff 15.10.2010, 20:52) |
| datacompression (2010) | datacompression.: Data Compression http://www.datacompression.info/ (Zugriff 15.10.2010, 20:52) |
| Nvidia Website (2010) | NVIDIA.: Tesla Server http://www.nvidia.de (Zugriff 15.10.2010, 20:52) |
| Vcodex White Paper (2008) | Vcodex.: Vcodex White Paper http://www.vcodex.com/h264overview.html (Zugriff 16.10.2010, 18:52) |
| OnLive Website (2010) | OnLive.: OnLive http://www.onlive.com (Zugriff 15.10.2010, 20:52) |
| Die Welt Website (2010) | WELT.: Videospiele-stehen-vor-ihrer-groessten-Revolution http://www.welt.de/wirtschaft/webwelt/article3434901/Videospiele-stehen-vor-ihrer-groessten-Revolution.html (Zugriff 20.11.2010, 12:30) |
| Golem (2010) | Golem.: Gaikai http://www.golem.de/1010/78562.html (Zugriff 15.10.2010, 20:52) |
| Golem (2010) | Golem.: Onlive http://www.golem.de/1007/76636.html (Zugriff 15.10.2010, 20:52) |
| Golem (2010) | Golem.: Spielestreaming auch für iPhone, iPad und Android http://www.golem.de/1007/76581.html (Zugriff 15.10.2010, 20:52) |
| H.264 (2010) | Article by Wiegand, Sullivan, Luthra and Bjontegaard (PDF).: Overview of H.264/AVC http://ip.hhi.de/imagecom_G1/assets/pdfs/csvt_overview_0305.pdf (Zugriff 15.10.2010, 20:52) |
| cnet (2009) | Cnet.com.: Interview: OnLive CEO Steve Perlman gives us his post-launch perspective http://news.cnet.com/8301-17938_105-20010687-1.html (Zugriff 15.10.2010, 20:52) |
| AMD (2010) | Advanced Micro Devices (AMD) (Hrsg.): Real-time Gaming from the Cloud, 2009, http://blogs.amd.com/play/tag/fusion-render-node/, 14.09.2010, 10:11 |
| Gaikai (2010) | Gaikai (Hrsg.): Streaming Worlds, 2009, http://www.gaikai.com/streaming-worlds/, 13.09.2010 16:39 |
| Gamestar (2010) | Gamestar (Hrsg.): OnLive, 2010, http://www.gamestar.de/specials/spiele/2311213/onlive_p2.html, 12.09.2010, 18:53 |
| o.V. (2010) | o.V.: Artikel "Plattform as a Service", http://en.wikipedia.org/wiki/Platform_as_a_service, 02.09.2010 |
| Stäuble, Markus (2010) | Stäuble, Markus (2008): Artikel "Cloud Computing - Ablaufplattformen im Vergleich", http://www.computerwoche.de/knowledge_center/software_infrastruktur/1876567/, 22.10.2010 |
| o.V. (2010) | o.V.: Internetreferenz "OnLive Partner: http://www.onlive.com/partners.html, 2010 |
| Brightman, James (2010) | Brightman, James (2009): Artikel "GDC Exclusive: David Perry's Entry into Server-Based Gaming", http://www.gamedaily.com/articles/news/gdc-exclusive-david-perrys-entry-into-serverbased-gaming/?biz=, 25.10.2010 |
| o.V. (2010) | o.V. (2009): Artikel "OnLive streamt Crysis auf den Mac und die Set-Top-Box", http://www.golem.de/0903/66088.html, 24.09.2010 |
| o.V. (2010) | o.V. (2009): Artikel "OnLive: Inside and Out", http://www.gamespot.com/features/6206623/p-3.html, 2009 |
| o.V. (2010) | o.V.: Artikel "Steve Perlman", http://en.wikipedia.org/wiki/Steve_Perlman, 22.08.2010 |
| OnLive (2010) | OnLive (Hrsg.): Press Room, 2010, "http://www.onlive.com/press_room.html", 29.12.2010, 14:22 |
| OnLive (2010) | OnLive (Hrsg.): How OnLive works, 2010, "http://www.onlive.com/service/how_onlive_works.html", 29.12.2010, 14:23 |
Monographien:
| Neumann (2008) | Frank Neumann: Komprimierungsverfahren bei Videosequenzen in Multimedia-Anwendungen: Beschleunigung des MPEG-Encoding-Prozesses durch Verwendung dedizierter 3D-Grafikhardware, GWV Fachverlag, Oldenburg, 2008, |
| Baun (2010) | Baun, C.; Kunze, M.; Nimis, J.; Tai, S.: Informatik im Fokus – Cloud Computing, Web-basierte dynamische IT-Services, Springer, Heidelberg 2010 |
| Bohles (2008) | Christoph Meinel,Harald Sack: Digitale Kommunikation: Vernetzen, Multimedia, Sicherheit, Springer-verlag Berlin Heidelberg 2009 |

