DE112018002110T5

DE112018002110T5 - Systeme und verfahren für spiel-generierte bewegungsvektoren

Info

Publication number: DE112018002110T5
Application number: DE112018002110.6T
Authority: DE
Inventors: Michael Kopietz
Original assignee: Zenimax Media Inc
Current assignee: Zenimax Media Inc
Priority date: 2017-04-21
Filing date: 2018-04-20
Publication date: 2020-01-09
Also published as: GB2576846A; AU2020267252A1; ZA201907680B; TWI691199B; AU2018254550A1; CA3059740A1; TWI721816B; CA3173525A1; KR20210148381A; EP3613015A4; US20200404317A1; US10701388B2; RU2020134091A3; JP2020518209A; GB201916979D0; KR20200019854A; MX2021004095A; ZA202007051B; TW202025757A; JP7135067B2

Abstract

Systeme und Verfahren zum integrierten Rendern von Grafik werden offenbart. In bestimmten Ausführungsformen verwenden die Systeme und Verfahren eine Grafik-Engine, eine Videocodierungsmaschine und eine Remote-Client-Codiermaschine, um Grafiken über ein Netzwerk zu rendern. Die Systeme und Verfahren beinhalten die Generierung von Pro-Pixel-Bewegungsvektoren, die in Pro-Block-Bewegungsvektoren am Grafikprozessor umgewandelt werden. Die Grafik-Engine speist diese Pro-Block-Bewegungsvektoren in eine Videocodiermaschine ein, sodass die Videocodiermaschine diese Vektoren in codierte Videodaten umwandeln kann, um sie an die Remote-Client-Codiermaschine zu übertragen.

Description

