PC Player forever

Abdiel hat geschrieben:

"So, let's say that Grand Theft Auto V is released..."

Was hängst du dich denn jetzt daran auf? Das soll doch nur ein Beispiel für irgendein zukpnftiges Spiel sein, dass Unmengen von Leute sofort zocken wollen werden.

Ganon hat geschrieben:

Was mir dabei auffällt: Das Problem fällt jedem als erstes ein. Da kann man doch irgendwie annehmen, dass die Macher sich da auch besonders viel Gedanken über eine Lösung gemacht haben.

Wieso, das ist doch nicht deren Problem. Wenn ich bei ET einen schlechten Ping habe, kann ich den Serverbetreiber ja auch nicht belangen.

Natürlich ist das deren Problem. Denn wenn es nicht einwandfrei funktioniert, verlieren sie massenhaft Kunden.

Vom Rest hab ich nicht genug Ahnung, deswegen sag ich dazu nichts. Wie er auf die 1000 fps gekommen ist, hat mich aber auch gewundert...

Abdiel hat geschrieben:

More than that, OnLive overlord Steve Perlmen has said that the latency introduced by the encoder is 1ms. Think about that; he's saying that the OnLive encoder runs at 1000fps.

wtf? Die Verzögerungszeit durch das Encoding beträgt 1 ms, aber es bleiben trotzdem immer nur 60 fps die es zu verarbeiten gilt.

Da hatte ich auch ganz kurz gestutzt, es ist jedoch eine ganz simple Rechnung: Das Spiel berechnet die Bilder in 60 fps. Ist so ein Bild berechnet, braucht der Encoder jedoch nur 1ms, das berechnete Bild in ein über Internet übertragbares Format umzurechnen (Zumindest, wenn man den Angaben Glauben schenken darf). Sprich der Encoder könnte bei der Geschwindigkeit mal eben 1000 Bilder/Sekunde encoden. Das ist schon etwas mehr als 60 fps...

Nötig wäre die Geschwindigkeit natürlich nicht. Selbst wenn der Encoder 10ms braucht, wäre ein Bild immer noch schneller encoded, als der Grafikprozessor das nächste berechnet hat. Ich glaube nicht, dass das einen großen Unterschied macht, sieht man davon ab, dass es natürlich am besten ist, wenn jede Verzögerung so gering wie irgend möglich ist.

Hier ist noch so ein Artikel: http://www.gamesindustry.biz/articles/going-live_2

Frogo hat geschrieben:

Da hatte ich auch ganz kurz gestutzt, es ist jedoch eine ganz simple Rechnung: Das Spiel berechnet die Bilder in 60 fps. Ist so ein Bild berechnet, braucht der Encoder jedoch nur 1ms, das berechnete Bild in ein über Internet übertragbares Format umzurechnen (Zumindest, wenn man den Angaben Glauben schenken darf). Sprich der Encoder könnte bei der Geschwindigkeit mal eben 1000 Bilder/Sekunde encoden. Das ist schon etwas mehr als 60 fps...

Das wird nirgends behauptet und gerade da fehlen am Ende auch die fachlichen Angaben, um diese Rechnung nachvollziehen zu können. Anscheinend geht der Autor des Artikels davon aus das immer die Vollbilder kodiert und anschließend übertragen werden, nur warum das so sein muss, enthält er den Lesern natürlich vor. Wenn man einen Schwindel entlarven möchte, dann spart man doch nicht mit Infos, aber genau da fehlt der Inhalt. Ebenso ist mir aufgefallen, dass man sich zwar an den Maximalangaben hochzieht, die SD-Variante am Ende aber als durchaus machbar angesehen wird, auch wenn das nur in Nebensätzen Erwähnung findet. Am Ende wird wie immer der Praxistest den Beweis erbringen, von daher wird sich alsbald ein belegbares Ergebnis vorweisen lassen, das man dann auch entsprechend beurteilen kann, Pressegeschwätz hin, verbohrter Zweifler her...

