RU2813614C2 - Systems and methods of motion compensation based on player input - Google Patents

Abstract

FIELD: information technologies.

SUBSTANCE: method for estimating motion using a computer, comprising the following steps: transmitting a lookup table consisting of one or more user inputs and one or more associated motion vectors, transmitting a command to access the lookup table to find appropriate motion vectors after receiving the player's input, transmitting a command to associate a unique marker with the corresponding motion vectors from the lookup table and adding the marked motion vectors to the queue, transmitting the frame, and sending a command to remove motion vectors from the queue, which are characterized by the presence of a marker associated with the marked frame received from the server; while the server transmits the encoded video frames to the client, the client receives a command to decode the video frames for motion estimation.

EFFECT: reducing the delay time for user input.

20 cl, 13 dwg

Description

Ссылка на родственные заявкиLink to related applications

[0001] Согласно настоящей заявке испрашивается приоритет в соответствии с такими предварительными заявками на патент США: №62/488 526, поданная 21 апреля 2017 г., №62/634 464, поданная 23 февраля 2018 г., №62/640,945, поданная 9 марта 2018 г., и №62/644,164, поданная 16 марта 2018 г.[0001] This application claims priority to the following US provisional patent applications: No. 62/488,526, filed April 21, 2017, No. 62/634,464, filed February 23, 2018, No. 62/640,945, filed March 9, 2018, and No. 62/644,164 filed March 16, 2018.

Предпосылки к созданию настоящего изобретенияBackground to the present invention

[0002] В удаленных играх, в которых игра на стороне сервера управляется игроком на стороне клиента, предпринимались попытки кодировать выходной видеосигнал от движка трехмерной (3D) графики в режиме реального времени с использованием существующих или специально настроенных кодировщиков. Однако интерактивный характер видеоигр, в частности, контур обратной связи с игроком между выходным видеосигналом и вводом игрока, делает потоковую передачу игрового видео более чувствительным к задержкам, чем в традиционной потоковой передаче видео. Существующие способы кодирования видеосигналов могут использовать вычислительную мощность, и практически ничего более, для уменьшения времени кодирования. Новые способы интеграции процесса кодирования в процесс рендеринга видео могут обеспечить существенное уменьшение времени кодирования, а также сокращение вычислительной мощности, повышение качества кодированного видео и сохранения исходного формата данных битового потока для поддержания функциональной совместимости существующих аппаратных устройств.[0002] In remote games, in which the server-side game is controlled by a client-side player, attempts have been made to encode the video output from a three-dimensional (3D) graphics engine in real time using existing or customized encoders. However, the interactive nature of video games, specifically the player feedback loop between video output and player input, makes game video streaming more latency-sensitive than traditional video streaming. Existing video encoding methods can use processing power, and little else, to reduce encoding time. New ways to integrate the encoding process into the video rendering process can provide significant reductions in encoding time, as well as reduced processing power, improved encoded video quality, and preservation of the original bitstream data format to maintain interoperability among existing hardware devices.

[0003] В отличие от обычного воспроизведения видео, видеоигры характеризуются уникальным вводом игрока в контур обратной видеосвязи. Игроки остро ощущают задержку между вводом и выходным видеосигналом. Длительная задержка в контуре ввод игрока-обратная связь является камнем преткновения в потоковой передаче видеоигр, когда серверная копия видеоигры управляется удаленным игроком. Любой процесс, способный сократить время между вводом и обратной связью, может напрямую улучшить впечатления от использования.[0003] Unlike conventional video playback, video games are characterized by a unique player input into the video feedback loop. Players are acutely aware of the delay between video input and output. Long latency in the player input-feedback loop is a stumbling block in video game streaming when the server copy of the video game is controlled by a remote player. Any process that can reduce the time between input and feedback can directly improve the user experience.

[0004]Клиентское аппаратное обеспечение в игровой потоковой среде может характеризоваться разными уровнями вычислительной мощности, но специализированные аппаратные декодеры Н.264 становятся все более распространенными даже в мобильных и других маломощных устройствах. Аппаратный декодер хорошо выполняет небольшой набор вычислений, таких как компенсация движения, которые постоянно выполняются в соответствии со стандартом кодирования Н.264. Сильные стороны специализированного аппаратного обеспечения для декодирования могут быть использованы для обеспечения лучшего взаимодействия с игроками в игровой потоковой среде, независимо от общей вычислительной мощности клиента.[0004] Client hardware in a gaming streaming environment can have varying levels of processing power, but dedicated H.264 hardware decoders are becoming increasingly common even in mobile and other low-power devices. The hardware decoder is good at performing a small set of calculations, such as motion compensation, that are constantly performed according to the H.264 encoding standard. The strengths of dedicated decoding hardware can be leveraged to provide a better player experience in a gaming streaming environment, regardless of the client's overall processing power.

[0005] В локальных приложениях рендеринга без потоковой передачи игровой движок может добавлять несколько кадров задержки между вводом игрока и обратной видеосвязью. При потоковой трансляции игр дополнительная задержка появляется в цикле ввод игрока-обратная связь из-за того, что ввод игрока должен пройти через сеть на удаленный сервер и выходной видеосигнал должен быть закодирован, передан и декодирован перед тем, как игрок принимает обратную связь. Для некоторых вводов игрока клиент может оценивать результаты по обратной видеосвязи за счет выполнения немедленной компенсации движения, отсекая сетевую задержку.[0005] In local non-streaming rendering applications, the game engine may add several frames of delay between player input and video feedback. When streaming games, additional latency is introduced in the player input-feedback loop due to the fact that the player input must pass through the network to the remote server and the video output must be encoded, transmitted, and decoded before the player receives the feedback. For some player inputs, the client can evaluate the results from video feedback by performing immediate motion compensation, cutting off network latency.

[0006] Компенсация движения на основании ввода игрока, на базовом уровне, представляет собой методику смещения групп пикселей, жертвуя некоторой четкость изображения в обмен на уменьшение задержки между вводом и обратной связью в ситуациях, когда видеоигра запущена на сервере и управляется удаленно сетевым клиентом. Эта методика хорошо себя проявляет при уменьшении задержки между вводом игрока и обратной связью, что приводит к получению соответствующих векторов движения, например, при поворотах обзора игрока в играх от первого лица.[0006] Motion compensation based on player input, at a basic level, is a technique for moving groups of pixels, sacrificing some image clarity in exchange for reducing the latency between input and feedback in situations where the video game is running on a server and controlled remotely by a network client. This technique works well in reducing the delay between player input and feedback, resulting in appropriate motion vectors, such as when rotating the player's view in first-person games.

[0007] В видеоигре контекст игрока определяется как текущее состояние игры, являющееся результатом предыдущих действий, вводов и решений игрока. Клиент в системе потоковой трансляции игры не знает о контексте игрока, то есть клиент принимает только выходной видеосигнал без информации о состоянии игры, которая будет определять результаты определенных вводов игрока. Существует широкий диапазон вводов, которые приводят к уникальным, но предсказуемым движениям, на основании информации о состоянии игры. Эти вводы выиграли бы от уменьшения задержки между вводом игрока и обратной связью, но они не могут быть предварительно кешированы на стороне клиента для традиционной компенсации движения на основании ввода игрока, поскольку клиент не будет обладать информацией о контексте игрока. Дополнительно объем преобразования контекста игрока может быть слишком велик для предварительного генерирования векторов движения для способов с использованием кешированных повторяющихся векторов движения. Эти системы и способы описаны в предварительных заявках на патент США №62/488526; 62/634464 и 62/640,945; все из которых включены в настоящий документ во всей своей полноте. Игровой сервер может осуществлять компенсацию за счет генерирования прогнозируемых векторов движения и обновления кеш-памяти компенсации движения на основании ввода на стороне клиента при изменении контекста игрока. Это позволяет клиенту использовать методики компенсации движения на основании ввода игрока для ограниченного набора зависящих от контекста вводов, что приводит к уменьшению задержки между вводом и обратной связью.[0007] In a video game, player context is defined as the current state of the game, resulting from the player's previous actions, inputs, and decisions. The client in a game streaming system is unaware of the player's context, meaning the client only receives the video output without game state information that would determine the results of certain player inputs. There is a wide range of inputs that result in unique but predictable movements based on game state information. These inputs would benefit from reduced latency between player input and feedback, but they cannot be pre-cached on the client side for traditional motion compensation based on player input, since the client would not have knowledge of the player's context. Additionally, the amount of player context transformation may be too large to pre-generate motion vectors for methods using cached repeat motion vectors. These systems and methods are described in US Provisional Patent Applications No. 62/488,526; 62/634464 and 62/640.945; all of which are included herein in their entirety. The game server can perform compensation by generating predicted motion vectors and updating the motion compensation cache based on client-side input when the player's context changes. This allows the client to use motion compensation techniques based on player input for a limited set of context-sensitive inputs, resulting in reduced latency between input and feedback.