VERWANDTE ANMELDUNGEN
Die Anmeldung beansprucht den Vorteil der folgenden US-Provisionalanmeldungen Nr. 62/488,526, eingereicht am 21. April 2017, und Nr. 62/596,325, eingereicht am 8. Dezember 2017.
HINTERGRUND DER ERFINDUNG
Bei Remote-Gaming-Anwendungen, wobei ein serverseitiges Spiel von einem clientseitigen Spieler gesteuert wird, wird versucht, die Videoausgabe einer dreidimensionalen (3D)-Grafik-Engine in Echtzeit mit vorhandenen oder benutzerdefinierten Codierern zu codieren. Die interaktive Natur von Videospielen, insbesondere die Spieler-Rückmeldungsschleife zwischen Videoausgang und Spielereingang, macht das Spiel-Video-Streaming jedoch viel empfindlicher bezüglich Latenzzeiten als herkömmliches Video-Streaming. Bestehende Videocodierverfahren können Rechenleistung, und sonst aber wenig anderes, für eine Verkürzung der Codierzeit in Anspruch nehmen. Neue Verfahren zum Integrieren des Codierungsprozesses in den Videowiedergabeprozess können deutliche Verkürzungen der Codierungszeit bei gleichzeitiger Verringerung der Rechenleistung, Verbesserung der Qualität des codierten Videos und Beibehaltung des ursprünglichen Bitstream-Datenformats ermöglichen, um die Interoperabilität bestehender Hardwaregeräte zu erhalten.
Bestehende Videocodierstandards enthalten nur Farb- und Zeitinformationen in Bildsequenzen, um die Zeit, Größe oder Qualität der Videocodierung zu verbessern. Einige Codierungsstandards, wie beispielsweise die in der MPEG-Standardreihe, verwenden ein rechenintensives, blockbasiertes Bewegungsschätzverfahren, um die Objektbewegung, basierend auf den in einem Video enthaltenen Farbdaten, anzunähern. Diese blockbasierten Bewegungsschätzverfahren haben in der Vergangenheit zu einer signifikanten Verringerung der Größe des codierten Videos geführt, sind aber eine Quelle für signifikante Latenzzeiten in Echtzeit-Videostreaming-U mgebungen.
Das Integrieren des Codierungsprozesses in den Video-Renderprozess ermöglicht den Zugriff auf zusätzliche Datenquellen, die für die Verbesserung der Codierung genutzt werden können. So können beispielsweise einige 3D-Grafik-Engines, wie sie beispielsweise in einer Spielmaschine enthalten sind, bereits Bewegungsvektoren generieren, die die Bewegung jedes Pixels auf jedem Videobild perfekt beschreiben. Durch das Bereitstellen sowohl des endgültigen gerenderten Einzelbildes als auch durch das Einspeisen korrekt formatierter Bewegungsvektordaten in den Codierer kann der rechenintensivste und zeitaufwändigste Schritt im Video-Codierer, die Bewegungsschätzung, für jedes Zwischenbild übersprungen werden. Darüber hinaus sind die von der Grafik-Engine gelieferten Bewegungsvektoren genauer als die, die durch einen blockbasierten Bewegungsschätzalgorithmus angenähert werden, was die Qualität des codierten Videos verbessert.
Diese beiden Bereiche, Videocodierung und Echtzeit-Grafikdarstellung, werden traditionsgemäß getrennt und unabhängig voneinander betrieben. Durch das Integrieren von Grafik-Engine und Codierer kann, um die Stärken der einzelnen Module zu nutzen, die Codierungszeit so weit verringert werden, dass Streaming-Anwendungen unterstützt werden, die überempfindlich auf Latenzzeiten reagieren.
Diese und andere damit verbundene Vorteile der Erfindung werden sich angesichts der Mängel bei den nachfolgend beschriebenen Technologien zeigen.
Zum Beispiel enthüllt die veröffentlichte US-Patentanmeldung Nr. 2015/0228106 A1 („die '106-Veröffentlichung“) eine Technologie, die auf das Decodieren von Videodaten abzielt, um eine Sequenz von decodierten Blöcken eines Videobildes zu generieren. Die Technologie ermöglicht die Verwendung jedes decodierten Blocks eines Videobildes als separate Textur für entsprechende Polygone der geometrischen Oberfläche, da der decodierte Block von der Codiermaschine generiert wird. Die Technologie der '106-Veröffentlichung beschreibt das Integrieren zwischen einer Codiermaschine, die codierte Videodaten decodiert, um das abzugleichenden Videobild zu generieren, und einer 3D-Grafik-Engine, die das Anzeigebild teilweise rendert, indem sie die Texturabbildung des Videobildes auf die geometrische Oberfläche durchführt. Diese Technologie ist jedoch im Vergleich zur vorliegenden Erfindung unzureichend, zumindest, weil sie keine Grafik-Engine offenbart oder verwendet, die sowohl den endgültigen gerenderten Frame als auch ordnungsgemäß formatierte Bewegungsvektordaten für das Einspeisen in die Video-Codiermaschine bereitstellt, sodass die Video-Codiermaschine vor dem Übertragen codierter Videodaten an die Remote-Client-Codiermaschine keine Bewegungsschätzung durchführen muss. Im Gegensatz dazu bietet die Verbesserung der Computertechnologie durch die vorliegende Erfindung eine Verringerung der Codierungszeit und der Rechenleistung, eine Verbesserung der Qualität des codierten Videos und führt zur Beibehaltung des ursprünglichen Bitstrom-Datenformats, um die Interoperabilität zu erhalten.
Die veröffentlichte US-Patentanmeldung Nr. 2011/0261885 A1 („die '885-Veröffentlichung“) offenbart Systeme und Verfahren, die auf die Bandbreitenverringerung durch das Integrieren von Bewegungsschätzung und Makroblockcodierung abzielen. In diesem System kann die Bewegungsschätzung unter Verwendung abgerufener Videodaten durchgeführt werden, um bewegungsschätzungsbezogene Informationen, einschließlich Bewegungsvektoren, zu generieren. Diese Bewegungsvektoren können einem aktuellen Makroblock entsprechen, wenn entsprechende Videodaten im Puffer zwischengespeichert werden. Auch hier ist die '885-Veröffentlichungstechnologie im Vergleich zur vorliegenden Erfindung unzureichend, zumindest, weil sie keine Grafik-Engine offenbart oder verwendet, die sowohl den endgültigen gerenderten Frame als auch ordnungsgemäß formatierte Bewegungsvektordaten für das Einspeisen in die Videocodiermaschine bereitstellt, sodass die Videocodiermaschine vor dem Übertragen codierter Videodaten an die Remote-Client-Codiermaschine keine Bewegungsschätzung durchführen muss. Daher bietet die Technologie der '885-Veröffentlichung nicht die gleiche Verringerung der Codierungszeit und Rechenleistung sowie die Verbesserung der Qualität des codierten Videos, die die vorliegende Erfindung bietet.
Wie aus der obigen Diskussion über den Stand der Technik in dieser Technologie hervorgeht, besteht in der Technik ein Bedarf an einer Verbesserung der derzeitigen Computertechnologie im Zusammenhang mit der Videocodierung in Spielumgebungen.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist daher eine Aufgabe der hierin offenbarten beispielhaften Ausführungsformen, um Nachteile in der Technik anzugehen und Systeme und Verfahren zum Generieren von Grafik bereitzustellen, die eine vernetzte Serverarchitektur verwenden, die eine Grafik-Engine, eine Videocodiermaschine und eine Remote-Client-Codiermaschine zum Übertragen codierter Videodaten verwendet, wobei die Grafik-Engine sowohl den endgültigen gerenderten Frame als auch korrekt formatierte Bewegungsvektordaten zum Einspeisen in die Videocodiermaschine bereitstellt.
Eine weitere Aufgabe der Erfindung besteht darin, Systeme und Verfahren zum Generieren von Grafik bereitzustellen, wobei die Videocodiermaschine keine Bewegungsschätzung durchführen muss, bevor sie codierte Videodaten an die Remote-Client-Codiermaschine überträgt.
Noch eine weitere Aufgabe der Erfindung besteht darin, Systeme und Verfahren zum Generieren von Grafik bereitzustellen, wobei die Grafik-Engine Pro-Pixel-Bewegungsvektoren in Pro-Block-Bewegungsvektoren umwandelt.
Noch eine weitere Aufgabe der Erfindung besteht darin, Systeme und Verfahren zum Generieren von Grafik bereitzustellen, wobei die Pro-Pixel-Bewegungsvektoren durch Verwendung eines Rechen-Shaders generiert werden, um die Pro-Pixel-Bewegungsvektoren zur Kamerageschwindigkeit hinzuzufügen, um ein Pro-Pixel-Ergebnis zu erhalten, und wobei das Pro-Pixel-Ergebnis in einem Bewegungsvektorpuffer gespeichert wird.
Noch eine weitere Aufgabe der Erfindung besteht darin, Systeme und Verfahren zum Generieren von Grafik bereitzustellen, wobei die Pro-Block-Bewegungsvektordaten von der Grafik-Engine in Echtzeit in die Videocodiermaschine gleichzeitig mit einem farbunterabgetasteten Videobild eingespeist werden.
Figurenliste
Eine umfassendere Würdigung der Erfindung und vieler der damit verbundenen Vorteile wird leicht erreicht, da diese durch Bezugnahme auf die folgende ausführliche Beschreibung besser verstanden wird, wenn sie im Zusammenhang mit den beigefügten Zeichnungen betrachtet wird. Es zeigen:

1 ein Blockdiagramm, das eine 3D-Grafik-Engine veranschaulicht, die ein Video zur Codierung und Übertragung an einen Client rendert;
2 ein Flussdiagramm, das die Schritte veranschaulicht, die zur Latenzverringerung durch Einspeisen von Bewegungsvektoren, die von der 3D-Grafik-Engine generiert werden, in den modifizierten Codierungsprozess von 4 erforderlich sind;
3 ein Diagramm, das die Transformation von in der Grafik-Engine generierten Pro-Pixel-Bewegungsvektoren in Pro-Makroblock-Bewegungsvektoren zum Einspeisen in die Codiermaschine veranschaulicht; und
4 ein Flussdiagramm, das die erforderlichen Änderungen an einem in 1 verwendeten Videocodierungsverfahren veranschaulicht.

DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Bei der Beschreibung der bevorzugten Ausführungsformen der in den Zeichnungen gerenderten Erfindung wird aus Gründen der Übersichtlichkeit auf eine spezifische Terminologie zurückgegriffen. Die Erfindung soll sich jedoch nicht auf die so ausgewählten spezifischen Begriffe beschränken, und es muss verstanden werden, dass jeder spezifische Begriff alle technischen Äquivalente umfasst, die ähnlich arbeiten, um einen ähnlichen Zweck zu erfüllen. Mehrere bevorzugte Ausführungsformen der Erfindung werden zur Veranschaulichung beschrieben, wobei davon ausgegangen wird, dass die Erfindung auch in anderen Formen verkörpert werden kann, die nicht ausdrücklich in den Zeichnungen gerendert sind.
In Anwendungen, in denen eine 3D-Grafik-Engine Videos darstellt, die in Echtzeit codiert und übertragen werden sollen, können die Grafik-Engine und der Codierer enger gekoppelt werden, um die Gesamtrechenzeit und den Rechenaufwand zu verringern. Pro-Pixel-Bewegungsvektordaten, die bereits von der Grafik-Engine für jedes Videobild generiert wurden, können in Pro-Block-Bewegungsvektordaten umgewandelt und in die Codiermaschine eingespeist werden, um den Schritt der Bewegungsschätzung zu umgehen, der der komplexeste und rechenintensivste Schritt im Codierungsprozess ist. In Grafik-Engines, die den Rekonstruktionsfilter für plausible Bewegungsunschärfe verwenden, können bereits Pro-Pixel-Bewegungsvektoren für jedes Videobild berechnet werden. Die Konvertierung von Pro-Pixel-Bewegungsvektoren in Pro-Block-Bewegungsvektoren kann durchgeführt werden, indem man den mittleren Vektor für jeden Makroblock von 16×16 Pixeln findet. Die Konvertierung erfolgt in der 3D-Grafik-Engine, sodass nur ein kleiner Bruchteil der ursprünglichen Bewegungsvektordaten von der 3D-Grafik-Engine an die Codiermaschine übergeben werden muss. In Fällen, in denen die Grafik- und Codiermaschine den Speicher nicht gemeinsam nutzen, trägt dies auch dazu bei, den Verbrauch der Speicherbandbreite zu verringern. Die Pro-Block-Bewegungsvektoren werden in die Codiermaschine eingespeist und überspringen den Schritt der Bewegungsschätzung vollständig, ohne den Rest des Codierungsprozesses wesentlich zu verändern.
Die 1-4 veranschaulichen eine beispielhafte Technik zur Verbesserung der Videocodierung in Videostreaming-Anwendungen, wobei eine 3D-Grafik-Engine beim Darstellen eines Videobildes begleitende Bewegungsvektordaten generiert.
1 veranschaulicht ein Beispielsystem, in dem Videos gerendert und codiert werden, um sie an einen entfernten Client 116 zu übertragen. Eine 3D-Grafik-Engine 100, die im Speicher 106 auf einer Serverarchitektur 120 läuft, übergibt die Videos und zusätzliche Bewegungsvektorinformationen über ein gerendertes Videobild an eine Codiermaschine 102 (hierin als Codec oder Codierer bezeichnet), die einen codierten Bitstrom 108 zur Übertragung an ein Client-Computersystem 116 generiert. Die Serverarchitektur 120 ist eine beliebige Kombination aus Hard- oder Software, die die Funktionen einer Grafik- und einer Codiermaschine unterstützen kann. In dem gegebenen Beispiel kann die Grafik-Engine 100 beispielsweise als Grafikprozessor implementiert werden, der die Videospielsoftware 104 ausführt, die in einen computerlesbaren Speicher 106 geladen wird, während die Codiermaschine 102 als CPU mit Videocodierungssoftware implementiert werden kann. Die Codiermaschine 102 generiert codierte Videodaten 108 zur Übertragung an ein entferntes Client-Computersystem 116, das eine entfernte Codiermaschine (Codec) 110 beinhaltet, die den Bitstrom zur Wiedergabe auf einer von einer Anzeigesteuerung 112 gesteuerten Anzeige 114 decodiert. Das Remote-Client-Computersystem 116 ist eine beliebige Kombination aus Hardware, Gerät oder Software, die die Decodierung und Anzeige des codierten Bitstroms 108 ermöglicht.
2 veranschaulicht die Schritte, die erforderlich sind, um schnellere Codierungszeiten zu erreichen, indem bestehende Zusatzdaten aus dem Rendering-Prozess in den Videocodierungsprozess übernommen werden. In Schritt 202 müssen die zusätzlichen Daten zunächst als normales Betriebsmerkmal der Grafik-Engine 100 auf einem Server 120 generiert werden. Da GPUs immer leistungsfähiger und allgegenwärtiger geworden sind, ist die Generierung von Echtzeit-Pro-Pixel-Bewegungsvektoren zu einem häufigen Bestandteil moderner Videospiel-Maschinen geworden. Während des Renderings eines 2D-Video-Frames aus einer 3D-Szene generiert eine 3D-Grafik-Engine während des Farbgenerierungsprozesses zusätzliche Ausgaben, die als Input für spätere Postprozessläufe verwendet werden können. Die Zusatzausgaben können Informationen beinhalten, die in die Akkumulations-, Farb- oder Geschwindigkeitspuffer geschrieben werden, sowie drei Speicherplätze, die für die Zwischenspeicherung von Informationen über Pixeltiefe, Pixelfarbe und Pixelbewegung vorgesehen sind.
In einer allgemein verwendeten Implementierung von Bewegungsunschärfe, die als Rekonstruktionsfilter für plausible Bewegungsunschärfe bezeichnet wird, werden die Pro-Pixel-Geschwindigkeiten aus dem Velocity-Puffer zunächst in eine kleinere Anzahl von Kacheln abgetastet, wobei jede Kachel die maximale Geschwindigkeit aus der Pixelgruppe übernimmt. Die Kacheln werden dann mit den Pro-Pixel-Tiefen im Akkumulationspuffer maskiert und die Ergebnisse auf die Pro-Pixel-Farben im Farbpuffer angewendet, um Bewegungsunschärfe zu generieren. Es gibt mehrere Variationen der Rekonstruktionsfiltermethode, die die Treue, Leistung oder beides verbessern, aber die Konzepte bleiben ähnlich und ein Velocity-Puffer enthält die Pro-Pixel-Bewegung zwischen zwei benachbarten Frames. Obwohl „Geschwindigkeit“ der Begriff in der Terminologie der Grafik-Engine und „Bewegungsvektor“ der Begriff in der Terminologie der Videocodierung ist, sind die Begriffe funktional äquivalent und eine Pro-Pixel-Geschwindigkeit ist die gleiche Sache wie ein Pro-Pixel-Bewegungsvektor. Der Geschwindigkeitspuffer enthält die zusätzlichen Daten in Form von Pro-Pixel-Bewegungsvektoren, die im Videocodierungsprozess wiederverwendet werden.
In Schritt 204 konvertiert die Grafik-Engine 100, die sich auf dem Server 120 befindet, die Pro-Pixel-Bewegungsvektoren in Pro-Block-Bewegungsvektoren, basierend auf der Makroblockgröße, die beim Codieren verwendet werden soll. Der H.264-Codec verwendet standardmäßig 16x16-Pixel-Makroblöcke und hat die Möglichkeit, weiter zu unterteilen. Die 256 Pro-Pixel-Bewegungsvektoren können gemittelt werden, um einen einzigen mittleren Vektor zu erhalten, der als Pro-Block-Bewegungsvektor dient. Dieser Prozess wird im Zusammenhang mit 3 näher beschrieben.
In Schritt 206 werden die Pro-Makroblock-Bewegungsvektorinformationen in den Codierungsmotor/Codierer 102 eingespeist, der sich auf dem Server 120 befindet, wobei der Bewegungsschätzschritt umgangen wird. In Software-Implementierungen des Codierers kann der Schritt der Bewegungsschätzung vollständig deaktiviert werden, was zu einer erheblichen Zeitersparnis bei der CPU-Berechnung führt. Die Zeitersparnis in der CPU sollte die zusätzliche Zeit, die benötigt wird, um die Durchschnittsvektoren im Grafikprozessor zu berechnen (in Schritt 204) und an die CPU zu übertragen, mehr als ausgleichen.
Da die von der Grafik-Engine 100 gelieferten Pro-Block-Bewegungsvektoren mit denen austauschbar sind, die in einem typischen Bewegungsschätzschritt berechnet wurden, beginnt die Codierung in Schritt 208 ab dem Schritt 208 der Bewegungskompensation. Der Rest des Videocodierungsprozesses, wie er in Verbindung mit 4 näher beschrieben wird, unterscheidet sich nicht wesentlich von den typischen Schritten der Bewegungskompensation, Restberechnung und Codierung, die von einem Codierungsstandard durchgeführt werden, der Bewegungsschätzungstechniken verwendet.
3 veranschaulicht im Detail die Transformation, die in der Grafik-Engine 100 stattfindet, von Pro-Pixel-Bewegungsvektoren zu Pro-Makroblock-Bewegungsvektoren. Während der Farbgenerierungsphase generiert eine 3D-Grafik-Engine 100 auf einem Server 120 Pro-Pixel-Bewegungsvektoren und speichert die Daten im Geschwindigkeitspuffer 300, der sich ebenfalls auf dem Server 120 befindet. Der Geschwindigkeitspuffer 300 kann Daten nur für dynamische Objekte enthalten, mit Ausnahme der Bewegungsinformationen, die durch die Bewegung der Spieler-Kamera übermittelt werden. Um Bewegungsvektorinformationen für jedes Pixel im Bildraum zu erhalten, kombiniert ein Rechen-Shader 302 die Vektoren im Geschwindigkeitspuffer 300 mit der Kamerageschwindigkeit für alle statischen Objekte, die nicht bereits im Geschwindigkeitspuffer enthalten sind, und speichert das Pro-Pixel-Ergebnis im Bewegungsvektorpuffer 304. Die Kamerageschwindigkeit ist die 2D-Projektion der Rotations- und Translationskamerabewegung während des Bildes. Spezifische Grafik-Engines können leicht unterschiedliche Methoden verwenden, um diese Pro-Pixel-Bewegungsvektoren für den gesamten Bildschirmraum zu berechnen, aber die Konzepte bleiben die gleichen.
Der H.264-Codierer verwendet eine Standard-Makroblockgröße von 16x16, kann aber in kleinere Größen bis hinunter zu 4x4 unterteilt werden. Im Beispiel (3) wird ein 4x4-Makroblock 306 als vereinfachtes Beispiel verwendet, aber das Verfahren sollte extrapoliert werden, um die im Codierer verwendete Makroblockgröße anzupassen. Für einen 4x4-Makroblock 306 sind 16 Pro-Pixel-Bewegungsvektoren 308 im Bewegungsvektorpuffer 304 gespeichert. Diese Pro-Pixel-Bewegungsvektoren 308 müssen in einen einzelnen Pro-Makroblock-Bewegungsvektor 310 umgewandelt werden, der in den Codierer eingespeist werden kann, um zur Bewegungskompensation verwendet zu werden, wie in 4 gerendert. Das arithmetische Mittel des Satzes der Pro-Pixel-Vektoren 308 ist ein Transformationsverfahren 312 mit geringer Rechenkomplexität und kurzer Rechenzeit.
Optionale Änderungen an der arithmetischen Mittelwert-Transformation 312 können vorgenommen werden, um die Qualität auf Kosten zusätzlicher Rechenkomplexität oder Leistung zu verbessern. So können beispielsweise Vektor-Medianfiltertechniken angewendet werden, um Diskontinuitäten im Vektorfeld des Makroblocks vor der arithmetischen Mittelwertbildung zu beseitigen, um sicherzustellen, dass der Pro-Makroblock-Bewegungsvektor 310 für die meisten Pixel im Makroblock 306 repräsentativ ist. Da der resultierende Pro-Makroblock-Bewegungsvektor von pixelgenauen Bewegungsvektoren abgeleitet ist, die ursprünglich auf der Grundlage bekannter Objekt-Bewegungsdaten berechnet wurden, werden diese Pro-Makroblock-Bewegungsvektoren immer eine genauere Darstellung sein als die, die von bestehenden blockbasierten Bewegungsschätzungsalgorithmen berechnet werden, die nur Bewegungen basierend auf Pixel-Farbdaten ableiten können.
4 veranschaulicht ein Verfahren zum Überspringen des rechenkomplexen Bewegungsschätzprozesses durch Einspeisen von Bewegungsvektoren, die in der Grafik-Engine 100 des Servers 120 von 1 generiert wurden, in die Codiermaschine 102 des Servers 120 in 1. Wie im Folgenden ausführlich erläutert, wird der resultierende Bitstrom von codierten Videodaten 108 an das entfernte Client-Computersystem 116 übertragen. Das in 4 gerenderte Verfahren veranschaulicht den Codierungsprozess für ein einzelnes Zwischenbild, insbesondere ein P-Bild, wie es durch die MPEG-Familie von Videocodierstandards definiert ist. Die Intra-Frame (I-Frame)-Generierung wird nicht geändert, da die Bewegungskompensation 406 bei der I-Frame-Generierung nicht durchgeführt wird. Der farbunterabgetastete Video Frame 402 und die Pro-Block-Bewegungsvektordaten 404 werden von der Grafik-Engine 100 übertragen, sobald sie verfügbar sind. Die spielgenerierten Bewegungsvektoren 404 werden verwendet, um die Generierung von Bewegungsvektoren zu umgehen, die sonst in einem typischen Schritt der Bewegungsschätzung 426 auftreten würden, wie im AVC-Standard H.264/MPEG-4 beschrieben. Der Schritt zur Bewegungsschätzung 426 wird übersprungen und kann in einer Software-Implementierung der Codiermaschine deaktiviert werden. Das Überspringen des Schrittes 426 der blockbasierten Bewegungsschätzung führt zu einer signifikanten Verringerung der Codierungszeit, die die Zeit, die für die Konvertierung der Geschwindigkeitspufferdaten in das entsprechende Format benötigt wird, wie in Verbindung mit 3 beschrieben, mehr als ausgleicht.
Die Bewegungsvektoren 404, die bereits auf die entsprechende Makroblockgröße umgerechnet wurden, können sofort ohne Änderung der Bewegungskompensation 406 verwendet werden. Die Ergebnisse der Bewegungskompensation 406 werden mit dem eingegebenen farbunterabgetasteten Videoframe 402 zu dem Residualbild 430 kombiniert, das von den Residualtransformations- und Skalierungsschritten 408, Quantisierung 410 und Scannen von 412 Schritten verarbeitet wird, die typischerweise in bestehenden Hardware- oder Software-Videoencodern auftreten.
Die Deblocking-Schritte müssen durchgeführt werden, wenn der von der Implementierung gewählte Decodierungsstandard dies erfordert. Die Deblocking-Einstellungen 420 und das deblockierte Bild 428 werden berechnet, indem die Algorithmen des Codierungsstandards für die inverse Quantisierung 414, die inverse Transformation & Skalierung 416 und die Deblockierung 418 angewendet werden. Die gescannten Koeffizienten 412 werden mit den Deblocking-Einstellungen 420 kombiniert und im Entropie-Codierer 422 codiert, bevor sie als Bitstrom 108 an das Remote-Client-Computersystem 116 zur Decodierung am Codec 110 des Remote-Client-Computersystems übertragen werden. Das deblockierte Bild 428 wird zum Eingang für die Bewegungskompensation 406 des nächsten Bildes. Der Bitstrom (umfassend codierte Videodaten) 108 behält das gleiche Format bei, das durch den in der Implementierung verwendeten Codierungsstandard wie H.264/MPEG-4 AVC definiert ist. Dieses Beispiel ist spezifisch für den H.264/MPEG-4 AVC-Standard, kann im Allgemeinen für ähnliche Codierungsstandards verwendet werden, die Bewegungsschätzung 426 und Bewegungskompensation 406 Techniken verwenden.
BEISPIEL 1: Benchmark-Tests zur Demonstration von Verringerungen der Codierungszeit
Der Bewegungsschätzschritt in der traditionellen H.264-konformen Codierung ist in der Regel der rechenintensivste und zeitaufwändigste Schritt. Wie hierin erläutert, kann die Wiederverwendung von spielgenerierten Bewegungsvektoren zu einer deutlichen Verkürzung der Codierungszeit führen.
In der Testumgebung generierte die Grafik-Engine eine Ausgabe mit einer Auflösung von 1280x720 bei 60 Bildern pro Sekunde. Die Codierungszeiten wurden von einem x264-Codierer erfasst, der einfädig läuft. Die Ausführung des einfädigen Codierers führt zu längeren Codierzeiten als in der realen Welt, normalisiert die Messungen jedoch auf einen Kern, sodass sie direkt miteinander vergleichbar sind. Die Codierungszeiten wurden zunächst mit Hilfe einer unveränderten Bewegungsschätzung innerhalb des Codierers gemessen und dann in derselben Umgebung mit der aktivierten Funktion der spielgenerierten Bewegungsschätzung neu gemessen.

Es wurde ein Bereich mit geringer Bewegung ausgewählt, der eine First-Person-Player-Ansicht der Hände, der Waffe und einer stationären Wand des Spielers umfasst. Die Hände und Waffen des Spielers durchlaufen eine leichte „wackelige“ Animation, um eine kleine Menge an Pixelbewegung auf relativ kleinem Bildschirm zu generieren. Die Ergebnisse dieses Tests sind in Tabelle 1 unten wiedergegeben, die Latenzergebnisse mit und ohne die hierin beschriebenen spielgenerierten Bewegungsschätzungstechniken zeigt. Bei geringer Intensität, bei deaktivierter spielgenerierter Bewegungsschätzung, betrug die unveränderte Codierungszeit 12 ms. Wenn die vom Spiel generierte Bewegungsschätzung aktiviert war, wurde die Codierungszeit um 3 ms auf eine Codierungszeit von 9 ms verringert. Ähnliche Latenzverringerungen wurden für Szenarien mit durchschnittlicher und hoher Bewegungsintensität gezeigt, wobei die Latenz um 17,6 % für Szenarien mit durchschnittlicher Bewegungsintensität und zwischen 15 % und 30 % Latenzverringerungen in Szenarien mit hoher Latenz abnahm. Diese Ergebnisse zeigen eine deutlich signifikante Verringerung der Latenzzeit, wenn die spielgenerierte Bewegungsschätzung aktiviert ist. TABELLE 1: Latenzergebnisse bei unterschiedlichen Bewegungsintensitäten

Bewegungsintensität	x264-BewegungsSchätzung	Spiel-generierte Bewegungsschätzung	% Änderung
Niedrig	12 ms	9 ms	25 %
Mittel	17 ms	14 ms	17,6 %
Hoch	20 ms - 27 ms	17 ms - 19 ms	15 % - 30 %

Die Testumgebung ergab auch, dass es zusätzliche Kosten bei der Konvertierung der spielgenerierten Pro-Pixel-Bewegungsvektoren in Pro-Makroblock-Bewegungsvektoren für den Codierer gibt. Diese Kosten sind jedoch deutlich geringer als die im vorherigen Abschnitt beschriebenen Zeiteinsparungen bei der Codierung. Da die Grafik-Engine Videos mit einer Auflösung von 1280x720 generiert, dauerte die Transformation des Bewegungsvektors von pro Pixel zu pro Makroblock 0,02 ms. Die Zeitersparnis des gemessenen Codierers ist um drei Größenordnungen größer als die Mehrkosten für die Verwendung von spielgenerierten Bewegungsvektoren zur Codierung.
Die vorstehende Beschreibung und die Zeichnungen sind nur als Illustration der Prinzipien der Erfindung zu betrachten. Die Erfindung ist nicht dazu bestimmt, durch die bevorzugte Ausführungsform eingeschränkt zu werden, und kann auf verschiedene Weise implementiert werden, die für eine der üblichen Fertigkeiten in der Kunst klar erkennbar sind. Zahlreiche Anmeldungen der Erfindung werden den Fachleuten leicht fallen. Daher ist es nicht erwünscht, die Erfindung auf die offenbarten spezifischen Beispiele oder die genaue Konstruktion und Funktionsweise zu beschränken. Vielmehr können alle geeigneten Modifikationen und Äquivalente herangezogen werden, die in den Anwendungsbereich der Erfindung fallen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2015/0228106 A1 [0007]
US 2011/0261885 A1 [0008]

Claims

Computerimplementiertes Verfahren zum Generieren von Grafiken, umfassend die folgenden Schritte: Generieren eines oder mehrerer Pro-Pixel-Bewegungsvektoren; Umwandeln des einen oder der mehreren Pro-Pixel-Bewegungsvektoren in einen oder mehrere Pro-Block-Bewegungsvektoren in einer Grafik-Engine; und Einspeisen der Pro-Block-Bewegungsvektoren in eine Videocodiermaschine, wobei die Videocodiermaschine die einen oder mehreren Pro-Block-Bewegungsvektoren in codierte Videodaten zur Übertragung an eine entfernte Client-Codiermaschine umwandelt.
Verfahren nach Anspruch 1, wobei die einen oder mehreren Pro-Pixel-Bewegungsvektoren vor der Umwandlung in einem Geschwindigkeitspuffer gespeichert werden.
Verfahren nach Anspruch 1, wobei die Generierung des einen oder der mehreren Pro-Pixel-Bewegungsvektoren die folgenden Schritte umfasst: Kombinieren des einen oder der mehreren Pro-Pixel-Bewegungsvektoren mit einer Kamerageschwindigkeit an einem Rechen-Shader, um ein Pro-Pixel-Ergebnis zu erhalten; und Speichern des Pro-Pixel-Ergebnisses in einem Bewegungsvektorpuffer.
Verfahren nach Anspruch 1, wobei eine Grafik-Engine die Pro-Block-Bewegungsvektordaten in die Videocodiermaschine gleichzeitig mit einem oder mehreren farbunterabgetasteten Video-Frames in Echtzeit einspeist.
Verfahren nach Anspruch 1, wobei die codierten Videodaten zur Wiedergabe auf einem entfernten Client-Computersystem decodiert werden.
Verfahren nach Anspruch 1, wobei die Videocodiermaschine eine Bewegungskompensation und Residualtransformation durchführt, um die einen oder mehreren Pro-Block-Bewegungsvektoren in codierte Videodaten zu konvertieren.
Verfahren nach Anspruch 1, wobei die videocodierten Daten zur Übertragung an die Remote-Client-Codiermaschine durch Anwenden von einem oder mehreren von inversen Quantisierungsalgorithmen, inverser Transformation und Skalierung und/oder Deblocking vorbereitet werden.
Verfahren nach Anspruch 1, wobei die einen oder mehreren Pro-Pixel-Vektoren in einen oder mehrere Pro-Block-Bewegungsvektoren unter Verwendung eines Transformationsverfahrens, das ein arithmetisches Mittel anwendet, umgewandelt werden.
Computerimplementiertes Grafikgenerierungssystem, bestehend aus einer oder mehreren Grafik-Engines und einer Videocodiermaschine, wobei die Grafik-Engine einen oder mehrere Pro-Pixel-Bewegungsvektoren generiert, die Pro-Pixel-Bewegungsvektoren in einen oder mehrere Pro-Block-Bewegungsvektoren umwandelt und die Pro-Block-Bewegungsvektoren direkt in die Videocodiermaschine einspeist, wobei die Videocodiermaschine die Pro-Block-Bewegungsvektoren in codierte Videodaten umwandelt und die codierten Videodaten an eine Remote-Client-Codiermaschine überträgt, die auf einem Remote-Client-Computersystem läuft.
System nach Anspruch 9, wobei die einen oder mehreren Pro-Pixel-Bewegungsvektoren vor der Umwandlung in einem Geschwindigkeitspuffer gespeichert werden.
System nach Anspruch 9, wobei die einen oder mehreren Pro-Pixel-Bewegungsvektoren durch Hinzufügen des einen oder der mehreren Pro-Pixel-Bewegungsvektoren zu einer Kamerageschwindigkeit an einem Rechen-Shader generiert werden, um ein Pro-Pixel-Ergebnis zu erhalten, und Speichern des Pro-Pixel-Ergebnisses in einem Bewegungsvektorpuffer.
System nach Anspruch 8, wobei die Grafik-Engine die Pro-Block-Bewegungsvektordaten in die Videocodiermaschine gleichzeitig mit einem oder mehreren farbunterabgetasteten Video-Frames in Echtzeit einspeist.
System nach Anspruch 9, wobei die Videocodiermaschine eine Bewegungskompensation und Residualtransformation durchführt, um die einen oder mehreren Pro-Block-Bewegungsvektoren in codierte Videodaten umzuwandeln.
System nach Anspruch 9, wobei die videocodierten Daten zur Übertragung an die Remote-Client-Codiermaschine durch Anwenden von einem oder mehreren von inversen Quantisierungsalgorithmen, inverser Transformation und Skalierung und/oder Deblocking vorbereitet werden.
System nach Anspruch 9, wobei die codierten Videodaten konfiguriert sind, um decodiert und auf einer von einer Anzeigesteuerung gesteuerten Anzeige wiedergegeben zu werden.
System nach Anspruch 9, wobei die Grafik-Engine die einen oder mehreren Pro-Pixel-Vektoren in einen oder mehrere Pro-Block-Bewegungsvektoren unter Verwendung eines Transformationsverfahrens umwandelt, das ein arithmetisches Mittel anwendet.
Computerimplementiertes Verfahren zum Generieren von Grafiken, umfassend die folgenden Schritte: Umwandeln des einen oder der mehreren Pro-Pixel-Bewegungsvektoren in einen oder mehrere Pro-Block-Bewegungsvektoren in einer Grafik-Engine, wobei die Pro-Block-Bewegungsvektordaten beim Empfang an eine Codiermaschine übertragen werden; und Empfangen eines oder mehrerer farbunterabgetasteter Video-Frames an einer Grafik-Engine, wobei die farbunterabgetasteten Video-Frames beim Empfangen an die Codiermaschine übertragen werden, wobei die Codiermaschine die Pro-Block-Bewegungsvektordaten und die farbunterabgetasteten Videobilder kombiniert, um Videodaten zur Übertragung an ein entferntes Client-Computersystem zu codieren, und wobei Bewegungsschätzberechnungen während der Codierung der Videodaten deaktiviert werden.
Verfahren nach Anspruch 17, wobei die kombinierten Pro-Block-Bewegungsvektordaten und die farbunterabgetasteten Video-Frames ein Residualbild bilden.
Verfahren nach Anspruch 18, wobei das Residualbild durch Residualtransformation und -skalierung, Quantisierung und/oder Abtastung vor dem Codieren weiterverarbeitet wird.
Verfahren nach Anspruch 18, ferner umfassend die folgenden Schritte von: Berechnen einer inversen Quantisierung, inversen Transformation und Skalierung; und Deblocking des Residualbildes.