Abdiel hat geschrieben:

Das wird nirgends behauptet und gerade da fehlen am Ende auch die fachlichen Angaben, um diese Rechnung nachvollziehen zu können.

Wie würdest du denn die Aussage interpretieren, dass der Encoder nur eine Verzögerung von 1ms liefert?

Frogo hat geschrieben:

Wie würdest du denn die Aussage interpretieren, dass der Encoder nur eine Verzögerung von 1ms liefert?

Das pro Frame nur eine Verzögerung von 1 ms auftritt, jedoch wird nicht gesagt ob auch immer das komplette Bild kodiert wird. Schon mal an zeilenweise Verarbeitung gedacht? An einen Monitor werden ja auch keine Vollbilder geschickt, warum sollte das nicht auch eher in der Signalkette möglich sein?

Abdiel hat geschrieben:

Frogo hat geschrieben:

Wie würdest du denn die Aussage interpretieren, dass der Encoder nur eine Verzögerung von 1ms liefert?

Das pro Frame nur eine Verzögerung von 1 ms auftritt, jedoch wird nicht gesagt ob auch immer das komplette Bild kodiert wird. Schon mal an zeilenweise Verarbeitung gedacht? An einen Monitor werden ja auch keine Vollbilder geschickt, warum sollte das nicht auch eher in der Signalkette möglich sein?

Was ist denn ein Frame? Warum soll bei zeilenweiser Verarbeitung die Geschwindigkeit eher möglich sein? Oder zählt da die Zeit nur bei der ersten Zeile, die letzte ist dann eben 20ms verzögert? Außerdem habe ich auch nie an komplette Encodierung des gesamten Frames gedacht, das macht ja auch sonst kein Video-Codec. Da gibt's zwar regelmäßig den ganzen Frame, aber dazwischen nur Diffs, hier erwarte ich eigentlich nichts anderes, es sei denn, sie haben wirklich eine bahnbrechende Alternative entwickelt. Wobei man dann aber wirklich zurecht fragen darf, warum sie das nicht anderweitig kommerziell nutzen.

Davon ab halte ich die 1ms irgendwie immer noch für übertrieben (nicht dass es nicht möglich sein soll, sondern unnötig), bei 60fps ist doch kein wesentlicher Unterschied, ob es 1ms oder 15ms sind, oder irre ich da?

Frogo hat geschrieben:

Davon ab halte ich die 1ms irgendwie immer noch für übertrieben (nicht dass es nicht möglich sein soll, sondern unnötig), bei 60fps ist doch kein wesentlicher Unterschied, ob es 1ms oder 15ms sind, oder irre ich da?

Naja, bei 60fps muss aller 16,6ms ein Frame generiert werden und da würde eine Latenz von 15ms den Zeitraum bis zur Ausgabe ja fast verdoppeln. Ob und wie sich das am Ende auswirkt ist eine andere Frage, aber ich kann mir durchaus vorstellen, dass man die beherrschbaren Verzögerungen so gering wie möglich zu halten versucht, um andere Unwägbarkeiten z.B. bei der Übertragung kompensieren zu können.

Außerdem habe ich auch nie an komplette Encodierung des gesamten Frames gedacht, das macht ja auch sonst kein Video-Codec. Da gibt's zwar regelmäßig den ganzen Frame, aber dazwischen nur Diffs, hier erwarte ich eigentlich nichts anderes, es sei denn, sie haben wirklich eine bahnbrechende Alternative entwickelt.

Auch bei der heute angewandten Differenzmethode wird immer der gesamte Frame in Relation zum vorherigen betrachtet und verarbeitet, jedoch reduziert sich dadurch der Berechnungsaufwand im Vergleich zu einem Frame mit vollständigen Informationen. Trotzdem handelt es sich immer noch um ein ausreichend großes Datenaufkommen und genau das wird ja von den Kritikern auch bemängelt.

