DE102013114633B4

DE102013114633B4 - Netzwerk-adaptive Latenzzeit-Verringerung durch Framerate-Steuerung

Info

Publication number: DE102013114633B4
Application number: DE102013114633.3A
Authority: DE
Inventors: Tony Tamasi; Xun Wang; Franck Diard
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2012-12-27
Filing date: 2013-12-20
Publication date: 2019-12-05
Anticipated expiration: 2033-12-21
Also published as: CN110460496A; CN103905836A; US20200195541A1; US11012338B2; US11683253B2; DE102013114633A1; US20200244559A1; US10999174B2; US20210226877A1; TW201440507A; US20140189091A1; US10616086B2

Abstract

Verfahren zum Bereitstellen eines Signals, wobei das Verfahren aufweist:Rendern einer Mehrzahl von Bildframes mit einer Rendering-Framerate in einem Prozessor eines Computersystems;Kodieren der Mehrzahl der Bildframes in Video-Information;Streamen der Video-Information über eine Netzwerkverbindung zu einer Recheneinrichtung;Überwachen einer Netzwerk-Latenzzeit, die der Netzwerkverbindung entspricht; unddynamisches Einstellen der Rendering-Framerate abhängig von der überwachten Netzwerk-Latenzzeit,wobei die Rendering-Framerate erhöht wird, wenn sich die Netzwerk-Latenzzeit erhöht,wobei die Rendering-Framerate verringert wird, wenn sich die Netzwerk-Latenzzeit verringert,wobei die Recheneinrichtung entfernt von dem Computersystem lokalisiert ist und mit dem Computersystem über die Netzwerkverbindung kommunikativ gekoppelt ist,wobei ferner die Video-Information dazu ausgelegt ist, in der Recheneinrichtung dekodiert zu werden und in einem Anzeigegerät, das zu der Recheneinrichtung gehört, mit einer Anzeige-Framerate angezeigt zu werden.

Description

