DE112018002561B3 - Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel - Google Patents

Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel Download PDF

Info

Publication number
DE112018002561B3
DE112018002561B3 DE112018002561.6T DE112018002561T DE112018002561B3 DE 112018002561 B3 DE112018002561 B3 DE 112018002561B3 DE 112018002561 T DE112018002561 T DE 112018002561T DE 112018002561 B3 DE112018002561 B3 DE 112018002561B3
Authority
DE
Germany
Prior art keywords
client
motion
motion vectors
motion vector
server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE112018002561.6T
Other languages
English (en)
Inventor
Michael Kopietz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zenimax Media Inc
Original Assignee
Zenimax Media Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zenimax Media Inc filed Critical Zenimax Media Inc
Application granted granted Critical
Publication of DE112018002561B3 publication Critical patent/DE112018002561B3/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/20—Analysis of motion
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T7/00—Image analysis
    • G06T7/20—Analysis of motion
    • G06T7/207—Analysis of motion for motion estimation over a hierarchy of resolutions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/521—Processing of motion vectors for estimating the reliability of the determined motion vectors or motion vector field, e.g. for smoothing the motion vector field or for correcting motion vectors
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/352—Details of game servers involving special game server arrangements, e.g. regional servers connected to a national server or a plurality of servers managing partitions of the game world
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/355—Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an MPEG-stream for transmitting to a mobile phone or a thin client
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30—Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35—Details of game servers
    • A63F13/358—Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/40—Processing input control signals of video game devices, e.g. signals generated by the player or derived from the environment
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/50—Controlling the output signals based on the game progress
    • A63F13/52—Controlling the output signals based on the game progress involving aspects of the displayed game scene
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/85—Providing additional services to players
    • A63F13/86—Watching games played by other players
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T5/00—Image enhancement or restoration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/124—Quantisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/124—Quantisation
    • H04N19/126—Details of normalisation or weighting functions, e.g. normalisation matrices or variable uniform quantisers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H04N19/137—Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139—Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/149—Data rate or code amount at the encoder output by estimating the code amount by means of a model, e.g. mathematical model or statistical model
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/154—Measured or subjectively estimated visual quality after decoding, e.g. measurement of distortion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/162—User input
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
    • H04N19/192—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding the adaptation method, adaptation tool or adaptation type being iterative or recursive
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • H04N19/426—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements using memory downsizing methods
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/43—Hardware specially adapted for motion estimation or compensation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • H04N19/517—Processing of motion vectors by encoding
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00—Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/55—Controlling game characters or game objects based on the game progress
    • A63F13/58—Controlling game characters or game objects based on the game progress by computing conditions of game characters, e.g. stamina, strength, motivation or energy level
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/534—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for network load management, e.g. bandwidth optimization, latency reduction
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/50—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers
    • A63F2300/53—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing
    • A63F2300/538—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game characterized by details of game servers details of basic data processing for performing operations on behalf of the game client, e.g. rendering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/10—Image acquisition modality
    • G06T2207/10016—Video; Image sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/527—Global motion vector estimation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding

Abstract

Computerimplementiertes Verfahren zum Zwischenspeichern von Bewegungsvektoren, umfassend:Übertragen einer zuvor generierten Bewegungsvektorbibliothek von einem Server zu einem Client, wobei die Bewegungsvektorbibliothek konfiguriert ist, um auf dem Client gespeichert zu werden;Übertragen einer Anweisung von dem Server an den Client zum Überwachen von Eingabedaten von einem Benutzer;Übertragen einer Anweisung von dem Server an den Client, eine Bewegungsabschätzung aus den Eingangsdaten zu berechnen: undÜbertragen einer Anweisung von dem Server an den Client, die gespeicherte Bewegungsvektorbibliothek basierend auf den Eingabedaten zu aktualisieren, wobei der Client die gespeicherte Bewegungsvektorbibliothek zum Starten von Bewegung in einer grafischen Schnittstelle anwendet, bevor er tatsächliche Bewegungsvektordaten vom Server empfängt.