Grundsätzlich stellt sich mir die Frage, welche Bandbreite ein konventionell mit H.264 kodierter Film in FullHD mit 60fps braucht. Liegt OnLive darüber, dann opfern sie die Kompressionsrate zugunsten höherer Geschwindigkeit, liegen sie darunter, sind die Zweifel durchaus berechtigt. Es gibt übrigens Videokonferenzsysteme, die FullHD mit 30fps in H.264 übermitteln können. Die Bandbreiten liegen in etwa dem Rahmen, den auch Onlive angibt, nur über die Latenzen hab ich leider nichts gefunden...

Gut, mir ist natürlich schon klar, dass es besser ist, je geringer die Latenz ist, und 15ms macht eben schon fast ein Frame aus, das, wenn man die restlichen Latenzen berücksichtigt, vielleicht doch einen Unterschied machen kann (und sei er nur psychologisch). Da habe ich vielleicht auch zu breit gegriffen, denn ich denke trotzdem, dass es zumindest im Bereich <5ms keinen wesentlichen Unterschied macht, und das bedeutet immerhin einen Unterschied von 400%.

Aber schlussendlich ist es wurscht, da dieses Detail nicht ausschlaggebend sein wird, da zu viele Faktoren insgesamt betrachtet werden müssen, die da potentiell schwierig sind. Die müssen erstmal alle gemeistert werden, wenn man wirklich Spiele in aktueller PC-Qualität über das Internet spielen können soll. Kurz: Warten wir doch einfach ab . Bei der Red-Kamera hat ja auch niemand für möglich gehalten, dass das funtkionieren soll

An der RED hab ich persönlich nicht gezweifelt, jedoch waren die anfänglichen Angaben teilweise schon recht optimistisch formuliert (z.B. der Preis). Bei OnLive das Gleiche: Grundsätzlich halte ich die Idee für absolut machbar, nur was am Ende genau herauskommt, wird sich erst noch zeigen müssen.

Noch mal etwas zu der Kritik bezüglich Echtzeitencoding von H.264: Anscheinend hat Matrox damit kein Problem. Hätte mich auch stark gewundert, jedoch bestätigen sich die Befürchtungen hinsichtlich der benötigten Bandbreite (in der HD-Spalte geht es bei 1 MBit los).

Von OnLive liest man in letzter Zeit wenig, aber die Konkurrenz schläft nicht. Dave Perry (früher bekant durch Shiny) enthüllte jetzt "Gaikai". Ein Vorführvideo und ein Interview gibt's hier.
Visionen hat der Mann auf jeden Fall. Ob die realistisch sind, ist wieder die andere Frage...

Leider gibt auch diese Vorführung keinen Aufschluss darüber, inwieweit man die Verzögerung in den Griff bekommen kann. Schade, aber immerhin zeigt das Engagement von Perry, dass diesem Geschäftsmodell ernsthafte Chancen eingeräumt werden. Das wird zwar nie etwas für Hardcore-Spieler sein, aber die höchsten Margen erzielt man ja eh in einem anderen Segment. Und ein "Game On Demand"-Dienst wirft da weit mehr ab, als der Verkauf der Titel, sofern er zufriedenstellend funktioniert...

ich finde es nach reiflicher überlegung für mich uninteressant. dazu bin ich zu oldskool/nischengamer.

KylRoy hat geschrieben:

ich finde es nach reiflicher überlegung für mich uninteressant. dazu bin ich zu oldskool/nischengamer.

Andererseits ist gerade digitale Distribution (und Gaikai ist ja im Grunde ien Variante davon) interessant für kleinere Entwickler, die Nischengenres bedienen, da das finanzielle Risiko gegenüber einer Retail-Veröffentlichung geringer ist. Sieht man aj an der großen Anzahl an Indie-Veröffentlichungen über Steam. Ok, das sind meist simplere Spielchen, keine komplexen Simulationen o.ä., aber vielleicht sieht das mit Gaikai oder OnLive ja anders aus, zumal Hardware-Anforderungen keine Rolle spielen.