Die US 2012/0004040 A1 beschreibt ein Computersystem, das einen ausführbaren Inhalt parallel mit einem Videostream bereitstellt. Dabei kann eine Framerate des Videos angepasst werden, um eine größere Bandbreite verfügbar zu haben, um den Inhalt herunterzuladen.
Die US 2008/0267069 A1 beschreibt eine Signalanpassung abhängig von einer Latenz.
Die US 2010/0063992 A1 beschreibt das Rendern eines Bildes, um eine Netzwerk-Latenz zu verbergen.
Die US 2011/0263332 A1 offenbart die Bereitstellung von Spieldiensten. Dabei kann eine Benutzer-Latenz verringert werden, indem individuelle Video-Frames schneller gerendert werden.
Die US 2011/0276710 A1 beschreibt ein System und ein Verfahren zum Multimedia-Streaming mit einer geringen Latenz.
Die US 2011/0058554 A1 beschreibt ein System und ein Verfahren zur Verbesserung der Qualität beim Streamen von Echtzeitdaten.
Die US 2012/0254456 A1 offenbart ein Speicherformat einer Mediendatei und ein adaptives Zulieferungssystem.
Cloudbasierte Datenverarbeitung stellt Datenverarbeitung, Kapazität und Speicher auf Anfrage bereit. Typische cloudbasierte EDV-Dienste ermöglichen es einem Benutzer, eine nahezu unbegrenzte Menge von EDV-Ressourcen auf Anfrage aus einem Pool von gemeinsam benutzten EDV-Ressourcen abzufragen und anzufordern. Häufig bestehen diese Ressourcen aus virtualisierten Instanzen von tatsächlichen Computer-Hardware-Systemen (z.B. Servern).
Dienstleister für Cloudcomputing können viele verschiedene Arten von cloudbasierten Diensten umfassen. Ein Gebiet mit zunehmender Beliebtheit im Cloudcomputing ist cloudbasiertes Spielen. Cloudbasiertes Spielen, auch Spielen auf Anfrage genannt, ist eine Art von Online-Spielen, die direktes und auf Anforderung ausgeführtes Streamen bzw. fortlaufendes Übertragen von Spielen auf einen Computer oder ein anderes elektronisches Gerät ermöglicht, typischerweise über ein Netzwerk, wie etwa das Internet. In herkömmlicher Weise speichert ein Videospiel, das von einem Dienstleister für cloudbasiertes Spielen bereitgestellt wird, die Software des Videospiels auf einem oder mehreren Servern. Wenn ein Benutzer auf die Server zugreift - typischerweise über eine Netzwerkverbindung - wird die Software ausgeführt und die resultierenden grafischen Ausgaben werden auf den Computer oder das Anzeigegerät des Benutzers gestreamt.
Allgemein wird das tatsächliche Vorlegen bzw. Ausgeben und Verarbeiten der Bilder, die den grafischen Inhalt bilden, der dem Benutzer angezeigt wird, auch in den Servern ausgeführt, bevor sie kodiert (komprimiert) werden und dann zu den Einrichtungen des Benutzers übertragen (gestreamt) werden, wobei der kodierte Video-Stream anschließend dekodiert und angezeigt wird. Steuerungseingaben des Benutzers - typischerweise in Antwort auf den Fortgang der angezeigten Bilder - kann von dem Benutzer empfangen und direkt zurück zu dem Server übertragen werden, woraufhin die Eingabe aufgezeichnet wird und eine neue Menge von Bildern verarbeitet, vorgelegt, kodiert und dann zurück zu dem Benutzer oder der „Client“-Einrichtung gestreamt wird. Dieser Vorgang kann für jeden Benutzer kontinuierlich ausgeführt werden, und häufig für im Wesentlichen die Gesamtheit der Zeit, während der das Videospiel von dem Benutzer gespielt wird.
Cloudbasiertes Spielen ermöglicht es den Benutzern, Spiele abzurufen, ohne das Erfordernis einer zweckbestimmten Spielkonsole oder eines Spielsystems, und eliminiert höhere Hardware-Anforderungen an die Computersysteme der Benutzer zu einem großen Teil, indem die Mehrheit der Speicher- und Prozessorerfordernisse von den Benutzergeräten auf die Server abgezogen wird. Ferner wird die Zeit, die zum Downloaden und Installieren des Videospiels auf den lokalen Geräten des Benutzers erforderlich ist, eliminiert, weil die Software auf den Servern des Spielbetreibers bereits vorgeladen ist.
Unglücklicherweise wird durch das cloudbasierte Spielen auch eine Menge neuer Herausforderungen über herkömmliche, lokalisierte Spiellösungen hinaus eingeführt. Beispielsweise sind zusätzliche Schritte erforderlich, um die grafische Ausgabe zur Anzeige vorzubereiten, wie etwa das kontinuierliche Komprimieren des Videos in Echtzeit, das Dekomprimieren des Videos in dem Client-Gerät des Benutzers und das fortlaufende Streamen von Daten über eine Netzwerkverbindung. Die Herausforderungen, diese Schritte schnell und effizient genug auszuführen, so dass sie die Erfahrung des Benutzers nicht merkbar beeinflussen, während Begrenzungen aufgrund der Netzwerkinfrastruktur ausgeglichen werden, ist enorm.
Ein quantifizierbares Maß dieser Effizienz ist die von dem Benutzer erfahrene Latenzzeit. Latenzzeit ist ein Maß für die Reaktionsfreudigkeit der Benutzereingaben zu dem Server und zurück, und kann durch ein großes Maß von Variablen beeinflusst sein, einschließlich wie schnell der Server läuft, die Effizienz der Software und Hardware, die auf dem Server läuft, die Netzwerkinfrastruktur und der Abstand, den das Netzwerk zu den Benutzergeräten auf der Client-Seite reisen muss. Je weiter das Benutzergerät von dem Server entfernt ist, beispielsweise entweder in Abstand oder in Netzwerksprüngen oder Netzwerkqualität, desto mehr Latenzzeit, die aufgrund der längeren Übertragung oder Routing-Zeiten eingeführt werden kann. Lange Latenzzeiten, häufig von Videospiel-Nutzern als Nachhinken bezeichnet, sind nicht wünschenswert, insbesondere während konkurrierender Spiele und/oder Zeit-sensitiver Interaktionen in Spielen, und können einen signifikant negativen Einfluss auf die Benutzererfahrung haben.
Unglücklicherweise berücksichtigen viele herkömmliche cloudbasierte Spielsysteme dem Netzwerk zuzuordnende Latenzzeit überhaupt nicht, indem sie diese als nicht vermeidbar oder unausweichlich betrachten.
Bestenfalls können Betreiber von cloudbasierten Spielen versuchen, Latenzzeiten zu steuern, indem sie zusätzliche Ressourcen auf der Server-Seite bereitstellen, um die Verarbeitung zu beschleunigen. Dies kann jedoch die Kapitalinvestitionskosten für die Spielbetreiber, möglicherweise untragbar, erhöhen und ist weder eine effiziente noch eine effektive Lösung. Noch andere Betreiber von cloudbasierten Spielen können versuchen, Latenzzeiten insgesamt zu vermeiden, indem sie die angebotenen Anwendungen begrenzen, entweder indem die Komplexität der Bilder, die vorgelegt bzw. ausgegeben werden, und die Größe und/oder die Frequenz der Datenübertragungen begrenzt werden, wobei nur Spiele mit asynchronen und/oder nicht mit der Zeitsteuerung zusammenhängenden Mechanismen bereitgestellt werden. Unglücklicherweise begrenzt dies auch die Wahlmöglichkeit der Benutzer für solche Videospiele und kann Benutzer davon abhalten, auf eine gefülltere Bibliothek mit Software-Entertainment zuzugreifen.
ZUSAMMENFASSUNG
Die vorliegende Erfindung stellt sich die Aufgabe, die Qualität oder Dienstgüte (Quality of Service) bei cloudbasierten Online-Spielen mit einem möglichst effektiven Einsatz von Rechenmitteln im Wesentlichen konstant zu halten.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren zum Bereitstellen eines Signals nach Anspruch 1 und durch ein System nach Anspruch 12 gelöst.
Diese Zusammenfassung wird bereitgestellt, um eine Auswahl von Konzepten in einer vereinfachten Form vorzustellen, die nachfolgend in der ausführlichen Beschreibung näher beschrieben wird. Diese Zusammenfassung ist nicht dazu gedacht, Schlüsselmerkmale oder wesentliche Merkmale der beanspruchten Gegenstände zu identifizieren, noch ist sie dazu gedacht, dazu verwendet zu werden, den Schutzumfang der beanspruchten Gegenstände zu beschränken.
Ausführungsformen der beanspruchten Gegenstände richten sich auf Verfahren und Systeme, die die Abgabe einer konsistenteren Dienstgüte, hinsichtlich der Latenzzeit für das cloudbasierte Vorlegen bzw. Ausgeben, zu ermöglichen, indem vorgelegte Bildfrequenzen bzw. Frameraten unter Verwendung von Bildfrequenz- bzw. Framerate-Kappung moderiert werden, um im Hinblick auf Einsparungen (oder Überschüssen) von Netzwerk-Latenzzeit zu optimieren. In weiteren Ausführungsformen kann auch die kodierte/gesendete Framerate an den Client gesteuert werden, zusätzlich oder als eine Alternative zum Kappen der vorgelegten Frameraten. Die beanspruchten Ausführungsformen halten nicht nur eine konstante Dienstgüte (QoS, Quality of Service) für den Benutzer aufrecht, sondern können auch dafür verwendet werden, gut funktionierende Netzwerke wirksam einzusetzen, um Betriebskosten zu verringern.
Gemäß einem Aspekt der Erfindung wird ein cloudbasiertes Spielsystem bereitgestellt, das ein Verfahren zum Moderieren von vorgelegten Frameraten implementiert, um Netzwerk-Latenzzeit zu optimieren. In einer Ausführungsform wird die Latenzzeit eines Netzwerks überwacht, und basiert auf der überwachten Latenzzeit wird die Framerate des Vorlegers des Bildes entweder erhöht, um relativ schlechte Netzwerk-Latenzzeit zu kompensieren, oder erniedrigt, um ein gut funktionierendes Netzwerk wirksam einzusetzen und den Grad des Leistungsverbrauchs verringern, während für den Benutzer eine konstante Latenzzeit-Erfahrung aufrechterhalten wird. Das Überwachen der Netzwerk-Latenzzeit kann in Echtzeit ausgeführt werden, und die Änderungen der vorgelegten Framerate kann dynamisch ausgeführt werden, während sich Netzwerk- und/oder Spielbedingungen ändern.
Weil ein wesentlicher Anteil der Latenzzeit für cloudbasiertes Vorlegen bzw. Ausgeben der Netzwerk-Infrastruktur zwischen einem Benutzer und dem cloudbasierten Spieldatenzentrum (das möglicherweise einen hohen Grad an Variabilität aufgrund des Abstands von dem cloudbasierten Datenzentrum aufweist) zugeschrieben werden kann, kann das Vergrößern von vorgelegten Frameraten zum Kompensieren von schlechten NetzwerkBedingungen dazu verwendet werden, eine konsistentere Dienstqualität auszugeben. In ähnlicher Weise kann für Benutzer mit besser funktionierenden Netzwerkverbindungen die Vorlage- bzw. Ausgabe-Framerate auf die minimale oder nahezu minimale Framerate, die gerade noch eine konstante angezeigte Framerate sicherstellt, entspannt (verringert) werden.
Typischerweise werden Videospiele mit einer konstanten und vorbestimmten Framerate angezeigt. Herkömmlicherweise entspricht diese Frequenz der Anzahl der angezeigten Datenübertragungsblöcke pro Sekunde (häufig abgekürzt als „fps“, Frames Per Second) auf dem Client-Gerät des Benutzers, und ist häufig auf 30, 60 oder 75 Datenübertragungsblöcke pro Sekunde eingestellt, obwohl Frameraten von 100 bis 200 fps oder höher nicht unbekannt sind. Wenn die Netzwerkbedingungen vorteilhaft sind - d.h., wenn die dem Netzwerk zuzuschreibende Latenzzeit relativ niedrig ist, - können die Bilder am Server mit einer Frequenz unterhalb der Fähigkeit des Servers, oder sogar mit der voreingestellten Vorlage-Framerate verarbeitet und vorgelegt werden, solange die Bilder nach dem Kodieren und Streamen über das Netzwerk kontinuierlich mit der vorbestimmten Framerate angezeigt werden können. Wenn er auf einer niedrigeren Framerate (Bilder) vorlegt, benötigt der Server weniger Leistung um betrieben zu werden, und kann folglich mit der Zeit signifikante Einsparungen bei den Betriebskosten erfahren.
Figurenliste
Die beigefügten Zeichnungen, die aufgenommen werden in und einen Teil ausbilden von dieser Beschreibung, veranschaulichen Ausführungsformen der Erfindung, und dienen zusammen mit der Beschreibung dazu, Merkmale der Offenbarung zu erläutern:

1 ist ein Blockdiagramm von einem cloudbasierten Spielabrufmodell gemäß verschiedener Ausführungsformen des beanspruchten Gegenstands.
2 ist ein Blockdiagramm einer cloudbasierten SpielserverArchitektur gemäß herkömmlicher Praxis.
3 ist eine Darstellung eines Ablaufdiagramms zum dynamischen Einstellen von Vorlage-Frameraten in einem cloudbasierten Spielserver gemäß verschiedener Ausführungsformen des beanspruchten Gegenstandes.
4 ist eine Darstellung eines Ablaufdiagramms zum Anzeigen von grafischer Ausgabe mit dynamisch eingestellten Vorlage-Frameraten, gemäß verschiedener Ausführungsformen des beanspruchten Gegenstands.
5 ist ein Blockdiagramm eines beispielhaften Computersystems gemäß verschiedener Ausführungsformen des beanspruchten Gegenstandes.

AUSFÜHRLICHE BESCHREIBUNG
Es wird nun in Einzelheiten verwiesen auf Ausführungsformen des beanspruchten Gegenstands zum Steuern von Anwendungen, um einer niedrige und/oder gefährdete Bandbreite in einem cloudbasierten Datenzentrum, von dem Beispiele in den beigefügten Zeichnungen veranschaulicht sind, zu vermeiden. Während der beanspruchte Gegenstand im Zusammenhang mit den offenbarten Ausführungsformen beschrieben wird, so wird verstanden werden, dass diese nicht dazu gedacht sind, diese Ausführungsformen zu begrenzen. Im Gegenteil, der beanspruchte Gegenstand ist dazu gedacht, Alternativen, Modifikationen und Äquivalente abzudecken, die innerhalb des Geistes und des Schutzumfangs, wie er durch die beigefügten Ansprüche definiert ist, umfasst sind.
Ferner werden in den folgenden ausführlichen Beschreibungen von Ausführungsformen des beanspruchten Gegenstandes vielzählige spezifische Einzelheiten dargelegt, um ein tiefgehendes Verständnis des beanspruchten Gegenstandes bereitzustellen. Es wird jedoch von einem gewöhnlichen Fachmann erkannt, dass der beanspruchte Gegenstand ohne diese spezifischen Einzelheiten ausgeführt werden kann. In anderen Fällen wurden bekannte Verfahren, Prozeduren, Komponenten und Schaltkreise nicht in Einzelheiten beschrieben, um Aspekte des beanspruchten Gegenstands nicht unnötig zu verschleiern.
Einige Teile der ausführlichen Beschreibung, die nachfolgt, sind durch Prozeduren, Schritte, Logikblocks, Datenverarbeitung und andere symbolische Darstellungen von Operationen auf Datenbits, die in einem Computerspeicher ausgeführt werden können, dargestellt. Diese Beschreibungen und Darstellungen sind die Mittel, die von den Fachleuten auf dem Gebiet der Datenverarbeitung verwendet werden, um das Wesen ihrer Arbeit an andere Fachleute auf dem Gebiet am effektivsten weitergeben können. Eine Prozedur, ein computererzeugter Schritt, ein Logikblock, ein Prozess, usw. wird hier und allgemein als eine selbst-konsistente Abfolge von Schritten oder Befehlen, die zu einem gewünschten Ergebnis führen, verstanden. Die Schritte sind solche, die physikalische Manipulationen von physikalischen Größen erfordern. Normalerweise, jedoch nicht notwendigerweise, nehmen diese Größen die Form von elektrischen oder magnetischen Signalen an, die dazu ausgebildet sind, gespeichert, übertragen, kombiniert, verglichen oder in anderer Weise in einem Computersystem manipuliert zu werden. Es hat sich gelegentlich als zweckmäßig erwiesen, hauptsächlich aus Gründen der allgemeinen Verwendung, diese Signale als Bits, Werte, Elemente, Symbole, Zeichen, Ausdrücke, Zahlen oder dergleichen zu bezeichnen.
Es sollte jedoch im Gedächtnis behalten werden, dass alle diese und ähnlichen Ausdrücke mit den zweckdienlichen physikalischen Größen in Zusammenhang zu bringen sind und lediglich für diese Größen angewendete, zweckdienliche Bezeichnungen sind. Außer, wenn dies anders als aus den folgenden Erörterungen offensichtlich spezifisch erwähnt wird, wird gewürdigt, dass in dem gesamten, vorliegenden, beanspruchten Gegenstand Erörterungen, die Ausdrücke, wie etwa „speichern“, „erzeugen“, „schützen“, „empfangen“, „verschlüsseln“, „entschlüsseln“, „zerstören“ oder dergleichen verwenden, Aktionen und Prozesse eines Computersystems oder eines integrierten Schaltkreises oder einer vergleichbaren elektronischen Recheneinrichtung, einschließlich eines eingebetteten Systems, bezeichnen, das bzw. die Daten manipuliert und transformiert, die als physikalische (elektronische) Größen innerhalb der Register und Speicher des Computersystems in andere Daten, die in ähnlicher Weise als physikalische Größen innerhalb der Speicher oder Register innerhalb des Computersystems oder anderen derartigen Informations-Speichern, Übertragungs- oder Anzeigegeräten dargestellt sind.
Cloudbasiertes Abrufmodell
1 ist eine Darstellung eines beispielhaften cloudbasierten Abrufmodells 100 gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie in 1 vorgestellt, kann das cloudbasierte Abrufmodell 100 ein cloudbasiertes Datenzentrum 101 mit einer Mehrzahl von Servern 103 umfassen, das mit einem Client-Gerät 109 über das Internet 199 kommunikativ gekoppelt bzw. verbunden ist. Gemäß verschiedener Ausführungsformen können ein oder mehrere Server 103 eine Mehrzahl von instanziierten, virtuellen Servern 105 umfassen. Die Server 103 können so ausgebildet sein, dass sie mehrere logische Partitionen umfassen, die den virtuellen Servern entsprechen, und auf denen eine oder mehrere Software-Anwendungen (z.B. Spiele) gehostet und ausgeführt werden können. Benutzer können die Spiele abrufen, indem sie sich mit den virtuellen Servern (z.B. über das Internet 199) verbinden, obwohl die tatsächliche Verarbeitung und Vorlage bzw. Ausgabe der grafischen Ausgabe auf dem physikalischen Server selbst ausgeführt werden kann.
Das Client-Gerät 109 kann eine Mehrzahl von Verbraucher- und persönlichen Elektronikgeräten umfassen. Beispiele der Client-Geräte 109 umfassen, sind jedoch nicht beschränkt auf: persönliche Arbeitsplatz- oder Laptop-Computer, mobile, zelluläre Hand-Geräte (z.B. Smartphones), Tablet-Computer-Geräte, Digital-Empfänger, (tragbare) Videospielkonsolgeräten, oder jedes beliebige andere Gerät, das in der Lage ist, einen vorab vorgelegten grafischen Inhalt anzuzeigen und Benutzereingaben zu empfangen. Das Client-Gerät 109 kann zu einem Lokal-Netzwerk (LAN) gehören und kann mit einem oder mehreren Netz-Kopplern (Gateways) des Internets 199 über einen Router und/oder Modem 107 verbunden sein. Gemäß einigen Ausführungsformen kann das Client-Gerät 109 ein Anzeigegerät, wie etwa einem Schirm oder einem kommunikativ verbundenen Monitor, umfassen und/oder damit kommunikativ gekoppelt sein.
In einer Ausführungsform kann ein Benutzer des Client-Geräts 109 eine cloudbasierte Spiele-Software-Anwendung abrufen, indem ein Teil einer Software auf dem Client-Gerät 109, das eine Netzwerkverbindung mit einem entsprechenden Server 103 in dem cloudbasierten Datenzentrum 101 herstellt, ausgeführt wird. In einigen Fällen kann eine grafische Benutzerschnittstelle erzeugt und angezeigt werden, die den Benutzer dazu auffordert, sich in die Server des Spielbetreibers (z.B. über einen Authentifizierungsprozess) einzuloggen. Einmal authentifiziert, kann eine Spielsitzung eingeleitet werden, und während der Spielsitzung kann grafischer Inhalt über die Netzwerkverbindung zwischen dem Client-Gerät 109 und einem Server 103 in dem cloudbasierten Datenzentrum 101 kontinuierlich übertragen werden. Der grafische Inhalt kann ein oder mehrere Serien von Bildern umfassen, die in einer oder mehreren, in dem Server 103 umfassten Grafikverarbeitungseinheiten (GPUs, Graphics Processing Units) auf einer oder mehreren variablen Vorlage-Frameraten verarbeitet und vorgelegt werden. Einmal vorgelegt, können die Bilder in ein kodiertes Video komprimiert, gepuffert und dann als eine Mehrzahl von Datenübertragungsblöcken gestreamt werden. Gemäß weiterer Ausführungsformen kann die Frequenz, mit der die Datenübertragungsblöcke aus dem Puffer gestreamt werden (d.h. die Streaming-Framerate), auch überwacht und variabel gesteuert werden.
Wenn die kodierten Daten in dem Client-Gerät 109 einmal empfangen sind, werden die Daten dekodiert (dekomprimiert) und dem Benutzer mit einer angezeigten Framerate angezeigt (z.B. in dem Anzeigegerät). Die angezeigte Framerate kann als ein Maß von Datenübertragungsblöcken pro Sekunde („fps“, Frames Per Second), das angezeigt wird (z.B. 30, 60, 90), ausgedrückt werden. Benutzereingaben, die in dem Client-Gerät 109 empfangen werden - über eine grafische Benutzerschnittstelle oder ein anderes Hardware-Eingabegerät, wie etwa eine Maus, eine Tastatur oder eine Steuereinrichtung - werden direkt zu dem Server 103 übertragen und die nächste Serie von Bildern in einer Sequenz oder neue Serie von Bildern, die auf eine Benutzereingabe reagierend sind, können verarbeitet, vorgelegt, kodiert und zurück zu dem Client-Gerät 109 gestreamt werden.
Gemäß einem Aspekt der vorliegenden Erfindung wird die Latenzzeit, die von einem Benutzer erfahren wird, d.h. die Zeitdauer, zwischen der die Benutzereingabe in dem Client-Gerät 109 empfangen wird und der Anzeige der nächsten Bildserie in dem Anzeigegerät, kontinuierlich überwacht. Die Latenzzeit kann von einer Mehrzahl von Faktoren beeinflusst sein, einschließlich der Vorlage-Framerate und/oder der Streaming-Framerate des Servers, der Effizienz der Netzwerkinfrastruktur zwischen dem cloudbasierten Datenzentrum 101 und dem Client-Gerät 109 und dem Abstand in dem Netzwerk (entweder der physikalische Abstand oder der „logische“ Abstand) zwischen dem cloudbasierten Datenzentrum 101 und dem Client-Gerät 109. Höhere Latenzzeiten können sich als eine Verzögerung (z.B. „Nachhinken“) zwischen der Benutzer-Aktion und der grafischen Antwort manifestieren und sind allgemein ungewünscht. Gemäß verschiedenen Ausführungsformen können eine oder beide der Vorlage-Frameraten und der Streaming-Framerate dynamisch erhöht werden, wenn eine Latenzzeit oberhalb eines bestimmten Schwellwerts detektiert wird.
Durch Erhöhen der Vorlage- und/oder Streaming-Framerate(en) nimmt die Zeitdauer, zum Herstellen und Vorlegen von jedem Datenübertragungsblock innerhalb des Servers, ab, was den Beitrag des Servers zur gesamten Latenzzeit verringert. Eine Verringerung von einigen wenigen Millisekunden pro ausgegebenem Datenübertragungsblock kompensiert eine äquivalente Zeitdauer andernorts in der Übertragungsschleife. Eine Ausgabe bei, beispielsweise, 30 fps (beispielsweise entsprechend der Anzeige-Framerate an dem Client-Gerät 109) erzeugt einen Datenübertragungsblock grob geschätzt einmal pro 33 ms. Ein Vergrößern der Vorlagefrequenz auf 60 fps, während die gleiche Anzeige-Framerate aufrechterhalten wird, verringert die Erzeugungszeit eines Datenübertragungsblocks auf grob etwa einmal pro 16 ms. Die 16 bis 17 Millisekunden „extra“ pro Datenübertragungsblock können dazu verwendet werden, Verzögerungen in der Netzwerkinfrastruktur, des Netzwerkabstands oder des Dekodierens in dem Client-Gerät 109 zu kompensieren.
Analog dazu, wenn aufgrund der Nähe zu dem Datenzentrum und/oder gut funktionierender Infrastruktur, die dem Netzwerk zugeordnete Latenzzeit kein Thema ist, dann können kodierte Videodaten, die auf einer Frequenz, die höher als die Anzeigefrequenz ist, empfangen und dekodiert werden und auf dem Client-Gerät gepuffert werden. Um zu verhindern, dass es dem Puffer möglich ist, außergewöhnlich voll zu werden, kann die Vorlage-Framerate gedrosselt, d.h. verringert, werden, weil die Extra-Erzeugung nicht länger erforderlich ist, um die Netzwerk-Latenzzeit zu kompensieren. Durch Verringern der Vorlage-Framerate können die Komponenten, die für das Verarbeiten und Vorlegen der Datenübertragungsblöcke verantwortlich sind (z.B. die Grafikverarbeitungseinheiten) in einen niedrigeren Leistungszustand versetzt werden und dadurch mit einer niedrigeren Rate Leistung zu verbrauchen. Typischerweise sind ein großer Anteil an den Kosten für einen Betreiber von cloudbasierten Spielen die Kosten zum Betreiben des Datenzentrums und der größte einzelne Faktor, der durch das Betreiben eines Datenzentrums anfällt, ist der erforderliche Energieverbrauch. Folglich kann das wirksame Einsetzen von Hochleistungsnetzwerkverbindungen, um die Effizienz des Leistungsverbrauchs zu erhöhen, zu wesentlichen Einsparungen für die Betreiber von cloudbasierten Spielen führen.
Cloud basiertes Abrufmodell
2 ist eine Darstellung einer beispielhaften cloudbasierten Spielserverarchitektur 200 gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. Wie in 2 vorgestellt, kann die cloudbasierte Spielserverarchitektur 200 einen cloudbasierten Spielserver 201 umfassen, der über das Internet 299 mit einem Client-Gerät 209 kommunikativ gekoppelt bzw. verbunden ist. Wie in 2 dargestellt, umfasst der cloudbasierte Spielserver 201 eine Bildvorlagekomponente 203 (d.h. eine oder mehrere Grafikverarbeitungseinheiten), die betriebsfähig dafür sind, programmierte Befehle aus einem Datenspeicher (nicht gezeigt) zu empfangen und zu verarbeiten und gemäß der Befehle grafische Bilder vorzulegen bzw. auszugeben. Der cloudbasierte Spielserver 201 ist auch so dargestellt, dass er ein Serversteuerungsmodul 205 umfasst, das mit einer Ausgabekomponente 203 gekoppelt ist und dazu ausgebildet ist, die Latenzzeit der Daten, die über Netzwerkverbindungen zu Client-Geräten 209 gestreamt werden, und die Frequenz, mit der die Bilder durch die Ausgabekomponente 203 ausgegeben werden, basierend auf der überwachten Latenzzeit dynamisch einzustellen.
In einer Ausführungsform wird während einer Spielsitzung eine Netzwerkverbindung zwischen einem Client-Steuerungsmodul 211 in dem Client-Gerät 209 und einer Stream-Komponente 207 in dem Server 201 über das Internet 299 aufgebaut. Datenübertragungsblöcke, die von der Ausgabekomponente 203 vorgelegt bzw. ausgegeben werden, können in dem Server-Steuerungsmodul 205 empfangen und zu der Stream-Komponente 207 weitergeleitet werden. Die Stream-Komponente 207 kann die empfangenen Bilddaten in kodiertes Video kodieren und komprimieren, was die Stream-Komponente 207 dann mit der Zeit als eine Mehrzahl von Paketen an das Client-Steuerungsmodul 211 in dem Client-Gerät 209 überträgt. Eine Benutzereingabe (z.B. Steuergeräteeingabe), die in dem Client-Gerät 209 empfangen wird, wird dann zurück zu dem Server 201 weitergeleitet und aufgezeichnet, bevor auf programmierte Befehle hin, die der Benutzereingabe entsprechen, verwiesen wird und eine neue oder nächste Abfolge von Bildern verarbeitet und vorgelegt wird. Die Latenzzeit der Spielsitzung, einschließlich der Latenzzeit, die dem Netzwerk zuzuschreiben ist, und der Latenzzeit, die dem Herstellen des kodierten Video-Streams zuzuordnen ist, entspricht der Zeitdauer zwischen dem Empfang der Benutzereingabe in dem Client-Gerät 209 und der Anzeige der neuen oder nächsten Abfolge von Bildern in dem Client-Gerät 209, in Antwort auf die Benutzereingabe. Gemäß verschiedenen Ausführungsformen kann die Latenzzeit von dem Server-Steuerungsmodul 205 oder dem Client-Steuerungsmodul 211, das dann dem Server-Steuerungsmodul 205 die detektierte Latenzzeit meldet, überwacht werden.
Wenn die Latenzzeit groß ist - wie etwa oberhalb eines vorbestimmten Schwellwerts - kann das Server-Steuerungsmodul 205 den Leistungszustand der Ausgabekomponente 203 dynamisch nach oben abstimmen und die Vorlage-Framerate der Ausgabekomponente 203 vergrößern, um den Beitrag des Spielservers zur Latenzzeit zu verringern. Gleichermaßen kann die Stream-Komponente 205 die Stream-Frequenz auch gesondert oder zusätzlich zur Vergrößerung der Vorlage-Framerate der Ausgabekomponente 203 vergrößern. Wenn die Latenzzeit niedrig ist - beispielsweise unterhalb eines zweiten vorbestimmten Schwellwerts - kann das Server-Steuerungsmodul 205 den Leistungszustand der Ausgabekomponente 203 kleiner einstellen, wobei die Vorlage-Framerate der Ausgabekomponente 203 effektiv plaffoniert bzw. gekappt wird, um den Beitrag des Spielservers zur Latenzzeit zu vergrößern, jedoch die von der Ausgabekomponente 203 verbrauchte Leistung zu verringern. Basierend auf der Bandbreite und der Latenzzeit zwischen dem Client und dem Server können die Bilder des Spiels mit einer Frequenz von N fps von der Ausgabekomponente 203 vorgelegt bzw. ausgegeben werden und mit einer Frequenz X von der Stream-Komponente 207 gestreamt werden. Gemäß einiger Ausführungsformen kann das Überwachen der Latenzzeit in Echtzeit ausgeführt werden und eine oder beide der Frameraten und die Kodier-/Dekodierfrequenz können dynamisch eingestellt werden. Gemäß noch weiterer Ausführungsformen können Datenübertragungen zwischen dem Server 201 und dem Client-Gerät 209, die während einer aktiven Spielsitzung durchgeführt werden, gemäß dem Echtzeittransportprotokoll (RTP, Real-Time Transport Protocol) ausgeführt werden. Unter RTP werden die Latenzzeit und Verluste von Datenübertragungsblöcken (aufgrund eines Einbruchs in der Bandbreite) fortlaufend gemessen. Diese Daten werden an die Stream-Komponente 207 kommuniziert und zu dem Server-Steuerungsmodul 205 weitergeleitet, der dann die Vorlage-Framerate des Spiels entsprechend modifizieren wird. In noch weiteren Ausführungsformen kann ein voreingestelltes Profil/eine Heuristik, die Werte für die Vorlage-, Stream- und/oder Anzeige-Framerate umfasst, erzeugt und pro Spiel gespeichert werden.
Dynamisches Einstellen von Vorlage-Frameraten in cloudbasierten Spielservern
3 ist eine Darstellung eines Ablaufdiagramms 300 zum dynamischen Einstellen von Vorlage-Frameraten in einem cloudbasierten Spielserver, gemäß einer Ausführungsform. Insbesondere beschreibt das Verfahren die Schritte, die ausgeführt werden, um die Herstellungsfrequenz von grafischen Bildern in Antwort auf detektierte Latenzzeit-Bedingungen dynamisch einzustellen. Die Schritte 301-309 beschreiben die Schritte, die den in dem Ablaufdiagramm 300 der 3 dargestellten Prozess umfassen. In einer Ausführungsform wird das Ablaufdiagramm 300 durch einen Server in einem cloudbasierten Datenzentrum ausgeführt.
In Schritt 301 wird eine Abfolge von grafischen Bildern verarbeitet und als Datenübertragungsblöcke vorgelegt bzw. ausgegeben. Die Grafikbilder können beispielsweise von einem zweckbestimmten Grafikprozessor, wie etwa eine Grafikverarbeitungseinheit, in einem Server eines cloudbasierten Datenzentrums vorgelegt werden. In einer Ausführungsform können die Grafikbilder mit einer vorbestimmten Vorlage-Framerate und gemäß programmierter Befehle in einem lokalen Datenspeicher ausgegeben werden. In noch anderen Ausführungsformen können die Grafikbilder auf der höchsten für den Grafik-Prozessor möglichen Vorlage-Framerate und/oder entsprechend dem aktuellen Leistungszustand des Grafikprozessors vorgelegt werden. Einmal vorgelegt, wird im Schritt 303 die Abfolge der Datenübertragungsblöcke in ein Video eines komprimierten Formats kodiert und als Video über eine Netzwerkverbindung gestreamt bzw. fortlaufend ausgegeben. In einer Ausführungsform wird bei 305 das Video auf einer zweiten, vorbestimmten Framerate, beispielsweise der Streaming-Framerate, gestreamt und kann über eine Mehrzahl von Internetprotokollen entsprechend verschiedenartiger Ausführungsformen gestreamt werden. Beispielsweise können diese Protokolle unter anderem Echtzeit-Protokoll (RTP, Real-time Protocol), Echtzeit-Streamingprotokoll (RTSP, Real-Time Streaming-Protocol), Sitzungseinleitungsprotokoll (SIP, Session Initiation Protocol), Hypertext-Transportprotokoll (HTTP, Hyper-Text Transport Protocol) umfassen. Das Streamen kann während einer Spielsitzung, die mit einem oder mehreren dieser Protokollen eingeleitet worden ist, ausgeführt werden und in einem Client-Gerät, das mit dem Server über ein Netzwerk, wie etwa das Internet, kommunikativ gekoppelt ist, empfangen werden.
Im Schritt 307 wird die Latenzzeit der Datenübertragungen während der Spielsitzung kontinuierlich überwacht. Das Überwachen kann wie folgt ausgeführt werden: kontinuierlich als periodische Intervalle, zum Begleiten von Ereignissen (z.B. erfolgreiche oder nicht erfolgreiche Übertragungen) und/oder in Antwort auf häufige, auslösende Ereignisse. Wenn bestimmt wird, dass die überwachte Latenzzeit innerhalb normaler Grenzen ist, d.h. eine oder mehrere vorbestimmte Schwellwerte nicht überschreitet, werden die Schritte 301-307 für die Dauer der Spielsitzung wiederholt. Wenn bestimmt wird, dass die überwachte Latenzzeit einen vorbestimmten Schwellwert überschreitet, d.h. wenn die Latenzzeit oberhalb eines ersten Schwellwerts ist, der die obere Begrenzung eines akzeptablen Latenzzeitgrades darstellt, wird die vorbestimmte Vorlage-Framerate dynamisch so angepasst, dass die nächste Abfolge von Bildern mit einer höheren Framerate vorgelegt wird. Wie oben beschrieben, verringert das Erhöhen der Vorlage- und/oder Streaming-Framerate(en) die Zeitdauer, die erforderlich dafür ist, jeden Datenübertragungsblock in dem Server herzustellen und vorzulegen, wobei der Beitrag des Servers zur gesamten Latenzzeit verringert wird. Wenn andererseits die Latenzzeit unter einem anderen Schwellwert ist, der das Vorhandensein eines Überschusses bei der Verarbeitungsgeschwindigkeit anzeigt, kann die Vorlage-Framerate für die nächste Abfolge von Bildern dynamisch so abgestimmt werden, dass die Datenübertragungsblöcke mit einer langsameren Frequenz hergestellt werden und dabei der Beitrag des Servers zur gesamten Latenzzeit vergrößert wird. Unter diesen Bedingungen kann verhindert werden, dass die Vorlage-Framerate unter eine minimale Framerate abfällt, die dafür erforderlich ist, eine konstante Dienstgüte für den Benutzer (z.B. ein Minimum von 30 fps angezeigt) aufrechtzuerhalten. In weiteren Ausführungsformen kann die Vorlage-Framerate auf die niedrigste Framerate verringert werden, die immer noch eine konsistente Dienstgüte bereitstellt. In weiteren Ausführungsformen können der Leistungszustand des die Vorlage ausführenden Grafikprozessors und/oder der Server selbst abgestimmt (erniedrigt) werden, um der eingestellten Vorlage-Framerate zu entsprechen.
Einmal eingestellt (entweder erhöht oder verringert), wird die nächste Abfolge von Datenübertragungsblöcken mit der eingestellten Framerate vorgelegt bzw. ausgegeben und die Schritte 301 bis 307 werden wiederholt. In weiteren Ausführungsformen kann die Anzeige der ausgegebenen Datenübertragungsblöcke von Benutzereingaben, die einer Benutzersteuerung entsprechen, begleitet sein. Gemäß derartiger Ausführungsformen kann die nächste Abfolge von Datenübertragungsblöcken in Antwort auf die Benutzereingabe und die eingestellte Vorlage-Framerate vorgelegt bzw. ausgegeben werden. In noch weiteren Ausführungsformen kann im Schritt 309 auch die Frequenz des im Schritt 305 ausgeführten Streamens für kodiertes Video, für denselben Zweck wie das Einstellen der Vorlage-Framerate, eingestellt werden.
Anzeigen von grafischer Ausgabe mit dynamisch eingestellten Vorlage-Frameraten
4 ist eine Darstellung eines Ablaufdiagramms 400 zum Anzeigen von grafischer Ausgabe mit dynamisch eingestellter Vorlage-Framerate, gemäß einer Ausführungsform. Insbesondere beschreibt das Verfahren die Schritte, die in einem Client-Gerät ausgeführt werden, um Bilder, die mit dynamisch eingestellter Vorlage-Framerate vorgelegt bzw. ausgegeben worden sind, anzuzeigen. Die Schritte 401-409 beschreiben die Schritte, die den in dem Ablaufdiagramm 400 der 4 dargestellten Prozess umfassen. In einer Ausführungsform wird das Ablaufdiagramm in einem Client-Gerät ausgeführt, das physikalisch eingebaute Anzeigeschirme und (drahtlose) Netzwerkfähigkeit aufweist und das folgendes umfassen kann (jedoch nicht begrenzt ist auf): mobile Smartphones, Laptop- oder Tablet-Computer, Mini-Computer bzw. Organizer, handhaltbare Videospielkonsolen. In noch weiteren Ausführungsformen wird das Ablaufdiagramm 400 in einem Client-Gerät mit einem kommunikativ gekoppelten Anzeigegerät ausgeführt. Unter diesen Ausführungsformen kann das Client-Gerät umfassen (jedoch nicht beschränkt sein auf): Personalcomputer, Digitalempfänger, Medienabspielgeräte, und Videospielkonsolen, mit kommunikativ gekoppelten Monitoren, Fernsehgeräten, Projektionsschirmen oder anderen Geräten, die in der Lage sind, grafische Ausgabe anzuzeigen.
Im Schritt 401 wird in einem Client-Gerät eine Benutzereingabe empfangen. Die Benutzereingabe kann in einem Benutzereingabegerät empfangen werden, das folgendes umfasst (jedoch nicht begrenzt ist auf): eine Steuereinrichtung, eine Maus oder eine Tastatur, oder über physikalische Eingabe-Geräte, wie beispielsweise Tasten bzw. Schaltflächen, analoge Steuerblöcke oder Trigger. Die Benutzereingabe kann auf grafische Ausgabe reagierend sein, die beispielsweise von einem Server in einem entfernt angeordneten, cloudbasierten Datenzentrum vorgelegt bzw. ausgegeben worden ist und über eine Netzwerkverbindung übertragen worden ist. In einer Ausführungsform kann der Empfang der Benutzereingabe in dem Client-Gerät verfolgt werden, z.B. als ein Signal zum Einleiten (oder Wiederaufnehmen) des Überwachens der Netzwerk-Latenzzeit. Im Schritt 403 wird die Benutzereingabe zu einem angeschlossenen Spielserver übertragen. Die Übertragung kann über eine Netzwerkverbindung und gemäß einem oder mehreren Datenübertragungsprotokollen ausgeführt werden. Gemäß einiger Ausführungsformen kann, wenn die Benutzereingabe in dem Spielserver empfangen wird, eine Abfolge von Bildern vorgelegt werden, die auf die empfangene Eingabe reagierend ist. Die Abfolge von Bildern kann dann als ein Video kodiert und über die Netzwerkverbindung gestreamt werden, wo sie im Schritt 405 durch das Client-Gerät empfangen wird. Anschließend werden im Schritt 407 die kodierten Daten dekodiert und schließlich im Schritt 409 in dem Anzeigegerät angezeigt. Wenn die empfangenen Daten einmal dekodiert und angezeigt sind, kann die Zeitdauer, seitdem die Benutzereingabe empfangen worden ist, gemessen und an den Spielserver als die bestimmte Latenzzeit kommuniziert werden. Der Spielserver kann basierend auf der kommunizierten Latenzzeit bestimmen, welcher Anteil der Latenzzeit der Netzwerkverbindung zuzuschreiben ist und kann entsprechend verschiedene interne Erzeugungs- oder Kommunikationsfrequenzen einstellen, wie hierin zuvor beschrieben ist.
Beispielhafte Recheneinrichtung
Wie in 5 vorgestellt, umfasst ein System, auf dem Ausführungsformen der vorliegenden Erfindung implementiert werden können, eine Mehrzweck-Computersystem-Umgebung, wie etwa ein Computersystem 500. In einer Ausführungsform kann ein Spielserver, wie etwa der oben mit Verweis auf die 1 und 2 beschriebene Server 103 und 201, als das Computersystem 500 implementiert sein. In alternativen Ausführungsformen kann ein Client-Gerät, wie etwa das ebenfalls oben mit Verweis auf die 1 und 2 beschriebene Client-Gerät 109 oder 209, anstelle von oder zusätzlich zu dem Spielserver, als Computersystem 500 implementiert werden. In seinem grundlegendsten Aufbau umfasst ein Computersystem 500 typischerweise zumindest eine Verarbeitungseinheit 501 und Datenspeicher, sowie einen Adress-/Datenbus 509 (oder eine andere Schnittstelle) zum Kommunizieren von Informationen. In Abhängigkeit vom genauen Aufbau und Typ der Computersystem-Umgebung kann der Datenspeicher flüchtig (wie etwa RAM 502), nicht-flüchtig (wie etwa ROM 503, Flash-Speicher, usw.) oder eine beliebige Kombination der beiden sein.
Das Computersystem 500 kann auch ein optionales Grafik-Teilsystem 505 umfassen zum Darstellen von Information an den Computernutzer, z.B. durch Anzeigen von Information auf einem angeschlossenen Anzeigegerät 501, das über ein Videokabel 511 angeschlossen ist. Gemäß Ausführungsformen der vorliegenden, beanspruchten Erfindung kann das Anzeigegerät physikalisch an dem Computersystem 500 montiert sein und mit dem Grafik-Teilsystem 505 gekoppelt sein. Alternativ kann das Grafik-Teilsystem 505 über das Videokabel 511 direkt mit dem Anzeigegerät 510 gekoppelt sein, oder indirekt über drahtlose Mittel. Das Computersystem 500, das als ein Spielserver implementiert ist, kann Grafikbilder in dem Grafik-Teilsystem 505 gemäß programmierter Befehle, die in dem Datenspeicher 502, 503 gespeichert und in der Verarbeitungs-Einheit 501 ausgeführt worden sind, verarbeiten und vorlegen bzw. ausgeben. Die von einem Spielserver produzierte Grafikausgabe kann in einem Client-Gerät, das als ein zweites Computersystem 500 implementiert ist, empfangen werden, in der Verarbeitungseinheit 501 des zweiten Computersystems 500 dekodiert werden und in dem Anzeigegerät 501 dem Benutzer angezeigt werden.
Nebenbei kann das Computersystem 500 auch zusätzliche Merkmale/Funktionalitäten aufweisen. Beispielsweise kann das Computersystem 500 auch zusätzlichen Speicher (entfernbar und/oder nicht-entfernbar) umfassen, was umfasst, jedoch nicht beschränkt ist auf, magnetische oder optische Platten oder Bänder. Derartiger zusätzlicher Speicher wird in 5 durch das Datenspeichergerät 507 dargestellt. Computerspeichermedien umfassen flüchtigen und nicht-flüchtigen, entfernbare und nicht-entfernbare Medien, die in einem beliebigen Verfahren oder einer beliebigen Technologie zum Speichern von Informationen, wie etwa computerlesbare Befehle, Datenstrukturen, Datenprogrammmodule oder andere Daten, implementiert sind. RAM 502, ROM 503 und Datenspeichergerät 507 sind alles Beispiele von Computerspeichermed ien.
Das Computersystem 500 umfasst auch optional ein alphanumerisches Eingabegerät 506, ein optionales Cursor-Steuerungs- oder - ausrichtungsgerät 507, und eine oder mehrere Signal-Kommunikationsschnittstellen (Eingabe-/Ausgabegeräte, z.B. eine Netzwerkschnittstellenkarte) 509. Ein optionales alphanumerisches Eingabegerät 506 kann Information und Befehlsauswahlen an die zentrale Verarbeitungs-Einheit 501 kommunizieren. Ein optionales Cursor-Steuerungs- oder -ausrichtungsgerät 507 ist zum Kommunizieren von Benutzereingabeinformation und Befehlsauswahlen an die zentrale Verarbeitungs-Einheit 501 an einem Bus 509 angeschlossen. Die Signalkommunikationsschnittstelle (Eingabe-/Ausgabegerät) 509, die auch an den Bus 509 angeschlossen ist, kann ein serieller Anschluss sein. Die Kommunikationsschnittstelle 509 kann auch drahtlose Kommunikationsmechanismen umfassen. Unter Verwendung der Kommunikationsschnittstelle 509 kann das Computersystem mit anderen Computersystemen über ein Kommunikationsnetzwerk, wie etwa beispielsweise das Internet oder ein Intranet (z.B. ein Lokal-Netzwerk), kommunikativ gekoppelt werden oder kann Daten empfangen (z.B. ein digitales Fernsehsignal).
Wie hierin beschrieben, wurden Ausführungsformen des beanspruchten Gegenstands geboten, die das Liefern einer konsistenten Dienstgüte, hinsichtlich der Latenzzeit, für cloudbasierte Spieldienstleistungen ermöglichen, und zwar durch Überwachen und Moderieren von vorgelegten Frameraten unter Verwendung von dynamischer Framerate-Einstellung zum Optimieren hinsichtlich Einsparungen (oder Überschüssen) von Netzwerk-Latenzzeit. Gemäß verschiedener Ausführungsformen kann auch die Kodier-/Streaming-Framerate zum Client ebenfalls zusammen mit, oder als eine Alternative zu, dem Steuern der vorgelegten Frameraten gesteuert werden. Die beanspruchten Ausführungsformen halten nicht nur eine konstante Dienstgüte für den Benutzer aufrecht, sondern können auch dafür eingesetzt werden, gut funktionierende Netzwerke wirksam dazu einzusetzen, Betriebskosten zu verringern. Obwohl die Inhalte in einer Sprache beschrieben worden sind, die für strukturelle Merkmale und/oder methodologische Vorgänge spezifisch ist, so sollte verstanden werden, dass der in den beigefügten Ansprüchen definierte Inhalt nicht notwendigerweise auf die oben beschriebenen, spezifischen Merkmale oder Vorgänge beschränkt ist. Vielmehr sind die oben beschriebenen, spezifischen Merkmale und Vorgänge als beispielhafte Ausbildungen zum Implementieren der Ansprüche offenbart.