Description

  • Die vorliegende Anmeldung betrifft ein clientseitiges Zwischenspeichern von Bewegungsvektoren zur Spielereingabe-Bewegungskompensation.
  • HINTERGRUND DER ERFINDUNG
  • Bei Remote-Gaming-Anwendungen, bei denen 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 Videoausgabe und Spielereingabe, macht das Spiel-Video-Streaming jedoch viel empfindlicher gegenüber 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 zur Integration des Codierungsprozesses in den Videowiedergabeprozess können signifikante Verkürzungen der Codierungszeit bei gleichzeitiger Reduzierung der Rechenleistung, Verbesserung der Qualität des codierten Videos und Beibehaltung des ursprünglichen Bitstream-Datenformats ermöglichen, um Interoperabilität bestehender Hardwaregeräte zu bewahren.
  • Im Gegensatz zur normalen Videowiedergabe haben Videospiele eine unverwechselbare Spielereingabe zur Video-Rückmeldungsschleife. Spieler reagieren sehr empfindlich auf Latenzzeiten zwischen Eingabe und Videoausgabe. Die hohe Latenzzeit in dieser Spielereingabe-Rückmeldungsschleife war ein wesentlicher Stolperstein bei Videospiel-Streaming-Anwendungen, bei denen eine vom Server gehostete Videospielinstanz von einem entfernten Spieler gesteuert wird. Jeder Prozess, der die Zeit zwischen Eingabe und Rückmeldung verkürzen kann, verbessert direkt die Benutzerfreundlichkeit.
  • Die Client-Hardware in einer Spiel-Streaming-Umgebung kann unterschiedliche Rechenleistungen aufweisen, aber dedizierte H.264-Hardware-Decoder werden immer allgegenwärtiger, selbst bei mobilen und anderen Geräten mit geringer Leistung. Ein Hardware-Decoder ist gut darin, eine kleine Auswahl an Berechnungen durchzuführen, wie z.B. die Bewegungskompensation, die regelmäßig nach dem Codierungsstandard H.264 durchgeführt wird. Die Stärken der dedizierten Decodierhardware können genutzt werden, um ein besseres Spielerlebnis in einer Spiel-Streaming-Umgebung zu bieten, unabhängig von der gesamten Rechenleistung des Clients.
  • In lokalen, nicht gestreamten Rendering-Anwendungen kann die Spiele-Maschine mehrere Frames mit Latenzzeiten zwischen Spielereingabe und Video-Rückmeldung hinzufügen. In Spiel-Streaming-Anwendungen wird eine zusätzliche Latenzzeit für den Spielereingabe-Rückmeldungszyklus eingeführt, da die Spielereingabe durch das Netzwerk zum Remote-Server geleitet werden muss und die Videoausgabe codiert, übertragen und decodiert werden muss, bevor der Spieler eine Rückmeldung erhält. Bei einigen Spielereingaben kann der Client die Ergebnisse bezüglich Videorückmeldung schätzen, indem er sofort eine Bewegungskompensation durchführt und die Netzwerklatenz ausschaltet.
  • Grundsätzlich betrachtet, ist die Spielereingabebewegungskompensation eine Technik zum Verschieben von Pixelgruppen, um eine gewisse Bildgenauigkeit für eine Verringerung der Eingabe-Rückmeldungslatenz zu opfern, wenn ein Videospiel auf einem Server läuft, während es von einem vernetzten Client ferngesteuert wird. Diese Technik ist gut geeignet, die Spieler-Rückmeldungslatenz für Eingaben zu reduzieren, die zu reproduzierbaren Bewegungsvektoren führen, wie z.B. Spielerperspektivendrehungen in Ego-Spielen.
  • In einem Videospiel ist der Spielerkontext definiert als der aktuelle Spielstand, der sich aus früheren Spieleraktionen, Eingaben und Entscheidungen ergibt. Der Client in einem Spiel-Streaming-System ist dem Spielerkontext gegenüber naiv, d.h. der Client erhält nur die Videoausgabe und keine der Spielstatusinformationen, die die Ergebnisse bestimmter Spielereingaben bestimmen. Es gibt eine Vielfalt an Eingaben, die zu einzigartigen, aber vorhersehbaren Bewegungsergebnissen führen, die auf Spielstatusinformationen basieren. Diese Eingaben würden von einer Verringerung der Spieler-Rückmeldungslatenz profitieren, können aber nicht auf dem Client zur traditionellen Spielereingabebewegungskompensation zwischengespeichert werden, da der Client keine Spielerkontextinformationen hat. Darüber hinaus kann der Permutationsraum des Spielerkontextes zu umfangreich sein, um Bewegungsvektoren für Methoden wie zwischengespeicherte repetitive Bewegungsvektoren vorab zu generieren. Der Spielserver kann dies kompensieren, indem er antizipierte Bewegungsvektoren generiert und den Eingabe-Cache der Bewegungskompensation des Clients aktualisiert, wenn sich der Spielerkontext ändert. Dies ermöglicht es dem Client, Techniken zur Kompensation der Spieler-Eingabebewegung für einen begrenzten Satz von kontextabhängigen Eingaben zu verwenden, was zu einer Latenzreduzierung bei der Eingaberückmeldung führt.
  • („das '351-Patent“), offenbart Systeme und Verfahren zum Überspringen eines Frames während der Übertragung von einem Server zu einer Client-Vorrichtung, wobei als Reaktion auf das Erkennen des übersprungenen Frames die Client-Vorrichtung einen vorhergesagten Frame generiert, der den übersprungenen Frame im komprimierten Videostrom ersetzt, wobei der vorhergesagte Frame basierend auf der Erweiterung von Deltainformationen aus einem oder mehreren vorherigen Frames, die von dem Client-Gerät decodiert wurden, generiert wird. Bei dieser Technologie wird die clientseitige Frame-Vorhersage eines oder mehrerer rekonstruierter oder vorhergesagter Frames nach einem übersprungenen Frame basierend auf den Daten (z.B. Bewegungsvektoren, Residuen, etc.) eines oder mehrerer vorhergehender Frames verwendet. Die Technologie priorisiert auch die Bit¬Zuordnung und/oder die Codierung von Untermerkmalen. Encoded Network Abstraction Layer Units (NALUs) können in (1) Bewegungsvektoren und (2) Residuen unterteilt werden. Anstatt einen Frame aktuell zu überspringen, kann die Vorrichtung einfach nur minimale Codierungsdaten als priorisiert senden. Beispielsweise könnte sie nur Bewegungsvektoren senden, wenn die Bewegung priorisiert wird. Die vorliegende Erfindung ist der Technologie des '351-Patents überlegen, zumindest da das '351-Patents kein Client-Gerät offenbart, das übertragene Lookup-Tabellen von einem Server verwendet, um Benutzereingaben mit Bewegungsvektoren und Marken abzugleichen, und diese Bewegungsvektoren summiert. Das '351 -Patent offenbart auch nicht die Anwendung dieser summierten Bewegungsvektoren auf die decodierten Frames, um die Bewegung in diesen Frames zu schätzen. Die vorliegende Erfindung ist auch deshalb überlegen, weil sie die Eingabe-Rückmeldungslatenz reduziert, die deutlich reduziert wird, indem die Kompensation der Spieler-Eingabebewegung verwendet wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • („das '929-Patent“), betrifft den Betrieb eines vernetzten, interaktiven Spielsystems. Die offenbarten Verfahren sind darauf abgestellt, die Netzwerkverzögerung zu reduzieren, indem sie kurskorrigierte Positionswerte für ein gemeinsames globales Objekt durch bidirektionales Blending bestimmen. Das in dem Patent diskutierte „Blending“ beinhaltet die Schritte der Netzwerksimulation, die die Berechnung einer Pose für den lokalen Spieler auf der lokalen Konsole sendet. Die Konsole kombiniert die lokalen und Netzwerksimulationen. Die Methoden mischen auch gemeinsame globale Objekte, indem sie die gemischte Pose des lokalen Players verwenden, um einen Positionswert für das gemeinsame globale Objekt auf der lokalen Konsole zu bestimmen. Wiederum ist die vorliegende Erfindung der Technologie des '929-Patents überlegen, zumindest da das '929- Patent kein Client-Gerät offenbart, das von einem Server übermittelte Lookup-Tabellen verwendet, um Benutzereingaben mit Bewegungsvektoren und Marken abzugleichen und diese Bewegungsvektoren zu summieren. Das '929-Patent offenbart auch nicht die Anwendung dieser summierten Bewegungsvektoren auf die decodierten Frames, um die Bewegung in diesen Frames zu schätzen. Die vorliegende Erfindung ist auch deshalb überlegen, da sie nicht die Anwesenheit eines Clients mit extrem hoher Rechenleistung erfordert, die Eingabe-Rückmeldungslatenz reduziert, die durch die Anwendung von Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • („das '258-Patent“) betrifft die Verwendung der lokalen Bildverarbeitung, um die scheinbare Netzwerkverzögerung von Mehrspieler-Simulationen zu reduzieren. Die beschriebenen Verfahren schließen das Abfangen von Eingaben eines lokalen Benutzers, das Bestimmen der Zustandsdaten eines entfernten Objekts in einer Netzwerksimulation aus einem vorherigen Spielframe und das Bestimmen der Wechselwirkungen von nicht deterministischen Objekten aus mehreren Spielsystemen, die Teil der vernetzten Simulation sind, ein. Diese Interaktionsdaten werden zusammen mit den Statusdaten und der lokalen Eingabe verwendet, um eine lokale Simulation des Videobildes zu erzeugen. Auf diese Weise können die lokalen und Netzwerksimulationen asynchron für einen einzelnen Frame laufen, wobei jeder Frame einer einzelnen Zeitphase innerhalb des Spiels entspricht. Dies ermöglicht es, die lokalen Simulationsaktualisierungen in Echtzeit während des vernetzten Gameplays durchzuführen, während sie (im Wesentlichen) mit dem Netzwerk synchronisiert bleiben. Die vorliegende Erfindung ist der Technologie des '258-Patents wieder einmal überlegen, zumindest da das '258-Patent kein Client-Gerät offenbart, das von einem Server übermittelte Lookup-Tabellen verwendet, um Benutzereingaben mit Bewegungsvektoren und Marken abzugleichen und diese Bewegungsvektoren zu summieren. Das '929-Patent offenbart auch nicht die Anwendung dieser summierten Bewegungsvektoren auf die decodierten Frames, um die Bewegung in diesen Frames zu schätzen. Die vorliegende Erfindung ist auch deshalb überlegen, weil sie nicht die Anwesenheit eines Clients mit extrem hoher Rechenleistung erfordert, die Eingabe-Rückmeldungslatenz reduziert, die durch die Verwendung von Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • US 9 665 334 B2 („das '334-Patent“) offenbart Systeme und Verfahren zum Rendern von Protokollen unter Anwendung mehrerer Verfahren und eines Compositors, um die kombinierten Grafiken auf einem Display zu rendern. Die Technologie funktioniert wie folgt: Wenn der Server gleichzeitig einen Spielebildschirm für eine Anzahl von Client-Geräten bereitstellt, wird die Rechenlast der Rendering-Verarbeitung auf dem Server stark, z.B. bei einem Spielinhalt, der eine schnelle Reaktion erfordert. Das heißt, die Anzahl der Client-Geräte, denen der Server einen Bildschirm zur Verfügung stellen kann, ist je nach Rendering-Leistung und erforderlicher Reaktionsfähigkeit begrenzt. Im Gegensatz dazu, wenn jede Client-Vorrichtung gesteuert wird, um eine Verarbeitung auszuführen, die durch eine allgemeine Rendering-Leistung ausgeführt werden kann, um die Rendering-Prozesse zwischen dem Server und der Client-Vorrichtung zu teilen, kann ein Bildschirm für mehr Client-Geräte bereitgestellt werden. Auch hat ein Spielbildschirm, der ohne Textur-Abgleich gerendert wird, im Allgemeinen eine hohe Komprimierungseffizienz und kann mit einer kleineren Bandbreite über ein Netzwerk wie das Internet gesendet werden. Die vorliegende Erfindung ist der im '334-Patent beschriebenen Technologie zumindest deshalb überlegen, weil sie die Erzeugung von Bewegungsvektoren auf einem Server nach vorgegebenen Kriterien und die Übertragung der generierten Bewegungsvektoren und eines oder mehrerer Invalidatoren an einen Client, der diese Bewegungsvektoren und Invalidatoren zwischenspeichert, nicht offenbart. Es wird auch nicht offenbart, dass der Server den Client anweist, Eingaben von einem Benutzer zu empfangen, und diese Eingaben verwendet, um sie mit zwischengespeicherten Bewegungsvektoren oder Invalidatoren zu vergleichen, wo diese Vektoren oder Invalidatoren zur Bewegungskompensation verwendet werden. Die vorliegende Erfindung ist auch deshalb überlegen, da sie die Eingabe-Rückmeldungslatenz reduziert, die durch die Verwendung der Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • („das '454-Patent“), offenbart Systeme und Verfahren zur Codierung, umfassend das Untersuchen der Verfügbarkeit eines Tiefenblocks, der mit einem Texturblock zusammengesetzt ist, das Bestimmen eines Vorhersageverfahrens für einen Texturblock auf der Grundlage der Verfügbarkeit eines zusammengesetzten Tiefenblocks und das Ableiten eines ersten Vorhersageblocks für den Texturblock auf der Grundlage der Verfügbarkeit des zusammengesetzten Tiefenblocks. Auch hier ist die vorliegende Erfindung der im '454-Patent diskutierten Technologie überlegen, zumindest da sie die Erzeugung von Bewegungsvektoren auf einem Server nach vorgegebenen Kriterien und die Übertragung der generierten Bewegungsvektoren und eines oder mehrerer Invalidatoren an einen Client, der diese Bewegungsvektoren und Invalidatoren zwischenspeichert, nicht offenbart. Es wird auch nicht offengelegt, dass der Server den Client anweist, Eingaben von einem Benutzer zu empfangen, und diese Eingaben verwendet, um sie mit zwischengespeicherten Bewegungsvektoren oder Invalidatoren zu vergleichen, wenn diese Vektoren oder Invalidatoren zur Bewegungskompensation verwendet werden. Die vorliegende Erfindung ist auch deshalb überlegen, weil sie die Eingabe-Rückmeldungslatenz reduziert, die durch die Verwendung der Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • („das '526-Patent“) offenbart Systeme und Verfahren zur Entropiecodierung in Medien- und Bildanwendungen. Die Technologie offenbart ein System, wobei die Kompression mit dem Empfangen einer Bildquelle und/oder Videodatenquelle beginnt, wie angegeben. Anschließend wird ein verlustfreies Kompressionsschema angewendet. Eine Prädiktor/Delta-Berechnungseinheit übernimmt dann die Eingabe und versucht, die Redundanz in den Eingabedaten durch eine Deltaberechnung zwischen benachbarten Eingabeelementen zu reduzieren. Anschließend werden diese Werte mit einer vordefinierten statistischen Modellierung in einem Entropie-Codierer codiert, um die komprimierten Bild- und/oder Videodaten zu erzeugen. Ähnlich wie oben ist die vorliegende Erfindung der im '526-Patent beschriebenen Technologie überlegen, zumindest da sie das Generieren von Bewegungsvektoren an einem Server nach vorgegebenen Kriterien und das Übertragen der generierten Bewegungsvektoren und eines oder mehrerer Invalidatoren an einen Client, der diese Bewegungsvektoren und Invalidatoren zwischenspeichert, nicht offenbart. Es wird auch nicht offengelegt, dass der Server den Client anweist, Eingaben von einem Benutzer zu empfangen, und diese Eingaben verwendet, um sie mit zwischengespeicherten Bewegungsvektoren oder Invalidatoren zu vergleichen, wenn diese Vektoren oder Invalidatoren zur Bewegungskompensation verwendet werden. Die vorliegende Erfindung ist auch deshalb überlegen, da sie die Eingabe-Rückmeldungslatenz reduziert, die durch die Verwendung der Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • US 8 873 636 B2 („das '636-Patent“) betrifft einen Bewegtbildverteilungsserver (z.B. einen, der ein Online-Spiel betreibt), der codierte Bilddaten an den PC des Benutzers liefert und die lokale Instanz des Spiels ausführt. Um diesen Prozess in relevanten Details durchzuführen, spezifiziert die CPU des PCs des Benutzers den zu referenzierenden Bereich, um den Bewegungsvektor zu decodieren, der dem ausgewählten Block in dem vorhergehenden Framebildschirm zugeordnet ist. Dies geschieht unter Bezugnahme auf den dem ausgewählten Block zugeordneten Bewegungsvektor (ein Vektor, der in den bereitgestellten Vorverarbeitungsinformationen enthalten ist) und extrahiert das Bild des Bereichs als Referenzbild. Wie in den anderen Druckschriften ist die vorliegende Erfindung der im '636-Patent beschriebenen Technologie zumindest deshalb überlegen, da sie die Erzeugung von Bewegungsvektoren auf einem Server nach vorgegebenen Kriterien und die Übertragung der generierten Bewegungsvektoren und eines oder mehrerer Invalidatoren an einen Client, der diese Bewegungsvektoren und Invalidatoren zwischenspeichert, nicht offenbart. Es wird auch nicht offengelegt, dass der Server den Client anweist, Eingaben von einem Benutzer zu empfangen, und diese Eingaben verwendet, um sie mit zwischengespeicherten Bewegungsvektoren oder Invalidatoren zu vergleichen, wenn diese Vektoren oder Invalidatoren zur Bewegungskompensation verwendet werden. Die vorliegende Erfindung ist auch deshalb überlegen, weil sie die Eingabe-Rückmeldungslatenzreduziert, die durch die Verwendung der Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • WO 2009/138878 A2 („die '878-Veröffentlichung“) betrifft die Verarbeitung und das Streaming mehrerer interaktiver Anwendungen in einem zentralisierten Streaming-Anwendungsserver, wobei der Detaillierungsgrad und die Nachfilterung verschiedener gerenderter Objekte gesteuert werden. Im System führt ein zentralisierter interaktiver Anwendungsserver an seinem Videopräprozessor eine räumliche und zeitliche Filterung der Framesequenz durch, bevor er einen komprimierten Strom von audiovisuellen Inhalten auf Client-Geräte codiert, die den komprimierten Strom decodieren und den Inhalt anzeigen. Der GPU-Befehlsprozessor des zentralisierten interaktiven Applikationsservers schließt ein Modul ein, das auch eine Bewegungskompensationsschätzung für jeden Makroblock im zielcodierten Frame im Video-Codierer berechnet. Dennoch bleibt die vorliegende Erfindung der in der '878er Veröffentlichung diskutierten Technologie überlegen, zumindest da sie die Erzeugung von Bewegungsvektoren auf einem Server nach vorgegebenen Kriterien und die Übertragung der generierten Bewegungsvektoren und eines oder mehrerer Invalidatoren an einen Client, der diese Bewegungsvektoren und Invalidatoren zwischenspeichert, nicht offenbart. Es wird auch nicht offengelegt, dass der Server den Client anweist, Eingaben von einem Benutzer zu empfangen, und diese Eingaben verwendet, um sie mit zwischengespeicherten Bewegungsvektoren oder Invalidatoren zu vergleichen, wenn diese Vektoren oder Invalidatoren zur Bewegungskompensation verwendet werden. Die vorliegende Erfindung ist auch deshalb überlegen, weil sie die Eingabe-Rückmeldungslatenzreduziert, die durch die Verwendung der Spielereingabebewegungskompensation deutlich reduziert wird, anstatt darauf zu warten, dass der Server das Ausgabevideo zurücksendet.
  • US 9 358 466 B2 („das '466 Patent“) betrifft die Verbesserung der Leistung von Videospielen durch die Wiederverwendung von zwischengespeicherten Daten. Die Systeme offenbarten die Score Cache-Leistung verschiedener generierter Videospielmissionen zumindest teilweise, indem sie die verwendeten digitalen Assets identifizierten und feststellten, ob sich die identifizierten digitalen Assets in einem Cache befinden. Die Cache-Scores können basierend auf einer Cache-Wiederverwendungsrate berechnet werden, die einem Anteil der digitalen Assets für eine Mission entspricht, die sich bereits in einem Cache befinden. Andere Techniken zum Generieren von Cache-Scores können Faktoren wie die Gesamtgröße der kombinierten digitalen Assets für eine Mission, die sich bereits in einem Cache befinden und/oder die Gesamtgröße der kombinierten digitalen Assets für eine Mission, die sich noch nicht in einem Cache befinden, berücksichtigen. Durch diese Art des Caching von Daten werden Daten und andere nicht zwischengespeicherte Datenanforderungen effizienter. Die vorliegende Erfindung bleibt der im '466-Patent diskutierten Technologie überlegen, zumindest da sie das Caching repetitiver Bewegungsvektoren, das Berechnen einer Bewegungsabschätzung aus den Eingabedaten oder das Aktualisieren der gespeicherten Bewegungsvektorbibliothek basierend auf den Eingabedaten nicht offenbart, so dass ein Client die gespeicherte Bewegungsvektorbibliothek verwenden kann, um eine Bewegung auszulösen, bevor er aktuelle Bewegungsvektordaten von einem Server erhält.
  • US 6 903 662 B2 („das '662-Patent“) betrifft eine konfigurierbare Computereingabevorrichtung, insbesondere eine, die Eingabedaten zwischenspeichert, um schnellere Reaktionszeiten aufrechtzuhalten. Das System arbeitet durch die Überprüfung von Tastendrücken gegen einen internen Speicher (oder Cache), um festzustellen, ob der jeweilige Schlüssel zuvor identifiziert wurde. Wenn das System vor diesem Zeitpunkt nicht mit dem Schlüssel kommuniziert hat, dann kann das System die der Eingabe entsprechenden Daten aus seinem Schlüsselspeicher abrufen. Das System aktualisiert dann seinen internen Speicher (Cache) mit der Schlüsselidentität und den entsprechenden Daten. Das System kann dann die Eingabedaten von dem Schlüssel an den Hostcomputer senden. Wenn das System jedoch das nächste Mal auf die gleiche Taste im gedrückten Zustand trifft, kann es seinen eigenen Speicher (Cache) abfragen, anstatt den gleichen Scan-Code erneut aus dem Schlüsselspeicher abzurufen. Die vorliegende Erfindung ist der im '662-Patent diskutierten Technologie überlegen, zumindest da sie das Caching repetitiver Bewegungsvektoren, das Berechnen einer Bewegungsabschätzung aus den Eingabedaten oder das Aktualisieren der gespeicherten Bewegungsvektorbibliothek basierend auf den Eingabedaten nicht offenbart, so dass ein Client die gespeicherte Bewegungsvektorbibliothek verwenden kann, um eine Bewegung auszulösen, bevor er aktuelle Bewegungsvektordaten von einem Server erhält.
  • JP 6 129 865 B2 („das '865-Patent“), offenbart Systeme und Verfahren zur Übertragung der gerenderten Spielinhaltsdaten für die Teilmengen von Pfadsegmenten an einen Spiel-Client zum Zwischenspeichern auf dem lokalen Cache, so dass die Spielinhaltsdaten bei Bedarf während des Echtzeit-Spiels verfügbar sind. Auch hier ist die vorliegende Erfindung der im '865-Patent diskutierten Technologie überlegen, zumindest da sie das Caching repetitiver Bewegungsvektoren, das Berechnen einer Bewegungsabschätzung aus den Eingabedaten oder das Aktualisieren der gespeicherten Bewegungsvektorbibliothek basierend auf den Eingabedaten nicht offenbart, so dass ein Client die gespeicherte Bewegungsvektorbibliothek verwenden kann, um eine Bewegung auszulösen, bevor er aktuelle Bewegungsvektordaten von einem Server erhält.
  • („das '919-Patent“) offenbart Systeme und Verfahren zum Caching von Referenzdaten in einer Blockverarbeitungspipeline. Die '919 Patenttechnologie offenbart einen Cache-Speicher (z.B. einen vollständig assoziativen Cache), der beispielsweise in einem lokalen (zum Pipeline-) Speicher wie SRAM (statischer Direktzugriffsspeicher) implementiert werden kann, auf den Teile der Chroma-Referenzdaten (z.B. 64-Byte-Speicherblöcke), die Bewegungsvektoren entsprechen, die für Makroblöcke in früheren Phasen der Pipeline bestimmt wurden, aus dem Speicher vorgezogen werden können. Die Chroma- Cache-Logik kann den Cache aufrechterhalten und sich über mehrere Stufen der Pipeline erstrecken. Abrufe für die Bewegungsvektoren eines bestimmten Makroblocks, der durch die Pipeline verläuft, können durch die Chroma-Cache-Logik eine oder mehrere Stufen vor der Chroma-Bewegungskompensationsphase eingeleitet werden, um Zeit (d.h. mehrere Pipeline-Zyklen) bereitzustellen, um die jeweiligen Speicherblöcke aus dem Speicher in den Cache zu lesen, bevor die Chroma-Bewegungskompensation dies erfordert. Das '919-Patent bleibt jedoch im Vergleich zu der vorliegenden Erfindung unzureichend. Die vorliegende Erfindung ist der im '919-Patent diskutierten Technologie überlegen, zumindest da sie das Caching repetitiver Bewegungsvektoren, das Berechnen einer Bewegungsabschätzung aus den Eingabedaten oder das Aktualisieren der gespeicherten Bewegungsvektorbibliothek basierend auf den Eingabedaten nicht offenbart, so dass ein Client die gespeicherte Bewegungsvektorbibliothek verwenden kann, um eine Bewegung auszulösen, bevor er aktuelle Bewegungsvektordaten von einem Server empfängt.
  • 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 Codierung von Echtzeit-Spielumgebungen.
  • ZUSAMMENFASSUNG DER ERFINDUNG
  • Es ist die Aufgabe der vorliegenden Erfindung ein Verfahren sowie ein System zum Zwischenspeichern von Bewegungsvektoren vorzuschlagen bei dem die Latenzzeit reduziert ist. Diese Aufgabe wird durch die Gegenstände der Ansprüche 1 und 11 gelöst. Bevorzugte Ausgestaltungen sind Gegenstand der Unteransprüche
    Insbesondere kann ein Client-Gerät eine von einem Server übertragene Lookup-Tabellen verwenden, um Benutzereingaben mit Bewegungsvektoren abzugleichen und diese Bewegungsvektoren zu markieren und zu summieren. Wenn ein Remote-Server codierte Videoframes an den Client sendet, decodiert der Client diese Videoframes und wendet die summierten Bewegungsvektoren auf die decodierten Bilder an, um die Bewegung in diesen Bildern zu schätzen.
  • Die codierten Videoframes können ohne Restbehandlung decodiert werden.
  • Der Client kann eine oder mehrere Glättungsfunktionen auf die summierten markierten Bewegungsvektoren in der Warteschlange anwenden.
  • Die den Bewegungsvektoren auf dem Client-Gerät zugeordneten Marken können chronologischer Natur sein.
  • Die Bewegungsvektoren können auf einem Server basierend auf vorgegebenen Kriterien generiert werden und die generierten Bewegungsvektoren und ein oder mehrere Invalidatoren können an einen Client übertragen werden, der diese Bewegungsvektoren und Invalidatoren zwischenspeichert. Der Server kann den Client anweisen, Eingaben von einem Benutzer zu empfangen und kann diese Eingaben verwenden, um sie mit zwischengespeicherten Bewegungsvektoren oder Invalidatoren abzustimmen. Basierend auf diesem Vergleich kann der Client dann die angepassten Bewegungsvektoren oder Invalidatoren anwenden, um Bewegungskompensation in einer grafischen Oberfläche zu bewirken.
  • Die Bewegungsvektoren können in einer Lookup-Tabelle zwischengespeichert werden.
  • Die Invalidatoren können mit einem oder mehreren zwischengespeicherten Bewegungsvektoren verknüpft werden.
  • Der Client kann angewiesen werden, einen oder mehrere zwischengespeicherte Bewegungsvektoren zu löschen, wenn die Eingabe mit einem zwischengespeicherten Invalidator übereinstimmt, der einem oder mehreren Bewegungsvektoren zugeordnet ist.
  • Durch Zwischenspeichern von repetitiven Bewegungsvektoren auf einem Server, der eine zuvor generierte Bewegungsvektorbibliothek an einen Client überträgt, kann die Latenzzeit reduziert werden. Der Client kann die Bewegungsvektorbibliothek speichern und die Benutzereingaben überwachen. Der Server kann den Client anweisen, aus den Eingabedaten eine Bewegungsabschätzung zu berechnen und den Client anweisen, die gespeicherte Bewegungsvektorbibliothek basierend auf den Eingabedaten zu aktualisieren, so dass der Client die gespeicherte Bewegungsvektorbibliothek anwendet, um eine Bewegung in einer grafischen Oberfläche zu starten, bevor er aktuelle Bewegungsvektordaten aus dem Server empfängt.
  • Der Server kann eine Kontext-Aktualisierung an den Client senden, um die Anwendung der gespeicherten Bewegungsvektorbibliothek zu deaktivieren.
  • Ein oder mehrere Skalierungsfaktoren können auf die Bewegungsvektorbibliothek angewendet werden.
  • Figurenliste
  • Eine umfassendere Würdigung der Erfindung und vieler der damit verbundenen Vorteile wird leicht erlangt, da diese durch Bezugnahme auf die folgende detaillierte Beschreibung besser verstanden wird, wenn sie im Zusammenhang mit den beigefügten Zeichnungen betrachtet wird. Es zeigen:
    • 1 ein Blockdiagramm, das beispielhaft ein Remote-Spielsystem veranschaulicht, in dem ein Videospiel auf einem Server läuft, während es durch Eingabe an einem Remote-Client gesteuert wird;
    • 2 ein Ablaufdiagramm, das beispielhaft die Reduzierung der Eingabe-Rückmeldungslatenz in Spiel-Streaming-Anwendungen durch Anwendung der Bewegungskompensation für eine entsprechende Spielereingabe beschreibt;
    • 3 ein Blockdiagramm, das beispielhaft einen beispielhaften Moment während der Laufzeit einer Videospiel-Streaming-Umgebung veranschaulicht, die eine Spielereingabebewegungskompensation verwendet;
    • 4 ein Diagramm, das beispielhaft einen beispielhaften Makroblock während der Spielereingabebewegungskompensation von 3 darstellt;
    • 5 ein Diagramm, das beispielhaft eine alternative Methode zur Anwendung von Bewegungsvektoren bei der Spielereingabebewegungskompensation auf dem Client veranschaulicht;
    • Die 6A, 6B und 6C einen beispielhaften Makroblock, der einer Bewegungskompensation und einem Blending für das in 5 dargestellte alternative Verfahren unterzogen wird;
    • 7 ein Diagramm, das die Laufzeitgenerierung von antizipierten Bewegungsvektoren veranschaulicht;
    • 8 ein Ablaufdiagramm, das beispielhaft die Übertragung und clientseitige Speicherung von antizipierten Bewegungsvektoren zum Zwecke der Spielereingabebewegungskompensation veranschaulicht;
    • 9 ein Diagramm, das einen beispielhaften Prozess der Invalidierung von antizipierten Bewegungsvektoren veranschaulicht;
    • 10 ein Diagramm, das ein beispielhaftes Verfahren zum Generieren der Bewegungsvektorbibliothek und eine beispielhafte repetitive Bewegungsvektorbibliothek für Zwischenspeicherzwecke darstellt;
    • 11 ein Ablaufdiagramm, das beispielhaft den Prozess zum Zwischenspeichern, Anwenden und Aktualisieren von Bewegungsvektorbibliotheken zur Spielereingabebewegungskompensation veranschaulicht;
    • 12 ein Diagramm, das beispielhaft veranschaulicht, wie die Bewegungsvektorzuordnung aktualisiert werden kann; und
    • 13 ein Diagramm, das eine beispielhafte Modifikation zum Anwenden von Multiframe-Bewegungsvektoren bei der Kompensation von Spielereingaben veranschaulicht, insbesondere bei zwischengespeicherten Bewegungsvektoren.
  • DETAILLIERTE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
  • Bei der Beschreibung der bevorzugten Ausführungsformen der in den Zeichnungen dargestellten 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 ist zu verstehen, 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 dargestellt sind.
  • Bestimmte Arten von Spielereingaben sind bessere Kandidaten für die Spielereingabebewegungskompensation. Zwei Faktoren tragen zur Eignung einer gegebenen Eingabe bei: die Spielerempfindlichkeit gegenüber der Eingabe-Rückmeldungslatenz und die Schwierigkeit, die Kompensation der Spieler-Eingabebewegung ohne signifikante Artefakte zu implementieren. Jeder Beitrag muss auf seine Eignung hin bewertet werden, bei einem Egoshooter-Spiel zum Beispiel ist der Spieler sehr empfindlich auf mausbasierte Blickrotation, ein Bruchteil einer zweiten Verzögerung von nur 16 ms zwischen Spielereingabe und Videoausgabe ist spürbar. In dergleichen Situation ist die Gamepad-Steuerung-basierte Blickrotation jedoch typischerweise langsamer und die Spieler sind möglicherweise weniger empfindlich gegenüber der Eingabe-Rückmeldungslatenz. Die Blickrotation kann durch Verschieben der Szene in die entgegengesetzte Richtung der Rotation angenähert werden, aber es kann zu unerwünschten Artefakten entlang des Bildrandes in Rotationsrichtung kommen. Bei kleinen Blickrotationen, wie z.B. der Einstellung des Ziels auf einen Gegner auf dem Bildschirm, bemerken die Spieler möglicherweise nicht einmal Kantenartefakte. In einem anderen Beispiel kann die Beschleunigung eines Autos in einem Bewegungsspiel aufgrund mangelnder Spielersensibilität und/oder Trägheit gegenüber Latenzzeiten eine geringe Priorität für die Spielereingabebewegungskompensation haben, aber Lenk- und Bremseingaben können eine hohe Priorität haben, da die Spieler Eingaberückmeldungslatenz bemerken.
  • Die Zeit zwischen dem Empfangen einer Spielereingabe und dem Anzeigen einer Bewegungsausgabe ist die Spieler-Rückmeldungslatenzzeit. Durch die Verwendung der Bewegungskompensation kann eine geschätzte Bewegung nahezu sofort Rückmeldung bereitstellen, während sie darauf wartet, dass der Server die Spielereingabe verarbeitet. Auf diese Weise wird die Spieler-Rückmeldungslatenzzeit in Game-Streaming-Anwendungen drastisch reduziert. Durch die Implementierung einer Spielereingabebewegungskompensation in einer Spiel-Streaming-Anwendung kann eine Bewegungsabschätzung im nächsten verfügbaren Frame bereitgestellt werden. Im Gegensatz dazu benötigt die Eingabe mehrere Frames, um zum Server zu gelangen, einen Ausgabeframe zu erzeugen und zurückzukehren. Die Spielereingabebewegungskompensation kann auch in traditionellen, nicht gestreamten Spieleanwendungen von Vorteil sein, bei denen die Spiele-Maschine und der Renderer eine Spieler-Rückmeldungslatenz von wenigen Bildern aufweisen können.
  • Der Client hat nicht den geeigneten Kontext, um die Bewegung eines Objekts auf dem Bildschirm zu verfolgen. Die Spielereingabebewegungskompensation ist nicht für Fälle geeignet, wobei die Position bestimmter Makroblöcke oder Videoobjekte für den Client nicht bekannt ist. So kann sich beispielsweise bei einem 2D-Plattformspiel der Charakter auf dem Bildschirm von links nach rechts bewegen. Der Client weiß nicht, wo sich der Charakter befindet, wenn der Spieler die Sprungeingabe drückt; daher kann in diesem Fall die Spielereingabebewegungskompensation allein nicht verwendet werden, um die Latenzzeit der Eingabe zu reduzieren.
  • Im Allgemeinen sollten die Bewegungsvektoren für die Spielereingabebewegungskompensation vorab generiert werden. Für Bewegungen wie die Drehung der Spielerkamera können die Bewegungsvektoren basierend darauf berechnet werden, wie das Spiel die Eingabe gewichtet. In bestimmten Ausführungsformen können die Bewegungsvektoren der Eingabewert multipliziert mit der Empfindlichkeitsgewichtung sein. Für Bewegungen, die nicht direkt berechnet werden können, wie z.B. animierte Bewegungen, kann die Animation während der Entwicklung so ausgelöst werden, dass die Bewegungsvektoren direkt gemessen und gespeichert werden können. Das Messen von Bewegungsvektoren kann durch die gleichen Bewegungsschätzungstechniken erreicht werden, die während der H.264-Codierung durchgeführt werden.
  • 1 veranschaulicht ein Beispielsystem, wobei ein Videospiel von einem Remote-Client gesteuert wird. In diesem System hostet ein Server 100 die Videospiel-Software 102 und eine Grafik-Maschine 104, die die Videoausgabe übernimmt. Das Video wird in einem Codec (auch als Codiermaschine oder Codierer bezeichnet) 106 codiert und die codierten Videodaten 108 werden an einen entfernten Client übertragen. Die Serverarchitektur 100 kann eine beliebige Kombination aus Hard- oder Software sein, die die Funktionen der Grafik-Maschine 104 und des Codec 106 unterstützen kann. In dem gegebenen Beispiel kann die Grafik-Maschine 104 als beispielsweise eine GPU 110 implementiert sein, die von der Videospiel-Software 102 gesteuert wird, die in einen computerlesbaren Speicher 112 geladen wird, während der Codec 106 als CPU 114 mit Videocodierungssoftware implementiert werden kann.
  • Der Remote-Client besteht aus einem Computersystem 116, das in der Lage ist, einen clientseitigen Codec 118 zum Decodieren der übertragenen codierten Videodaten 108 und eine Clientanwendung 120 zum Anwenden der Spielereingabebewegungskompensation auszuführen. Das Client-Computersystem 116 enthält auch eine Anzeigesteuerung 122 zum Ansteuern der Anzeigehardware 124. Die Eingaben der clientseitigen Eingabeperipherie 126 werden von der Client-Anwendung 120 in Steuerdaten 128 umgewandelt, die an die auf dem Server 100 laufende Spielsoftware 102 zurückgesendet werden. Der Eingang von den Peripheriegeräten 126 wird auch verwendet, um zu bestimmen, um welche es sich handelt, sofern vorhanden, Spielereingabebewegungskompensation angewendet werden soll, wie in 2 näher erläutert.
  • 2 ist ein Ablaufdiagramm, das die Schritte beschreibt, die erforderlich sind, um die Spielereingabebewegungskompensation für eine einzelne Eingabe durchzuführen. Wenn der Client initialisiert, sendet der Server eine Lookup-Tabelle mit Eingaben und den zugehörigen Bewegungsvektoren bei Schritt 200, die dann vom Client bei Schritt 202 zwischengespeichert wird. In dieser Implementierung wird der Client generalisiert, um die Anforderungen mehrerer Streaming-Spiele zu erfüllen. In bestimmten Ausführungsformen kann ein spielspezifischer Client die Schritte 200 und 202 überspringen, da er bereits die Lookup-Tabelle für das Spiel enthält. In einer alternativen Implementierung kann ein spielspezifischer Client die Bewegungsvektor-Lookup-Tabelle dauerhaft speichern, ohne dass der Server Zwischenspeichern muss.
  • Wenn der Client bei Schritt 204 Spielereingaben von einem Eingabegerät wie einer Maus oder einer Gamepad-Steuerung empfängt, überprüft die Client-Anwendung die zwischengespeicherte Bewegungsvektor-Lookup-Tabelle auf passende Eingaben bei Schritt 206. Wenn keine passenden Spielereingaben vorhanden sind, ergreift der Client keine zusätzlichen Maßnahmen und sendet Eingaben ohne zusätzliche Modifikationen an den Server. Wenn eine passende Spielereingabe im Zwischenspeicher vorhanden ist, wendet der Client eine Spielereingabebewegungskompensation an. gegebenenfalls kann der Zwischenspeicher in der Lage sein, Einträge in der Lookup-Tabelle basierend auf der Eingabe des Spielers zu ändern. Wenn der Spieler beispielsweise die Pausentaste drückt, sollten alle Eingaben für die Spielerbewegung deaktiviert werden, bis der Spieler den Pausenbildschirm verlässt. In einer Implementierung kann die clientgesteuerte Lookup-Tabelle zwei Sätze von Eingaben aufweisen, einen für die Verwendung im Pausenmenü und einen für die Verwendung außerhalb des Pausenmenüs, die, vorzugsweise vom Client, umgeschaltet werden, wenn der Spieler die Pauseneingabe wählt. In einer alternativen Implementierung kann der Server den Inhalt der zwischengespeicherten Lookup-Tabelle auf dem Client wechseln.
  • Wenn die Client-Anwendung eine Spielereingabe zur Bewegungskompensation erhält, fügt der Client bei Schritt 208 der Spielereingabe und den zugehörigen Bewegungsvektoren eine Marke hinzu. Die markierte Eingabe wird bei Schritt 210 an den Server gesendet. Die Marke ist jede Kennung, die die Spielereingabe mit einem zukünftigen Frame korrelieren kann. So kann beispielsweise die Kennung eine ganze Zahl sein, die jedes Mal erhöht wird, wenn der Client Eingaben erhält, die zur Kompensation der Spielereingabenbewegung verwendet werden. Die Marke kann als Metadaten im gleichen Netzwerkpaket wie die Spielereingabe hinzugefügt oder in einem ähnlichen Messaging-Muster gesendet werden, das die Markeninformationen mit den Eingabeinformationen synchronisiert. Der Client bestätigt, ob bei Schritt 213 eine Marke empfangen wird oder nicht. Während die Spielereingabe markiert und gesendet wird, wendet der Client die in der zwischengespeicherten Lookup-Tabelle bei Schritt 212 enthaltenen Bewegungsvektoren an. Diese Bewegungsvektoren werden für jedes eingehende Bild angewendet, bis die entsprechende Marke von dem Server zurückgesendet wird. Eine detaillierte Beschreibung eines Beispiel-Verfahrens zur Anwendung dieser Bewegungsvektoren ist in 3 dargestellt.
  • Wenn der Server markierte Spielereingaben erhält, wird die markierte Spielereingabe an das Spiel weitergeleitet, das bei Schritt 214 einen Ausgabeframe generiert. Das Videobild wird dann bei Schritt 216 codiert. Bevor der codierte Frame an den Client zurückgesendet wird, wird die Spielereingabe-Marke bei Schritt 218 an den codierten Frame angehängt. Dies ist die gleiche Marke, die zuvor mit dem Spielereingabe gesendet wurde und bedeutet, dass der Ausgabeframe die aktuelle Videorückmeldung aus der Spielereingabe enthält. Das Anhängen einer Marke an den codierten Frame kann durch Hinzufügen der Marke als Metadaten zum gleichen Netzwerkpaket wie der codierte Frame erfolgen. Der mit einer Marke versehene codierte Frame wird bei Schritt 220 an den Client zurückgesendet. Wenn der Client einen codierten Frame mir einer Marke empfängt, kann der Client die Marke mit einer vorherigen Bewegungskompensation für die Spielereingabe korrelieren. Der Client stoppt dann die Anwendung der vorherigen Bewegungskompensation bei Schritt 222.
  • 3 ist eine Veranschaulichung eines beispielhaften Moments während der Laufzeit einer Videospiel-Streaming-Umgebung, die die Spielereingabebewegungskompensation nutzt. Wenn der Client bei Schritt 300 eine Spielereingabe erhält, wird diese mit der Tabelle zur Bewegungsvektorsuche bei Schritt 302 verglichen. Wenn eine passende Spielereingabe vorhanden ist, werden die zugehörigen Bewegungsvektoren zur Spielereingabebewegungskompensation verwendet. Die Bewegungsvektoren werden bei Schritt 306 mit einer unverwechselbaren Eingabemarke bei Schritt 304 gekennzeichnet. In diesem Beispiel ist die gewählte Marke die ganze Zahl „1003“. Die markierten Bewegungsvektoren werden bei Schritt 308 zu einer Warteschlange hinzugefügt, die alle anderen markierten Bewegungsvektoren enthält, die derzeit für die Spielereingabebewegungskompensation verwendet werden.
  • Der nächste Frame kommt im Bitstream aus dem Server bei Schritt 320 an. Dieser Frame wird bei Schritt 318 mit einer unverwechselbaren Kennung versehen, in diesem Fall mit der Ganzzahl „1001“, die angibt, dass der Frame die resultierende Bewegung aller vorherigen Spielereingaben bis einschließlich der Eingabe entsprechend der Marke „1001“ enthält. Die Marke „1001“ zeigt dem Client an, dass er die Anwendung der Bewegungskompensation bei Schritt 322 für diese markierte Eingabe einstellen kann. Die Bewegungsvektoren mit der Marke „1001“ werden dann bei Schritt 308 aus der markierten Bewegungsvektorwarteschlange entfernt, zusammen mit allen Bewegungsvektoren mit früheren Marken, die in der Warteschlange verbleiben können, falls vorherige Pakete verloren gegangen sind.
  • Das codierte Video 316 wird bei Schritt 324 decodiert. Unterdessen werden die verbleibenden Bewegungsvektoren in der Bewegungsvektorwarteschlange bei Schritt 308 bei Schritt 310 summiert. Die Bewegungsvektoren sind typischerweise Vektorfelder mit einem Vektor für jeden Makroblock im Bild. Um die Bewegungsvektoren zu summieren, werden die Vektoren elementweise so summiert, dass das Ergebnis ein Vektorfeld mit einem Vektor für jeden Makroblock ist. Die Summe zweier Vektorfelder ist die Vektorsumme der Vektoren für jeden Punkt im Feld, so dass die Summe zweier Sätze von Bewegungsvektoren die Vektorsumme für jeden Makroblock im Bild ist. Die Summe zweier Vektoren ist definiert als die komponentenweise Summe ihrer Komponenten, die als {u1, u2} + {v1, v2} = {u1 + v1, u2 + v2} dargestellt werden kann. In diesem Beispiel sind zwei Sätze von Bewegungsvektoren mit den Marken „1002“ und „1003“ in der Warteschlange enthalten; diese beiden Sätze von Bewegungsvektoren werden summiert. Die Marken sind chronologischer Natur, was es dem Client ermöglicht, die Reihenfolge der zuvor markierten Spielereingaben zu kennen. Dadurch kann der Client markierte Bewegungsvektoren bis hin zur Return-Marke in einem eingehenden Frame verwerfen. Darüber hinaus ist das oben beschriebene Markieren rechnerisch günstiger als komplexere Verfahren. An dieser Stelle können optionale Glättungsfunktionen angewendet werden, um Klemmartefakte zu vermeiden oder ähnliche eingeführte Artefakte abzumildern.
  • Klemmartefakte werden eingeführt, wenn Makroblöcke aus dem Bildschirm verschoben werden und sich als Verschmieren von Pixelfarben senkrecht zum Bildschirmrand manifestieren. Eine beispielhafte Glättungsfunktion würde die Stärke von nach außen gerichteten Bewegungsvektoren verringern, wenn sie näher an den Bildrand heranrücken. Lediglich die nach außen gerichtete Komponente muss geschwächt werden, die y-Komponente für nach außen gerichtete Vektoren zum oberen und unteren Rand des Bildes und die x-Komponente für nach außen gerichtete Vektoren zum linken und rechten Rand des Bildes. Für Vektoren, die auf den Rand zeigen, könnte die Vektorkomponente mit dem Quadrat des Abstands vom Rand multipliziert werden, so dass, wenn sich der Abstand vom Rand dem Nullpunkt nähert, sich die Vektorkomponente dem Nullpunkt nähert. In diesem Beispiel wird ein nach außen gerichteter Vektor zum rechten Bildrand von {x,y} auf {x*d*d*d,y} transformiert, wobei d der Abstand vom Rand ist. Dadurch werden die Klemmartefakte gemildert, im Austausch für eine leichte Bildverzerrung und den Rand des Bildes. Die Verzerrung ist für den Spieler weitaus weniger auffällig als die Klemmartefakte.
  • Nachdem der Decodiervorgang bei Schritt 324 an dem codierten Videobild abgeschlossen ist, werden die summierten Bewegungsvektoren bei Schritt 312 zur Bewegungskompensation verwendet. Das resultierende Video wird bei Schritt 314 ausgegeben. Diese Ausgabe enthält die Spieler-Eingabebewegungskompensationsdaten und wird auf dem Client angezeigt. Dieser ausgegebene Frame ist der erste Frame, der eine Bewegungsabschätzung für die Eingabe mit Korrelationsmarke „1003“ enthält. Dieser ausgegebene Frame enthält auch eine Bewegungsschätzung für die vorherige Eingabe mit Korrelationsmarke „1002“, bei der der Client noch darauf wartet, dass der Server aktuelle Bewegungsvektoren zurückgibt. Dieser ausgegebene Frame ist auch der erste Frame, der die aktuellen Bewegungsvektoren für eine vorherige Eingabe mit Korrelationsmarke „1001“ enthält, für die der Client zuvor die Bewegung geschätzt hatte. Infolgedessen existieren an dieser Stelle des Verfahrens drei Bewegungsschätzungszustände: ein neuer Schätzungszustand für neue Eingaben; ein fortgesetzter Schätzungszustand, der auf aktuelle Ergebnisse wartet; und ein weiterer Schätzungszustand, der gestoppt wird, weil aktuelle Ergebnisse beim Client angekommen sind.
  • 4 ist ein Diagramm, das einen beispielhaften Makroblock während des Spielereingabebewegungskompensationschritts in 3 veranschaulicht. Der Spielereingabebewegungskompensationschritt ähnelt verfahrenstechnisch dem Verfahren, das während der H.264-Decodierung durchgeführt wird, wobei decodierte Bewegungsvektoren verwendet werden, um zu bestimmen, wo sich Makroblöcke im aktuellen Frame von dem vorherigen Frame bewegt haben. Für die Spielereingabebewegungskompensation schätzen die angewandten Bewegungsvektoren die zukünftige Rückmeldung für eine Spielereingabe durch Bewegen der Makroblöcke im aktuellen Frame, bevor das Ausgabevideo für den Spieler angezeigt wird. 4A zeigt die beiden Sätze von markierten Bewegungsvektoren in der Warteschlange bei Schritt 400 aus den beispielhaften markierten Bewegungsvektoren bei Schritt 308 in 3. Diese beiden Sätze werden summiert, indem die Vektorsumme für jeden Makroblock in dem Bild herangezogen wird, um einen Satz von Bewegungsvektoren bei Schritt 402 in 4B zu erzeugen. Jeder der Bewegungsvektoren in diesem Satz stellt die geschätzte Bewegung für jeden Makroblock im aktuellen Frame dar. Für jeden Vektor in den summierten Bewegungsvektoren bei Schritt 402 wird ein entsprechender Makroblock im Beispielbild von 4C verschoben. Ein Beispiel für einen Makroblock ist in 4C dargestellt, der um seinen entsprechenden Spielereingabebewegungsvektor bei Schritt 404 verschoben wird. Jeder Makroblock im Beispielbild wird auf diese Weise verschoben. Das Beispielbild in 4C enthält nur 50 Makroblöcke, aber ein hochdefiniertes Bild enthält Tausende von Makroblöcken. Die in 4 dargestellten beispielhaften Bewegungsvektoren zeigen eine einheitliche starre Bewegung, aber die beschriebene Technik der Bewegungskompensation kann mit Bewegungsvektoren beliebiger Komplexität verwendet werden, um Rotationen, Vibrationen oder andere komplexe Bewegungen im Bildschirmraum zu beschreiben, die in der Technik bekannt sind.
  • 5 ist eine Veranschaulichung eines alternativen Verfahrens zum Anwenden von Bewegungsvektoren während der Spielereingabebewegungskompensation auf dem Client. In bestimmten Ausführungsformen dieses Verfahrens ist es nicht notwendig, Residuen während der Codierung und Decodierung von Videos zu behandeln. Nachdem eine passende Spielereingabe in der Lookup-Tabelle gefunden wurde, werden die zugehörigen Bewegungsvektoren bei Schritt 500 markiert und zur Spielereingabebewegungskompensation verwendet, wie in den Schritten 208 und 212 in 2 dargestellt. Während des Decodierungsverfahrens auf dem nächsten Frame werden die Spielereingabebewegungsvektoren zu den decodierten Bewegungsvektoren hinzugefügt und in den Bewegungskompensationsschritt bei Schritt 502 eingeschleust, der im H.264-Codierungsstandard definiert ist. Der Deblocking-Filter, wie er durch den H.264-Codierungsstandard definiert ist, wird bei Schritt 504 angewendet, sollte aber nur auf Blöcke angewendet werden, die nicht durch die Spielereingabebewegungskompensation verändert wurden. Die resultierende Ausgabe, die in Schritt 506 dargestellt ist, enthält die Spielereingabebewegungskompensation und wird auf dem Client angezeigt. Die Ausgabe wird anschließend bei Schritt 506 gepuffert und wird bei Schritt 518 zum vorherigen Bild zur Verwendung bei der Bewegungskompensation im nächsten Frame. Im Gegensatz zur Implementierung in 3 werden bei dieser Implementierung die markierten Spielereingabebewegungsvektoren nur einmal angewendet. Das bedeutet, dass sie nicht mit allen markierten Bewegungsvektoren in der Warteschlange summiert werden müssen, da das vorherige Bild, das bei Schritt 518 gezeigt ist, die Summe der vorherigen markierten Bewegungsvektoren enthält. Die Zeit zwischen dem Empfangen der Eingabe und dem Anzeigen der Videoausgabe ist die Eingabe-Rückmeldungslatenz, die unter Verwendung der Spielereingabebewegungskompensation deutlich reduziert wurde, anstatt darauf zu warten, dass der Server das Ausgangsvideo zurücksendet.
  • Gleichzeitig mit Schritt 500 sendet der Client die entsprechenden markierten Spielereingaben an den Server, wie in den Schritten 208 und 210 in 2 dargestellt. Der Client erhält schließlich codiertes Video, wie in Schritt 508 mit der gleichen Marke 510 im Bitstream aus dem Server in Schritt 512 gezeigt, wie in Schritt 220 in 2 gezeigt. Marke 510 bedeutet, dass die aktuelle Bewegung, die zuvor durch die Spielereingabebewegungskompensation geschätzt wurde, im codierten Video dargestellt wird, wie in Schritt 508 gezeigt. Das codierte Video durchläuft die Entropie-Decodierung bei Schritt 514 und die umgekehrte Quantisierung und umgekehrte Transformation bei Schritt 516, wie sie durch den H.264-Codierungsstandard definiert ist.
  • Der vorherige Spielereingabebewegungskompensationsschritt, der vor den in den vorangegangenen Abschnitten beschriebenen Schritten 508,510,512, 514 und 516 durchgeführt wurde, hat bereits die Makroblöcke verschoben, die die aktuellen Bewegungsvektoren aus dem codierten Frame zu verschieben versuchen. Daher verschiebt die direkte Anwendung der aktuellen Bewegungsvektoren inkorrekte Makroblöcke. Der Bitstream enthält zwei zusammengehörige Datenstücke: den codierten Videoframe und eine Korrelationsmarke. Der codierte Frame wird bei Schritt 514 zur Entropie-Decodierung gesendet, während die Marke bei Schritt 520 zum Blending-Prozess vorausgeschickt wird. Zur Kompensation liefert der Blending- Prozess bei Schritt 520 Korrektur-Bewegungsvektoren durch Berechnen der Differenz zwischen den eingehenden aktuellen Bewegungsvektoren und den zuvor verwendeten Spielereingabewegungsvektoren 500 mit einer passenden Korrelationsmarke. Die Differenz kann durch Hinzufügen der inversen Bewegungsvektoren für die Korrelationsmarke zu den aktuellen Bewegungsvektoren berechnet werden und wird in Verbindung mit 6 näher beschrieben. Die Korrekturvektoren werden anstelle der decodierten Bewegungsvektoren zur Bewegungskompensation bei Schritt 502 verwendet. Der Rest der Decodierleitung wird wie gewohnt mit dem Deblocking-Filter bei Schritt 504, dem nächsten Ausgabevideoframe bei Schritt 506 und dem Puffern der Ausgabe bei Schritt 518 fortgesetzt. Diese Schritte können sich für jeden Frame auf unbestimmte Zeit wiederholen. Im Allgemeinen erfolgt der Blending-Prozess von Schritt 520 nach der inversen Quantisierung (Schritt 514) und der inversen Transformation (Schritt 516), da die eigentlichen Bewegungsvektoren bis zu diesem Zeitpunkt nicht verfügbar sind. Sobald die aktuellen Bewegungsvektoren verfügbar sind, verwendet der Blending-Prozess sie, um die Differenz zwischen aktuellen und geschätzten Bewegungsvektoren zu berechnen.
  • 6 veranschaulicht einen beispielhaften Makroblock, der die Bewegungskompensation und das Blending der Spielereingaben durchläuft. Zu der Zeit von 0 ms drückt der Spieler auf die Eingabe, um die Kameraansicht nach links zu drehen. Die zugehörigen Spielereingabebewegungskompensationsvektoren, dargestellt als „PIMC“ 600, aus der Lookup-Tabelle werden im nächsten Frame auf alle Makroblöcke angewendet. 6A zeigt einen beispielhaften Makroblock, der nach rechts verschoben ist. Die Ergebnisse der Spielereingabebewegungskompensation erscheinen im nächsten decodierten Frame, was zu einer maximalen Eingabe-Rückmeldungslatenz von 16 ms, der Länge eines Frames, für Videos mit 60 Bildern pro Sekunde führt. In anderen Ausführungsformen kann die maximale Eingabe-Rückmeldungslatenz 33 ms für Videos mit 30 Bildern pro Sekunde betragen. Es wird daher erwogen, dass die Erfindung über eine Vielzahl von Frameraten arbeitet und die maximale Eingabe-Rückmeldungslatenz auf die Länge eines Frames begrenzt. Wenn das markierte Video vom Server zurückkehrt, enthält es die aktuellen Bewegungsvektoren 602, die vom Server codiert wurden, wie in 6B dargestellt. In diesem Beispiel wird das codierte Video nach 100 ms zurückgesendet, was jedoch stark von der Netzwerklatenz abhängig ist. Die aktuellen Vektoren 602 beziehen sich auf Makroblöcke, die bereits während der Bewegungskompensation 600 verschoben wurden, so dass die aktuellen Vektoren 602 nicht direkt auf den vorhandenen Frame angewendet werden können. Stattdessen müssen die Korrekturvektoren 604 durch Finden der Differenz zwischen den aktuellen Vektoren 602 und den Bewegungsvektoren 600 der Spielereingabe berechnet werden. Die Differenz kann durch Addition der inversen Spielereingabebewegungsvektoren zu den aktuellen Bewegungsvektoren berechnet werden. Das Finden dieser Vektorunterschiede wird bei Schritt 524 in 5 als Blending bezeichnet. Je kleiner der Korrekturvektor 604, desto erfolgreicher war das Verfahren der Spielereingabebewegungskompensation bei der Schätzung der aktuellen Bewegungsvektoren. Die resultierende Bewegung 608, die in 6C für den beispielhaften Makroblock dargestellt ist, ist mit dem aktuellen Bewegungsvektor 602 identisch. Dieses Beispiel zeigt, wie die Spielereingabebewegungskompensation die Video-Rückmeldung für eine Spielereingabe abschätzen und das Ergebnis für die Zeit zwischen 16 ms und 100 ms anzeigen kann, während ein unverändertes System erst 116 ms nach Erhalt der Spielereingabe eine Spieler-Rückmeldung anzeigen würde.
  • Während der Entwicklung müssen Spieleentwickler entscheiden, welche Bewegungen und Animationen antizipierte Bewegungsvektoren während der Laufzeit senden. Unverwechselbare, aber vorhersehbare Bewegungsvektoren sind die besten Kandidaten für antizipierte Bewegungsvektoren. Ein kategorisches Beispiel würde Animationen einschließen, die durch die Engine adaptiv verändert werden, wie beispielsweise Animationen, die kinematischen Gleichungen zur Berechnung von Gelenkwinkeln verwenden, Animationen, die zeitverzerrt sind oder Animationen, die anderweitig gedehnt oder gestaucht werden. Zum Beispiel spielt sich eine Ledge-Grab-Animation ab, wenn ein Spieler in die Reichweite eines definierten Überhangs kommt und springt. Die Ledge-Grab-Animation wird so gedehnt, dass die Hände des Spielers auf dem Überhang aufliegen, aber immer noch am Körper des Spielers befestigt sind. Die Animation spielt sich über eine definierte Anzahl von Frames ab, wobei der Spieler oben auf dem Überhang platziert wird. Der Startpunkt ist in diesem Beispiel variabel, mit einem Bereich von vertretbaren Positionen und Orientierungen. Diese Ledge-Grab-Animation ist ein guter Kandidat für die Generierung von antizipierten Bewegungsvektoren, da die genaue Animation nicht im Voraus bekannt ist, sondern programmgesteuert von der Spiel-Engine auf Anforderung generiert wird. Insbesondere kann der Client die Bewegungsvektoren für diese Animation nicht kennen, da der Client keine Kontextinformationen über die Spielerposition in einer Spiel-Streaming-Umgebung hat.
  • Antizipierte Bewegungsvektoren sind nur in einem begrenzten kontextuellen oder zeitlichen Rahmen geeignet, wie z.B. einer bestimmten Kameraposition, einem kleinen Zeitfenster oder einem anderen spezifischen Spielerkontext. Für jeden Satz von antizipierten Bewegungsvektoren muss ein entsprechender Invalidator generiert werden. Der Invalidator kann auf dem Client verwendet werden, um zu verhindern, dass antizipierte Bewegungsvektoren angewendet werden, nachdem sie gültig waren. In bestimmten Ausführungsformen kann ein Invalidator eine Reihe von beliebigen Spielereingaben sein, die den Spielkontext ändern würden, so dass das Abspielen der antizipierten Bewegungsvektoren nicht mehr möglich ist. In anderen Ausführungsformen kann ein Invalidator ein Zeitfenster sein, für das antizipierte Bewegungsvektoren gültig sein können. In noch weiteren Ausführungsformen kann ein Invalidator eine Kombination aus invalidierenden Eingaben und einem Zeitfenster sein. So sind beispielsweise die antizipierten Bewegungsvektoren, die für eine Ledge-Grab-Animation generiert werden, nur innerhalb einer begrenzten Spielerposition und -orientierung gültig, und als solche würde ein Invalidator notwendigerweise jede Eingabe einer Translations- oder Drehbewegung einschließen. Invalidatoren müssen während der Entwicklung des antizipierten Bewegungsvektormerkmals entworfen und implementiert werden. Antizipierte Bewegungsvektoren können auch durch Ereignisse oder Nachrichten, die vom Server gesendet werden, wie nachfolgend in Verbindung mit 10 bis 13 beschrieben, deaktiviert oder aktualisiert werden, die die Verwendung von zwischengespeicherten repetitiven Bewegungsvektoren zur Bewegungskompensation behandeln.
  • Antizipierte Bewegungsvektoren können vorzeitig oder bei Bedarf während der Laufzeit generiert werden. Bei Animationen, die beispielsweise eine begrenzte Anzahl von Permutationen haben, können die antizipierten Bewegungsvektoren offline generiert werden, indem jede Permutation ausgelöst und die Bewegungsvektoren aufgezeichnet werden. In bestimmten Ausführungsformen werden die Bewegungsvektoren für einen generalisierten Client serverseitig gespeichert und dann an den Client gesendet, um bei Bedarf zwischengespeichert zu werden. Wenn die Bewegungsvektoren an den Client gesendet werden, werden sie in der Lookup-Tabelle zwischengespeichert. Vorgenerierte antizipierte Bewegungsvektoren können auf dem Server gespeichert werden und stehen als spielbares Dateiformat zur Verfügung, das es dem Server ermöglicht, vorgenerierte Bewegungsvektoren zu senden, die während der Laufzeit des Spiels in der Lookup-Tabelle auf dem Client zwischengespeichert werden. Animationen, die während der Laufzeit generiert werden, wie z.B. Animationen, die durch inverse Kinematik berechnet werden, können nicht vorgeneriert werden, da es möglicherweise keine diskrete Anzahl von möglichen Animationspermutationen gibt. Inverse Kinematik ist ein Verfahren, das häufig beim Echtzeit-Rendering verwendet wird, um eine Animation innerhalb eines Satzes von Randbedingungen anzupassen. Zum Beispiel möchte ein Spielercharakter in einem Videospiel einen nahegelegenen Vorsprung greifen, die Randbedingungen werden durch die Stellen definiert, an denen die Hände des Spielers auf den Überhang treffen, und die Animation des Überhangs wird durch eine inverse Kinematik entsprechend geändert. Für solche adaptiv geänderten Animationen kann das Spiel spekulativ mögliche Animationen in ein Offscreen-Bewegungsvektorbild während der Laufzeit darstellen und die antizipierten Bewegungsvektoren bei Bedarf aufnehmen. Wenn sich der Spieler beispielsweise in der Nähe eines greifbaren Überhangs befindet, kann das Spiel antizipieren, dass der Spieler den Überhang bald ergreifen wird, und das Spiel kann spekulativ die Animation des Überhangs darstellen, um antizipierte Bewegungsvektoren zu erzeugen. Adaptiv veränderte Animationen, bei denen während der Laufzeit antizipierte Bewegungsvektoren generiert werden müssen, müssen von einem Entwickler vorab identifiziert werden.
  • Bestehende Spielsysteme, die den Kontext des Spielers beschreiben, wie z.B. Standortverfolgung, Skriptsysteme, Triggervolumen oder Pfadfindungssysteme, können verwendet werden, um ein Ereignis zu erzeugen, das signalisiert, wenn das Spiel eine Animation spekulativ darstellen muss. So kann beispielsweise ein Spiel die Nähe des Spielers zu einem greifbaren Überhäng verfolgen und dem Spiel signalisieren, die Überhanggreifanimation spekulativ darzustellen und die antizipierten Bewegungsvektoren aufzuzeichnen. Bestimmte Animationen wie das Aufnehmen einer Waffe, das Ziehen eines Hebels oder das Drücken eines Knopfs können je nach Nähe des Spielers zur Interaktion und Spielerorientierung gedehnt oder angepasst werden. Diese Animationen haben zu viele Permutationen, um die Vorgenerierung möglich zu machen, könnten aber auch während der Laufzeit generiert werden, wie in 7 beispielhaft dargestellt. Bewegungen, die sich jedes Mal auf die gleiche Weise abspielen, können offline generiert und aufgezeichnet werden. Dies sind typischerweise Bewegungen, die bei jedem Auslösen im gleichen Bildschirmraum mit der gleichen Geschwindigkeit auftreten. Bewegungsvektoren für diese Animationen können offline aufgezeichnet werden, indem alle möglichen Permutationen der Animation ausgelöst und die spielgenerierten Bewegungsvektoren aufgezeichnet werden oder Bewegungsvektoren durch traditionellere Bewegungsschätzungstechniken, wie sie im H.264-Codec verwendet werden, generiert werden. In einer bevorzugten Ausführungsform werden spielgenerierte Bewegungsvektoren, wie vorstehend in Verbindung mit 1 bis 6 beschrieben, verwendet, um eine hohe Qualität der Bewegungsabschätzungen zu gewährleisten. Dieser Prozess kann zu jedem Zeitpunkt der Entwicklung stattfinden, aber es ist vorzuziehen, diesen Prozess als Phase während des Build-Prozesses oder eines anderen bestehenden Asset-Conditioning- Prozesses hinzuzufügen, wie z.B. das Vorerzeugen von Mip-Maps und den Detaillierungsgrad („LODs“). Die Asset-Konditionierung kann jeden Prozess einschließen, der Spielinhalte aus menschenlesbaren Quellformaten in maschinenlesbare Formate zusammenfasst. So können beispielsweise Mip-Maps vorab generiert werden, indem von Künstlern erstellte Texturdateien in spielbereite Formate umgewandelt werden, die mehrere Auflösungen enthalten. Ebenso können LODs vorzeitig generiert werden, indem von Künstlern erstellte Modelldateien in spielbereite Formate umgewandelt werden, die mehrere Detaillierungsstufen enthalten. Die Generierung von Bewegungsvektoren kann zu einem bestehenden Asset-Conditioning-Prozess hinzugefügt werden, der von Künstlern generierte Animationsformate in spielbereite Formate umwandelt.
  • 7 veranschaulicht ein beispielhaftes Verfahren zum Generieren von Bewegungsvektoren in Offline- oder Laufzeitszenarien. Die Animationen können auf eine Offscreen-Oberfläche/Bild gerendert werden, Schritt 700, und die Bewegungsvektoren können zur sofortigen Verwendung aufgezeichnet werden. Es müssen nur die sich bewegenden Teile des Bildschirms gerendert werden, die anderen Objekte in der Szene können ignoriert werden. Das in Schritt 702 dargestellte gestrichelte Objekt und das in Schritt 704 dargestellte feste Objekt stellen die Position eines animierten Objekts in einem vorherigen Frame bzw. aktuellen Frame dar. Die Bewegung vom vorherigen Frame zum aktuellen Frame wird bei Schritt 706 in Form von Bewegungsvektoren erfasst, wie in Schritt 708 dargestellt. Die Bewegungsvektoren können von den spielgenerierten Bewegungsvektoren erfasst oder durch traditionellere Bewegungsschätzungstechniken, wie sie im H.264-Codec verwendet werden, erfasst werden. In einer bevorzugten Ausführungsform werden spielgenerierte Bewegungsvektoren, wie vorstehend in Verbindung mit den 1 bis 6 beschrieben, verwendet, um qualitativ hochwertige Bewegungsvektoren zu gewährleisten. Der Wert von antizipierten Bewegungsvektoren für mehrere Frames kann für eine bestimmte Animation schnell berechnet werden, indem der in den Schritten 700 bis 708 dargestellte Prozess wiederholt wird, bis Bewegungsvektoren für alle erforderlichen Frames generiert wurden. Nicht alle Frames in der Animation müssen generiert werden, sondern nur genug, um auf dem Client abgespielt zu werden, während der Videostream aufholt. Die minimale Anzahl der generierten Frames hängt von der Verzögerung zwischen dem Übertragen der Spielereingabe und dem Empfangen des resultierenden Videostroms auf dem Client ab; und die Länge des generierten Teils einer Animation sollte mindestens so lang sein wie die Verzögerung. Die antizipierten Bewegungsvektor-Frames können während der Wiedergabe ratenskaliert werden, wie unten in Verbindung mit den 10 bis 13 beschrieben., die die Verwendung von zwischengespeicherten repetitiven Bewegungsvektoren bei der Bewegungsschätzung diskutieren. Wenn die Wiedergabe von antizipierten Bewegungsvektor-Frames ratenskaliert ist, führt das Generieren von antizipierten Bewegungsvektoren für einen Abschnitt einer Animation, der der Verzögerung entspricht, zu einer Wiedergaberatenskalierung von 50%. Das Generieren von Bewegungsvektoren für einen längeren Abschnitt der Animation führt zu einer Wiedergabe, die weniger aggressiv ratenskaliert ist.
  • Die für die Videocodierung verwendete Makroblockgröße sollte bei der Recodierung der Bewegungsvektoren berücksichtigt werden, und es sollte für jeden Makroblock ein Bewegungsvektor vorhanden sein. In der bevorzugten Ausführungsform werden spielgenerierte Bewegungsvektoren als Per-Pixel-Bewegungsvektoren generiert und in Per-Makroblock-Bewegungsvektoren umgewandelt, indem das arithmetische Mittel für jede Makroblockgruppe von Per-Pixel-Bewegungsvektoren ermittelt wird.
  • 8 veranschaulicht die Übertragung und clientseitige Speicherung von antizipierten Bewegungsvektoren zum Zwecke der Bewegungskompensation der Spielereingaben. Während der Entwicklung der Videospiel-Software müssen Ereignisse konfiguriert werden, um anstehende eingabegesteuerte kontextsensitive Animationen zu signalisieren. Ein Spieleentwickler möchte beispielsweise antizipierte Bewegungsvektoren senden, damit sie verfügbar sind, wenn der Spieler eine Ledge-Grab-Animation durchführt. Der Entwickler implementiert ein Ereignis, das ausgelöst wird, wenn sich der Spieler sowohl nach vorne als auch in Reichweite eines greifbaren Überhangs befindet. In diesem Beispiel wird, wenn sich der Spieler während des Spiels einem greifbaren Überhang nähert, das Beispielereignis bei „EMPFANGEN EINES EREIGNIS WÄHREND DER SPIELLAUFZEIT“, Schritt 800, empfangen. Der Ereignistyp beschreibt, ob die antizipierten Bewegungsvektoren wie bei adaptiv geänderten Animationen generiert werden müssen oder ob die antizipierten Bewegungsvektoren offline vorgeneriert wurden, wie bei Animationen, die nie geändert, aber selten abgespielt werden oder vom Spielerkontext abhängig sind. In dem obigen Beispiel wird die Ledge-Grab-Animation basierend auf dem Abstand des Spielers von dem Überhang gedehnt, was bedeutet, dass Bewegungsvektoren während der Laufzeit bei „ERZEUGEN ANTIZIPIERTER BEWEGUNGSVEKTOREN“, Schritt 802, generiert werden müssen; in einem anderen Fall können die Bewegungsvektoren bereits offline generiert und aus dem Speicher bei „LESEN VORGENERIERTER BEWEGUNGSVEKTOREN“, Schritt 804, gelesen werden.
  • Ein Beispiel für vorgenerierte Bewegungsvektoren kann das Wechseln zwischen Waffen in einem großen Arsenal sein. Die Anzahl der möglichen Waffenwechsel-Permutationen kann recht groß werden, so dass es impraktikabel ist, den gesamten Satz resultierender Bewegungsvektoren zwischenzuspeichern. Im Allgemeinen sind, wenn Bewegungsvektoren eine übermäßige Menge an Platz im begrenzten Zwischenspeicher einnehmen und nicht häufig genug verwendet werden, sie keine erstklassigen Kandidaten für das Pre-Caching. Die antizipierten Bewegungsvektoren werden an den Client bei „SENDEN ANTIZIPIERTER BEWEGUNGSVEKTOREN UND INVALIDATOREN“, Schritt 806, gesendet. Die antizipierten Bewegungsvektoren werden der Bewegungsvektor-Lookup-Tabelle bei „ZWISCHENSPEICHEN ANTIZIPIERTER BEWEGUNGSVEKTOREN UND INVALIDATOREN“, Schritt 808, hinzugefügt. In einer Ausführungsform funktioniert das Invalidierungssystem ähnlich wie das System, das die Anwendung von Bewegungsvektoren in der Lookup-Tabelle auslöst, stattdessen aber die Bewegungsvektoren deaktiviert. Wenn ein Satz von Bewegungsvektoren und Invalidatoren bei „ZWISCHENSPEICHEN ANTIZIPIERTER BEWEGUNGSVEKTOREN UND INVALIDATOREN“, Schritt 808, empfangen wird, müssen die Invalidatoren vom Invalidierungssystem registriert werden.
  • Das Verfahren zur Bewegungskompensation der Spieler-Eingabe, wie vorstehend in Verbindung mit den 1 bis 6 beschrieben, vergleicht alle Spielereingaben mit den Einträgen in der Bewegungsvektor-Lookup-Tabelle. Im obigen Beispiel, wenn der Spieler die erforderliche Eingabe eingibt, um die Ledge-Grab-Animation zu starten, stimmt die Eingabe mit der zuvor zwischengespeicherten Eingabe in der Lookup-Tabelle bei „MATCHING PLAYER INPUT RECEIVED“, Schritt 810, überein. Wenn die zwischengespeicherten antizipierten Bewegungsvektoren noch nicht invalidiert wurden, werden die antizipierten Bewegungsvektoren bei „APPLY PLAYER INPUT MO-TION COMPENSATION“, Schritt 812, angewendet. Wenn eine passende Spielereingabe die antizipierten Bewegungsvektoren invalidiert, oder wenn die antizipierten Bewegungsvektoren nach einer vorbestimmten Zeit ablaufen, oder wenn die antizipierten Bewegungsvektoren nach einmaliger Anwendung ablaufen, werden die antizipierten Bewegungsvektoren aus der Lookup-Tabelle bei „INVALIDIEREN“, Schritt 814, entfernt und nicht angewendet.
  • 9 beschreibt ein beispielhaftes Verfahren von Signalen, die einen antizipierten Bewegungsvektorsatz invalideren können. Invalidierung ist eine Art Aktualisierung der Lookup-Tabelle, bei der ein Satz von antizipierten Bewegungsvektoren aus der Lookup-Tabelle, die vorzugsweise beim Client zwischengespeichert wird, entfernt wird. Zusätzlich zur Reaktion auf vom Server empfangene Aktualisierungsereignisse kann der Aktualisierungsmechanismus auch die Eingaben der Spieler überwachen und Invalidierungs-Countdown-Timer enthalten. Wenn ein Satz von antizipierten Bewegungsvektoren in der Lookup-Tabelle zwischengespeichert wird, wird ihr Invalidator wahrscheinlich mit der Aktualisierungsfunktion/-mechanismus registriert. Ein Invalidator ist jedes Datensignal, das eine Invalidierungsaktualisierung in der Lookup-Tabelle auslöst. Die beispielhafte Lookup-Tabelle „Lookup-Tabelle“, die in Schritt 900 dargestellt ist, enthält drei Sätze von antizipierten Bewegungsvektoren: eine antizipierte Tür-Animation, die in „ANTIZIPIERTE TÜR-ANIMATION“ gezeigt wird, Schritt 902, eine antizipierte Ledge-Grab-Animation, die in „ANTIZIPIERTES LEDGE GRAB“ gezeigt wird, Schritt 904, und eine antizipierte Kill-Shot-Animation, die in „ANTIZIPIERTE KILL SHOT ANIMATION‟ gezeigt wird, Schritt 906. Antizipierte Bewegungsvektoren können nach einmaliger Anwendung invalidiert werden. Im Beispiel werden die antizipierten Bewegungsvektoren der Tür-Animation, die bei „ANTIZIPIERTE TÜR-ANIMATION“, Schritt 902, gezeigt werden, angewendet, wenn der Spieler die Eingabe bei „OPEN DOOR INPUT“, Schritt 908, drückt, um eine nahegelegene Tür zu öffnen. Gleichzeitig wird die Eingabe offene Türe bei „EINGABE OFFEN TÜRE“, Schritt 908, deregistriert und die antizipierten Tür-Animationen, die unter „ANTIZIPIERTE TÜR¬ANIMATION“, Schritt 902, angezeigt werden, können aus der Lookup-Tabelle unter „INVALIDIEREN NACH GEBRAUCH“, Schritt 910, entfernt werden. Ebenso können andere Eingaben antizipierte Bewegungsvektoren vor ihrer Anwendung invalidieren. Im Beispiel sind eine Reihe von antizipierten Bewegungsvektoren für eine Ledge-Grab-Animation, die bei „ANTIZIPIERTES LEDGE GRAB“, Schritt 904, gezeigt wird, nur in einem begrenzten Abstand von einem Überhang gültig.
  • Wenn sich der Spieler mit Hilfe der Bewegungseingabe, die bei „BEWEGUNGSEINGABE“ angezeigt wird, von dem Überhang entfernt, bevor der Spieler springt, um den Überhang zu greifen (unter Verwendung der Sprung-Eingabe, die bei „SPRUNG-EINGABE“ gezeigt ist, Schritt 914), dann werden die antizipierten Vektoren für die Greifbewegung des Überhangs, die bei „ANTIZIPIERTES LEDGE GRAB“ gezeigt werden, ”Schritt 904 bei „EINGABEN INVALIDIEREN“, Schritt 916 invalidiert. Andere Beispiele der Invaldierung von Eingaben können Fälle sein, wobei der Spieler einen Enterhaken oder eine andere bewegungsbasierte Waffe besitzt, die antizipierte Bewegungsvektoren invalidieren würde, und Fälle, in denen der Spieler eine Taste drückt, die eine spezielle Fähigkeit aktiviert. Da invalidierende Eingaben kontextspezifisch sind, können aufgrund der jeweiligen Implementierung auch andere sichtbar sein. Antizipierte Bewegungsvektoren können auch mit der Zeit ablaufen. Im Beispiel wird dem Spieler eine Killshot-Möglichkeit nur für ein Drei-Sekunden-Fenster präsentiert. Wenn der Spieler die Nahkampf-Eingabe, der bei „NAHKAMPF-EINGABE“ gezeigt wird, Schritt 918, innerhalb des Drei-Sekunden-Fensters nicht drückt, werden die Bewegungsvektoren für eine antizipierte Kill-Shot-Animation, die bei „ANTIZIPIERTE KILL SHOT ANIMATION“, Schritt 906, gezeigt werden, bei "INVALIDIEREN AUF VERFALLS-ZEITTIMER, Schritt 920, invalidiert. Antizipierte Bewegungsvektoren können mehrere Invalidatoren aufweisen und umgekehrt. So kann beispielsweise ein antizipiertes Ledge-Grab invalidiert, wenn eine Bewegungseingabe empfangen wird oder nachdem die Ledge-Grab-Bewegungsvektoren verwendet werden, je nachdem, was zuerst eintritt.
  • 10 zeigt ein beispielhaftes Verfahren zum Generieren der Bewegungsvektorbibliothek und eine beispielhafte repetitive Bewegungsvektorbibliothek für Zwischenspeicherzwecke. Da die ausgewählten Bewegungen sehr repetitiv sind, werden sie bei jeder Auslösung auf die gleiche Weise abgespielt. Dadurch ist es möglich, Bewegungsvektoren vorab zu generieren und in Bibliotheken zu organisieren. Die Generierung der Bewegungsvektorbibliothek kann zu jedem Zeitpunkt der Entwicklung erfolgen, aber es kann sinnvoll sein, diesen Prozess als Phase während des Build-Prozesses oder einer anderen Asset-Konditionierungsphase hinzuzufügen. In diesem Beispiel wird für jede verfügbare Waffe in einem Egoshooter eine Bewegungsvektorbibliothek generiert. Wenn die Bibliotheksgenerierung für die erste Waffe bei „BIBLIOTHEKSGENERIERUNG“, Schritt 1000, beginnt, wird die erste Waffenanimation bei „TRIGGER ANIMATION“, Schritt 1002 ausgelöst, und die Bewegungsvektoren werden bei „BEWEGUNGSVEKTOREN AUFZEICHNEN“, Schritt 1004, aufgezeichnet. Die Bewegungsvektoren können spielgeneriert oder durch traditionellere Bewegungsschätzungstechniken, wie sie im H.264-Codec verwendet werden, generiert werden. In einer bevorzugten Ausführungsform werden spielgenerierte Bewegungsvektoren,verwendet, um eine hohe Qualität der Bewegungsschätzungen zu gewährleisten. Wenn die aufgenommenen Bewegungsvektoren nicht genau oder korrekt quantisiert sind, werden Artefakte eingefügt, wenn sie während der der Spieler-Eingabebewegungskompensation verwendet werden. Die Schritte 1002 und 1004 wiederholen sich, bis die Bewegungsvektoren für jede hochrepetitive Animation in der Bibliothek aufgezeichnet wurden. Die Bibliotheksgenerierung beginnt wieder bei Schritt 1000, bis alle Bibliotheken generiert sind.
  • Das bei „BEWEGUNGSVEKTORBIBLIOTHEK“ gezeigte Beispiel, Schritt 1006, ist eine stark vereinfachte Version einer repetitiven Bewegungsvektorbibliothek für eine Plasmagewehr-Waffe in einem Egoshooterspiel. Dieses Beispiel wird vereinfacht, so dass es zwei einfache Animationen einschließt: eine 2-Frame-Animation für die Rückmeldungsanimation, die abgespielt wird, wenn der Spieler das Plasmagewehr abfeuert, wie in Schritt 1008 gezeigt, und eine 4-Frame-Animation für die Wippbewegung des Gewehrs, die auftritt, wenn der Spieler vorwärts geht, wie in Schritt 1010 gezeigt. In einer typischen, realen Umgebung würde eine Waffe wahrscheinlich mehr Animationen haben und die Animationen können viel länger als vier Frames sein.
  • 11 veranschaulicht den Prozess zum Zwischenspeichern, Anwenden und Aktualisieren von Bewegungsvektorbibliotheken zur Bewegungskompensation bei der Spielereingabe. Wenn das Spiel beginnt, sendet der Server die vorgenerierten Bewegungsvektorbibliotheken an den Client bei „BEIM START, SENDEN VON REPETITIVEN BEWEGUNGSVEKTORBIBLIOTHEKEN“, Schritt 1100. Der Client speichert die Bewegungsvektorbibliotheken im Speicher, typischerweise in Form einer Lookup-Tabelle, unter „CACHE REPETITIVE BEWEGUNGS-BIBLIOTHEKEN“, Schritt 1102. In dieser Implementierung wird der Client generalisiert, um die Anforderungen mehrerer Streaming-Spiele zu erfüllen. In einer alternativen Implementierung kann ein spielspezifischer Client die Bewegungsvektorbibliotheken dauerhaft speichern, ohne dass wiederholte Bewegungsvektoren vom Server zwischengespeichert werden müssen.
  • An dieser Stelle kann der Client mit der Überwachung der Spielereingabe beginnen und die eingehenden Eingaben mit den Einträgen in der Tabelle zur Bewegungskompensation der Spielereingabe vergleichen. Wenn eine eingehende Eingabe einen passenden Eintrag in der Lookup-Tabelle unter „PASSENDE SPIELEREINGABE EMPFANGEN“, Schritt 1104, aufweist, werden die der Spielereingabe zugeordneten Bewegungsvektoren verwendet, um eine Bewegungsschätzung bereitzustellen, wie sie beispielhaft in Verbindung mit den 1 bis 10, bei„ ANWENDEN DER SPIELER-EINGABEBEWEGUNGSKOMPENSATION‟, Schritt 1106, beschrieben ist. Es kann bestimmte Fälle geben, in denen das Empfangen einer bestimmten Eingabe erfordern kann, dass die Lookup-Tabelle unter „AKTUALISIEREN VON ZWISCHENGESPEICHERTER REPETITIVER BEWEGUNGSVEKTORÜBEREINSTIMMUNG“, Schritt 1112, geändert wird. Ein Beispiel für eine Eingabe, die die Lookup-Tabelle ändern würde, ist die Pausentaste, die Spielereingaben wie Charakterbewegung, Waffenschussanimationen oder andere spielbezogene Bewegungen deaktivieren kann. Nach dem Anwenden der Bewegungsvektoren und der optionalen Aktualisierung der Lookup-Tabelle überwacht der Client weiterhin die Spielereingabe. Nachdem die Lookup-Tabelle bei „AKTUALISIEREN ZWISCHENGESPEICHERTER REPETITIVER BEWEGUNGSVEKTORZUORDNUNG“, Schritt 1112, aktualisiert wurde, wird die eingehende Spielereingabe mit den aktualisierten Einträgen in der Lookup-Tabelle verglichen.
  • Zu jedem Zeitpunkt während der Laufzeit des Spiels kann eine Änderung des Kontextes für den Spieler eine Änderung der Lookup-Tabelle erfordern. So kann der Spieler beispielsweise die Waffen wechseln, wobei die zwischengespeicherte Bewegungsbibliothek von der zuvor gehaltenen Waffe auf die neue Waffe umgestellt werden muss. Eine beispielhafte Implementierung kann die serverseitige Spielüberwachung für bestimmte Spielereignisse einschließen. Diese Ereignisse werden nach den in der Technik bekannten Verfahren während der Spieleentwicklung konfiguriert und können über das bestehende Messaging- oder Eventsystem des Spiels gesendet werden. Wenn eine laufende Spielinstanz eines dieser Ereignisse bei „EMPFANG EINES EREIGNISSES UNTER LAUFZEIT“, Schritt 1108, empfängt, wird eine Nachricht generiert und bei „KONTEXT-AKTUALISERUNG SENDEN“, Schritt 1110, an den Client gesendet. Eine Kontext-Aktualisierung kann für jedes Spielereignis gesendet werden, das die Beziehung zwischen der Spielereingabe und den in der Lookup-Tabelle enthaltenen Bewegungsvektoren ändert. Kontext-Aktualisierungen können eine Spielereingabe dabei aktivieren oder deaktivieren, einen Satz von Bewegungsvektoren auszulösen, sie können die einer bestimmten Eingabe zugeordneten Bewegungsvektoren ändern oder anderweitig Assoziationen zwischen Spielereingabe und Bewegungsvektoren hinzufügen oder entfernen, um die Bewegungskompensation der Playereingaben zu ermöglichen. Wenn die Nachricht den Client erreicht, wird die Lookup-Tabelle entsprechend dem sich ändernden Kontext bei „AKTUALISIERUNG DER ZWISCHENGESPEICHERTEN REPETITIVEN BEWEGUNGSVEKTORZUORDNUNG“, Schritt 1112, geändert.
  • 12 ist ein Diagramm, das veranschaulicht, wie die Bewegungsvektorzuordnung aktualisiert werden kann. Die Lookup-Tabelle 1200, die im Cache 1202 des Clients gespeichert wurde, wird vom Client verwendet, um herauszufinden, welche Bewegungsvektoren einer bestimmten Spielereingabe zugeordnet sind. Es kann Zeiten während der Laufzeit des Spiels geben, in denen kontextabhängige Änderungen das Verhalten der Spielereingaben verändern. Wenn sich ein Spieler beispielsweise vorwärts bewegt, aber auf einen Bewegungsblocker wie eine Wand trifft, müssen die vorhergesagten Bewegungsvektoren für die Vorwärtsbewegung aufgehoben werden. In diesem Fall sendet der Server eine Kontext-Aktualisierung an den Client, wie in Schritt 1110 in 11 gezeigt. Dieses Bewegungsblockierereignis 1204 wird empfangen, das dem Client signalisiert, die Verbindung zwischen der Vorwärtsbewegungseingabe 1206 und den entsprechenden Bewegungsvektoren 1208 zu deaktivieren. Die Vorwärtsbewegungsvektoren werden nicht mehr angewendet, wenn der Spieler die Vorwärtsbewegungseingabe verwendet, bis ein anderes Ereignis vom Server die Verbindung zwischen der Vorwärtsbewegungseingabe und den Vorwärtsbewegungsvektoren wieder aktiviert. In diesem Beispiel generiert das Spiel ein Ereignis, wenn die Bewegung des Spielers freigegeben wird, und sendet die Kontext-Aktualisierung an den Client, um die Verbindung zwischen der Vorwärtseingabe und den Bewegungsvektoren in der Lookup-Tabelle wieder einzurichten.
  • In einem anderen Beispiel hält der Spieler das Plasmagewehr, wechselt aber zu einer Schrotflinte. Die Plasmagewehr-Bewegungsvektorbibliothek 1210 wird zusammen mit ihren Feuerungsbewegungsvektoren 1209, die einer bestimmten Feuerungseingabe 1211 entsprechen, im Zwischenspeicher gespeichert. Der Zwischenspeicher speichert auch Bewegungsvektorbibliotheken für andere Waffen, einschließlich einer Schrotflinte 1212 und einer Pistole 1214. Wenn der Client das Waffenwechselereignis 1216 aus dem Server empfängt, wird die Plasmagewehr-Bewegungsvektorbibliothek 1210 aus der Lookup-Tabelle 1200 für die Schrotflinten-Bewegungsvektorbibliothek 1212 zugeschaltet. Um zu verhindern, dass die Spieler-Eingabebewegungskompensation während des Waffenwechsels unsachgemäß erfolgt, können zwei Ereignisse gleichzeitig verwendet werden, um zunächst die Plasmagewehrbewegungsvektorbibliothek 1210 zu deaktivieren, während eine Waffenwechselanimation abgespielt wird, und dann die beiden Bewegungsvektorbibliotheken zu wechseln, nachdem die Waffenwechselanimation abgeschlossen ist.
  • Bei längeren Multiframe-Bewegungsvektoren ist es möglich, ihre Anwendung so auszudehnen, dass den letzten Frame von Bewegungsvektoren angewendet wird, während der letzte Frame des aktuellen Videos vom Server empfangen wird. Dies ermöglicht es dem Server, die geschätzte Bewegung in dem Moment nachzuholen, in dem Client die zwischengespeicherten Bewegungsvektoren ausgehen. Der Skalierungsfaktor für die Bewegungsvektoren ist definiert als playbackSpeedScale, was berechnet wird, wie unten beispielhaft dargestellt. p l a y b a c k S p e e d S c a l e = Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t + V e r z ö g e r u n g
    Figure DE112018002561B3_0001
  • Wobei die Verzögerung definiert ist als die Zeit zwischen dem ersten Spielereingabe-Ereignis und dem Empfang des aktuellen Videos auf dem Client. Diese Verzögerung schließt die die Zeit ein, die benötigt wird, um die Eingabe über das Netzwerk an den Server zu senden, zur Verarbeitung auf dem Server einschließlich Spiellogik, Rendering-Logik, GPU-Renderingzeit und Codierungszeit sowie die Netzwerkzeit, um das Video wieder an den Spieler zurückzusenden. Die Verzögerung sollte in jeder Spiel-Streaming-Umgebung bereits kontinuierlich gemessen werden. Die bevorzugte Ausführungsform der Spieler-Eingabebewegungskompensation verwendet eine Korrelationsmarke, wie in U.S. Prov. App. Nr. 62/488,256 und 62/634,464 beschrieben, um die Spielereingaben und das aktuelle Video zu korrelieren. Bevor eine eingehende Spielereingabe an den Server gesendet wird, wird eine Korrelationsmarke als unverwechselbare Kennung angehängt. Wenn ein Videobild vom Server mit einer Korrelationsmarke zurückkehrt, ordnet der Client die unverwechselbare Kennung einer vorherigen Eingabe zu. Dies signalisiert dem Client, die Schätzung der Bewegung für die korrelierte Eingabe zu stoppen oder eine vorherige Bewegungsschätzung durch Biending-Techniken rückgängig zu machen. Die Länge des zwischengespeicherten Teils der Animation oder der zwischengespeicherten Animationszeit kann berechnet werden, indem die Anzahl der Frames in der zwischengespeicherten Animation mit der Länge jedes Frames multipliziert wird.
  • In 13 wird eine exemplarische Animation mit Frames zur Kompensation der Spieler-Eingabebewegung in einem Spiel mit 60 Bildern pro Sekunde und einer Verzögerung von 100 ms verwendet. Wenn die Spielereingabe die Spieler-Eingabebewegungskompensation auslöst, wird PlaybackSpeedScale für die zwischengespeicherten Bewegungsvektoren berechnet, wie unten gezeigt: playbackSpeedScale = Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t + V e r z ö g e r u n g
    Figure DE112018002561B3_0002
     playbackSpeedScale = 10 F r a m e s ∗ 1000 m s 60 F r a m e s ( 10 F r a m e s ∗ 1000 m s 60 F r a m e s ) + 100 m s
    Figure DE112018002561B3_0003
     playbackSpeedScale = 166,66 m s 166,66 m s + 100 m s = 0,625
    Figure DE112018002561B3_0004
  • Die Spielereingabe wurde zum Zeitpunkt 0 ms empfangen. Die Wiedergaberate der Bewegungsvektoren wird bei 1300 mit der berechneten PlaybackSpeedScale skaliert. Der erste Frame von Bewegungsvektoren wird auf den nächsten verfügbaren Frame im Videostream vom Server angewendet. Die skalierten Bewegungsvektorframes werden interpoliert, um die Animation glatt zu halten. Da die Bewegungsvektorframes über mehrere Frames skaliert sind, ist die Interpolation ein Verfahren, das verwendet werden kann um zu berechnen, „wie viel“ des Bewegungsvektors auf einen bestimmten Frame angewendet werden soll. Eine beispielhafte Implementierung kann eine lineare Interpolation basierend auf der berechneten PlaybackSpeedScale verwenden. In unserem Beispiel beträgt die berechnete PlaybackSpeedScale 0,625, was einen Satz von Bewegungsvektoren über 1,6 Anzeige-Frames streckt. Interpolation ist ein Verfahren zum Berechnen, wie viel von einem Bewegungsvektor auf einen gegebenen Frame angewendet werden soll. Das heißt, die Interpolation berechnet, wie weit ein Makroblock in einem Bewegungsvektor nach unten bewegt werden soll, wenn der Satz von Bewegungsvektoren über mehrere Anzeigeframes gestreckt wird. Nur ein Teil der ersten skalierten Bewegungsvektoren sollte mit 17 ms auf den ersten Anzeigeframe angewendet werden, was der PlaybackSpeedScale von 0,625 entspricht. Auf den zweiten Anzeigeframe bei 33 ms wird der Rest der ersten skalierten Bewegungsvektoren angewendet, berechnet als 0,625 = 0,375, dann wird der erste Abschnitt der zweiten skalierten Bewegungsvektoren angewendet, berechnet als die PlaybackSpeedScale minus der verbleibende Abschnitt der ersten skalierten Bewegungsvektoren oder 0,625 - 0,375 = 0,25. Auf dem dritten Anzeigefram bei 50 ms wird der zweite Satz skalierter Bewegungsvektoren weiterhin angewendet, die Makroblöcke werden um die nächsten 62,5% nach unten bewegt. Auf den vierten Anzeigeframe bei 67 ms wird der Rest der zweiten skalierten Bewegungsvektoren angewendet, berechnet als 1 - 0,25 - 0,625 = 0,125, und der erste Abschnitt der dritten skalierten Bewegungsvektoren wird angewendet, berechnet als Playback- SpeedScale minus der verbleibende Abschnitt der zweiten skalierten Bewegungsvektoren 0,625 - 0,125 = 0,5. Die lineare Interpolation wird fortgesetzt, wenn die skalierten Bewegungsvektoren angewendet werden.
  • Multiframe-Bewegungsvektoren können für jeden Frame der zwischengespeicherten Animation eine Korrelationsmarke senden, um jeden Frame der geschätzten Bewegung mit dem zukünftigen aktuellen Video zu korrelieren.
  • Die Verzögerung hängt stark vom Netzwerkpfad und der Architektur zwischen Client und Server ab. Dieses Beispiel verwendet eine Verzögerung von 100 ms, aber die Verzögerungen können zwischen Dutzenden und Hunderten von Millisekunden variieren. Kürzere Verzögerungen bieten ein besseres Spielerlebnis, aber Techniken zur Kompensation von Bewegungseinflüssen können helfen, die Auswirkungen hoher Verzögerungszeiten in bestimmten Fällen zu verdecken. Nach einer Verzögerung 1304 wird das aktuelle Video 1302 empfangen. Bei Edge-Located Servern oder Servern, die physisch nahe am Verbraucher sind, können die Verzögerungszeiten bis zu 30 ms betragen. Für typischere Serverstandorte sind 100 ms wahrscheinlicher. Das aktuelle Video behält die ursprüngliche Animationslänge 1306, da es nicht skaliert wurde. Das eigentliche Video wird in Übereinstimmung mit den Spieler-Eingabebewegungskompensationstechniken angewendet.
  • Wenn der Client die vorherige Bewegungskompensation nicht perfekt ausblenden kann, bietet der H.264-Codierungsstandard eine redundante Slice-Funktion, die alle zeitlich propagierten Fehler korrigieren kann. Basierend auf den H.264-Profileinstellungen wird jede Scheibe als Intra-Slice (I-Slice) codiert und in einem rotierenden Zeitplan mit einer bestimmten Frequenz gesendet. Da Intra-Slices keine Bewegungsvektoren enthalten, sollten die Bewegungsvektoren nur dann angewendet werden, wenn die aktuellen Bewegungsvektoren in p-Slices ankommen. Dadurch wird verhindert, dass Blend-Bewegungsvektoren auf Makroblöcke angewendet werden, die in einem I-Slice erschienen sind, bevor der markierte Frame vom Server zurückkehrt.

Claims (20)

  1. Computerimplementiertes Verfahren zum Zwischenspeichern von Bewegungsvektoren, umfassend: Übertragen einer zuvor generierten Bewegungsvektorbibliothek von einem Server zu einem Client, wobei die Bewegungsvektorbibliothek konfiguriert ist, um auf dem Client gespeichert zu werden; Übertragen einer Anweisung von dem Server an den Client zum Überwachen von Eingabedaten von einem Benutzer; Übertragen einer Anweisung von dem Server an den Client, eine Bewegungsabschätzung aus den Eingangsdaten zu berechnen: und Übertragen einer Anweisung von dem Server an den Client, die gespeicherte Bewegungsvektorbibliothek basierend auf den Eingabedaten zu aktualisieren, wobei der Client die gespeicherte Bewegungsvektorbibliothek zum Starten von Bewegung in einer grafischen Schnittstelle anwendet, bevor er tatsächliche Bewegungsvektordaten vom Server empfängt.
  2. Computerimplementiertes Verfahren nach Anspruch 1, ferner umfassend den Schritt des Übertragens einer Kontext-Aktualisierung vom Server an den Client, um die Anwendung der gespeicherten Bewegungsvektorbibliothek zu deaktivieren.
  3. Computerimplementiertes Verfahren nach Anspruch 1, ferner umfassend den Schritt des Übertragens einer Anweisung zum Anwenden eines oder mehrerer Skalierungsfaktoren auf die Bewegungsvektorbibliothek.
  4. Computerimplementiertes Verfahren nach Anspruch 3, wobei der Skalierungsfaktor basierend auf der allgemeinen Gleichung berechnet wird: playbackSpeedScale = Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t + V e r z ö g e r u n g
    Figure DE112018002561B3_0005
  5. Computerimplementiertes Verfahren nach Anspruch 1, wobei die generierte Bewegungsvektorbibliothek aus einer Vielzahl von Bewegungsvektoren besteht.
  6. Computerimplementiertes Verfahren nach Anspruch 5, wobei die Bewegungsvektoren spielgeneriert sind.
  7. Computerimplementiertes Verfahren nach Anspruch 1, wobei die generierte Bewegungsvektorbibliothek konfiguriert ist, um dauerhaft auf dem Client gespeichert zu werden.
  8. Computerimplementiertes Verfahren nach Anspruch 1, wobei die Bewegungsvektorbibliothek während des Build-Prozesses generiert wird.
  9. Computerimplementiertes Verfahren nach Anspruch 1, wobei die generierte Bewegungsvektorbibliothek den Eingabedaten des Benutzers zugeordnet ist.
  10. Computerimplementiertes Verfahren nach Anspruch 1, wobei die Anweisung an den Client zum Überwachen von Eingabedaten von einem Benutzer ferner eine Korrelationsmarke überwacht, wobei die Korrelationsmarke den Eingabedaten des Benutzers zugeordnet ist.
  11. System zum Zwischenspeichern von Bewegungsvektoren, wobei über ein Netzwerk ein Server: eine zuvor generierte Bewegungsvektorbibliothek an einen Client überträgt, wobei die Bewegungsvektorbibliothek konfiguriert ist, um auf dem Client gespeichert zu werden; eine Anweisung an den Client überträgt, um die Eingabedaten eines Benutzers zu überwachen; eine Anweisung an den Ciient überträgt, aus den Eingangsdaten eine Bewegungsabschätzung zu berechnen; und eine Anweisung an den Client überträgt, die gespeicherte Bewegungsvektorbibliothek basierend auf den Eingabedaten zu aktualisieren, wobei der Client konfiguriert ist, um die gespeicherte Bewegungsvektorbibliothek anzuwenden, um eine Bewegung in einer grafischen Schnittstelle einzuleiten, bevor er tatsächliche Bewegungsvektordaten vom Server empfängt.
  12. System nach Anspruch 11, ferner umfassend den Schritt des Übertragens einer Kontext-Aktualisierung vom Server an den Client, um die Anwendung der gespeicherten Bewegungsvektorbibliothek zu deaktivieren.
  13. System nach Anspruch 11, wobei der Server ferner eine Anweisung überträgt, einen oder mehrere Skalierungsfaktoren auf die Bewegungsvektorbibliothek anzuwenden.
  14. System nach Anspruch 13, wobei der Skalierungsfaktor basierend auf der allgemeinen Gleichung berechnet wird: playbackSpeedScale = Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t Z w i s c h e n g e s p e i c h e r t e A n i m a t i o n s z e i t + V e r z ö g e r u n g
    Figure DE112018002561B3_0006
  15. System nach Anspruch 11, wobei die generierte Bewegungsvektorbibliothek aus einer Vielzahl von Bewegungsvektoren besteht.
  16. System nach Anspruch 15, wobei die Bewegungsvektoren spielgeneriert sind.
  17. System nach Anspruch 11, wobei die generierte Bewegungsvektorbibliothek konfiguriert ist, dauerhaft auf dem Client gespeichert zu werden.
  18. System nach Anspruch 11, wobei die Bewegungsvektorbibliothek während des Build-Prozesses generiert wird.
  19. System nach Anspruch 11, wobei die generierte Bewegungsvektorbibliothek den Eingabedaten des Benutzers zugeordnet ist.
  20. System nach Anspruch 11, wobei die Anweisung an den Client zum Überwachen von Eingabedaten von einem Benutzer ferner eine Korrelationsmarke überwacht, wobei die Korrelationsmarke den Eingabedaten des Benutzers zugeordnet ist.
DE112018002561.6T 2017-04-21 2018-04-20 Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel Active DE112018002561B3 (de)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201762488526P 2017-04-21 2017-04-21
US62/488,526 2017-04-21
US201862634464P 2018-02-23 2018-02-23
US62/634,464 2018-02-23
US201862640945P 2018-03-09 2018-03-09
US62/640,945 2018-03-09
US201862644164P 2018-03-16 2018-03-16
US62/644,164 2018-03-16

Publications (1)

Publication Number Publication Date
DE112018002561B3 true DE112018002561B3 (de) 2022-01-05

Family

ID=63854344

Family Applications (3)

Application Number Title Priority Date Filing Date
DE112018002562.4T Active DE112018002562B3 (de) 2017-04-21 2018-04-20 Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel durch Zwischenspeichern wiederkehrender Bewegungsvektoren
DE112018002561.6T Active DE112018002561B3 (de) 2017-04-21 2018-04-20 Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel
DE112018002096.7T Pending DE112018002096T5 (de) 2017-04-21 2018-04-20 Spielereingabebewegungskompensation durch antizipation von bewegungsvektoren

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE112018002562.4T Active DE112018002562B3 (de) 2017-04-21 2018-04-20 Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel durch Zwischenspeichern wiederkehrender Bewegungsvektoren

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE112018002096.7T Pending DE112018002096T5 (de) 2017-04-21 2018-04-20 Spielereingabebewegungskompensation durch antizipation von bewegungsvektoren

Country Status (14)

Country Link
US (12) US10341678B2 (de)
EP (3) EP3723045B1 (de)
JP (3) JP6984001B2 (de)
KR (1) KR102302643B1 (de)
CN (2) CN113628240A (de)
AU (4) AU2018255983B2 (de)
BR (1) BR112019022004A2 (de)
CA (3) CA3060089C (de)
DE (3) DE112018002562B3 (de)
GB (4) GB2591059B (de)
RU (3) RU2726284C1 (de)
TW (9) TWI721670B (de)
WO (1) WO2018195461A1 (de)
ZA (6) ZA201907686B (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA3060089C (en) 2017-04-21 2023-06-13 Zenimax Media Inc. Player input motion compensation by anticipating motion vectors
JP7145643B2 (ja) 2018-05-17 2022-10-03 株式会社ディスコ 検査治具及び検査方法
JP7322341B2 (ja) * 2019-03-12 2023-08-08 株式会社コナミデジタルエンタテインメント ゲーム装置、及び、ゲームシステム
US10926177B2 (en) * 2019-03-15 2021-02-23 Sony Interactive Entertainment Inc. Systems and methods for predicting states by using a distributed game engine
US11207594B2 (en) * 2019-03-29 2021-12-28 Electronic Arts Inc. State stream game engine
CN110138769B (zh) * 2019-05-09 2021-06-15 深圳市腾讯网域计算机网络有限公司 一种图像传输的方法以及相关装置
US11033813B2 (en) * 2019-06-07 2021-06-15 Microsoft Technology Licensing, Llc Latency erasure
US20220068013A1 (en) * 2020-08-28 2022-03-03 Nvidia Corporation System and method for image generation using jittered motion vectors
CN115209208A (zh) * 2021-04-08 2022-10-18 海信视像科技股份有限公司 一种视频循环播放的处理方法及装置
KR20230081402A (ko) * 2021-11-30 2023-06-07 삼성전자주식회사 서버와 전자 장치 사이의 영상 콘텐트를 스트리밍하는 방법, 영상 콘텐트를 스트리밍하는 서버 및 전자 장치

Family Cites Families (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS56117640A (en) 1980-02-22 1981-09-16 Mitsubishi Motors Corp Molding board for car
US4501980A (en) 1982-06-04 1985-02-26 Motornetics Corporation High torque robot motor
JPH01277055A (ja) * 1988-04-28 1989-11-07 Dainippon Screen Mfg Co Ltd 多値描画のためのラスターデータ生成方法
JPH06129865A (ja) 1992-10-20 1994-05-13 Sumitomo Electric Ind Ltd シングルモ−ドファイバ型デポラライザとその製造方法及び光ファイバジャイロ
JPH0974568A (ja) 1995-09-06 1997-03-18 Nippon Telegr & Teleph Corp <Ntt> 動画像の動き補償予測符号化方法
US5838823A (en) * 1996-02-29 1998-11-17 Electronic Arts, Inc. Video image compression and decompression
US6057847A (en) 1996-12-20 2000-05-02 Jenkins; Barry System and method of image generation and encoding using primitive reprojection
JP3344345B2 (ja) 1998-12-15 2002-11-11 日本電気株式会社 共有メモリ型ベクトル処理システムとその制御方法及びベクトル処理の制御プログラムを格納する記憶媒体
US6507618B1 (en) * 2000-04-25 2003-01-14 Hewlett-Packard Company Compressed video signal including independently coded regions
US7091975B1 (en) 2000-07-21 2006-08-15 Microsoft Corporation Shape and animation methods and systems using examples
US6884171B2 (en) * 2000-09-18 2005-04-26 Nintendo Co., Ltd. Video game distribution network
JP4011327B2 (ja) 2000-11-15 2007-11-21 株式会社レクサー・リサーチ 表示オブジェクト提供装置、表示オブジェクト提供方式及び表示オブジェクト提供プログラム
US6761636B2 (en) 2001-01-16 2004-07-13 Fucom Company, Ltd. Real time data exchange system
GB2375673A (en) * 2001-05-14 2002-11-20 Salgen Systems Ltd Image compression method using a table of hash values corresponding to motion vectors
US20030189980A1 (en) * 2001-07-02 2003-10-09 Moonlight Cordless Ltd. Method and apparatus for motion estimation between video frames
EP1520431B1 (de) 2002-07-01 2018-12-26 E G Technology Inc. Wirksame kompression und transport von video über ein netzwerk
US7391409B2 (en) 2002-07-27 2008-06-24 Sony Computer Entertainment America Inc. Method and system for applying gearing effects to multi-channel mixed input
US7546534B1 (en) * 2002-08-26 2009-06-09 Microsoft Corporation Personalizing access of game web site based on user configuration
US6903662B2 (en) 2002-09-19 2005-06-07 Ergodex Computer input device with individually positionable and programmable input members
US8054880B2 (en) 2004-12-10 2011-11-08 Tut Systems, Inc. Parallel rate control for digital video encoder with multi-processor architecture and picture-based look-ahead window
US20050195975A1 (en) 2003-01-21 2005-09-08 Kevin Kawakita Digital media distribution cryptography using media ticket smart cards
US7408984B2 (en) 2003-09-17 2008-08-05 International Business Machines Corporation Method and system for multiple pass video coding
EP2408193A3 (de) 2004-04-16 2014-01-15 James A. Aman Kamera für sichtbares und unsichtbares Licht für Videoaufnahmen und Objektnachführung
US7129951B2 (en) 2004-05-06 2006-10-31 Valve Corporation Method and system for performing speculative collisions for a video game
US8902971B2 (en) 2004-07-30 2014-12-02 Euclid Discoveries, Llc Video compression repository and model reuse
BRPI0519544A2 (pt) * 2004-12-21 2009-02-17 Qualcomm Inc configuraÇço firewall assistida de cliente
US20060230428A1 (en) 2005-04-11 2006-10-12 Rob Craig Multi-player video game system
US20070009042A1 (en) * 2005-07-08 2007-01-11 Robert Craig Video game system using pre-encoded macro-blocks in an I-frame
DE602006015650D1 (de) * 2005-07-08 2010-09-02 Tag Networks Inc Videospielsystem mit vorcodierten makroblöcken
US8118676B2 (en) 2005-07-08 2012-02-21 Activevideo Networks, Inc. Video game system using pre-encoded macro-blocks
US9060101B2 (en) * 2005-07-08 2015-06-16 Activevideo Networks, Inc. Video game system having an infinite playing field
US8787460B1 (en) * 2005-07-28 2014-07-22 Teradici Corporation Method and apparatus for motion vector estimation for an image sequence
JP4722936B2 (ja) * 2005-09-30 2011-07-13 シャープ株式会社 画像表示装置及び方法
US8020029B2 (en) 2006-02-17 2011-09-13 Alcatel Lucent Method and apparatus for rendering game assets in distributed systems
JP4961850B2 (ja) 2006-06-15 2012-06-27 ソニー株式会社 動き検出方法、動き検出方法のプログラム、動き検出方法のプログラムを記録した記録媒体及び動き検出装置
US8160056B2 (en) * 2006-09-08 2012-04-17 At&T Intellectual Property Ii, Lp Systems, devices, and methods for network routing
JP4319211B2 (ja) 2006-09-21 2009-08-26 株式会社スクウェア・エニックス ビデオゲーム処理装置、およびビデオゲーム処理プログラム
US8218640B2 (en) 2006-10-31 2012-07-10 Sony Computer Entertainment Inc. Picture decoding using same-picture reference for pixel reconstruction
US8874655B2 (en) 2006-12-13 2014-10-28 Napo Enterprises, Llc Matching participants in a P2P recommendation network loosely coupled to a subscription service
US9697280B2 (en) 2006-12-13 2017-07-04 Quickplay Media, Inc. Mediation and settlement for mobile media
US8804829B2 (en) 2006-12-20 2014-08-12 Microsoft Corporation Offline motion description for video generation
US20090017910A1 (en) * 2007-06-22 2009-01-15 Broadcom Corporation Position and motion tracking of an object
JP4931223B2 (ja) * 2007-03-30 2012-05-16 株式会社バンダイナムコゲームス 動きベクトル探索プログラム、情報記憶媒体、動きベクトル探索装置、及び、ネットワークシステム
US8069258B1 (en) 2007-09-11 2011-11-29 Electronic Arts Inc. Local frame processing to apparently reduce network lag of multiplayer deterministic simulations
US8127233B2 (en) * 2007-09-24 2012-02-28 Microsoft Corporation Remote user interface updates using difference and motion encoding
US20090172565A1 (en) * 2007-12-26 2009-07-02 John Clarke Jackson Systems, Devices, and Methods for Sharing Content
US8681870B2 (en) * 2008-02-14 2014-03-25 Nec Corporation Motion vector detection device
WO2009138878A2 (en) 2008-05-12 2009-11-19 Playcast Media Systems, Ltd. Centralized streaming game server
US8154553B2 (en) 2008-05-22 2012-04-10 Playcast Media System, Ltd. Centralized streaming game server
US8571106B2 (en) * 2008-05-22 2013-10-29 Microsoft Corporation Digital video compression acceleration based on motion vectors produced by cameras
JP4545809B2 (ja) 2008-06-05 2010-09-15 株式会社スクウェア・エニックス ゲーム装置及びプログラム
JP4613990B2 (ja) 2008-07-31 2011-01-19 ソニー株式会社 画像処理装置、画像処理方法、プログラム
US8678929B1 (en) 2008-08-01 2014-03-25 Electronics Arts Inc. Client-side prediction of a local game object to reduce apparent network lag of multiplayer simulations
US10192389B2 (en) 2008-09-01 2019-01-29 New Bis Safe Luxco S.À.R.L. Methods, apparatus and systems for determining an adjustment value of a gaming device
KR100997541B1 (ko) * 2008-10-08 2010-11-30 인하대학교 산학협력단 신상품 추천문제 해결을 위한 내용기반 필터링과 협업 필터링을 혼합한 사용자 프로파일 기반 이미지 추천 방법 및 장치
US10235832B2 (en) 2008-10-17 2019-03-19 Igt Post certification metering for diverse game machines
FR2940736B1 (fr) 2008-12-30 2011-04-08 Sagem Comm Systeme et procede de codage video
JP4718622B2 (ja) * 2009-03-24 2011-07-06 株式会社スクウェア・エニックス ゲーム装置、ゲームの進行方法、ゲームプログラム及び記録媒体
CN101583025B (zh) * 2009-06-11 2011-05-11 中兴通讯股份有限公司 一种流媒体播放方法及装置
US8854376B1 (en) 2009-07-30 2014-10-07 Lucasfilm Entertainment Company Ltd. Generating animation from actor performance
US8577466B2 (en) * 2011-09-30 2013-11-05 Nyxoah SA System and method for nerve modulation using noncontacting electrodes
US9338523B2 (en) 2009-12-21 2016-05-10 Echostar Technologies L.L.C. Audio splitting with codec-enforced frame sizes
US8553982B2 (en) * 2009-12-23 2013-10-08 Intel Corporation Model-based play field registration
ES2627521T3 (es) * 2010-01-18 2017-07-28 Telefonaktiebolaget Lm Ericsson (Publ) Método y disposición para soportar reproducción de contenidos
US20110250948A1 (en) 2010-04-08 2011-10-13 Wms Gaming, Inc. Video compression in gaming machines
US20110261885A1 (en) 2010-04-27 2011-10-27 De Rivaz Peter Francis Chevalley Method and system for bandwidth reduction through integration of motion estimation and macroblock encoding
JP5218995B2 (ja) 2010-05-14 2013-06-26 Ｎｅｃシステムテクノロジー株式会社 動画再生端末，動画再生方法及びプログラム
US9789392B1 (en) 2010-07-09 2017-10-17 Open Invention Network Llc Action or position triggers in a game play mode
JP2012043158A (ja) 2010-08-18 2012-03-01 Sony Computer Entertainment Inc 情報処理装置、情報処理端末、情報処理システム、情報処理方法、情報処理プログラム
US8924544B2 (en) * 2010-12-07 2014-12-30 Samsung Electronics Co., Ltd. Techniques for sessionless reporting by device management client
RU2602792C2 (ru) * 2011-01-28 2016-11-20 Конинклейке Филипс Электроникс Н.В. Сравнение движущихся объектов на основе вектора движения
KR20120088488A (ko) * 2011-01-31 2012-08-08 한국전자통신연구원 시간적 움직임 벡터 저장 방법 및 그 장치
US20130329797A1 (en) 2011-02-25 2013-12-12 Panasonic Corporation Image coding method and image decoding method
US9122609B2 (en) 2011-03-07 2015-09-01 Texas Instruments Incorporated Caching method and system for video coding
JP5155462B2 (ja) 2011-08-17 2013-03-06 株式会社スクウェア・エニックス・ホールディングス 動画配信サーバ、動画再生装置、制御方法、プログラム、及び記録媒体
EP2563038A1 (de) * 2011-08-26 2013-02-27 Streamtainment Systems OÜ Verfahren zum Übertragen von Videosignalen von einer Anwendung auf einem Server über ein IP-Netz an ein Client-Gerät
US9578336B2 (en) * 2011-08-31 2017-02-21 Texas Instruments Incorporated Hybrid video and graphics system with automatic content detection process, and other circuits, processes, and systems
US8913664B2 (en) * 2011-09-16 2014-12-16 Sony Computer Entertainment Inc. Three-dimensional motion mapping for cloud gaming
US9734167B2 (en) * 2011-09-21 2017-08-15 Horsetooth Ventures, LLC Interactive image display and selection system
JP5977023B2 (ja) 2011-11-07 2016-08-24 株式会社スクウェア・エニックス・ホールディングス 描画システム、プログラム、及び記録媒体
JP6129865B2 (ja) * 2011-12-09 2017-05-17 エンパイア テクノロジー ディベロップメント エルエルシー ゲームコンテンツデータの予測的なキャッシング
EP2645713A1 (de) 2012-03-30 2013-10-02 Alcatel Lucent Verfahren und Vorrichtung zur Codierung eines ausgewählten räumlichen Abschnitts eines Video-Streams
CN104641644A (zh) * 2012-05-14 2015-05-20 卢卡·罗萨托 基于沿时间的样本序列的混合的编码和解码
HUE037047T2 (hu) * 2012-06-11 2018-08-28 Samsung Electronics Co Ltd Eljárás színes komponens szerinti SAO paramétert megosztó videók kódolására
EP2859729B1 (de) 2012-06-12 2020-09-16 Coherent Logix, Incorporated Verteilte architektur für codierung und ausgabe von videoinhalten
JP5586718B2 (ja) 2012-06-19 2014-09-10 株式会社東芝 制御プログラム、ホスト装置の制御方法、情報処理装置およびホスト装置
GB201211994D0 (en) * 2012-07-05 2012-08-22 Sensewhere Ltd Method of estimating position of user device
US8737460B2 (en) 2012-07-16 2014-05-27 Seagate Technology, Llc Equalizer and detector arrangement employing joint entropy-based calibration
CN104813669B (zh) 2012-09-21 2018-05-22 诺基亚技术有限公司 用于视频编码的方法和装置
CN104756513A (zh) 2012-11-05 2015-07-01 索尼电脑娱乐公司 信息处理设备
JP6151909B2 (ja) * 2012-12-12 2017-06-21 キヤノン株式会社 動画像符号化装置、方法およびプログラム
US10715817B2 (en) * 2012-12-19 2020-07-14 Nvidia Corporation Apparatus and method for enhancing motion estimation based on user input
BR112015015575A2 (pt) 2013-01-30 2020-02-04 Intel Corp particionamento adaptativo ao conteúdo para a previsão e codificação para vídeo da próxima geração
US9257092B2 (en) 2013-02-12 2016-02-09 Vmware, Inc. Method and system for enhancing user experience for remoting technologies
US9564102B2 (en) * 2013-03-14 2017-02-07 Microsoft Technology Licensing, Llc Client side processing of player movement in a remote gaming environment
US9661351B2 (en) 2013-03-15 2017-05-23 Sony Interactive Entertainment America Llc Client side frame prediction for video streams with skipped frames
CN105246567B (zh) 2013-05-31 2016-09-14 英派尔科技开发有限公司 受缓存影响的视频游戏
US20150088942A1 (en) * 2013-09-25 2015-03-26 Westell Technologies, Inc. Methods and Systems for Providing File Services
US9192863B2 (en) 2013-10-29 2015-11-24 Disney Enterprises, Inc. Selective caching of interactive objects
US9749642B2 (en) 2014-01-08 2017-08-29 Microsoft Technology Licensing, Llc Selection of motion vector precision
US20150228106A1 (en) 2014-02-13 2015-08-13 Vixs Systems Inc. Low latency video texture mapping via tight integration of codec engine with 3d graphics engine
US9762919B2 (en) 2014-08-28 2017-09-12 Apple Inc. Chroma cache architecture in block processing pipelines
US10063866B2 (en) 2015-01-07 2018-08-28 Texas Instruments Incorporated Multi-pass video encoding
US11477477B2 (en) 2015-01-26 2022-10-18 Qualcomm Incorporated Sub-prediction unit based advanced temporal motion vector prediction
CA2958254A1 (en) * 2015-01-29 2016-08-04 Ecole De Technologie Superieure Methods and systems for determining motion vectors in a motion estimation process of a video encoder
TW201642655A (zh) * 2015-04-21 2016-12-01 Ｖｉｄ衡器股份有限公司 基於藝術意向之視訊編碼
CN104811721B (zh) 2015-05-26 2017-09-22 珠海全志科技股份有限公司 视频解码数据存储方法及运动向量数据的计算方法
JP6910130B2 (ja) 2015-11-06 2021-07-28 三星電子株式会社Ｓａｍｓｕｎｇ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏ．，Ｌｔｄ． ３ｄレンダリング方法及び３ｄレンダリング装置
US9426543B1 (en) * 2015-12-18 2016-08-23 Vuclip (Singapore) Pte. Ltd. Server-based video stitching
US10163183B2 (en) 2016-01-13 2018-12-25 Rockwell Collins, Inc. Rendering performance using dynamically controlled samples
US10306258B2 (en) 2016-01-29 2019-05-28 Google Llc Last frame motion vector partitioning
US9705526B1 (en) 2016-03-17 2017-07-11 Intel Corporation Entropy encoding and decoding of media applications
US10109100B2 (en) 2016-03-25 2018-10-23 Outward, Inc. Adaptive sampling of pixels
CN109416613A (zh) 2016-07-15 2019-03-01 爱迪德技术有限公司 获取用户输入
US9875552B1 (en) 2016-07-26 2018-01-23 Teradici Corporation Content independent method of motion determination using sparse matrices
US10514799B2 (en) 2016-09-08 2019-12-24 Google Llc Deep machine learning to perform touch motion prediction
US10049481B2 (en) * 2016-09-12 2018-08-14 Disney Enterprises, Inc. Direct manipulation interpolation and ghost wedging for distributed node-based interactive workflows
US10719447B2 (en) 2016-09-26 2020-07-21 Intel Corporation Cache and compression interoperability in a graphics processor pipeline
US10306180B2 (en) 2016-10-21 2019-05-28 Liquidsky Software, Inc. Predictive virtual reality content streaming techniques
US10463964B2 (en) * 2016-11-17 2019-11-05 Activision Publishing, Inc. Systems and methods for the real-time generation of in-game, locally accessible heatmaps
CA3060089C (en) 2017-04-21 2023-06-13 Zenimax Media Inc. Player input motion compensation by anticipating motion vectors

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Gabriel Gambetta: Fast-Paced Multiplayer (Part I – Part IV), archive.org-Snapshots vom 03.07.2017 bzw. 06.07.2017 von https://web.archive.org/web/20170706184810/https://www.gabrielgambetta.com/client-server-game-architecture.html; https://web.archive.org/web/20170706031432/https://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html; https://web.archive.org/web/20170703191713/https://www.gabrielgambetta.com/entity-interpolation.html;https://web.archive.org/web/20170703191746/https://www.gabrielgambetta.com/lag-compensation.html

Also Published As

Publication number Publication date
EP3613014A1 (de) 2020-02-26
US10469867B2 (en) 2019-11-05
AU2020201835A1 (en) 2020-04-02
US20210195233A1 (en) 2021-06-24
RU2729705C2 (ru) 2020-08-11
EP3723045B1 (de) 2023-10-18
RU2020121361A (ru) 2020-09-02
ZA202007216B (en) 2022-04-28
GB202103296D0 (en) 2021-04-21
WO2018195461A1 (en) 2018-10-25
US10595040B2 (en) 2020-03-17
TW201907363A (zh) 2019-02-16
KR20200019855A (ko) 2020-02-25
ZA202003699B (en) 2021-08-25
US20200053383A1 (en) 2020-02-13
GB201916978D0 (en) 2020-01-08
EP3723045A1 (de) 2020-10-14
JP2020078080A (ja) 2020-05-21
TW201907725A (zh) 2019-02-16
TW202016882A (zh) 2020-05-01
JP6972097B2 (ja) 2021-11-24
TW202011745A (zh) 2020-03-16
RU2020121361A3 (de) 2020-12-01
US20180311577A1 (en) 2018-11-01
TW202131692A (zh) 2021-08-16
ZA201907686B (en) 2021-04-28
TW202131691A (zh) 2021-08-16
US10148978B2 (en) 2018-12-04
GB2591059B (en) 2022-02-16
GB2585145A (en) 2020-12-30
EP3613014A4 (de) 2020-07-22
US10595041B2 (en) 2020-03-17
CN111052182A (zh) 2020-04-21
AU2018255983B2 (en) 2020-04-23
TW201844003A (zh) 2018-12-16
US20190364297A1 (en) 2019-11-28
RU2019138605A (ru) 2020-04-17
US20190222861A1 (en) 2019-07-18
RU2019138605A3 (de) 2020-06-01
US11323740B2 (en) 2022-05-03
GB2590034A (en) 2021-06-16
AU2020201835B2 (en) 2021-07-29
GB2590034B (en) 2021-12-22
TWI721677B (zh) 2021-03-11
AU2018255983A1 (en) 2019-12-12
GB2585145B (en) 2021-05-26
US20210235112A1 (en) 2021-07-29
TW202145144A (zh) 2021-12-01
JP7039546B2 (ja) 2022-03-22
AU2020201834A1 (en) 2020-04-02
US10341678B2 (en) 2019-07-02
EP3723370A1 (de) 2020-10-14
TWI721670B (zh) 2021-03-11
TWI780682B (zh) 2022-10-11
DE112018002562B3 (de) 2022-01-05
CA3060089A1 (en) 2018-10-25
EP3723370B8 (de) 2024-01-17
CN113628240A (zh) 2021-11-09
CN111052182B (zh) 2021-07-13
TWI681669B (zh) 2020-01-01
ZA202003698B (en) 2021-08-25
US11503332B2 (en) 2022-11-15
GB2578527A (en) 2020-05-13
AU2020201834B9 (en) 2021-07-01
AU2020201834B2 (en) 2021-04-29
TWI797549B (zh) 2023-04-01
GB202105234D0 (en) 2021-05-26
TW202015416A (zh) 2020-04-16
US11601670B2 (en) 2023-03-07
JP2020091874A (ja) 2020-06-11
US20180310020A1 (en) 2018-10-25
AU2020203120A1 (en) 2020-05-28
RU2726284C1 (ru) 2020-07-10
EP3723370B1 (de) 2023-12-06
BR112019022004A2 (pt) 2020-05-12
AU2020203120B2 (en) 2021-10-07
DE112018002096T5 (de) 2020-01-09
CA3194408A1 (en) 2018-10-25
TWI729607B (zh) 2021-06-01
US20200186829A1 (en) 2020-06-11
GB2578527B (en) 2021-04-28
TWI684357B (zh) 2020-02-01
ZA202007217B (en) 2022-04-28
US11533504B2 (en) 2022-12-20
KR102302643B1 (ko) 2021-09-14
US11330291B2 (en) 2022-05-10
US20190124357A1 (en) 2019-04-25
EP3613014B1 (de) 2023-10-18
CA3060089C (en) 2023-06-13
US11695951B2 (en) 2023-07-04
CA3194309A1 (en) 2018-10-25
TWI788772B (zh) 2023-01-01
RU2742221C2 (ru) 2021-02-03
GB202012029D0 (en) 2020-09-16
GB2591059A (en) 2021-07-14
US20200204821A1 (en) 2020-06-25
JP6984001B2 (ja) 2021-12-17
JP2020518210A (ja) 2020-06-18
ZA202007215B (en) 2022-03-30
US20180310019A1 (en) 2018-10-25
US20230269393A1 (en) 2023-08-24
TWI729288B (zh) 2021-06-01

Similar Documents

Publication Publication Date Title
DE112018002561B3 (de) Systeme und Verfahren zur Spielereingabe-Bewegungskompensation in einem Client-Server-Videospiel

Legal Events

Date Code Title Description
R129 Divisional application from

Ref document number: 112018002096

Country of ref document: DE

R012 Request for examination validly filed
R082 Change of representative

Representative=s name: GRUENECKER PATENT- UND RECHTSANWAELTE PARTG MB, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final