[0008] В патенте США №9661351 («патент '351») раскрываются системы и способы пропуска кадра во время передачи от сервера на клиентское устройство, причем, в ответ на обнаружение пропущенного кадра, клиентское устройство генерирует спрогнозированный кадр, который заменяет пропущенный кадр в сжатом видеопотоке, причем спрогнозированный кадр генерируется на основании расширенной дельта-информации из одного или нескольких предыдущих кадров, декодированных клиентским устройством. Для этой технологии прогнозирование кадров на стороне клиента для одного или нескольких восстановленных или спрогнозированных кадров используется после пропущенного кадра на основании данных (например, векторов движения, остаточных кадров и т.д.) одного или нескольких предыдущих кадров. Эта технология также отдает приоритет распределению битов и/или кодированию подпризнаков. Кодированные единицы слоя сетевой абстракции (NALU) могут быть разделены на (1) векторы движения и (2) остаточные кадры. Вместо фактического пропуска кадра устройство может только отправлять минимальные кодированные данные согласно приоритету. Например, оно может отправлять только векторы движения, если движение в приоритете. Технология согласно настоящему изобретению превосходит технологию патента '351 по меньшей мере потому, что в патенте '351 не раскрывается клиентское устройство, которое использует таблицы поиска, переданные от сервера, для сопоставления ввода пользователя с векторами движения, а также маркирует и суммирует эти векторы движения. В патенте '351 также не раскрывается применение этих суммированных векторов движения к декодированным кадрам для оценки движения в этих кадрах. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0008] US Pat. No. 9,661,351 (the "'351 patent") discloses systems and methods for dropping a frame during transmission from a server to a client device, wherein, in response to detection of a dropped frame, the client device generates a predicted frame that replaces the dropped frame in compressed video stream, wherein the predicted frame is generated based on expanded delta information from one or more previous frames decoded by the client device. For this technology, client-side frame prediction for one or more reconstructed or predicted frames is used after a dropped frame based on data (e.g., motion vectors, residual frames, etc.) of one or more previous frames. This technology also gives priority to bit allocation and/or sub-feature encoding. Network Abstraction Layer (NALU) coded units can be divided into (1) motion vectors and (2) residual frames. Instead of actually dropping the frame, the device can only send the minimum encoded data according to priority. For example, it can only send motion vectors if motion is a priority. The technology of the present invention is superior to that of the '351 patent at least because the '351 patent does not disclose a client device that uses lookup tables passed from the server to match user input to motion vectors and labels and summarizes those motion vectors. The '351 patent also does not disclose the application of these summed motion vectors to decoded frames to estimate motion in those frames. The technology of the present invention is also superior to this technology because it reduces the latency between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0009] В патенте США №8678929, («патент '929») раскрывается управление сетевой интерактивной игровой системой. Раскрытые способы направлены на уменьшение запаздывания в сети за счет определения значений положения со скорректированным курсом для общего глобального объекта посредством двустороннего наложения. Термин «наложение» в указанном патенте предусматривает стадии сетевого моделирования с отправкой вычисления позиции для локального игрока на локальной консоли. Консоль осуществляет наложение локального и сетевого моделирования. В способах также осуществляют наложение общих глобальных объектов за счет использования наложенной позиции локального игрока для определения значения положения для общего глобального объекта на локальной консоли. Технология согласно настоящему изобретению, опять-таки, превосходит технологию патента '929 по меньшей мере потому, что в патенте '929 не раскрывается клиентское устройство, которое использует таблицы поиска, переданные от сервера, для сопоставления ввода пользователя с векторами движения, а также маркирует и суммирует эти векторы движения. В патенте '929 также не раскрывается применение этих суммированных векторов движения к декодированным кадрам для оценки движения в этих кадрах. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она не требует наличия клиента с чрезвычайно высокой вычислительной мощностью, уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0009] US Pat. No. 8,678,929 (the '929 patent) discloses control of a networked interactive gaming system. The disclosed methods aim to reduce network latency by determining course-corrected position values for a common global object through a two-way overlay. The term "overlay" in the said patent involves network simulation stages sending a position calculation to the local player on the local console. The console overlays local and network simulations. The methods also overlay shared global objects by using the local player's overlay position to determine a position value for the shared global object on the local console. The technology of the present invention is again superior to that of the '929 patent, at least because the '929 patent does not disclose a client device that uses lookup tables passed from the server to match user input to motion vectors, and marks and summarizes these motion vectors. The '929 patent also does not disclose the application of these summed motion vectors to decoded frames to estimate motion in those frames. The technology of the present invention is also superior to this technology because it does not require a client with extremely high processing power, reduces the delay between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0010] В патенте США №8069258, («патент '258») раскрыто использование локальной обработки кадров для уменьшения явного запаздывания в сети при многопользовательском моделировании. Описанные способы предусматривают прерывание вводов от локального пользователя, определение данных о состоянии удаленного объекта при сетевом моделировании из предыдущего кадра игры и определение взаимодействий недетерминистических объектов из множества игровых систем, которые представляют собой часть сетевого моделирования. Эти данные о взаимодействии, вместе с данными о состоянии и локальным вводом, используются для локального моделирования видеокадра. Таким образом, локальное и сетевое моделирование могут быть запущены асинхронно для одного кадра, причем каждый кадр соответствует одной временной фазе в игре. Это обеспечивает возможность обновления локального моделирования в режиме реального времени в процессе сетевой игры, при этом оно остается (по существу) синхронизированным с сетью. Технология согласно настоящему изобретению, опять-таки, превосходит технологию патента '258 по меньшей мере потому, что в патенте '258 не раскрывается клиентское устройство, которое использует таблицы поиска, переданные от сервера, для сопоставления ввода пользователя с векторами движения, а также маркирует и суммирует эти векторы движения. В патенте '929 также не раскрывается применение этих суммированных векторов движения к декодированным кадрам для оценки движения в этих кадрах. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она не требует наличия клиента с чрезвычайно высокой вычислительной мощностью, уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0010] US Pat. No. 8,069,258 (the '258 patent) discloses the use of local frame processing to reduce apparent network latency in multi-user simulations. The described methods involve interrupting inputs from a local user, determining the state of a remote object in a network simulation from a previous frame of the game, and determining the interactions of non-deterministic objects from multiple game systems that are part of the network simulation. This interaction data, along with state data and local input, is used to locally model the video frame. In this way, local and online simulations can be run asynchronously on a single frame, with each frame corresponding to one time phase in the game. This allows the local simulation to be updated in real time during online play, while remaining (essentially) synchronized with the network. The technology of the present invention is again superior to that of the '258 patent, at least because the '258 patent does not disclose a client device that uses lookup tables passed from the server to match user input to motion vectors, and marks and summarizes these motion vectors. The '929 patent also does not disclose the application of these summed motion vectors to decoded frames to estimate motion in those frames. The technology of the present invention is also superior to this technology because it does not require a client with extremely high processing power, reduces the delay between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0011] В патенте США №9665334 В2 («патент '334») раскрываются системы и способы для протоколов рендеринга, в которых применяется множество процессов и компоновщик для рендеринга комбинированного графического изображения на дисплее. Технология работает следующим образом: когда сервер одновременно выдает игровой экран на несколько клиентских устройств, вычислительная нагрузка от процесса рендеринга на сервере приводит к «утяжелению», например, игрового содержимого, которое требует быстрого отклика. То есть, количество клиентских устройств, на которые сервер может выдавать экран, ограничено в зависимости от его характеристик рендеринга и требуемого отклика. В отличие от этого, когда каждое клиентское устройство управляется для выполнения обработки, которая может быть осуществлена с использованием общих характеристик рендеринга для совместного выполнения процессов рендеринга между сервером и клиентским устройством, экран может быть выдан на большее количество клиентских устройств. Кроме того, в целом, игровой экран, который подвергнут рендерингу без применения наложения текстуры, характеризуется высокой эффективностью сжатия, и может быть отправлен на меньшей ширине полосы посредством сети, такой как Интернет. Технология согласно настоящему изобретению превосходит технологию патента '334 по меньшей мере потому, что в нем не раскрыты генерирование векторов движения на сервере на основании предварительно определенных критериев и передача сгенерированных векторов движения и одного или нескольких указателей недействительности клиенту, который осуществляет кеширование этих векторов движения и указателей недействительности. Кроме того, в нем не раскрыты отдача сервером команды клиенту на прием ввода от пользователя, а также использование этого ввода для сопоставления кешированных векторов движения или указателей недействительности, причем эти векторы или указатели недействительности используются при компенсации движения. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0011] US Pat. No. 9,665,334 B2 (the '334 patent) discloses systems and methods for rendering protocols that employ a plurality of processes and a compositor to render a composite graphic image on a display. The technology works as follows: when the server simultaneously renders the game screen to several client devices, the computational load from the rendering process on the server leads to “heavier”, for example, game content that requires fast response. That is, the number of client devices to which the server can render a screen is limited depending on its rendering characteristics and the required response. In contrast, when each client device is controlled to perform processing, which can be accomplished using common rendering characteristics to share rendering processes between the server and the client device, the screen can be rendered to a larger number of client devices. In addition, in general, a game screen that is rendered without applying texture mapping has high compression efficiency, and can be sent at a lower bandwidth over a network such as the Internet. The technology of the present invention is superior to that of the '334 patent at least because it does not disclose generating motion vectors on a server based on predefined criteria and transmitting the generated motion vectors and one or more invalidity indicators to a client that caches those motion vectors and indicators invalidity. It also does not disclose the server issuing a command to the client to receive input from the user, nor the use of that input to match cached motion vectors or invalidity indicators, which vectors or invalidity indicators are used in motion compensation. The technology of the present invention is also superior to this technology because it reduces the latency between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0012] В патенте США №9736454 («патент '454») раскрыты системы и способы кодирования, предусматривающие анализ доступности блока глубины, совместно расположенного с блоком текстуры, определение способа прогнозирования для блока текстуры на основании доступности совместно расположенного блока глубины и нахождение первого блока прогнозирования для блока текстуры на основании доступности совместно расположенного блока глубины. Опять-таки, технология согласно настоящему изобретению превосходит технологию патента '454 по меньшей мере потому, что в нем не раскрыты генерирование векторов движения на сервере на основании предварительно определенных критериев и передача сгенерированных векторов движения и одного или нескольких указателей недействительности клиенту, который осуществляет кеширование этих векторов движения и указателей недействительности. Кроме того, в нем не раскрыты отдача сервером команды клиенту на прием ввода от пользователя, а также использование этого ввода для сопоставления кешированных векторов движения или указателей недействительности, причем эти векторы или указатели недействительности используются при компенсации движения. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0012] US Pat. No. 9,736,454 (the '454 patent) discloses encoding systems and methods that include analyzing the availability of a depth block co-located with a texture block, determining a prediction method for a texture block based on the availability of a co-located depth block, and finding the first block making predictions for a texture block based on the availability of a co-located depth block. Again, the technology of the present invention is superior to that of the '454 patent at least because it does not disclose generating motion vectors on a server based on predefined criteria and transmitting the generated motion vectors and one or more invalidity indicators to the client, which caches those motion vectors and invalidity indicators. It also does not disclose the server issuing a command to the client to receive input from the user, nor the use of that input to match cached motion vectors or invalidity indicators, which vectors or invalidity indicators are used in motion compensation. The technology of the present invention is also superior to this technology because it reduces the latency between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0013] В патенте США №9705526 («патент '526») раскрыты системы и способы энтропийного кодирования в мультимедийных и связанных с изображениями приложениях. Технология касается системы, в которой сжатие начинается с приема источника данных изображения или видео, как указано. Затем применяется схема сжатия без потерь. Блок прогнозирования/вычисления разности затем получает ввод и пытается уменьшить избыточность входных данных с использованием вычисления разности между соседними входными элементами. Затем эти значения кодируются с использованием заданного статистического моделирования в энтропийном кодере для получения сжатых данных изображения и/или видео. Аналогично вышеописанному, технология согласно настоящему изобретению превосходит технологию, описанную в патенте '526, по меньшей мере потому, что в нем не раскрыты генерирование векторов движения на сервере на основании предварительно определенных критериев и передача сгенерированных векторов движения и одного или нескольких указателей недействительности клиенту, который осуществляет кеширование этих векторов движения и указателей недействительности. Кроме того, в нем не раскрыты отдача сервером команды клиенту на прием ввода от пользователя, а также использование этого ввода для сопоставления кешированных векторов движения или указателей недействительности, причем эти векторы или указатели недействительности используются при компенсации движения. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0013] US Pat. No. 9,705,526 (the '526 patent) discloses entropy encoding systems and methods for multimedia and imaging applications. The technology refers to a system in which compression begins by receiving an image or video data source as specified. A lossless compression scheme is then applied. The prediction/difference block then receives the input and attempts to reduce the redundancy of the input data using a difference calculation between adjacent input elements. These values are then encoded using specified statistical modeling in an entropy encoder to produce compressed image and/or video data. Similar to the above, the technology of the present invention is superior to the technology described in the '526 patent, at least because it does not disclose generating motion vectors on the server based on predefined criteria and transmitting the generated motion vectors and one or more invalidity indicators to the client, which caches these motion vectors and invalidation pointers. It also does not disclose the server issuing a command to the client to receive input from the user, nor the use of that input to match cached motion vectors or invalidity indicators, which vectors or invalidity indicators are used in motion compensation. The technology of the present invention is also superior to this technology because it reduces the latency between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0014] В патенте США №8873636 В2 («патент '636») раскрывается сервер распределения динамических изображений (например, на котором запущена онлайн-игра), который подает кодированные данные изображения на ПК пользователя, на котором запущена локальная копия игры. Для выполнения этого процесса в соответствующих деталях ЦП (центральный процессор) в ПК (персональный компьютер) пользователя указывает область, на которую следует ссылаться, для декодирования вектора движения, связанного с выбранным блоком на экране предшествующего кадра. Это осуществляется за счет отсылки к вектору движения, связанному с выбранным блоком (вектору, который включен в информацию предварительной обработки, которую он обеспечивает), и извлекает изображение этой области в качестве эталонного изображения. Как и в случае с другими упоминаемыми документами, технология согласно настоящему изобретению превосходит технологию, описанную в патенте '636, по меньшей мере потому, что в нем не раскрыты генерирование векторов движения на сервере на основании предварительно определенных критериев и передача сгенерированных векторов движения и одного или нескольких указателей недействительности клиенту, который осуществляет кеширование этих векторов движения и указателей недействительности. Кроме того, в нем не раскрыты отдача сервером команды клиенту на прием ввода от пользователя, а также использование этого ввода для сопоставления кешированных векторов движения или указателей недействительности, причем эти векторы или указатели недействительности используются при компенсации движения. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0014] US Pat. No. 8,873,636 B2 (the '636 patent) discloses a dynamic image distribution server (eg, running an online game) that supplies encoded image data to a user's PC running a local copy of the game. To carry out this process in the corresponding parts, the CPU (Central Processing Unit) in the user's PC (Personal Computer) specifies the area to be referenced for decoding the motion vector associated with the selected block on the screen of the previous frame. This is done by referring to the motion vector associated with the selected block (a vector that is included in the preprocessing information it provides) and retrieving an image of that region as a reference image. As with other referenced documents, the technology of the present invention is superior to the technology described in the '636 patent, at least because it does not disclose generating motion vectors on a server based on predefined criteria and transmitting the generated motion vectors and one or more several invalidation indicators to the client, which caches these motion vectors and invalidation indicators. It also does not disclose the server issuing a command to the client to receive input from the user, nor the use of that input to match cached motion vectors or invalidity indicators, which vectors or invalidity indicators are used in motion compensation. The technology of the present invention is also superior to this technology because it reduces the latency between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0015] В международной публикации патента № WO2009138878 А2 («публикация '878») раскрыты обработка и потоковая передача множества интерактивных приложений в централизованном сервере приложений потоковой передачи с управлением уровнями детализации и постфильтрации различных отрендеренных объектов. В этой системе централизованный сервер интерактивных приложений на своем видеопроцессоре предварительной обработки выполняет пространственную и временную фильтрацию последовательности кадров перед кодированием сжатого потока аудиовизуального содержимого, поступающего на клиентские устройства, которые декодируют сжатый поток и отображают содержимое. Командный процессор ГП (графический процессор) централизованного сервера интерактивных приложений содержит модуль, который также вычисляет оценку компенсации движения для каждого макроблока в целевом кодированном кадре в видеокодере. Тем не менее, технология согласно настоящему изобретению по-прежнему превосходит технологию, описанную в публикации '878, по меньшей мере потому, что в нем не раскрыты генерирование векторов движения на сервере на основании предварительно определенных критериев и передача сгенерированных векторов движения и одного или нескольких указателей недействительности клиенту, который осуществляет кеширование этих векторов движения и указателей недействительности. Кроме того, в нем не раскрыты отдача сервером команды клиенту на прием ввода от пользователя, а также использование этого ввода для сопоставления кешированных векторов движения или указателей недействительности, причем эти векторы или указатели недействительности используются при компенсации движения. Технология согласно настоящему изобретению также превосходит эту технологию, поскольку она уменьшает задержку между вводом и обратной связью, которая существенно уменьшается за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0015] International Patent Publication No. WO2009138878 A2 (“'878 Publication”) discloses the processing and streaming of multiple interactive applications in a centralized streaming application server with control over the levels of detail and post-filtering of various rendered objects. In this system, a centralized interactive application server uses its video pre-processor to spatially and temporally filter a sequence of frames before encoding a compressed stream of audiovisual content to client devices, which decode the compressed stream and display the content. The GPU (graphics processing unit) command processor of the centralized interactive application server contains a module that also calculates a motion compensation estimate for each macroblock in the target coded frame in the video encoder. However, the technology of the present invention is still superior to the technology described in the '878 publication, at least because it does not disclose generating motion vectors on a server based on predefined criteria and transmitting the generated motion vectors and one or more indicators invalidation to the client, which caches these motion vectors and invalidation pointers. It also does not disclose the server issuing a command to the client to receive input from the user, nor the use of that input to match cached motion vectors or invalidity indicators, which vectors or invalidity indicators are used in motion compensation. The technology of the present invention is also superior to this technology because it reduces the latency between input and feedback, which is significantly reduced by using motion compensation based on player input instead of waiting for the video output signal to be returned from the server.

[0016] В патенте США №9358466 В2 («патент '466») раскрывается улучшение характеристик видеоигр посредством повторного использования кешированных данных. Раскрытые системы оценивают характеристики кеш-памяти для разных сгенерированных миссий видеоигры по меньшей мере частично за счет идентификации используемых цифровых активов и определения того, хранятся ли идентифицированные цифровые активы в кеш-памяти. Показатели кеш-памяти могут быть вычислены на основании скорости повторного использования кеш-памяти, соответствующей пропорции цифровых активов для миссии, которые уже находятся в кеш-памяти. Другие методики для генерирования показателей кеш-памяти могут учитывать такие факторы, как общие размер комбинации цифровых активов для миссии, которые уже находятся в кеш-памяти, и/или общий размер комбинации цифровых активов для миссии, которые уже не находятся в кеш-памяти. За счет кеширования данных таким образом, запросы этих данных и других некешированных данных становятся более эффективными. Технология согласно настоящему изобретению по-прежнему превосходит технологию, описанную в патенте '466, по меньшей мере потому, что в нем не раскрыты кеширование повторяющихся векторов движения, вычисление оценки движения исходя из данных ввода или обновление сохраненной библиотеки векторов движения на основании данных ввода, вследствие чего клиент может использовать сохраненную библиотеку векторов движения для инициации движения перед приемом актуальных данных вектора движения от сервера.[0016] US Patent No. 9358466 B2 (the '466 patent) discloses improving the performance of video games by reusing cached data. The disclosed systems evaluate cache characteristics for different generated video game missions at least in part by identifying the digital assets being used and determining whether the identified digital assets are stored in the cache. Cache metrics can be calculated based on the cache reuse rate corresponding to the proportion of digital assets for the mission that are already in the cache. Other techniques for generating cache metrics may consider factors such as the total size of the combination of digital assets for the mission that are already in cache, and/or the total size of the combination of digital assets for the mission that are not already in cache. By caching data in this way, queries for that data and other uncached data become more efficient. The technology of the present invention is still superior to the technology described in the '466 patent, at least because it does not disclose caching repeated motion vectors, calculating a motion estimate from input data, or updating a stored motion vector library based on input data, due to whereby the client can use a stored motion vector library to initiate motion before receiving the actual motion vector data from the server.

[0017] В патенте США №6903662 В2 («патент '662») раскрывается настраиваемое компьютерное устройство ввода, которое, в частности, кеширует данные ввода для поддержания более короткого времени отклика. Система сопоставляет нажатие на клавиши с внутренним запоминающим устройством (или кеш-памятью) для определения того, была ли ранее идентифицирована конкретная клавиша. Если система не была связана с этой клавишей ранее, система может извлекать данные, соответствующие вводу, из памяти клавиши. Система затем обновляет свое внутреннее запоминающее устройство (кеш-память) с внесением идентификатора клавиши и соответствующих данных. Система затем может отправлять данные ввода от клавиши на главный компьютер. Однако в следующий раз, когда система сталкивается с этой клавишей в нажатом состоянии, она может обратиться к собственному запоминающему устройству (кеш-памяти) вместо извлечения того же кода опроса из памяти клавиши снова. Технология согласно настоящему изобретению превосходит технологию, описанную в патенте '662, по меньшей мере потому, что в нем не раскрыты кеширование повторяющихся векторов движения, вычисление оценки движения исходя из данных ввода или обновление сохраненной библиотеки векторов движения на основании данных ввода, вследствие чего клиент может использовать сохраненную библиотеку векторов движения для инициации движения перед приемом актуальных данных вектора движения от сервера.[0017] US Pat. No. 6,903,662 B2 (the '662 patent) discloses a configurable computer input device that, among other things, caches input data to support faster response times. The system compares keystrokes to internal storage (or cache) to determine whether a particular key has previously been identified. If the system has not previously been associated with the key, the system can retrieve data corresponding to the input from the key's memory. The system then updates its internal storage (cache) with the key ID and associated data. The system can then send the key input data to the host computer. However, the next time the system encounters that key in a pressed state, it can access its own memory (cache) instead of retrieving the same poll code from the key's memory again. The technology of the present invention is superior to the technology described in the '662 patent, at least because it does not disclose caching repeated motion vectors, calculating motion estimates from input data, or updating a stored motion vector library based on input data, whereby the client can use a stored motion vector library to initiate motion before receiving the latest motion vector data from the server.

[0018] В патенте Японии № JP6129865B2 («патент '865») раскрываются системы и способы передачи данных отрендеренного игрового содержимого для подмножеств сегментов пути на игрового клиента для сохранения на локальной кеш-памяти, вследствие чего данные игрового содержимого могут быть доступны при необходимости во время игрового процесса в режиме реального времени. Опять-таки, технология согласно настоящему изобретению превосходит технологию, описанную в патенте '865, по меньшей мере потому, что в нем не раскрыты кеширование повторяющихся векторов движения, вычисление оценки движения исходя из данных ввода или обновление сохраненной библиотеки векторов движения на основании данных ввода, вследствие чего клиент может использовать сохраненную библиотеку векторов движения для инициации движения перед приемом актуальных данных вектора движения от сервера.[0018] Japanese Patent No. JP6129865B2 (the '865 Patent) discloses systems and methods for transmitting rendered game content data for subsets of path segments to a game client for storage in a local cache, whereby the game content data can be accessed when needed in real-time gameplay time. Again, the technology of the present invention is superior to the technology described in the '865 patent, at least because it does not disclose caching repeated motion vectors, calculating a motion estimate from input, or updating a stored motion vector library from input. whereby the client can use the stored motion vector library to initiate movement before receiving the actual motion vector data from the server.

[0019] В патенте США №9762919 («патент '919») раскрываются системы и способы кеширования эталонных данных в схеме обработки блоков. Технология в патенте '919 касается кеш-памяти (например, полностью ассоциативной кеш-памяти), которая может быть реализована, например, в локальном (относительно схемы) запоминающем устройстве, таком как SRAM (статическое оперативное запоминающее устройство), в которое части эталонных данных о цветности (например, 64-байтовые блоки запоминающего устройства), соответствующие векторам движения, определенным для макроблоков на более ранних стадиях схемы, могут быть предварительно загружены из запоминающего устройства. Кеш-логика цветности может поддерживать кеш-память, и может проходить по нескольким стадиям схемы. Загрузки векторов движения заданного макроблока, проходящие через схему, могут быть инициированы кеш-логикой цветности на одну или несколько стадий перед стадией компенсации движения цветности для предоставления времени (т.е. нескольких циклов схемы) для считывания соответствующих блоков запоминающего устройства из запоминающего устройства и записи в кеш-память перед тем, как они потребуются для компенсации движения цветности. Однако настоящее изобретение превосходит патент '919. Технология согласно настоящему изобретению превосходит технологию, описанную в патенте '919, по меньшей мере потому, что в нем не раскрыты кеширование повторяющихся векторов движения, вычисление оценки движения исходя из данных ввода или обновление сохраненной библиотеки векторов движения на основании данных ввода, вследствие чего клиент может использовать сохраненную библиотеку векторов движения для инициации движения перед приемом актуальных данных вектора движения от сервера.[0019] US Pat. No. 9,762,919 (the '919 patent) discloses systems and methods for caching reference data in a block processing scheme. The technology in the '919 patent concerns a cache memory (e.g., a fully associative cache memory), which can be implemented, for example, in a local (with respect to the circuit) memory device, such as SRAM (static random access memory), in which parts of the reference data chroma (eg, 64-byte memory blocks) corresponding to motion vectors defined for macroblocks in earlier circuit stages may be preloaded from memory. Chroma cache logic can support cache memory, and can pass through multiple stages of the circuit. Loads of a given macroblock's motion vectors through the circuit may be initiated by the chroma cache logic one or more stages before the chrominance motion compensation stage to provide time (i.e., several circuit cycles) to read the corresponding storage blocks from the storage device and write into the cache before they are needed to compensate for chroma motion. However, the present invention is superior to the '919 patent. The technology of the present invention is superior to the technology described in the '919 patent, at least because it does not disclose caching repeated motion vectors, calculating motion estimates from input data, or updating a stored motion vector library based on input data, whereby the client can use a stored motion vector library to initiate motion before receiving the latest motion vector data from the server.

[0020] Как очевидно из приведенного выше описания уровня техники в этой технологии, в данной области техники существует необходимость в улучшении существующей компьютерной технологии, связанной с кодированием игровых сред в режиме реального времени.[0020] As is apparent from the above description of the prior art of this technology, there is a need in the art for improving existing computer technology associated with encoding gaming environments in real time.

Краткое раскрытие настоящего изобретенияBrief Disclosure of the Present Invention

[0021] Таким образом, целью настоящего изобретения является предоставление систем и способов уменьшения задержки за счет методик компенсации движения, в которых клиентское устройство использует таблицы поиска, переданные от сервера, для сопоставления ввода пользователя с векторами движения, а также маркировки и суммирования этих векторов движения. Когда удаленный сервер передает кодированные видеокадры клиенту, клиент декодирует эти видеокадры и применяет суммированные векторы движения к декодированным кадрам для оценки движения в этих кадрах.[0021] Thus, it is an object of the present invention to provide systems and methods for reducing latency through motion compensation techniques in which a client device uses lookup tables transmitted from a server to match user input to motion vectors, and to mark and summarize those motion vectors . When the remote server transmits encoded video frames to the client, the client decodes those video frames and applies summed motion vectors to the decoded frames to estimate the motion in those frames.

[0022] Другой целью настоящего изобретения является предоставление систем и способов, в которых кодированные видеокадры декодируют без обработки остаточных кадров.[0022] Another object of the present invention is to provide systems and methods in which encoded video frames are decoded without processing residual frames.

[0023] Еще одной целью настоящего изобретения является предоставление систем и способов уменьшения задержки за счет методик компенсации движения, в которых клиент применяет одну или нескольких функций сглаживания к суммированным маркированным векторам движения в очереди.[0023] Another object of the present invention is to provide systems and methods for reducing latency through motion compensation techniques in which a client applies one or more smoothing functions to summed labeled motion vectors in a queue.

[0024] Еще одной целью настоящего изобретения является предоставление систем и способов уменьшения задержки за счет методик компенсации движения, в которых маркеры, связанные с векторами движения на клиентском устройстве, являются хронологическими по своей сути.[0024] Another object of the present invention is to provide systems and methods for reducing latency through motion compensation techniques in which markers associated with motion vectors on a client device are chronological in nature.

[0025] Другой целью настоящего изобретения является предоставление систем и способов уменьшения задержки между вводом и обратной связью за счет генерирования векторов движения на сервере на основании предварительно определенных критериев и передачи сгенерированных векторов движения и одного или нескольких указателей недействительности клиенту, который осуществляет кеширование этих векторов движения и указателей недействительности. Сервер отдает клиенту команду на прием ввода от пользователя и использование этого ввода для сопоставления с кешированными векторами движения или указателями недействительности. На основании этого сравнения клиент затем применяет сопоставленные векторы движения или указатели недействительности для осуществления компенсации движения в графическом интерфейсе.[0025] Another object of the present invention is to provide systems and methods for reducing latency between input and feedback by generating motion vectors on a server based on predefined criteria and transmitting the generated motion vectors and one or more invalidation indicators to a client, which caches these motion vectors and invalidity indicators. The server instructs the client to accept input from the user and use that input to match cached motion vectors or invalidity pointers. Based on this comparison, the client then applies the mapped motion vectors or invalidation pointers to perform motion compensation in the GUI.

[0026] Другой целью настоящего изобретения является предоставление систем и способов уменьшения задержки между вводом и обратной связью за счет кеширования векторов движения в таблице поиска.[0026] Another object of the present invention is to provide systems and methods for reducing latency between input and feedback by caching motion vectors in a lookup table.

[0027] Еще одной целью настоящего изобретения является предоставление систем и способов уменьшения задержки между вводом и обратной связью за счет связывания указателей недействительности с одним или несколькими кешированными векторами движения.[0027] Another object of the present invention is to provide systems and methods for reducing latency between input and feedback by associating invalidation indicators with one or more cached motion vectors.

[0028] Другой целью настоящего изобретения является предоставление систем и способов уменьшения задержки между вводом и обратной связью за счет отдачи клиенту команды на удаление одного или нескольких кешированных векторов движения, если ввод сопоставлен с кешированным указателем недействительности, связанным с одним или несколькими векторами движения.[0028] Another object of the present invention is to provide systems and methods for reducing latency between input and feedback by instructing a client to delete one or more cached motion vectors if the input is associated with a cached invalidation indicator associated with one or more motion vectors.

[0029] Еще одной целью настоящего изобретения является предоставление систем и способов уменьшения задержки за счет кеширования повторяющихся векторов движения на сервере, который передает ранее сгенерированную библиотеку векторов движения клиенту. Клиент сохраняет библиотеку векторов движения и отслеживает данные ввода пользователя. Сервер отдает клиенту команду на вычисление оценки движения исходя из данных ввода и отдает клиенту команду на обновление сохраненной библиотеки векторов движения на основании данных ввода, вследствие чего клиент применяет сохраненную библиотеку векторов движения для инициации движения в графическом интерфейсе перед приемом актуальных данных вектора движения от сервера.[0029] Another object of the present invention is to provide systems and methods for reducing latency by caching repeated motion vectors on a server that delivers a previously generated library of motion vectors to a client. The client stores a library of motion vectors and tracks user input data. The server instructs the client to calculate a motion estimate from the input data and instructs the client to update the stored motion vector library based on the input data, whereby the client uses the stored motion vector library to initiate motion in the GUI before receiving the actual motion vector data from the server.

[0030] Другой целью настоящего изобретения является предоставление систем и способов уменьшения задержки за счет кеширования повторяющихся векторов движения, в которых сервер передает обновление контекста клиенту для запрещения применения сохраненной библиотеки векторов движения.[0030] Another object of the present invention is to provide systems and methods for reducing latency by caching repeated motion vectors, in which the server transmits a context update to the client to disable the use of a stored motion vector library.

[0031] Еще одной целью настоящего изобретения является предоставление систем и способов уменьшения задержки за счет кеширования повторяющихся векторов движения, в которых один или несколько коэффициентов масштабирования применяют к библиотеке векторов движения.[0031] Another object of the present invention is to provide systems and methods for reducing latency by caching repeated motion vectors in which one or more scaling factors are applied to a library of motion vectors.

Краткое описание фигурBrief description of the figures

[0032] Более полное понимание настоящего изобретения и многих сопутствующих его преимуществ будет легко получено, поскольку оно станет более понятным при обращении к следующему подробному описанию, рассматриваемому со ссылкой на прилагаемые фигуры, на которых:[0032] A more complete understanding of the present invention and its many attendant advantages will be readily gained as it becomes clearer by reference to the following detailed description, taken in conjunction with the accompanying drawings, in which:

[0033] на фиг. 1 показана структурная схема, на которой в иллюстративных целях изображена удаленная игровая система, в которой видеоигра запущена на сервере и управляется посредством ввода на удаленном клиенте;[0033] in FIG. 1 is a block diagram illustrating, for illustrative purposes, a remote gaming system in which a video game is running on a server and controlled by input on a remote client;

[0034] на фиг. 2 показана блок-схема, в иллюстративных целях описывающая уменьшение задержки между вводом и обратной связью в потоковой передаче игр за счет применения компенсации движения для соответствующего ввода игрока;[0034] in FIG. 2 is a block diagram for illustrative purposes describing the reduction of latency between input and feedback in game streaming by applying motion compensation to the corresponding player input;

[0035] на фиг. 3 показана структурная схема, на которой в иллюстративных целях изображен приведенный в качестве примера момент во время исполнения среды потоковой передачи видеоигры, в который используется компенсация движения на основании ввода игрока;[0035] in FIG. 3 is a block diagram showing, for illustrative purposes, an exemplary point during execution of a video game streaming environment at which motion compensation is used based on player input;

[0036] на фиг. 4 показана схема, на которой в иллюстративных целях изображен приведенный в качестве примера макроблок во время компенсации движения на основании ввода игрока согласно фиг. 3;[0036] in FIG. 4 is a diagram showing, for illustrative purposes, an exemplary macroblock during motion compensation based on player input in FIG. 3;

[0037] на фиг. 5 показана схема, на которой в иллюстративных целях изображен альтернативный способ применения векторов движения во время компенсации движения на основании ввода игрока на клиенте;[0037] in FIG. 5 is a diagram illustrating, for illustrative purposes, an alternative method of applying motion vectors during motion compensation based on player input on a client;

[0038] на фиг. 6А, 6В и 6С показан приведенный в качестве примера макроблок, подвергающийся компенсации движения на основании ввода игрока и наложению для альтернативного способа, показанного на фиг. 5;[0038] in FIG. 6A, 6B and 6C show an exemplary macroblock undergoing motion compensation based on player input and overlay for the alternative method shown in FIG. 5;

[0039] на фиг. 7 показана схема, изображающая генерирование прогнозируемых векторов движения во время исполнения;[0039] in FIG. 7 is a diagram depicting generation of predicted motion vectors during execution;

[0040] на фиг. 8 показана блок-схема, в иллюстративных целях изображающая передачу и хранение на стороне клиента прогнозируемых векторов движения с целью компенсации движения на основании ввода игрока;[0040] in FIG. 8 is a block diagram illustratively depicting the transmission and client-side storage of predicted motion vectors for the purpose of motion compensation based on player input;

[0041] на фиг. 9 показана схема, изображающая приведенный в качестве примера процесс определения недействительности прогнозируемых векторов движения;[0041] in FIG. 9 is a diagram illustrating an exemplary process for determining the invalidity of predicted motion vectors;

[0042] на фиг. 10 показана схема, изображающая приведенный в качестве примера способ генерирования библиотеки векторов движения и приведенной в качестве примера библиотеки повторяющихся векторов движения для кеширования;[0042] in FIG. 10 is a diagram showing an exemplary method for generating a motion vector library and an exemplary repeating motion vector library for caching;

[0043] на фиг. 11 показана блок-схема, на которой в иллюстративных целях изображен процесс кеширования, применения и обновления библиотек векторов движения для компенсации движения на основании ввода игрока;[0043] in FIG. 11 is a flowchart illustrative of the process of caching, applying, and updating motion vector libraries for motion compensation based on player input;

[0044] на фиг. 12 показана схема, на которой в иллюстративных целях изображен способ обновления соответствия векторов движения; и[0044] in FIG. 12 is a diagram illustrating a method for updating motion vector correspondence for illustrative purposes; And

[0045] на фиг. 13 показана схема, на которой изображено приведенная в качестве примера модификация применения многокадровых векторов движения во время компенсации движения на основании ввода игрока, в частности, в случае кешированных векторов движения.[0045] in FIG. 13 is a diagram illustrating an exemplary modification of the use of multi-frame motion vectors during motion compensation based on player input, particularly in the case of cached motion vectors.

Подробное раскрытие предпочтительных вариантов осуществленияDetailed Disclosure of Preferred Embodiments

[0046] При описании предпочтительных вариантов осуществления настоящего изобретения, изображенных на фигурах, для ясности будет использоваться конкретная терминология. Однако настоящее изобретение не ограничивается конкретными выбранными терминами, и следует понимать, что каждый конкретный термин включает в себя все технические эквиваленты, функционирующие аналогичным образом для выполнения подобной цели. Несколько предпочтительных вариантов осуществления настоящего изобретения будут описаны в иллюстративных целях, но следует понимать, что настоящее изобретение может быть реализовано в других формах, не показанных на фигурах.[0046] In describing the preferred embodiments of the present invention depicted in the figures, specific terminology will be used for clarity. However, the present invention is not limited to the specific terms selected, and it should be understood that each specific term includes all technical equivalents that function in a similar manner to accomplish a similar purpose. Several preferred embodiments of the present invention will be described for illustrative purposes, but it should be understood that the present invention may be embodied in other forms not shown in the figures.

[0047] Определенные типы ввода игрока являются лучшими вариантами для компенсации движения на основании ввода игрока. На пригодность заданного ввода влияет два фактора: чувствительность игрока к задержке между вводом и обратной связью и сложность реализации компенсации движения на основании ввода игрока без внесения заметных артефактов. Каждый ввод должен оцениваться на пригодность. Например, в шутере от первого лица игрок очень чувствителен к повороту обзора, осуществляемому мышкой, то есть задержка в долю секунды, всего лишь 16 мс, между вводом игрока и выходным видеосигналом будет заметной. Однако в той же ситуации поворот обзора, осуществляемый геймпадом, как правило, медленнее, и игроки могут быть менее чувствительными к задержке между вводом и обратной связью. Поворот обзора может быть приблизительно оценен за счет сдвига сцены в направлении, противоположном направлению поворота, но возможно появление нежелательных артефактов вдоль края изображения в направлении поворота. При небольших поворотах обзора, например при корректировке прицела на находящемся на экране враге, игроки могут даже не заметить артефактов на краю. В другом примере ускорение машины в гоночной игре может обладать низким приоритетом для компенсации движения на основании ввода игрока из-за отсутствия чувствительности игрока и/или инерции к задержке, но вводы, связанные с поворотом и торможением, могут обладать высоким приоритетом, поскольку игроки заметят задержку между вводом и обратной связью.[0047] Certain types of player input are better options for compensating for motion based on player input. The suitability of a given input is influenced by two factors: the player's sensitivity to the delay between input and feedback, and the difficulty of implementing motion compensation based on the player's input without introducing noticeable artifacts. Each input must be assessed for suitability. For example, in a first-person shooter game, the player is very sensitive to the rotation of the view performed by the mouse, meaning a split second delay, just 16 ms, between the player's input and the video output will be noticeable. However, in the same situation, view rotation performed by a gamepad tends to be slower, and players may be less sensitive to the delay between input and feedback. View rotation can be approximated by shifting the scene in the opposite direction to the rotation direction, but unwanted artifacts may appear along the edge of the image in the direction of rotation. During small rotations of view, such as when adjusting the crosshair on an on-screen enemy, players may not even notice the artifacts on the edge. In another example, accelerating a car in a racing game may have low priority to compensate for motion based on player input due to lack of player sensitivity and/or inertia to latency, but inputs related to turning and braking may have high priority because players will notice the latency between input and feedback.

[0048] Время между приемом ввода игрока и отображением вывода движения представляет собой задержку между вводом игрока и обратной связью. За счет использования компенсации движения оцененное движение может обеспечивать обратную связь практически сразу, несмотря на ожидание обработки сервером ввода игрока. Таким образом, задержка между вводом игрока и обратной связью существенно уменьшается при потоковой передаче игр. За счет реализации компенсации движения на основании ввода игрока при потоковой передаче игр оценка движения может быть обеспечена в следующем доступном кадре. В отличие от этого, поступление ввода на сервер, создание выходного кадра и возврат занимают несколько кадров. Компенсация движения на основании ввода игрока также может обеспечивать некоторое преимущество в традиционных «непотоковых» играх, в которых игровой движок и рендерер могут испытывать задержку между вводом игрока и обратной связью в несколько кадров.[0048] The time between receiving player input and displaying motion output represents the delay between player input and feedback. By using motion compensation, estimated motion can provide feedback almost immediately, despite waiting for the server to process player input. Thus, the latency between player input and feedback is significantly reduced when streaming games. By implementing motion compensation based on player input when streaming games, motion estimation can be provided in the next available frame. In contrast, input arriving at the server, creating an output frame, and returning takes several frames. Motion compensation based on player input can also provide some benefit in traditional "non-streaming" games, where the game engine and renderer may experience a delay of several frames between player input and feedback.

[0049] Клиент не будет обладать соответствующим контекстом для отслеживания перемещения объекта относительно экрана. Компенсация движения на основании ввода игрока не подходит для случаев, когда местоположение конкретных макроблоков или видеообъектов неизвестно клиенту. Например, в 2D-платформере персонаж может перемещать по экрану слева направо. Клиент не будет знать, где персонаж расположен, когда игрок нажимает ввод, связанный с прыжком; таким образом, компенсация движения на основании ввода игрока сама по себе не может использоваться в этом случае для уменьшения задержки между вводом и обратной связью.[0049] The client will not have the appropriate context to track the object's movement relative to the screen. Motion compensation based on player input is not suitable for cases where the location of specific macroblocks or video objects is unknown to the client. For example, in a 2D platformer, a character can move across the screen from left to right. The client will not know where the character is located when the player presses the jump input; thus, motion compensation based on player input alone cannot be used in this case to reduce the delay between input and feedback.

[0050] В целом, векторы движения для компенсации движения на основании ввода игрока должны генерироваться заранее. Для такого движения, как поворот камеры игроком, векторы движения могут быть вычислены на основании того, как игра определяет весовой коэффициент ввода. Согласно некоторым вариантам осуществления векторы движения могут представлять собой значение ввода, умноженное на весовой коэффициент чувствительности. Для движения, которое нельзя вычислить непосредственно, такое как анимированное движение, анимация может быть запущена во время разработки, вследствие чего векторы движения могут быть непосредственно измерены и сохранены. Измерение векторов движения может быть осуществлено посредством тех же методик оценки движения, которые выполняются во время кодирования по стандарту Н.264.[0050] In general, motion vectors for motion compensation based on player input must be generated in advance. For a motion such as the player turning the camera, motion vectors can be calculated based on how the game determines the weighting of the input. In some embodiments, the motion vectors may be an input value multiplied by a sensitivity weight. For motion that cannot be directly calculated, such as animated motion, animation can be started at design time so that motion vectors can be directly measured and stored. Measuring motion vectors can be accomplished using the same motion estimation techniques performed during H.264 encoding.

[0051] На фиг. 1 изображена приведенная в качестве примера система, в которой видеоигра управляется удаленным клиентом. В этой системе на сервере 100 размещено программное обеспечение 102 видеоигры и графический движок 104, который осуществляет рендеринг выходного видеосигнала. Видео кодируется в кодеке (также называемом кодирующим движком или кодером) 106, и кодированные видеоданные 108 передаются на удаленный клиент. Серверная архитектура 100 может представлять собой любую комбинацию программного или аппаратного обеспечения, которое может поддерживать функции как графического движка 104, так и кодека 106. В приведенном примере графический движок 104 может быть реализован в виде, например, ГП НО, управляемого программным обеспечением 102 видеоигры, загруженным в некоторое машиночитаемое запоминающее устройство 112, при этом кодек 106 может быть реализован в виде ЦП 114, на котором запущено программное обеспечение для кодирования видео.[0051] In FIG. 1 depicts an exemplary system in which a video game is controlled by a remote client. In this system, a server 100 hosts video game software 102 and a graphics engine 104 that renders the video output. The video is encoded in a codec (also called encoding engine or encoder) 106, and the encoded video data 108 is transmitted to the remote client. The server architecture 100 may be any combination of software or hardware that can support the functions of both the graphics engine 104 and the codec 106. In the example shown, the graphics engine 104 may be implemented as, for example, a HO GPU controlled by video game software 102, loaded into some computer readable storage device 112, wherein the codec 106 may be implemented as a CPU 114 running video encoding software.

[0052] Удаленный клиент состоит из компьютерной системы 116, выполненной с возможностью запуска кодека 118 на стороне клиента для декодирования передаваемых кодированных видеоданных 108 и клиентского приложения 120 для применения компенсации движения на основании ввода игрока. Компьютерная система 116 клиента также содержит контроллер 122 дисплея для управления аппаратным обеспечением 124 дисплея. Ввод от периферийных устройств 126 ввода на стороне клиента преобразуется клиентским приложением 120 в управляющие данные 128, которые передаются обратно на программное обеспечение 102 игры, запущенное на сервере 100. Ввод от периферийных устройств 126 также используется для определения того, какую компенсацию движения на основании ввода игрока следует применить, если вообще стоит, как изображено более подробно на фиг. 2.[0052] The remote client consists of a computer system 116 configured to run a client-side codec 118 to decode the transmitted encoded video data 108 and a client application 120 to apply motion compensation based on player input. Client computer system 116 also includes a display controller 122 for controlling display hardware 124 . Input from client-side input peripherals 126 is converted by client application 120 into control data 128, which is passed back to game software 102 running on server 100. Input from peripherals 126 is also used to determine how much motion compensation based on player input. should be applied, if at all, as shown in more detail in Fig. 2.

[0053] На фиг. 2 показана блок-схема, описывающая стадии, необходимые для выполнения компенсации движения на основании ввода игрока для одного ввода. Когда клиент запускается, сервер отправляет таблицу поиска, содержащую вводы и их связанные векторы движения, на стадии 200, которую затем кеширует клиент на стадии 202. В этом варианте исполнения клиент является общим устройством, обслуживающим потребности множества потоковых игр. Согласно некоторым вариантам осуществления характерный для игры клиент может пропускать стадии 200 и 202, поскольку он уже содержит таблицу поиска для игры. В альтернативном варианте исполнения характерный для игры клиент может постоянно хранить таблицу поиска векторов движения без необходимости в кешировании от сервера.[0053] In FIG. 2 is a flowchart describing the steps required to perform motion compensation based on player input for one input. When the client starts, the server sends a lookup table containing the inputs and their associated motion vectors at step 200, which is then cached by the client at step 202. In this embodiment, the client is a general device serving the needs of multiple streaming games. In some embodiments, the game-specific client may skip steps 200 and 202 because it already contains a lookup table for the game. In an alternative embodiment, a game-specific client may persistently store a motion vector lookup table without the need for caching from the server.

[0054] Когда клиент принимает ввод игрока от устройства ввода, такого как мышь или геймпад на стадии 204, клиентское приложение проверяет кешированную таблицу поиска векторов движения на наличие соответствующих вводов на стадии 206. Если соответствующего ввода игрока нет, клиент не совершает дополнительных действий и отправляет ввод на сервер без дополнительно модификации. Если в кеш-памяти есть соответствующий ввод игрока, клиент применяет компенсацию движения на основании ввода игрока. Необязательно кеш-память может быть выполнена с возможностью изменения записей в таблице поиска на основании ввода игрока. Например, когда игрок нажимает кнопку «пауза», все вводы игрока, связанные с движением, должны быть запрещены, пока игрок не выйдет из экрана паузы. В одном варианте исполнения управляемая клиентом таблица поиска может характеризоваться наличием двух наборов вводов: один для использования в меню паузы, и один для использования вне меню паузы, которые переключаются, предпочтительно клиентом, каждый раз, когда игрок выбирает ввод, связанный с паузой. В альтернативном варианте исполнения сервер может переключать содержимое кешированной таблицы поиска на клиенте.[0054] When the client receives player input from an input device such as a mouse or gamepad at step 204, the client application checks the cached motion vector lookup table for matching inputs at step 206. If there is no matching player input, the client takes no further action and sends input to the server without additional modification. If there is a matching player input in the cache, the client applies motion compensation based on the player input. Optionally, the cache memory may be configured to change entries in the lookup table based on player input. For example, when a player presses the pause button, all player inputs related to movement should be disabled until the player exits the pause screen. In one embodiment, the client-controlled lookup table may be characterized by having two sets of inputs: one for use in the pause menu, and one for use outside the pause menu, which are switched, preferably by the client, each time the player selects an input associated with the pause. In an alternative embodiment, the server may switch the contents of a cached lookup table on the client.

[0055] Когда клиентское приложение принимает ввод игрока для компенсации движения, клиент добавляет маркер к вводу игрока и связанным с ним векторам движения на стадии 208. Маркированный ввод отправляют на сервер на стадии 210. Маркер представляет собой любой идентификатор, который может соотнести ввод игрока с будущим кадром. Например, маркер может представлять собой целое число, которое увеличивается каждый раз, когда клиент принимает ввод, который будет использоваться для выполнения компенсации движения на основании ввода игрока. Маркер может быть добавлен в качестве метаданных в тот же сетевой пакет, что и ввод игрока, или отправлен по аналогичной схеме передачи, которая сохраняет маркерную информацию в синхронизации с информацией ввода. Клиент подтверждает, принят или нет маркер, на стадии 213. Когда ввод игрока маркирован и отправлен, клиент применяет векторы движения, содержащиеся в кешированной таблице поиска, на стадии 212. Эти векторы движения будут применяться к каждому входящему кадру до тех пор, пока маркер соотнесения не будет возвращен от сервера. Подробное описание приведенного в качестве примера способа применения этих векторов движения изображено на фиг. 3.[0055] When the client application receives the player's input for motion compensation, the client adds a token to the player's input and its associated motion vectors at step 208. The token input is sent to the server at step 210. The token is any identifier that can associate the player's input with future frame. For example, the token may be an integer that is incremented each time the client receives input that will be used to perform motion compensation based on the player's input. The token may be added as metadata in the same network packet as the player's input, or sent via a similar transmission scheme that keeps the token information in sync with the input information. The client confirms whether or not the token is accepted at step 213. When the player's input is tokenized and sent, the client applies the motion vectors contained in the cached lookup table at step 212. These motion vectors will be applied to each incoming frame as long as the mapping token will not be returned from the server. A detailed description of an exemplary method of using these motion vectors is shown in FIG. 3.

[0056] Когда сервер принимает маркированный ввод игрока, маркированный ввод игрока передается в игру, которая генерирует выходной кадр на стадии 214. Видеоизображение затем кодируют на стадии 216. Перед отправкой кодированного кадра назад клиенту, маркер ввода игрока прикрепляют к кодированному кадру на стадии 218. Это тот же маркер, который ранее был отправлен с вводом игрока, и он означает, что выходной кадр содержит актуальную обратную видеосвязь от ввода игрока. Прикрепление маркера к кодированному кадру может быть осуществлено за счет добавления маркера в качестве метаданных к тому же сетевому пакету, в котором находится кодированный кадр. Маркированный кодированный кадр отправляют назад клиенту на стадии 220. Когда клиент принимает кодированный кадр с маркером, клиент может соотносить маркер с предыдущей компенсацией движения на основании ввода игрока. Клиент затем прекращает применять предыдущую компенсацию движения на стадии 222.[0056] When the server receives the player's token input, the player's token input is sent to the game, which generates an output frame at step 214. The video image is then encoded at step 216. Before sending the encoded frame back to the client, the player's input token is attached to the encoded frame at step 218. This is the same token that was previously sent with the player's input, and it means that the output frame contains the actual video feedback from the player's input. Attaching a token to an encoded frame can be accomplished by adding the token as metadata to the same network packet that contains the encoded frame. The token encoded frame is sent back to the client at step 220. When the client receives the token encoded frame, the client may correlate the token with previous motion compensation based on the player's input. The client then stops applying the previous motion compensation at step 222.

[0057] На фиг. 3 показано изображение приведенного в качестве примера момента во время исполнения среды потоковой передачи видеоигры, в котором используется компенсация движения на основании ввода игрока. Когда клиент принимает какой-либо ввод игрока на стадии 300, он может быть сравнен с таблицей поиска векторов движения на стадии 302. Если есть соответствующий ввод игрока, связанные векторы движения будут использованы для компенсации движения на основании ввода игрока. Векторы движения маркируют на стадии 306 с помощью уникального маркера ввода на стадии 304. В этом примере выбранный маркер представляет собой целое число «1003». Маркированные векторы движения добавляют в очередь на стадии 308, содержащую любые другие маркированные векторы движения, используемые в настоящее время для компенсации движения на основании ввода игрока.[0057] In FIG. 3 shows an image of an exemplary moment during execution of a video game streaming environment in which motion compensation is used based on player input. When the client receives any player input at step 300, it may be compared to the motion vector lookup table at step 302. If there is matching player input, the associated motion vectors will be used to compensate for motion based on the player input. The motion vectors are marked at 306 with a unique input token at 304. In this example, the selected token is the integer "1003". The tagged motion vectors are added to a queue at step 308 containing any other tagged motion vectors currently used to compensate for motion based on player input.

[0058] Следующий кадр поступает в битовом потоке от сервера на стадии 320. Этот кадр маркируют с помощью уникального идентификатора на стадии 318, в этом случае целого числа «1001», которое указывает, что кадр содержит итоговое движение всех предыдущих вводов игрока вплоть до ввода, соответствующего маркеру «1001», и включая его. Маркер «1001» указывает клиенту, что он может прекратить применение компенсации движения на стадии 322 для этого маркированного ввода. Векторы движения с маркером «1001» затем удаляют из очереди маркированных векторов движения на стадии 308 вместе с любыми векторами движения с более ранними маркерами, которые могут оставаться в очереди в случае, если предыдущие пакеты были утеряны.[0058] The next frame arrives in the bitstream from the server at step 320. This frame is marked with a unique identifier at step 318, in this case the integer "1001", which indicates that the frame contains the resulting movement of all the player's previous inputs up to the input , corresponding to and including the marker “1001”. The token "1001" indicates to the client that it can stop applying motion compensation at step 322 for this token input. The motion vectors with token "1001" are then removed from the tagged motion vector queue at step 308, along with any motion vectors with earlier tokens that may remain in the queue if previous packets were lost.

[0059] Кодированное видео 316 декодируют на стадии 324. Вместе с тем, оставшиеся векторы движения в очереди векторов движения на стадии 308 суммируют на стадии 310. Векторы движения, как правило, представляют собой векторные поля с вектором для каждого макроблока в изображении. Для суммирования векторов движения векторы суммируют поэлементно, вследствие чего в результате получают векторное поле с вектором для каждого макроблока. Сумма двух векторных полей представляет собой сумму векторов для каждого точки в поле, вследствие чего сумма двух наборов векторов движения представляет собой сумму векторов для каждого макроблока в изображении. Сумма двух векторов определяется как покомпонентная сумма их компонентов, которая может быть представлена следующим образом: {u1, u₂}+{v₁, v₂}={u₁+v₁, u₂+v₂}. В этом примере два набора векторов движения с маркерами «1002» и «1003» содержится в очереди; эти два набора векторов движения суммируют. Маркеры являются хронологическими по своей сути, что позволяет клиенту знать порядок ранее маркированных вводов игрока. Это позволяет клиенту отбрасывать маркированные векторы движения вплоть до маркера возврата во входящем кадре, и включая его. Дополнительно, маркирование, описанное выше, является более дешевым с точки зрения вычислений, чем более сложные способы. Необязательные функции сглаживания могут быть применены в этот момент для предотвращения артефактов зажатия или ослабления подобных вносимых артефактов.[0059] The encoded video 316 is decoded at step 324. However, the remaining motion vectors in the motion vector queue at step 308 are summed at step 310. The motion vectors are typically vector fields with a vector for each macroblock in the image. To sum motion vectors, the vectors are summed element by element, resulting in a vector field with a vector for each macroblock. The sum of two vector fields is the sum of vectors for each point in the field, whereby the sum of two sets of motion vectors is the sum of vectors for each macroblock in the image. The sum of two vectors is defined as the component-wise sum of their components, which can be represented as follows: {u1, u ₂ }+{v ₁ , v ₂ }={u ₁ +v ₁ , u ₂ +v ₂ }. In this example, two sets of motion vectors with markers "1002" and "1003" are contained in the queue; these two sets of motion vectors are summed. Markers are chronological in nature, allowing the client to know the order of the player's previously marked inputs. This allows the client to discard marked motion vectors up to and including the return marker in the incoming frame. Additionally, the marking described above is computationally cheaper than more complex methods. Optional smoothing functions can be applied at this point to prevent clamping artifacts or reduce such introduced artifacts.

[0060] Артефакты зажатия вносятся, когда макроблоки перемещаются за пределы экрана, и проявляются как смазывание цвета пикселя перпендикулярно краю экрана. Приведенная в качестве примера функция сглаживания уменьшает величину направленных наружу векторов движения, когда они приближаются к краю изображения. Необходимо ослабить только направленный наружу компонент, компонент у для направленных наружу векторов в направлении верхнего и нижнего краев изображения, и компонент х для направленных наружу векторов в направлении левого и правого краев изображения. Для векторов, которые направлены к границе, компонент вектора может быть умножен на квадрат расстояния до края, вследствие чего при приближении к нулю расстояния до границы, компонент вектора будет приближаться к нулю. В этом примере направленный наружу вектор в направлении правого края изображения будет преобразован из {х,у} в {x*d*d,y}, где d - расстояние от края. Это ослабит артефакты зажатия в обмен на небольшое искажение изображения возле границы изображения. Искажение намного менее заметно для игрока, чем артефакты зажатия.[0060] Clamping artifacts are introduced when macroblocks move off the screen and appear as pixel color smearing perpendicular to the edge of the screen. The example smoothing function reduces the magnitude of outward motion vectors as they approach the edge of the image. Only the outward component needs to be attenuated, the y component for outward vectors towards the top and bottom edges of the image, and the x component for outward vectors towards the left and right edges of the image. For vectors that are directed towards the boundary, the vector component can be multiplied by the square of the distance to the edge, as a result of which as the distance to the boundary approaches zero, the vector component will approach zero. In this example, the outward vector towards the right edge of the image will be converted from {x,y} to {x*d*d,y}, where d is the distance from the edge. This will reduce clamping artifacts in exchange for slight image distortion near the image border. Distortion is much less noticeable to the player than clamping artifacts.

[0061] После завершения процесса декодирования на стадии 324 на кодированном видеокадре, суммированные векторы движения используются в компенсации движения на стадии 312. Полученное в результате видео выводят на стадии 314. Выходной сигнал содержит данные компенсации движения на основании ввода игрока и будет отображаться на клиенте. Этот выходной кадр представляет собой первый кадр, содержащий оценку движения для ввода с маркером соотнесения «1003». Выходной кадр также содержит оценку движения для предыдущего ввода с маркером соотнесения «1002», для которого клиент по-прежнему ожидает возврата от сервера актуальных векторов движения. Этот выходной кадр также представляет собой первый кадр, содержащий актуальные векторы движения для предыдущего ввода с маркером соотнесения «1001», по которому клиент ранее оценил движение. В результате, в этом способе есть три состояния оценки движения: одно состояние новой оценки для новых вводов; одно состояние продолжающей оценки, ожидающее актуальных результатов; и состояние другой оценки, которое прекращается, поскольку актуальные результаты поступили клиенту.[0061] After the decoding process is completed at step 324 on the encoded video frame, the summed motion vectors are used in motion compensation at step 312. The resulting video is output at step 314. The output contains motion compensation data based on the player input and will be displayed on the client. This output frame is the first frame containing the motion estimate for the input with the correlation marker "1003". The output frame also contains the motion estimate for the previous input with the mapping token "1002", for which the client still expects the server to return actual motion vectors. This output frame is also the first frame containing the actual motion vectors for the previous input with the reference marker "1001" from which the client previously estimated the motion. As a result, there are three motion estimation states in this method: one new evaluation state for new inputs; one continuing assessment state awaiting up-to-date results; and the state of another evaluation, which is terminated because the current results have arrived to the client.

[0062] На фиг. 4 показана схема, на которой изображен приведенный в качестве примера макроблок во время стадии компенсации движения на основании ввода игрока согласно фиг. 3. Стадия компенсации движения на основании ввода игрока в процедурном аспекте подобна процессу, выполняемому во время декодирования Н.264, когда декодированные векторы движения используются для определения того, откуда переместились макроблоки в текущем кадре из предыдущего кадра. Для компенсации движения на основании ввода игрока применяемые векторы движения оценивают будущую обратную связь для ввода игрока за счет перемещения макроблоков в текущем кадре перед отображением выходного видеосигнала игроку. На фиг. 4А показаны два набора маркированных векторов движения в очереди на стадии 400 из приведенных в качестве примера маркированных векторов движения, показанных на стадии 308 на фиг. 3. Эти два набора суммируют, взяв сумму векторов для каждого макроблока в изображении, для создания одного набора векторов движения на стадии 402 на фиг. 4В. Каждый из векторов движения в этом наборе представляет оцененное перемещение для каждого макроблока в текущем кадре. Для каждого вектора в суммированных векторах движения на стадии 402, соответствующий макроблок в приведенном в качестве примера изображении на фиг. 4С будет сдвинут. Один приведенный в качестве примера макроблок показан на фиг. 4С сдвинутым на соответствующий вектор движения при вводе игрока на стадии 404. Каждый макроблок в приведенном в качестве примера изображении будет сдвинут таким образом. Приведенное в качестве примера изображение на фиг. 4С содержит только 50 макроблоков, но изображение с высоким разрешением будет содержать тысячи макроблоков. Приведенные в качестве примера векторы движения, показанные на фиг. 4, отображают равномерное движение как твердого тела, но описанная методика компенсации движения на основании ввода игрока может использоваться с векторами движения произвольной сложности для описания поворотов, вибраций или других сложных движений в экранном пространстве, которые известны в уровне техники.[0062] In FIG. 4 is a diagram showing an exemplary macroblock during the motion compensation stage based on player input according to FIG. 3. The motion compensation step based on player input is procedurally similar to the process performed during H.264 decoding, where the decoded motion vectors are used to determine where the macroblocks in the current frame have moved from the previous frame. To compensate for motion based on player input, the applied motion vectors estimate future feedback for the player's input by moving macroblocks in the current frame before displaying the video output to the player. In fig. 4A shows two sets of marked motion vectors in the queue at step 400 from the exemplary marked motion vectors shown at step 308 in FIG. 3. These two sets are summed by taking the sum of the vectors for each macroblock in the image to create one set of motion vectors at step 402 in FIG. 4B. Each of the motion vectors in this set represents the estimated motion for each macroblock in the current frame. For each vector in the summed motion vectors at step 402, the corresponding macroblock in the example image of FIG. 4C will be shifted. One exemplary macroblock is shown in FIG. 4C shifted by the corresponding motion vector upon player input at step 404. Each macroblock in the example image will be shifted in this manner. The exemplary image in FIG. 4C only contains 50 macroblocks, but a high resolution image will contain thousands of macroblocks. The exemplary motion vectors shown in FIG. 4 display uniform motion as a rigid body, but the described technique for compensating motion based on player input can be used with motion vectors of arbitrary complexity to describe rotations, vibrations, or other complex motions in screen space that are known in the art.

[0063] На фиг. 5 показано изображение альтернативного способа применения векторов движения во время компенсации движения на основании ввода игрока на клиенте. Согласно некоторым вариантам осуществления этого способа нет необходимости обрабатывать остаточные кадры во время кодирования и декодирования видео. После нахождения соответствующего ввода игрока в таблице поиска, связанные векторы движения маркируют на стадии 500 и используют для компенсации движения на основании ввода игрока, как показано на стадиях 208 и 212 на фиг. 2. Во время процесса декодирования в следующем кадре векторы движения при вводе игрока добавляют к декодированным векторам движения и вводят в стадию компенсацию движения на стадии 502, определенной согласно стандарту кодирования Н.264. Деблочный фильтр, определенный согласно стандарту кодирования Н.264, применяют на стадии 504, но только к тем блокам, которые не были модифицированы за счет компенсации движения на основании ввода игрока. Полученный в результате выходной сигнал, показанный на стадии 506, характеризуется компенсацией движения на основании ввода игрока и будет отображаться на клиенте. Выходной сигнал затем помещают в буфер на стадии 506 и на стадии 518 он становится предыдущим изображением для использования при компенсации движения в следующем кадре. В отличие от варианта исполнения, показанного на фиг. 3, в этом варианте исполнения маркированные векторы движения при вводе игрока применяют только один раз. Это означает, что они не должны суммироваться со всеми маркированными векторами движения в очереди, поскольку предыдущее изображение, показанное на стадии 518, будет содержать сумму предыдущих маркированных векторов движения. Время между приемом ввод и отображением выходного видеосигнала представляет собой задержку между вводом и обратной связью, которая будет существенно уменьшена за счет использования компенсации движения на основании ввода игрока вместо ожидания возврата от сервера выходного видеосигнала.[0063] In FIG. 5 shows an image of an alternative method of applying motion vectors during motion compensation based on player input on the client. In some embodiments of this method, there is no need to process residual frames during video encoding and decoding. Once the corresponding player input is found in the lookup table, associated motion vectors are marked at step 500 and used to compensate for motion based on the player input, as shown at steps 208 and 212 in FIG. 2. During the decoding process in the next frame, the player input motion vectors are added to the decoded motion vectors and motion compensation is introduced into the stage at stage 502 determined according to the H.264 encoding standard. The deblock filter defined according to the H.264 encoding standard is applied at step 504, but only to those blocks that have not been modified by motion compensation based on player input. The resulting output, shown at step 506, is motion compensated based on the player input and will be displayed on the client. The output signal is then buffered at step 506 and at step 518 it becomes the previous image for use in motion compensation in the next frame. Unlike the embodiment shown in FIG. 3, in this embodiment, the marked motion vectors are applied only once upon player input. This means that they do not have to be summed with all the marked motion vectors in the queue, since the previous image shown at step 518 will contain the sum of the previous marked motion vectors. The time between receiving input and displaying the video output represents the delay between input and feedback, which will be significantly reduced by using motion compensation based on player input instead of waiting for the video output server to return.

[0064] В то же время на стадии 500 клиент отправляет соответствующий маркированный ввод игрока на сервер, как показано на стадиях 208 и 210 на фиг. 2. Клиент в конечном итоге принимает кодированное видео, как показано на стадии 508, с тем же маркером 510 в битовом потоке от сервера на стадии 512, как показано на стадии 220 на фиг. 2. Маркер 510, связанный с видео, обозначает, что актуальное движение, ранее оцененное за счет компенсации движения на основании ввода игрока, представлено в кодированном видео, как показано на стадии 508. Кодированное видео проходит через энтропийное декодирование на стадии 514, а также обратное квантование и обратное преобразование на стадии 516, как определено стандартом кодирования Н.264.[0064] At the same time, at step 500, the client sends the corresponding token player input to the server, as shown at steps 208 and 210 in FIG. 2. The client ultimately receives the encoded video, as shown at step 508, with the same token 510 in the bitstream from the server at step 512, as shown at step 220 in FIG. 2. A marker 510 associated with the video indicates that the actual motion, previously estimated by motion compensation based on the player input, is represented in the encoded video, as shown at step 508. The encoded video goes through entropy decoding at step 514, as well as the reverse quantization and deconversion at step 516, as defined by the H.264 coding standard.

[0065] На предыдущей стадии компенсации движения на основании ввода игрока, которая была выполнена перед стадиями 508, 510, 512, 514 и 516, описанными в предыдущих абзацах, уже были сдвинуты макроблоки, которые актуальные векторы движения из кодированного кадра пытаются сдвинуть. Таким образом, применение актуальных векторов движения приведет непосредственно к сдвигу неправильных макроблоков. Битовый поток будет содержать два связанных элемента данных: кодированный видеокадр и маркер соотнесения. Кодированный кадр отправляют на энтропийное декодирование на стадии 514, а маркер отправляют дальше в процесс наложения на стадии 520. Для компенсации в процессе наложения на стадии 520 применяют поправочные векторы движения за счет вычисления разности между входящими актуальными векторами движения и ранее использованными векторами движения при вводе игрока 500 с соответствующим маркером соотнесения. Разность может быть вычислена за счет добавления обратных векторов движения для маркера соотнесения к актуальным векторам движения и описывается более подробно со ссылкой на фиг. 6. Поправочные векторы используются вместо декодированных векторов движения для компенсации движения на стадии 502. Оставшаяся часть схемы декодирования продолжается как обычно, с использованием деблочного фильтра на стадии 504, следующим выходным видеокадром на стадии 506, и помещением в буфер выходного сигнала на стадии 518. Эти стадии могут продолжаться для повторения для каждого кадра до бесконечности. В целом, процесс наложения на стадии 520 осуществляется после обратного квантования (стадия 514) и обратного преобразования (стадия 516), поскольку актуальные векторы движения не будут доступны до этого момента. После того как актуальные векторы движения станут доступны, они будут использованы в процессе наложения для вычисления разности между актуальными и оцененными векторами движения.[0065] In the previous stage of motion compensation based on player input, which was performed before stages 508, 510, 512, 514 and 516 described in the previous paragraphs, the macroblocks that the actual motion vectors from the encoded frame are trying to shift have already been shifted. Thus, the application of actual motion vectors will directly lead to the shift of incorrect macroblocks. The bitstream will contain two associated data elements: an encoded video frame and an association token. The encoded frame is sent to entropy decoding at step 514, and the marker is sent further to the overlay process at step 520. To compensate during the overlay process, motion correction vectors are applied at step 520 by calculating the difference between the incoming actual motion vectors and the previously used motion vectors of the player input 500 with the corresponding correlation marker. The difference can be calculated by adding the inverse motion vectors for the mapping marker to the actual motion vectors and is described in more detail with reference to FIG. 6. The correction vectors are used in place of the decoded motion vectors to compensate for motion in step 502. The remainder of the decoding circuit continues as usual, using the deblocking filter in step 504, the next output video frame in step 506, and the output buffer in step 518. These stages can continue to be repeated for each frame ad infinitum. In general, the overlay process at step 520 occurs after dequantization (step 514) and detransformation (step 516), since the actual motion vectors will not be available until then. Once the actual motion vectors are available, they are used in the overlay process to calculate the difference between the actual and estimated motion vectors.

[0066] На фиг. 6 изображен приведенный в качестве примера макроблок, подвергающийся компенсации движения на основании ввода игрока и наложению. В момент времени 0 мс игрок нажимает на кнопку и делает ввод для поворота обзора камеры влево. Связанные векторы движения для компенсации движения на основании ввода игрока, показанные как «Р1МС» 600, из таблицы поиска применяются ко всем макроблокам в следующем кадре. На фиг. 6А показан приведенный в качестве примера макроблок, сдвинутый вправо. Результаты компенсации движения на основании ввода игрока появляются в следующем декодированном кадре, что приводит к максимальной задержке между вводом и обратной связью, составляющей 16 мс, то есть продолжительности одного кадра для видео, идущего с частотой 60 кадров в секунду. Согласно другим вариантам осуществления максимальная задержка между вводом и обратной связью может составлять 33 мс для видео, идущего с частотой 30 кадров в секунду. Таким образом, предполагается, что настоящее изобретение применяется при различных частотах кадров, ограничивая максимальную задержку между вводом и обратной связью продолжительностью одного кадра. Когда маркированное видео возвращается от сервера, оно содержит актуальные векторы движения 602, кодированные сервером, как показано на фиг. 6В. В этом примере кодированное видео возвращается в момент времени 100 мс, но это сильно зависит от задержки в сети. Актуальные векторы 602 относятся к макроблокам, которые уже были сдвинуты во время компенсации движения на основании ввода игрока 600, поэтому актуальные векторы 602 не могут применяться непосредственно к существующему кадру. Вместо этого, поправочные векторы 604 должны быть вычислены за счет нахождения разности между актуальными векторами 602 и векторами движения при вводе игрока 600. Разность может быть вычислена за счет добавления обратных векторов движения при вводе игрока к актуальным векторам движения. Нахождение этих разностей векторов называется наложением на стадии 524 на фиг. 5. Чем меньше поправочный вектор 604, тем более успешен был способ компенсации движения на основании ввода игрока при оценке актуальных векторов движения. Итоговое движение 608, показанное на фиг. 6С для приведенного в качестве примера макроблока, аналогично актуальном вектору движения 602. Этот пример отображает, как с помощью компенсации движения на основании ввода игрока можно оценить обратную видеосвязь для ввода игрока, и показывает результат для времени между 16 мс и 100 мс, при этом немодифицированная система не будет отображать обратную связь на ввод игрока до 116 мс после приема ввода игрока.[0066] In FIG. 6 shows an exemplary macroblock undergoing motion compensation based on player input and overlay. At time 0 ms, the player presses the button and makes an input to rotate the camera view to the left. Associated motion vectors for motion compensation based on player input, shown as "P1MC" 600, from the lookup table are applied to all macroblocks in the next frame. In fig. 6A shows an example macroblock shifted to the right. The results of motion compensation based on player input appear in the next decoded frame, resulting in a maximum latency between input and feedback of 16 ms, which is the duration of one frame for video running at 60 frames per second. In other embodiments, the maximum delay between input and feedback may be 33 ms for video running at 30 frames per second. Thus, it is intended that the present invention be applied at various frame rates, limiting the maximum delay between input and feedback to the duration of one frame. When the tagged video is returned from the server, it contains the actual motion vectors 602 encoded by the server, as shown in FIG. 6B. In this example, the encoded video is returned at 100ms, but this is highly dependent on network latency. The actual vectors 602 refer to macroblocks that have already been shifted during motion compensation based on player input 600, so the actual vectors 602 cannot be applied directly to an existing frame. Instead, correction vectors 604 must be calculated by finding the difference between the actual vectors 602 and the player input motion vectors 600. The difference may be calculated by adding the inverse player input motion vectors to the actual motion vectors. Finding these vector differences is called superposition at step 524 in FIG. 5. The smaller the correction vector 604, the more successful the motion compensation method based on player input was in estimating the actual motion vectors. The resulting movement 608 shown in FIG. 6C for an exemplary macroblock, similar to the actual motion vector 602. This example depicts how motion compensation based on player input can estimate video feedback for player input, and shows the result for times between 16 ms and 100 ms, while unmodified the system will not display feedback on player input until 116ms after receiving player input.

[0067] Во время разработки разработчики игры должны решить, какие движения и анимации будут отправлять прогнозируемые векторы движения во время исполнения. Уникальные, но прогнозируемые векторы движения являются наилучшими вариантами для прогнозируемых векторов движения. Однозначный пример включает анимации, которые адаптивно изменяются движком, например анимации, которые используют уравнения кинематики для вычисления углов соединения, анимации, в которых изменен масштаб времени, или анимации, которые иным образом растянуты или сжаты. Например, анимация зацепа за край воспроизводится, когда игрок находится в пределах зоны определенного края объекта и подпрыгивает. Анимация зацепа за край растягивается таким образом, что руки игрока находятся на краю, но по-прежнему прикреплены к телу игрока. Анимация воспроизводится в течение определенного количества кадров, в результате чего игрок перемещается на верх края. Исходная точка в этом примера является варьируемой, при этом возможен ряд допустимых местоположений и ориентаций. Эта анимация зацепа за край является хорошим вариантом для генерирования прогнозируемых векторов движения, поскольку точная анимация не известна заранее, но может быть сгенерирована программными средствами игровым движком по требованию. Клиент, в частности, не может знать векторы движения для этой анимации, поскольку у клиента нет контекстуальной информации о местоположении игрока в среде потоковой передачи игры.[0067] During development, game developers must decide which motions and animations will send predicted motion vectors during execution. Unique but predictable motion vectors are the best options for predicted motion vectors. Clear examples include animations that are adaptively modified by the engine, such as animations that use kinematics equations to calculate joint angles, animations in which the time scale is changed, or animations that are otherwise stretched or compressed. For example, the edge hook animation plays when the player is within the area of a specific edge of an object and jumps. The edge hook animation is stretched so that the player's hands are on the edge but still attached to the player's body. The animation plays for a certain number of frames, causing the player to move to the top of the edge. The starting point in this example is variable, with a range of valid locations and orientations possible. This edge hook animation is a good option for generating predicted motion vectors since the exact animation is not known in advance, but can be generated programmatically by the game engine on demand. The client in particular cannot know the motion vectors for this animation because the client has no contextual information about the player's location in the game streaming environment.

[0068] Прогнозируемые векторы движения будут пригодны только в ограниченном контекстуальном или временном диапазоне, например при конкретном местоположении камеры, небольшом временном окне или некотором другом специфичном контексте игрока. Для каждого набора прогнозируемых векторов движения должен быть сгенерирован соответствующий указатель недействительности. Указатель недействительности может использоваться на клиенте для предотвращения применения прогнозируемых векторов движения после того как они станут действительными. Согласно некоторым вариантам осуществления указатель недействительности может представлять собой набор из любых вводов игрока, который приведет к изменению игрового контекста, вследствие чего применение прогнозируемых векторов движения больше не будет целесообразным. Согласно другим вариантам осуществления указатель недействительности может представлять собой временное окно, в котором прогнозируемые векторы движения могут быть действительными. Согласно еще одним вариантам осуществления указатель недействительности может представлять собой комбинацию вводов обеспечения недействительности и временного окна. Например, прогнозируемые векторы движения, генерируемые для анимации зацепа за край, действительны только для ограниченного местоположения и ориентации игрока, и, таким образом, указатель недействительности обязательно будет включать любой ввод, связанный с перемещением или поворотом. Указатели недействительности должны быть спроектированы и реализованы во время разработки функции прогнозируемых векторов движения. Прогнозируемые векторы движения также могут быть отключены или обновлены в результате событий или сообщений, отправленных от сервера, как описано ниже со ссылкой на фиг. 10-13, на которых раскрывается использование кешированных повторяющихся векторов движения для компенсации движения.[0068] Predicted motion vectors will only be useful within a limited contextual or temporal range, such as a specific camera location, a small time window, or some other specific player context. For each set of predicted motion vectors, a corresponding invalidity indicator must be generated. An invalidation indicator can be used on the client to prevent predicted motion vectors from being applied after they become valid. In some embodiments, the invalidation indicator may be a set of any player inputs that will cause the game context to change such that the use of predicted motion vectors is no longer practical. In other embodiments, the invalidity indicator may represent a time window in which predicted motion vectors may be valid. In yet other embodiments, the invalidation indicator may be a combination of invalidation inputs and a time window. For example, the predicted motion vectors generated for an edge-hook animation are only valid for a limited location and orientation of the player, and thus the invalidation indicator will necessarily include any translation- or rotation-related input. Invalidity indicators must be designed and implemented during the development of the predictive motion vectors function. Predicted motion vectors may also be disabled or updated as a result of events or messages sent from the server, as described below with reference to FIG. 10-13, which disclose the use of cached repeating motion vectors for motion compensation.

[0069] Прогнозируемые векторы движения могут быть сгенерированы заранее или они могут быть сгенерированы при необходимости во время исполнения. Для анимаций, которые характеризуются ограниченным количеством изменений, например, прогнозируемые векторы движения могут быть сгенерированы в режиме оффлайн посредством инициации каждого изменения и записи векторов движения. Согласно некоторым вариантам осуществления для общего клиента векторы движения хранятся на стороне сервера, а затем отправляются клиенту для кеширования по требованию. Когда векторы движения отправляются клиенту, они кешируются в таблице поиска. Предварительно сгенерированные прогнозируемые векторы движения могут храниться на сервере и будут в виде читаемого игрой формата файла, что позволяет серверу отправлять предварительно сгенерированные векторы движения, подлежащие кешированию в таблице поиска, клиенту во время исполнения игры. Анимации, которые генерируются во время исполнения, например анимации, вычисленные посредством обратной кинематики, не могут быть предварительно сгенерированы, поскольку может не быть отдельного количества возможных изменений анимации. Обратная кинематика - это способ, обычно применяемый при рендеринге в режиме реального времени для обеспечения соответствия анимации набору граничных условий. Например, персонаж игрока в видеоигре хочет сделать зацеп за ближайший край, граничные условия будут определены местоположениями, где руки игрока берутся за край, и анимация зацепа за край будет изменена соответственно посредством обратной кинематики. Для адаптивно изменяемых анимаций, таких как эти, игра может теоретически осуществлять рендеринг возможных анимаций на изображении за пределами экрана с векторами движения во время исполнения и записывать прогнозируемые векторы движения при необходимости. Например, если игрок находится возле края, за который можно зацепиться, игра может прогнозировать, что игрок будет скоро делать зацеп за край, и игра может теоретически осуществлять рендеринг анимации зацепа за край для генерирования прогнозируемых векторов движения. Адаптивно изменяемые анимации, для которых должны быть сгенерированы прогнозируемые векторы движения во время исполнения, должны быть идентифицированы разработчиком заранее.[0069] Predicted motion vectors may be generated in advance, or they may be generated as needed during execution. For animations that have a limited number of changes, for example, predicted motion vectors can be generated offline by triggering each change and recording the motion vectors. In some embodiments, for a shared client, motion vectors are stored on the server side and then sent to the client for on-demand caching. When motion vectors are sent to the client, they are cached in the lookup table. Pre-generated predicted motion vectors may be stored on the server and will be in a game-readable file format, allowing the server to send pre-generated motion vectors to be cached in a lookup table to the client during game execution. Animations that are generated at runtime, such as animations computed via inverse kinematics, cannot be pre-generated because there may not be a distinct number of possible animation changes. Inverse kinematics is a technique commonly used in real-time rendering to ensure that an animation adheres to a set of boundary conditions. For example, a player character in a video game wants to grab a nearby edge, the boundary conditions will be determined by the locations where the player's hands grip the edge, and the edge grab animation will be modified accordingly via inverse kinematics. For adaptively changing animations such as these, the game could theoretically render possible animations on an off-screen image with motion vectors at runtime, and record the predicted motion vectors as needed. For example, if the player is near a grab-able edge, the game can predict that the player will soon be doing the edge-grab, and the game can theoretically render the edge-grab animation to generate the predicted motion vectors. Responsive animations for which predicted motion vectors are to be generated at runtime must be identified by the developer in advance.

[0070] Существующие игровые системы, которые описывают контекст игрока, например отслеживание местоположения игрока, системы сценариев, зоны с триггером или системы поиска пути, могут использоваться для генерирования события, которое будет сигнализировать о том, когда игра должна теоретически осуществлять рендеринг анимации. Например, игра может отслеживать близость игрока к краю, за который можно зацепиться, и сигнализировать игре о том, что необходимо теоретически осуществить рендеринг анимации зацепа за край и записать прогнозируемые векторы движения. Некоторые анимации, типа взятия в руки оружия, использования рычага или нажатия кнопки, могут быть растянуты или отрегулированы на основании близости игрока к месту взаимодействия и ориентации игрока. Эти анимации характеризуются очень большим количеством изменений, чтобы можно было осуществить предварительное генерирование, но они могут также быть сгенерированы во время исполнения, как в иллюстративных целях показано на фиг. 7. Движения, которые воспроизводятся аналогичным образом каждый раз, могут быть сгенерированы и записаны в режиме оффлайн. Они, как правило, представляют собой движения, которые происходят каждый раз в одном и том же экранном пространстве и с одной и той же скоростью, когда они инициируются. Векторы движения для этих анимаций могут быть записаны в режиме оффлайн за счет инициации все возможных изменений анимации и записи сгенерированных игрой векторов движения или генерирования векторов движения посредством более традиционных методик оценки движения, таких как используются в кодеке Н.264. Согласно предпочтительному варианту осуществления сгенерированные игрой векторы движения, как описано выше со ссылкой на фиг. 1-6, используются для обеспечения оценок движения высокого качества. Этот процесс может происходить в любой момент времени в течение разработки, но предпочтительно добавить этот процесс в качестве стадии процесса сборки или другого существующего процесса настройки активов, например предварительного генерирования MIP-карт и уровней детализации («LOD»). Настройка активов может включать любой процесс, который осуществляет компиляцию активов игры из человекочитаемых исходных форматов в машиночитаемые форматы. Например, MIP-карты могут быть сгенерированы заранее за счет преобразования созданных художником файлов текстур в готовые для игры форматы, которые характеризуются множеством разрешений. Например, LOD могут быть сгенерированы заранее за счет преобразования созданных художником файлов моделей в готовые для игры форматы, которые характеризуются множеством уровней детализации. Генерирование векторов движения может быть добавлено в существующий процесс настройки активов, которые преобразует форматы созданной художником анимации в готовые для игры форматы.[0070] Existing game systems that describe the player's context, such as player location tracking, scripting systems, trigger zones, or pathfinding systems, can be used to generate an event that will signal when the game should theoretically render an animation. For example, the game could track the player's proximity to a grab-able edge and signal the game to theoretically render the edge-grab animation and record the predicted motion vectors. Some animations, such as picking up a weapon, using a lever, or pressing a button, can be stretched or adjusted based on the player's proximity to the interaction location and the player's orientation. These animations have too many changes to allow for pre-generation, but they can also be generated at runtime, as shown in FIG. 7.Moves that are played in the same way every time can be generated and recorded offline. They tend to be movements that occur in the same screen space and at the same speed every time they are initiated. Motion vectors for these animations can be recorded offline by initiating all possible animation changes and recording game-generated motion vectors or generating motion vectors through more traditional motion estimation techniques such as those used in the H.264 codec. In a preferred embodiment, the game-generated motion vectors as described above with reference to FIG. 1-6 are used to provide high quality motion estimates. This process can occur at any time during development, but it is preferable to add this process as a step in the build process or other existing asset setup process, such as pre-generation of MIP maps and levels of detail (“LOD”). Asset customization can include any process that compiles game assets from human-readable source formats to machine-readable formats. For example, mip maps can be pre-generated by converting artist-created texture files into game-ready formats that feature multiple resolutions. For example, LODs can be pre-generated by converting artist-created model files into game-ready formats that feature multiple levels of detail. Motion vector generation can be added to an existing asset setup process that converts artist-created animation formats into game-ready formats.

[0071] На фиг. 7 изображен приведенный в качестве примера способ генерирования векторов движения в режиме оффлайн или во время исполнения. Анимации могут быть отрендерены для поверхности/изображения вне экрана, стадия 700, и векторы движения могут быть записаны для немедленного использования. Должны быть отрендерены только те части экрана, которые перемещаются, другие объекты в сцене можно игнорировать. Обведенный пунктирной линией объект, показанный на стадии 702, и обведенный сплошной линией объект, показанный на стадии 704, представляют положение анимированного объекта в предыдущем кадре и текущем кадре соответственно. Перемещение из предыдущего кадра в текущий кадр захватывается на стадии 706 в форме векторов движения, показанных на стадии 708. Векторы движения могут быть захвачены из сгенерированных игрой векторов движения или захвачены посредством более традиционных методик оценки движения, например используемых в кодеке Н.264. Согласно предпочтительному варианту осуществления сгенерированные игрой векторы движения, как описано выше со ссылкой на фиг. 1-6, используются для обеспечения векторов движения высокого качества. Ценность нескольких кадров прогнозируемых векторов движения может быть быстро вычислена для заданной анимации за счет повторения процесса, изображенного на стадиях 700-708, до тех пор, пока векторы движения не будут сгенерированы для всех необходимых кадров. Не все из кадров в анимации должны быть сгенерированы - необходимы только те, которые должны быть воспроизведены на клиенте, пока видеопоток догружается. Минимальное количество сгенерированных кадров будет зависеть от задержки между отправкой ввода игрока и приемом итогового видеопотока на клиенте; и продолжительность сгенерированного отрезка анимации должна по меньшей мере не уступать задержке. Кадры прогнозируемых векторов движения могут быть масштабированы по скорости во время воспроизведения, как описано ниже со ссылкой на фиг. 10-13, на которых раскрывается использование кешированных повторяющихся векторов движения при оценке движения. Если воспроизведение кадров прогнозируемых векторов движения масштабировано по времени, генерирование прогнозируемых векторов движения для отрезка анимации, равного задержке, приведет к масштабированию скорости воспроизведения, равному 50%. Генерирование векторов движения для более продолжительного отрезка анимации приведет к воспроизведению, которое характеризуется менее выраженным масштабированием по скорости.[0071] In FIG. 7 shows an exemplary method for generating motion vectors offline or at runtime. Animations can be rendered to an off-screen surface/image, stage 700, and motion vectors can be recorded for immediate use. Only those parts of the screen that move should be rendered; other objects in the scene can be ignored. The dotted line object shown at 702 and the solid line object shown at 704 represent the position of the animated object in the previous frame and the current frame, respectively. Movement from the previous frame to the current frame is captured at 706 in the form of motion vectors, shown at 708. The motion vectors may be captured from game-generated motion vectors or captured through more traditional motion estimation techniques, such as those used in the H.264 codec. In a preferred embodiment, the game-generated motion vectors as described above with reference to FIG. 1-6 are used to provide high quality motion vectors. The value of several frames of predicted motion vectors can be quickly calculated for a given animation by repeating the process depicted in steps 700-708 until motion vectors have been generated for all required frames. Not all of the frames in the animation need to be generated - only those that need to be played on the client while the video stream is loading. The minimum number of frames generated will depend on the delay between sending the player input and receiving the resulting video stream on the client; and the duration of the generated animation segment should be at least as long as the delay. The predicted motion vector frames may be speed scaled during playback, as described below with reference to FIG. 10-13, which disclose the use of cached repeating motion vectors in motion estimation. If playback of predicted motion vector frames is time scaled, generating predicted motion vectors for a span of animation equal to the delay will result in playback speed scaling equal to 50%. Generating motion vectors for a longer period of animation will result in playback that exhibits less pronounced speed scaling.

[0072] При записи векторов движения должен учитываться размер макроблока, используемый для кодирования видео, и должен быть предусмотрен вектор движения для каждого макроблока. Согласно предпочтительному варианту осуществления, сгенерированные игрой векторы движения генерируются как попиксельные векторы движения и преобразуются в помакроблочные векторы движения за счет поиска среднего арифметического для каждой группы макроблоков попиксельных векторов движения.[0072] When recording motion vectors, the macroblock size used for video encoding must be taken into account and a motion vector must be provided for each macroblock. In a preferred embodiment, game-generated motion vectors are generated as per-pixel motion vectors and converted to macroblock-by-macroblock motion vectors by taking the arithmetic average of each macroblock group of per-pixel motion vectors.

[0073] На фиг. 8 изображены передача и хранение на стороне клиента прогнозируемых векторов движения с целью компенсации движения на основании ввода игрока. Во время разработки программного обеспечения видеоигры, события должны быть настроены для сигнализации о намечающихся чувствительных к контексту анимациях, запускаемых от ввода. Например, разработчик игры хочет отправить прогнозируемые векторы движения, чтобы они были доступны, когда игрок выполняет анимацию зацепа за край. Разработчик реализует событие, которое будет инициировано каждый раз, когда игрок обращен к краю, за который можно зацепиться, и находиться вблизи от него. В этом примере, когда игрок приближается к краю, за который можно зацепиться, во время игры, приведенное в качестве примера событие принимается на стадии 800 «Прием события во время исполнения игры». Тип события будет описывать, должны ли быть сгенерированы прогнозируемые векторы движения, как в случае адаптивно изменяемых анимаций, или были ли прогнозируемые векторы движения предварительно сгенерированы в режиме оффлайн, как в случае анимаций, которые никогда не изменяются, а воспроизводятся редко или зависят от контекста игрока. В приведенном выше примере анимация зацепа за край растягивается на основании расстояния игрока от края, что означает, что векторы движения должны быть сгенерированы во время исполнения на стадии 802 «Генерирование прогнозируемых векторов движения». В другом случае векторы движения могут быть сгенерированы в режиме оффлайн и считаны из запоминающего устройства на стадии 804 «Считывание предварительно сгенерированных векторов движения».[0073] In FIG. 8 depicts the transmission and client-side storage of predicted motion vectors for the purpose of motion compensation based on player input. During video game software development, events must be configured to signal upcoming context-sensitive animations triggered by input. For example, a game developer wants to send predicted motion vectors so that they are available when the player performs an edge-hook animation. The developer will implement an event that will be triggered whenever the player is facing an edge that can be grabbed onto and is close to it. In this example, when the player approaches a catchable edge during the game, the exemplary event is received in the Game Execution Event Reception step 800. The event type will describe whether predicted motion vectors should be generated, as in the case of adaptively changing animations, or whether predicted motion vectors were pre-generated offline, as in the case of animations that never change but are played infrequently or depend on the player's context . In the example above, the edge hook animation is stretched based on the player's distance from the edge, which means that motion vectors must be generated at runtime in the Generate Predicted Motion Vectors step 802. Alternatively, motion vectors may be generated offline and read from the memory in a Read Pre-Generated Motion Vectors step 804.

[0074] Один пример предварительно сгенерированные векторы движения может представлять собой переключение между видами оружия в большом арсенале. Количество возможных изменений при переключении оружия может достаточно сильно возрасти, что делает нецелесообразным кеширование всего набора итоговых векторов движения. В целом, если векторы движения занимают чрезмерный объем в ограниченной кеш-памяти и не используются достаточно часто, они не являются подходящими вариантами для предварительного кеширования. Прогнозируемые векторы движения отправляют клиенту на стадии 806 «Отправка прогнозируемых векторов движения и указателей недействительности». Прогнозируемые векторы движения добавляют в таблицу поиска векторов движения на стадии 808 «Кеширование прогнозируемых векторов движения и указателей недействительности». Согласно одному варианту осуществления система определения недействительности функционирует аналогично системе, которая инициирует применение векторов движения в таблице поиска, но вместо этого запрещает применение векторов движения. Когда набор векторов движения и указателей недействительности принят на стадии 808 «Кеширование прогнозируемых векторов движения и указателей недействительности», указатели недействительности должны быть зарегистрированы системой определения недействительности.[0074] One example of pre-generated motion vectors could represent switching between weapons in a large arsenal. The number of possible changes when switching weapons can increase quite significantly, making caching the entire set of resulting motion vectors impractical. In general, if motion vectors take up excessive space in a limited cache and are not used frequently enough, they are not suitable options for precaching. The predicted motion vectors are sent to the client in step 806, “Send Predicted Motion Vectors and Invalidity Indicators.” The predicted motion vectors are added to the motion vector lookup table in a "Caching Predicted Motion Vectors and Invalid Indicators" step 808. In one embodiment, the invalidation determination system functions similarly to a system that initiates the application of motion vectors in a lookup table, but instead disables the application of motion vectors. When the set of motion vectors and invalidity indicators is received in the Caching Predicted Motion Vectors and Invalidation Indicators step 808, the invalidation indicators must be registered by the invalidation determination system.

[0075] В способе компенсации движения на основании ввода игрока, как описано выше со ссылкой на фиг. 16, сравнивают все вводы игрока с записями в таблице поиска векторов движения. В приведенном выше примере, когда игрок осуществляет необходимый ввод для инициации анимации зацепа за край, ввод будет сопоставлен с ранее кешированным вводом в таблице поиска на стадии 810 «Сопоставление принятого ввода игрока». Если кешированные прогнозируемые векторы движения еще не были признаны недействительными, прогнозируемые векторы движения будут применены на стадии 812 «Применение компенсации движения на основании ввода игрока». Если соответствующий ввод игрока будет делать недействительными прогнозируемые векторы движения, или если прогнозируемые векторы движения становятся недействительными через предварительно определенный период времени, или если прогнозируемые векторы движения становятся недействительными после однократного применения, прогнозируемые векторы движения удаляют из таблицы поиска на стадии 814 «Признание недействительности» и не применяются.[0075] In the motion compensation method based on player input, as described above with reference to FIG. 16, compares all player inputs with entries in the motion vector lookup table. In the above example, when the player provides the necessary input to initiate the edge hook animation, the input will be matched to the previously cached input in the lookup table in the Match Received Player Input step 810. If the cached predicted motion vectors have not already been invalidated, the predicted motion vectors will be applied in the Apply Motion Compensation Based on Player Input step 812. If the corresponding player input would invalidate the predicted motion vectors, or if the predicted motion vectors become invalid after a predetermined period of time, or if the predicted motion vectors become invalid after a single application, the predicted motion vectors are removed from the lookup table at Invalidate step 814 and do not apply.

[0076] На фиг. 9 описан приведенный в качестве примера способ отправки сигналов, которые могут определить недействительность набора прогнозируемых векторов движения. Определение недействительности представляет собой тип обновления таблицы поиска, где набор прогнозируемых векторов движения удаляется из таблицы поиска, которая предпочтительно кешируется на клиенте. В дополнение к реакции на события обновления, принятые от сервера, механизм обновления может отслеживать вводы игрока и содержать таймеры обратного отсчета определения недействительности. Когда набор прогнозируемых векторов движения подвергнут кешированию в таблице поиска, его указатель недействительности вероятно будет зарегистрирован с помощью функции/механизма обновления. Указатель недействительности представляет собой любой сигнал данных, который инициирует обновление определения недействительности таблицы поиска. Приведенная в качестве примера таблица поиска, «Таблица поиска», показанная на стадии 900, содержит три набора прогнозируемых векторов движения: прогнозируемую анимация двери, показанную на стадии 902 «Прогнозируемая анимация двери», прогнозируемую анимацию зацепа за край, показанную на стадии 904 «Прогнозируемый зацеп за край», и прогнозируемую анимацию убийственного удара, показанную на стадии 906 «Прогнозируемая анимация убийственного удара». Прогнозируемые векторы движения могут быть признаны недействительными после однократного применения. В примере векторы движения прогнозируемой анимации двери, показанные на стадии 902 «Прогнозируемая анимация двери», применяют, когда игрок нажимает ввод на стадии 908 «Ввод для открывания двери», чтобы открыть ближайшую дверь. Одновременно, ввод для открывания двери на стадии 908 «Ввод для открывания двери», удаляется из регистра и прогнозируемые анимации двери, показанные на стадии 902 «Прогнозируемая анимация двери», могут быть удалены из таблицы поиска на стадии 910 «Признание недействительности после использования». Аналогично, другие вводы могут делать недействительными прогнозируемые векторы движения перед их применением. В этом примере набор прогнозируемых векторов движения для анимации зацепа за край, показанной на стадии 904 «Прогнозируемый зацеп за край», действителен только в пределах ограниченного расстояния до края.[0076] In FIG. 9 describes an exemplary method of sending signals that can determine the invalidity of a set of predicted motion vectors. Invalidation is a type of lookup table update where a set of predicted motion vectors are removed from the lookup table, which is preferably cached on the client. In addition to responding to update events received from the server, the update mechanism may monitor player inputs and contain invalidation determination countdown timers. When a set of predicted motion vectors is cached in the lookup table, its invalidation indicator will likely be registered using the update function/mechanism. An invalidation indicator is any data signal that triggers an update to the invalidation definition of a lookup table. An exemplary lookup table, “Lookup Table” shown at step 900, contains three sets of predicted motion vectors: a predictable door animation shown at step 902 “Predicted Door Animation”, a predictable edge hook animation shown at step 904 “Predicted” edge hook" and the predicted kill strike animation shown in the "Predicted Kill Strike Animation" step 906. Predicted motion vectors may be invalidated after a single use. In the example, the predictive door animation motion vectors shown in the Predictive Door Animation step 902 are applied when the player presses enter in the Input to Open Door step 908 to open a nearby door. At the same time, the door opening input in the Door Opening Input step 908 is removed from the register and the predicted door animations shown in the Door Predicted Animation step 902 can be removed from the lookup table in the Invalidate After Use step 910. Likewise, other inputs may invalidate predicted motion vectors before applying them. In this example, the set of predicted motion vectors for the edge hook animation shown in the Predicted Edge Hook step 904 is only valid within a limited distance to the edge.

[0077] Если игрок перемещается в сторону от края за счет использования ввода для перемещения, показанного на стадии 912 «Ввод для перемещения», перед тем как игрок подпрыгнет, чтобы зацепиться за край (за счет использования ввода для прыжка, показанного на стадии 914 «Ввод для прыжка»), векторы движения прогнозируемого зацепа за край, показанные на стадии 904 «Прогнозируемый зацеп за край», будут признаны недействительными на стадии 916 «Признание недействительности при вводах». Другие примеры вводов обеспечения недействительности могут представлять собой случаи, в которых у игрока есть абордажный крюк или некоторое другое оружие, основанное на перемещении, которое может сделать недействительными прогнозируемые векторы движения, и случаи, в которых игрок нажимает кнопку, которая активирует специальную возможность. Поскольку вводы обеспечения недействительности являются характерными для контекста, другие варианты могут быть очевидными на основании конкретного варианта исполнения. Прогнозируемые векторы движения также могут становиться недействительными с течением времени. В указанном примере возможность убийственного удара предоставляется игроку только в течение трехсекундного окна. Если игрок не нажимает ввод для ближнего боя, показанный на стадии 918 «Ввод для ближнего боя», в течение трехсекундного окна, векторы движения для прогнозируемой анимации убийственного удара, показанные на стадии 906 «Прогнозируемая анимация убийственного удара», будут признаны недействительными на стадии 920 «Признание недействительности по таймеру прекращения действия». Прогнозируемые векторы движения могут характеризоваться наличием множества указателей недействительности и наоборот. Например, прогнозируемый зацеп за край может быть признан недействительным, если принят ввод для перемещения или после использования векторов движения зацепа за край, в зависимости от того, что наступит раньше.[0077] If the player moves away from the edge by using the move input shown in step 912 "Move Input" before the player jumps to catch the edge (by using the jump input shown in step 914 " Jump Input), the predicted edge hold motion vectors shown in the Predicted Edge Hook step 904 will be invalidated in the Input Invalidation step 916. Other examples of invalidation inputs might be cases in which the player has a grappling hook or some other movement-based weapon that could invalidate predicted motion vectors, and cases in which the player presses a button that activates a special ability. Since invalidation inputs are context specific, other options may be obvious based on a particular embodiment. Predicted motion vectors may also become invalid over time. In the above example, the killing blow opportunity is only given to the player during a three second window. If the player does not press the melee input shown in the Melee Input step 918 within the three second window, the motion vectors for the predicted kill strike animation shown in the Predicted Kill Strike Animation step 906 will be invalidated in step 920 “Invalidation by Termination Timer.” Predicted motion vectors may be characterized by the presence of multiple invalidity indicators and vice versa. For example, a predicted edge hold may be invalidated when motion input is accepted or after edge hold motion vectors are used, whichever comes first.

[0078] На фиг. 10 показан приведенный в качестве примера способ генерирования библиотеки векторов движения и приведенная в качестве примера библиотека повторяющихся векторов движения для кеширования. Поскольку выбранные движения очень повторяющиеся по своей сути, они будут воспроизводиться аналогичным образом каждый раз при инициации. Это позволяет сгенерировать векторы движения заранее и организовать их в библиотеки. Генерирование библиотеки векторов движения может осуществляться в любой момент времени в течение разработки, но есть смысл добавить этот процесс в качестве стадии во время процесса сборки или некоторой другой фазы настройки активов. В этом примере библиотеку векторов движения генерируют для каждого доступного оружия в шутере от первого лица. Когда генерирование библиотеки для первого оружия начинается на стадии 1000 «Генерирование библиотеки», анимацию первого оружия инициируют на стадии 1002 «Инициация анимации» и векторы движения записывают на стадии 1004 «Запись векторов движения». Векторы движения могут быть сгенерированы игрой или сгенерированы посредством более традиционных методик оценки движения, например используемых в кодеке Н.264. Согласно предпочтительному варианту осуществления сгенерированные игрой векторы движения, как описано в предварительных заявках на выдачу патента США №62/488256 и 62/634464, которые включены в настоящий документ во всей своей полноте, используются для обеспечения оценок движения высокого качества. Если записанные векторы движения не точно или правильно квантованы, они будут вносить артефакты при использовании во время компенсации движения на основании ввода игрока. Стадии 1002 и 1004 повторяют до тех пор, пока векторы движения не будут записаны для каждой очень повторяющейся анимации в библиотеке. Генерирование библиотеки начинается снова на стадии 1000 до тех пор, пока все библиотеки не будут сгенерированы.[0078] In FIG. 10 shows an exemplary method for generating a motion vector library and an exemplary repeating motion vector library for caching. Since the selected moves are very repetitive in nature, they will be played in a similar manner each time they are initiated. This allows motion vectors to be generated in advance and organized into libraries. Generating the motion vector library can be done at any point during development, but it makes sense to add this process as a step during the build process or some other asset setup phase. In this example, a library of motion vectors is generated for each available weapon in a first-person shooter game. When library generation for the first weapon begins in the Generate Library step 1000, the animation of the first weapon is initiated in the Initiate Animation step 1002 and the motion vectors are recorded in the Write Motion Vectors step 1004. Motion vectors can be generated by the game or generated through more traditional motion estimation techniques, such as those used in the H.264 codec. In a preferred embodiment, game-generated motion vectors as described in US Provisional Patent Applications 62/488,256 and 62/634,464, which are incorporated herein in their entirety, are used to provide high quality motion estimates. If recorded motion vectors are not accurately or correctly quantized, they will introduce artifacts when used during motion compensation based on player input. Steps 1002 and 1004 are repeated until motion vectors have been recorded for every highly repetitive animation in the library. Library generation begins again at step 1000 until all libraries have been generated.

[0079] Пример, показанный на стадии 1006 «Библиотека векторов движения», представляет собой очень упрощенную версию библиотеки повторяющихся векторов движения для плазменного ружья в шутере от первого лица. Этот пример является упрощенным, чтобы включить две простые анимации: одну 2-кадровую анимацию для анимации отдачи, которая воспроизводится, когда игрок стреляет из плазменного ружья, как показано на стадии 1008, и одну 4-кадровую анимацию для покачивающего движения ружья, которая происходит, когда игрок идет вперед, как показано на стадии 1010. В обычной среде реального мира оружие вероятно будет характеризоваться большим количеством анимаций, и продолжительность анимации может быть значительно длиннее, чем четыре кадра.[0079] The example shown in Motion Vector Library step 1006 is a very simplified version of a repeating motion vector library for a plasma gun in a first-person shooter game. This example is simplified to include two simple animations: one 2-frame animation for the recoil animation that plays when the player fires the plasma gun, as shown at step 1008, and one 4-frame animation for the gun's swinging motion, which occurs when when the player walks forward, as shown at step 1010. In a typical real world environment, the weapon will likely feature a large number of animations, and the duration of the animation may be significantly longer than four frames.

[0080] На фиг. 11 изображен процесс кеширования, применения и обновления библиотек векторов движения для компенсации движения на основании ввода игрока. Когда игра начинается, сервер отправляет библиотеки предварительно сгенерированных векторов движения клиенту на стадии 1100 «Отправка библиотек повторяющихся векторов движения при запуске». Клиент сохраняет библиотеки векторов движения в запоминающем устройстве, как правило, в форме таблицы поиска, на стадии 1102 «Кеширование повторяющихся векторов движения». В этом варианте исполнения клиент является общим устройством, обслуживающим потребности множества потоковых игр. В альтернативном варианте исполнения характерный для игры клиент может постоянно хранить библиотеки векторов движения без необходимости в кешировании повторяющихся векторов движения от сервера.[0080] In FIG. 11 depicts the process of caching, applying, and updating motion vector libraries for motion compensation based on player input. When the game starts, the server sends libraries of pre-generated motion vectors to the client in step 1100, “Sending repeating motion vector libraries at startup.” The client stores the motion vector libraries in storage, typically in the form of a lookup table, in a "Caching Repeated Motion Vectors" step 1102. In this embodiment, the client is a common device serving the needs of a plurality of streaming games. In an alternative embodiment, a game-specific client may persistently store motion vector libraries without the need to cache duplicate motion vectors from the server.

[0081] В этот момент времени клиент может начинать отслеживать ввод игрока и сравнивать входящие вводы с записями в таблице поиска компенсации движения на основании ввода игрока. Когда у входящего ввода есть соответствующая запись в таблице поиска на стадии 1104 «Сопоставление принятого ввода игрока», векторы движения, связанные с вводом игрока, используются для обеспечения оценки движения, как в иллюстративных целях описано со ссылкой на фиг. 1-10 на стадии 1106 «Применение компенсации движения на основании ввода игрока». Может быть несколько случаев, в которых прием конкретного ввода может требовать изменения таблицы поиска на стадии 1112 «Обновление соответствия кешированных повторяющихся векторов движения». Примером ввода, который приводит к изменению таблицы поиска, является нажатие кнопки «пауза», которая может запрещать такие вводы игрока, как перемещение персонажа, анимации выстрела из оружия или другие связанные с игрой движения. После применения векторов движения и необязательно обновления таблицы поиска, клиент продолжает отслеживать ввод игрока. После обновления таблицы поиска на стадии 1112 «Обновление соответствия кешированных повторяющихся векторов движения», входящий ввод игрока сравнивается с обновленными записями в таблице поиска.[0081] At this point in time, the client may begin to monitor the player's input and compare the incoming inputs with entries in the motion compensation lookup table based on the player's input. When the incoming input has a corresponding lookup table entry in the Match Received Player Input step 1104, the motion vectors associated with the player input are used to provide a motion estimate, as described for illustrative purposes with reference to FIG. 1-10 at step 1106 “Applying motion compensation based on player input.” There may be several cases in which receiving a particular input may require changing the lookup table in the Update Cached Repetitive Motion Vectors Match step 1112. An example of an input that causes a lookup table to change is pressing the "pause" button, which may inhibit player inputs such as character movement, weapon firing animations, or other game-related movements. After applying motion vectors and optionally updating the lookup table, the client continues to track the player's input. After updating the lookup table in the Update Cache Repetitive Motion Vector Match step 1112, the player's incoming input is compared with the updated entries in the lookup table.

[0082] В любой момент времени в течение исполнения игры, изменение контекста для игрока может требовать изменения таблицы поиска. Например, игрок может осуществлять смену оружия, что требует переключения библиотеки кешированных движений от ранее взятого оружия на новое оружие. В приведенном в качестве примера варианте исполнения серверная игра может отслеживать конкретные игровые события. Эти события настроены посредством способов, известных в уровне техники, во время разработки игры и они могут быть отправлены посредством существующей системы отправки сообщений или предупреждения о событиях игры. Когда запущенная копия игры принимает одно из этих событий на стадии 1108 «Прием события во время исполнения» сообщение будет сгенерировано и передано клиенту на стадии 1110 «Отправка обновления контекста». Обновление контекста может быть отправлено для любого игрового события, которое изменяет взаимосвязь между вводом игрока и векторами движения, содержащимися в таблице поиска. Обновления контекста могут разрешать или запрещать инициацию посредством ввода игрока набора векторов движения, изменение векторов движения, связанных с указанным вводом, или иным образом добавлять или удалять связи между вводом игрока и векторами движения для компенсация движения на основании ввода игрока. Когда сообщение поступает клиенту, таблица поиска изменяется согласно изменившемуся контексту на стадии 1112 «Обновление соответствия кешированных повторяющихся векторов движения».[0082] At any point in time during execution of the game, a change in context for the player may require a change in the lookup table. For example, a player can perform a weapon swap, which requires switching the library of cached moves from a previously taken weapon to a new weapon. In an exemplary embodiment, the server game may monitor specific game events. These events are configured through methods known in the art during game development, and they can be sent through an existing game event messaging or alert system. When the running copy of the game receives one of these events in the Receive Runtime Event step 1108, a message will be generated and sent to the client in the Send Context Update step 1110. A context update can be sent for any game event that changes the relationship between the player's input and the motion vectors contained in the lookup table. Context updates may enable or disable player input from initiating a set of motion vectors, modifying motion vectors associated with said input, or otherwise adding or removing connections between player input and motion vectors to compensate for motion based on the player input. When the message arrives at the client, the lookup table is updated according to the changed context in the "Update Cache Repetitive Motion Vectors Match" step 1112.

[0083] На фиг. 12 показана схема, на которой изображен способ обновления соответствия векторов движения. Таблица 1200 поиска, которая хранилась в кеш-памяти 1202 клиента, используется клиентом для нахождения того, какие векторы движения связаны с указанным вводом игрока. Могут быть моменты времени в течение исполнения игры, в которые контекстуальные изменения приводят к изменению характера вводов игрока. Например, если игрок перемещается вперед, но сталкивается с препятствием, таким как стена, должно быть прекращено применение спрогнозированных векторов движения для перемещения вперед. Когда это происходит, сервер отправляет обновление контекста клиенту, как показано на стадии 1110 на фиг. 11. Это событие 1204 блокирования перемещения принимается, что сигнализирует клиенту об отключении связи между вводом 1206 для перемещения вперед и соответствующими векторами 1208 движения. Применение векторов движения для перемещения вперед прекращается, когда игрок использует ввод для перемещения вперед, пока другое событие от сервера не возобновит связь между вводом для перемещения вперед и векторами движения для перемещения вперед. В этом примере игра сгенерирует событие, когда перемещение игрока перестанет блокироваться, и передаст обновление контекста клиенту для повторного установления связи между вводом для перемещения вперед и векторами движения для перемещения вперед в таблице поиска.[0083] In FIG. 12 is a diagram showing a method for updating motion vector correspondence. Lookup table 1200, which was stored in client cache 1202, is used by the client to find which motion vectors are associated with a specified player input. There may be points in time during the execution of a game at which contextual changes result in a change in the nature of the player's inputs. For example, if a player is moving forward but encounters an obstacle such as a wall, the predicted motion vectors must be stopped from being used to move forward. When this happens, the server sends a context update to the client, as shown at step 1110 in FIG. 11. This move block event 1204 is received, which signals to the client that the communication between the forward move input 1206 and the corresponding motion vectors 1208 has been disabled. Application of forward motion vectors stops when the player uses forward motion vectors until another event from the server re-establishes the connection between forward motion vectors and forward motion vectors. In this example, the game will generate an event when the player's movement is no longer blocked and pass a context update to the client to re-establish the association between the move forward input and the move forward motion vectors in the lookup table.

[0084] В другом примере игрок держит плазменное ружье, но выполняет смену на дробовик. Библиотека 1210 векторов движения плазменного ружья хранится в кеш-памяти вместе с его векторами 1209 движения при стрельбе, которые соответствуют конкретному вводу 1211 для стрельбы. В кеш-памяти также хранятся библиотеки векторов движения для других видов оружия, включая дробовик 1212 и пистолет 1214. Когда клиент принимает событие 1216 на смену оружия от сервера, библиотека 1210 векторов движения плазменного ружья заменяется в таблице 1200 поиска на библиотеку 1212 векторов движения дробовика. Для предотвращения неправильного осуществления компенсации движения на основании ввода игрока во время смены оружия, два события могут использоваться совместно, чтобы сначала исключить библиотеку 1210 векторов движения плазменного ружья, пока воспроизводится анимация смены оружия, а затем включить две библиотеки векторов движения после завершения анимации смены оружия.[0084] In another example, the player is holding a plasma gun, but switches to a shotgun. A plasma gun motion vector library 1210 is stored in cache memory along with its firing motion vectors 1209 that correspond to a particular firing input 1211 . The cache also stores motion vector libraries for other weapons, including shotgun 1212 and pistol 1214. When the client receives a weapon change event 1216 from the server, the plasma gun motion vector library 1210 is replaced in the lookup table 1200 with the shotgun motion vector library 1212. To prevent motion compensation from being incorrectly implemented based on player input during a weapon change, the two events may be used together to first exclude the plasma gun motion vector library 1210 while the weapon change animation is playing, and then enable the two motion vector libraries after the weapon change animation has completed.

[0085] Для более продолжительных многокадровых векторов движения можно растянуть их применение таким образом, что последний кадр векторов движения применяется, когда последний кадр актуального видео принимается от сервера. Это позволит серверу догнать оцененное движение в момент, когда на клиенте заканчиваются кешированные векторы движения. Коэффициент масштабирования для векторов движения определяется как масштаб скорости воспроизведения, вычисляемый, как указано ниже.[0085] For longer multi-frame motion vectors, it is possible to stretch out their application such that the last frame of the motion vectors is applied when the last frame of the actual video is received from the server. This will allow the server to catch up with the estimated motion when the client runs out of cached motion vectors. The scaling factor for motion vectors is defined as the playback speed scale, calculated as follows.

[0086] Здесь задержка - время между начальным событием ввода игрока и приемом актуального видео на клиенте. Эта задержка включает время, необходимое для отправки ввода по сети на сервер, обработку на сервере, включая логику игры, логику рендеринга, время рендеринга ГП и время кодирования, а также время в сети для возврата видео обратно игроку. Задержка должна непрерывно измеряться в любой среде потоковой передачи игры. Согласно предпочтительному варианту осуществления компенсации движения на основании ввода игрока используется маркер соотнесения, как описано в предварительных заявках на выдачу патента США №62/488256 и 62/634464, для соотнесения ввода игрока и актуального видео. Перед отправкой входящего ввода игрока на сервер, маркер соотнесения прикрепляют в качестве уникального идентификатора. Когда видеокадр возвращается от сервера с маркером соотнесения, клиент сопоставляет уникальный идентификатор с предыдущим вводом. Это отдает сигнал клиенту прекратить оценку движения для соотнесенного ввода или отменить предыдущую оценку движения посредством методик наложения. Продолжительность кешированного отрезка анимации, или время кешированной анимации, может быть вычислено за счет умножения количества кадров в кешированной анимации на продолжительность каждого кадра.[0086] Here, the delay is the time between the initial player input event and the reception of the actual video on the client. This latency includes the time it takes to send input over the network to the server, processing on the server including game logic, rendering logic, GPU rendering time and encoding time, and network time to return the video back to the player. Latency should be continuously measured in any game streaming environment. In a preferred embodiment, motion compensation based on player input uses a correlation marker, as described in US Provisional Patent Applications 62/488,256 and 62/634,464, to correlate the player's input with the actual video. Before the player's incoming input is sent to the server, a mapping token is attached as a unique identifier. When a video frame is returned from the server with a correlation token, the client matches the unique identifier with the previous input. This signals the client to stop estimating motion for the related input or cancel previous motion evaluation through overlay techniques. The duration of a cached animation segment, or cached animation time, can be calculated by multiplying the number of frames in the cached animation by the duration of each frame.

[0087] На фиг. 13 приведенная в качестве примера анимация, содержащая 10 кадров, используется для компенсации движения на основании ввода игрока в игре с частотой 60 кадров в секунду и задержкой 100 мс. Когда ввод игрока инициирует компенсацию движения на основании ввода игрока, масштаб скорости воспроизведения вычисляется для кешированных векторов движения, как указано ниже.[0087] In FIG. 13, an example animation containing 10 frames is used to compensate for motion based on player input in a game running at 60 frames per second and 100 ms latency. When player input triggers motion compensation based on player input, the playback speed scale is calculated for the cached motion vectors as follows.

[0088] Ввод игрока был принят в момент времени 0 мс. Скорость воспроизведения векторов движения масштабируют 1300 посредством вычисленного масштаба скорости воспроизведения. Первый кадр векторов движения применяют к следующему доступному кадру в видеопотоке от сервера. Кадры масштабированных векторов интерполируют для сохранения плавности анимации. Поскольку кадры векторов движения масштабируют на нескольких кадрах, интерполяция представляет собой способ, который может использоваться для вычисления того, «насколько» вектор движения должен быть применен в любом указанном кадре. В приведенном в качестве примера варианте исполнения может использоваться линейная интерполяция, основанная на вычисленном масштабе скорости воспроизведения. Для этого примера вычисленный масштаб скорости воспроизведения составляет 0,625, что означает, что один набор векторов движения будет растянут по 1,6 кадров отображения. Интерполяция представляет собой способ вычисления того, насколько вектор движения должен быть применен в указанном кадре. То есть с помощью интерполяции вычисляют, насколько переместить макроблок по вектору движения, когда набор векторов движения растянут по нескольким кадрам отображения. Только часть первых масштабированных векторов движения должна быть применена в первом кадре отображения на моменте времени 17 мс, равном масштабу скорости воспроизведения, составляющем 0,625. Во втором кадре отображения на моменте времени 33 мс применяется оставшаяся часть первых масштабированных векторов движения, вычисленных как 1-0,625=0,375, затем применяется первая часть вторых масштабированных векторов движения, вычисленная как результат вычитания из масштаба скорости воспроизведения оставшейся части первых масштабированных векторов движения или 0,625-0,375=0,25. В третьем кадре отображения на моменте времени 50 мс продолжает применяться второй набор масштабированных векторов движения, причем макроблоки перемещаются следующие 62,5% по векторам движения. В четвертом кадре отображения на моменте времени 67 мс применяется оставшаяся часть вторых масштабированных векторов движения, вычисленных как 1-0,25-0,625=0,125, и применяется первая часть третьих масштабированных векторов движения, вычисленная как результат вычитания из масштаба скорости воспроизведения оставшейся части вторых масштабированных векторов движения: 0,625-0,125=0,5. Линейная интерполяция продолжается при применении масштабированных векторов движения.[0088] Player input was accepted at time 0 ms. The rendering speed of the motion vectors is scaled 1300 by the calculated rendering speed scale. The first frame of motion vectors is applied to the next available frame in the video stream from the server. Frames of scaled vectors are interpolated to maintain smooth animation. Because motion vector frames are scaled across multiple frames, interpolation is a technique that can be used to calculate "how much" a motion vector should be applied in any given frame. An exemplary embodiment may use linear interpolation based on the calculated playback speed scale. For this example, the calculated playback speed scale is 0.625, which means that one set of motion vectors will be stretched across 1.6 display frames. Interpolation is a method of calculating how much motion vector should be applied in a specified frame. That is, using interpolation, they calculate how much to move the macroblock along the motion vector when the set of motion vectors is stretched over several display frames. Only a portion of the first scaled motion vectors should be applied in the first display frame at 17 ms, equal to the playback speed scale of 0.625. The second display frame at 33 ms applies the remainder of the first scaled motion vectors, calculated as 1-0.625=0.375, then applies the first portion of the second scaled motion vectors, calculated as the result of subtracting the remainder of the first scaled motion vectors from the playback speed scale, or 0.625 -0.375=0.25. In the third display frame at 50 ms, the second set of scaled motion vectors continues to be applied, with macroblocks moving the next 62.5% along the motion vectors. The fourth display frame at 67 ms applies the remainder of the second scaled motion vectors, calculated as 1-0.25-0.625=0.125, and applies the first portion of the third scaled motion vectors, calculated as the result of subtracting the remainder of the second scaled motion vectors from the rendering speed scale. motion vectors: 0.625-0.125=0.5. Linear interpolation continues when scaled motion vectors are applied.

[0089] Многокадровые векторы движения могут отправлять маркер соотнесения для каждого кадра кешированной анимации для соотнесения каждого кадра оцененного движения с будущим актуальным видео.[0089] Multi-frame motion vectors may send a correlation marker for each frame of the cached animation to correlate each frame of the estimated motion with a future actual video.

[0090] Задержка будет сильно зависеть от сетевого пути и архитектуры между клиентом и сервером. В этом примере используется задержка 100 мс, но размер задержки может варьировать от десятков до сотен миллисекунд. Меньшие задержки обеспечивают лучшее впечатление для игрока, но методики компенсации движения на основании ввода игрока могут помочь скрыть влияние большой задержки в некоторых случаях. После задержки 1304 принимают 1302 актуальное видео. Для серверов с граничным расположением или серверов, которые физически находятся близко к потребителям, время задержки может составлять не более 30 мс. Для более обычных расположений сервера более вероятна задержка 100 мс. Актуальное видео сохраняет исходную продолжительность анимации 1306 поскольку оно не было масштабировано. Актуальное видео применяется в соответствии с методиками компенсации движения на основании ввода игрока.[0090] Latency will be highly dependent on the network path and architecture between the client and server. This example uses a delay of 100 ms, but the size of the delay can vary from tens to hundreds of milliseconds. Lower latencies provide a better experience for the player, but motion compensation techniques based on player input can help mask the impact of high latency in some cases. After a delay 1304, the current video is received 1302. For edge servers or servers that are physically close to consumers, latency can be as low as 30 ms. For more common server locations, 100ms latency is more likely. The actual video retains the original animation length of 1306 because it has not been scaled. The actual video is applied according to motion compensation techniques based on the player's input.

[0091] Если клиент не может идеально осуществить наложение предыдущей компенсации движения, стандарт кодирования Н.264 обеспечивает резервную функцию отсечения по плоскости, которая может исправить любые временно распространившиеся ошибки. На основании настроек профиля Н.264 каждая плоскость кодируется как внутренняя плоскость (плоскость I) и отправляться по скользящему графику с определенной частотой. Поскольку внутренние плоскости не содержат векторов движения, векторы движения для наложения должны применяться только тогда, когда актуальные векторы движения поступают в плоскости р. Это предотвращает применение векторов для наложения в макроблоках, которые появились в плоскости I, перед возвратом маркированного кадра от сервера.[0091] If the client cannot perfectly apply the previous motion compensation overlay, the H.264 coding standard provides a fallback flat-clipping function that can correct any transient errors. Based on the H.264 profile settings, each plane is encoded as an internal plane (I plane) and sent on a sliding schedule at a certain frequency. Since internal planes do not contain motion vectors, motion vectors for overlay should only be applied when actual motion vectors arrive in the p plane. This prevents overlay vectors from being applied to macroblocks that appeared in the I plane before returning the marked frame from the server.

[0092] Представленное выше описание и фигуры следует рассматривать только как приведенные в целях иллюстрации принципов настоящего изобретения. Настоящее изобретение не ограничено предпочтительным вариантом осуществления и может быть реализовано различными способами, которые будут очевидны специалисту в данной области техники. Специалистам в данной области техники будут очевидны многочисленные области применения настоящего изобретения. Таким образом, настоящее изобретение не ограничено конкретными раскрытыми примерами или точной конструкцией и принципом работы, которые показаны и описаны. Наоборот, могут использоваться все подходящие модификации и эквиваленты, которые находятся в пределах объема настоящего изобретения.[0092] The above description and figures should be considered only as being given for the purpose of illustrating the principles of the present invention. The present invention is not limited to the preferred embodiment and can be implemented in various ways that will be apparent to one skilled in the art. Numerous applications of the present invention will be apparent to those skilled in the art. Thus, the present invention is not limited to the specific examples disclosed or to the precise construction and operating principle as shown and described. Conversely, all suitable modifications and equivalents may be used that are within the scope of the present invention.

Claims (29)

1. Выполняемый на компьютере способ оценки движения, предусматривающий следующие стадии:1. A computer-based method for assessing motion, which involves the following stages: передачу таблицы поиска, состоящей из одного или нескольких вводов пользователя и одного или нескольких связанных векторов движения;transmitting a lookup table consisting of one or more user inputs and one or more associated motion vectors; передачу команды на обращение к таблице поиска для нахождения соответствующих векторов движения после приема ввода игрока;transmitting a command to access a lookup table to find corresponding motion vectors after receiving the player's input; передачу команды на связывание уникального маркера с соответствующими векторами движения из таблицы поиска и добавление маркированных векторов движения в очередь;transmitting a command to associate a unique marker with corresponding motion vectors from the lookup table and adding the marked motion vectors to the queue; передачу кадра, содержащего векторы движения, с уникальным идентифицирующим маркером; иtransmitting a frame containing motion vectors with a unique identifying marker; And передачу команды на удаление из очереди векторов движения, которые характеризуются наличием маркера, связанного с маркированным кадром, принятым от сервера, при этом, когда сервер передает кодированные видеокадры клиенту, клиент получает команду на декодирование видеокадров для оценки движения.transmitting a command to remove motion vectors from the queue, which are characterized by the presence of a marker associated with the marked frame received from the server, while when the server transmits encoded video frames to the client, the client receives a command to decode the video frames for motion estimation. 2. Способ по п. 1, в котором один или несколько векторов движения представляют собой одно или несколько векторных полей.2. The method of claim 1, wherein the one or more motion vectors are one or more vector fields. 3. Способ по п. 2, в котором одно или несколько векторных полей состоят из вектора движения для каждого макроблока в кадре.3. The method of claim 2, wherein the one or more vector fields consist of a motion vector for each macroblock in the frame. 4. Способ по п. 1, дополнительно предусматривающий стадию применения функции сглаживания к маркированным векторам движения.4. The method according to claim 1, further comprising the step of applying a smoothing function to the marked motion vectors. 5. Способ по п. 1, дополнительно предусматривающий стадию применения деблочного фильтра к макроблокам, содержащим немаркированные векторы движения, в кадре.5. The method of claim 1, further comprising the step of applying a deblocking filter to macroblocks containing unlabeled motion vectors in the frame. 6. Способ по п. 1, в котором маркированные векторы движения применяют один раз.6. The method according to claim 1, in which the marked motion vectors are applied once. 7. Способ по п. 1, в котором сервер передает данные клиенту как битовый поток.7. The method according to claim 1, in which the server transmits the data to the client as a bit stream. 8. Способ по п. 1, в котором остаточные кадры не обрабатывают.8. The method according to claim 1, in which the residual frames are not processed. 9. Способ по п. 1, в котором кодированный видеокадр проходит через энтропийное кодирование и обратное квантование.9. The method according to claim 1, in which the encoded video frame goes through entropy coding and inverse quantization. 10. Способ по п. 1, дополнительно предусматривающий стадию применения процесса наложения к векторам движения кодированного видеокадра.10. The method of claim 1, further comprising the step of applying an overlay process to the motion vectors of the encoded video frame. 11. Система для оценки движения, в которой сервер по сети:11. A system for motion estimation, in which the server over the network: передает клиенту команду на обращение к таблице поиска для нахождения соответствующих векторов движения после приема ввода игрока;instructs the client to access the lookup table to find appropriate motion vectors after receiving the player's input; передает клиенту команду на связывание уникального маркера с соответствующими векторами движения из таблицы поиска и добавляет маркированные векторы движения в очередь;sends a command to the client to associate a unique marker with the corresponding motion vectors from the lookup table and adds the marked motion vectors to the queue; передает клиенту кадр, содержащий векторы движения, с уникальным идентифицирующим маркером; иtransmits to the client a frame containing motion vectors with a unique identifying marker; And передает клиенту команду на удаление из очереди векторов движения, которые характеризуются наличием маркера, связанного с маркированным кадром, принятым от сервера, при этом, когда сервер передает кодированные видеокадры клиенту, клиент получает команду на декодирование видеокадров для оценки движения.transmits to the client a command to remove motion vectors from the queue, which are characterized by the presence of a marker associated with the marked frame received from the server, and when the server transmits encoded video frames to the client, the client receives a command to decode the video frames for motion estimation. 12. Система по п. 11, в которой один или несколько векторов движения представляют собой одно или несколько векторных полей.12. The system according to claim 11, in which the one or more motion vectors represent one or more vector fields. 13. Система по п. 12, в которой одно или несколько векторных полей состоят из вектора движения для каждого макроблока в кадре.13. The system of claim 12, wherein the one or more vector fields consist of a motion vector for each macroblock in the frame. 14. Система по п. 11, в которой функция сглаживания применяется к маркированным векторам движения.14. The system according to claim 11, in which the smoothing function is applied to the marked motion vectors. 15. Система по п. 11, в которой деблочный фильтр применяется к макроблокам, содержащим немаркированные векторы движения, в кадре.15. The system of claim 11, wherein the deblocking filter is applied to macroblocks containing unlabeled motion vectors in the frame. 16. Система по п. 11, в которой маркированные векторы движения применяются один раз.16. The system according to claim 11, in which the marked motion vectors are applied once. 17. Система по п. 11, в которой сервер передает данные клиенту как битовый поток.17. The system according to claim 11, in which the server transmits data to the client as a bitstream. 18. Система по п. 11, в которой остаточные кадры не обрабатываются.18. The system according to claim 11, in which residual frames are not processed. 19. Система по п. 11, в которой кодированный видеокадр проходит через энтропийное кодирование и обратное квантование.19. The system according to claim 11, in which the encoded video frame goes through entropy coding and inverse quantization. 20. Система по п. 11, в которой процесс наложения применяется к векторам движения кодированного видеокадра.20. The system of claim 11, wherein the overlay process is applied to motion vectors of the encoded video frame.