Claims

Verfahren zum Bereitstellen eines Signals, wobei das Verfahren aufweist: Rendern einer Mehrzahl von Bildframes mit einer Rendering-Framerate in einem Prozessor eines Computersystems; Kodieren der Mehrzahl der Bildframes in Video-Information; Streamen der Video-Information über eine Netzwerkverbindung zu einer Recheneinrichtung; Überwachen einer Netzwerk-Latenzzeit, die der Netzwerkverbindung entspricht; und dynamisches Einstellen der Rendering-Framerate abhängig von der überwachten Netzwerk-Latenzzeit, wobei die Rendering-Framerate erhöht wird, wenn sich die Netzwerk-Latenzzeit erhöht, wobei die Rendering-Framerate verringert wird, wenn sich die Netzwerk-Latenzzeit verringert, wobei die Recheneinrichtung entfernt von dem Computersystem lokalisiert ist und mit dem Computersystem über die Netzwerkverbindung kommunikativ gekoppelt ist, wobei ferner die Video-Information dazu ausgelegt ist, in der Recheneinrichtung dekodiert zu werden und in einem Anzeigegerät, das zu der Recheneinrichtung gehört, mit einer Anzeige-Framerate angezeigt zu werden.
Verfahren nach Anspruch 1, wobei das Überwachen der Netzwerk-Latenzzeit, die der Netzwerkverbindung entspricht, umfasst: Vergleichen der Netzwerk-Latenzzeit mit einer ersten vorbestimmten Latenzzeit.
Verfahren nach Anspruch 2, wobei das dynamische Abstimmen der Rendering-Framerate umfasst: dynamisches Erhöhen der Rendering-Framerate, wenn die Netzwerk-Latenzzeit die erste vorbestimmte Latenzzeit übersteigt.
Verfahren nach Anspruch 3, wobei das dynamische Abstimmen der Rendering-Framerate umfasst: dynamisches Erhöhen der Rendering-Framerate, um die überwachte Netzwerk-Latenzzeit, die über die erste vorbestimmte Latenzzeit hinausgeht, zu kompensieren.
Verfahren nach Anspruch 2, wobei das Überwachen der Netzwerk-Latenzzeit, die der Netzwerkverbindung entspricht, umfasst: Vergleichen der Netzwerk-Latenzzeit mit einer zweiten vorbestimmten Latenzzeit.
Verfahren nach Anspruch 5, ferner umfassend: dynamisches Verringern der Rendering-Framerate, wenn die Netzwerk-Latenzzeit unter der zweiten vorbestimmten Latenzzeit ist.
Verfahren nach Anspruch 6, wobei das dynamische Verringern der Rendering-Framerate einer niedrigeren Leistungsverbrauchrate des Prozessors entspricht.
Verfahren nach Anspruch 1, wobei die Anzeige-Framerate konstant aufrechterhalten wird, wenn die Rendering-Framerate dynamisch abgestimmt wird.
Verfahren nach Anspruch 1, wobei die Anzeige-Framerate einer Dienstgüte (QoS)-Bedingung entspricht.
Verfahren nach Anspruch 1, ferner umfassend: über die Netzwerkverbindung Empfangen einer Benutzereingabe von der Recheneinrichtung in dem Computersystem; Rendern in dem Prozessor einer zweiten Mehrzahl von Bildframes, die eine bildliche Rückmeldung in Antwort auf die empfangene Benutzereingabe umfasst; Kodieren der zweiten Mehrzahl der Bildframes in eine zweite Video-Information; Streamen der zweiten Video-Information über die Netzwerkverbindung zu der Recheneinrichtung, wobei die zweite Video-Information dazu ausgelegt ist, in der Recheneinrichtung dekodiert zu werden und in dem Anzeigegerät, das zu der Recheneinrichtung gehört, angezeigt zu werden.
Verfahren nach Anspruch 10, wobei das Überwachen der Netzwerk-Latenzzeit umfasst: Verfolgen einer Zeitdauer zwischen einem Empfang der Benutzereingabe in der Recheneinrichtung und einer Anzeige der zweiten Video-Information in dem Anzeigegerät, das zu der Recheneinrichtung gehört, wobei die Netzwerk-Latenzzeit der verfolgten Zeitdauer entspricht.
System, aufweisend: eine Mehrzahl von Computersystemen, wobei ein Computersystem aus der Mehrzahl der Computersysteme umfasst: einen Datenspeicher, der betriebsfähig dafür ist, eine Mehrzahl von programmierten Befehlen zu speichern; eine Mehrzahl von Prozessoren, die betriebsfähig dafür sind, eine Mehrzahl von grafischen Bildern entsprechend der Mehrzahl der programmierten Befehle zu rendern und die Mehrzahl der grafischen Bilder in ein kodiertes Video zu kodieren; ein Streaming-Modul, das dazu ausgelegt ist, einen Video-Stream entsprechend dem kodierten Video zu einer entfernten Recheneinrichtung über eine Netzwerkverbindung zwischen der entfernten Recheneinrichtung und dem Computersystem zu übertragen; und eine Netzwerküberwachungseinrichtung, die dazu ausgelegt ist, einen Zustand der Netzwerkverbindung zu überwachen, wobei die Mehrzahl der grafischen Bilder von der Mehrzahl der Prozessoren mit einer Rendering-Framerate gerendert wird; wobei ferner die Rendering-Framerate in Antwort auf die Netzwerk-Latenzzeit dynamisch eingestellt wird, wobei die Rendering-Framerate erhöht wird, wenn sich die Netzwerk-Latenzzeit erhöht, wobei die Rendering-Framerate verringert wird, wenn sich die Netzwerk-Latenzzeit verringert.
System nach Anspruch 12, wobei die entfernte Recheneinrichtung ferner betriebsfähig dafür ist, den von dem Streaming-Modul-empfangenen Video-Stream zu dekodieren.
System nach Anspruch 13, wobei die entfernte Recheneinrichtung eine Mehrzahl von Anzeigegeräten umfasst, die betriebsfähig dafür sind, den dekodierten Video-Stream einem Benutzer der entfernten Recheneinrichtung anzuzeigen.
System nach Anspruch 12, wobei die Rendering-Framerate in Antwort darauf, dass die Netzwerk-Latenzzeit unter einen ersten vorbestimmten Schwellwert abfällt, dynamisch erniedrigt wird.
System nach Anspruch 12, wobei die Rendering-Framerate in Antwort darauf, dass die Netzwerk-Latenzzeit einen zweiten vorbestimmten Schwellwert überschreitet, dynamisch erhöht wird.
System nach Anspruch 12, wobei die in der entfernten Recheneinrichtung empfangene Benutzereingabe zu dem Computersystem übertragen wird.
System nach Anspruch 17, wobei eine zweite Mehrzahl von grafischen Bildern in einem Prozessor aus der Mehrzahl der Prozessoren in Antwort auf die Benutzereingabe gerendert wird, wobei die zweite Mehrzahl der grafischen Bilder in einem zweiten Video kodiert ist und zu der entfernten Recheneinrichtung gestreamt wird.
System nach Anspruch 18, wobei die Netzwerk-Latenzzeit einer Zeitdauer zwischen einem Empfang der Benutzereingabe in der entfernten Recheneinrichtung und einer Anzeige des zweiten Videos in einem Anzeigegerät der entfernten Recheneinrichtung entspricht.
System nach Anspruch 12, wobei die Mehrzahl der Computersysteme in einem cloudbasierten Datenzentrum umfasst ist.