CN116583332A - 云游戏应用程序中的显示控件 - Google Patents

Abstract

一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的显示的方法，该方法包括：向服务器发送(301A)表示用户动作的信息；接收(305B)表示根据该用户动作预测的该游戏的预测状态的至少一个帧；获得允许确定所述至少一个帧是否对应于该用户动作的信息；以及；在该至少一个帧对应于所述用户动作的情况下，根据执行此用户动作的时间和所述信息来确定何时显示该至少一个帧中的一个帧。

Description

云游戏应用程序中的显示控件

1.技术领域

本发明实施方案中的至少一个实施方案整体涉及一种用于控制云游戏应用程序中的图像编码的方法和装置。

2.背景技术

云游戏允许将游戏渲染过程部分地卸载到位于云中的一些远程游戏服务器。

图1示意性地表示云游戏基础结构。基本上，需要昂贵且耗电的设备的游戏引擎10和3D图形渲染11由云中的服务器1实现。然后用规则视频编码器12将生成的帧传统地编码在视频流中，并经由网络3将其发送到用户游戏系统2。然后，在用户游戏系统2侧上用规则/标准视频解码器20对视频流进行解码，用于在显示设备上渲染。附加的轻质模块21负责管理玩家交互命令(即，负责注册用户动作)。

游戏应用程序中用户舒适度的一个关键因素是被称为运动到光子(motion-to-photon)的延迟，即用户动作(运动)与该动作的结果在显示设备上的显示(光子)之间的延迟。

图2示意性地描述了在传统游戏应用程序中的典型运动到光子路径。

有关图2所描述的步骤全部由用户游戏系统(诸如PC或控制台)实现。这里我们假设用户游戏系统包括输入设备(诸如游戏手柄)和显示设备。

在步骤200中，由输入设备对用户动作进行注册并且将其发送到主处理模块。

在步骤202中，游戏引擎使用所注册的动作来计算下一个游戏状态(或下一些游戏状态)。游戏状态包括用户状态(位置等)，以及所有其他实体状态，所有其他实体状态可以是由游戏引擎计算的或者可以是在多玩家游戏的情况下的外部状态。

在步骤203中，从游戏状态计算帧渲染。在步骤206中，首先将所得的帧放置于视频缓冲器中，然后在步骤207中，将视频缓冲器的内容显示在显示设备上。

上述步骤中的每个步骤都引入了处理延迟。在图2中，带有点背景的框表示由于硬件计算而引入延迟的步骤。一般来讲，该延迟是固定的、小的并且不会轻易改变。带有白色背景的框表示由于软件计算而引入延迟的步骤。一般来讲，该延迟是较长的并且能够被动态地调适。

总之，运动到光子的延迟通常低于“100”毫秒(ms)。通常，当延迟高于“200”ms时，用户不适开始。需注意，对于基于使用头戴式耳机可视化的虚拟现实的游戏而言，通常需要较低的延迟以获得良好的用户舒适度。

图3示意性地描述了云游戏应用程序中的典型运动到光子路径。

有关图3所描述的步骤不再由单个设备实现，而是如图1所示，需要服务器1与用户游戏系统2(即，客户端系统)之间的协作。

步骤200由用户游戏系统2执行。

在步骤301中，经由网络3将表示用户动作的信息传输到服务器1。

游戏引擎202步骤和渲染203步骤由服务器1实现。

渲染之后在步骤304中由视频编码器12进行视频编码。

然后在步骤305中，由视频编码器12生成的视频流经由网络3传输到用户游戏系统2，并且在步骤306中由视频解码器20解码。

与图2的过程相比，引入了附加的延迟：

·传输延迟。传输延迟取决于网络的连接质量。该延迟的范围可以从几ms到几“100”ms。

·编码器延迟：在此类框架中，编码器典型地用于低延迟配置中，即只要帧到达，就对其进行编码并且在视频流中进行发送。当实时视频编码器在硬件中实现时，该视频编码器通常在几ms内对帧进行编码。

·解码器延迟：典型的视频解码器可以在几ms内对帧进行解码。

可以看出，附加的延迟(特别是传输延迟)可能潜在地增加全局延迟，使得所述全局延迟对于用户而言变得无法接受。此外，由于网络状态改变，延迟方差也增加了。

希望提出允许克服上述问题的解决方案。具体地，希望提出一种有助于减少游戏应用程序中的延迟的方法和装置。

3.发明内容

在第一方面，本发明实施方案中的一个或多个实施方案提供了一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的显示的方法，该方法包括：向服务器发送表示用户动作的信息；接收表示根据该用户动作预测的该游戏的预测状态的至少一个帧；获得允许确定所述至少一个帧是否对应于该用户动作的信息；以及；在该至少一个帧对应于所述用户动作的情况下，根据执行此用户动作的时间和所述信息来确定何时显示该至少一个帧中的一个帧。

在一个实施方案中，所述信息表示在执行此用户动作的时间与显示对应于所述用户动作的帧的时间之间的延时。

在一个实施方案中，该方法由用户系统执行，并且其中该信息允许通过允许将该用户系统的时钟与该服务器的时钟同步来确定何时显示该至少一个帧中的一个帧。

在一个实施方案中，以包括元数据的编码视频流的形式接收该至少一个帧，所述元数据包括所述信息。

在一个实施方案中，传输到该服务器的表示该用户动作的该信息包括该用户动作的标识符，并且该元数据包括所述标识符。

在一个实施方案中，该元数据包括表示延时的信息，该延时固定预测对应于该用户动作的预测状态的时间。

在一个实施方案中，接收多个帧，每个帧表示根据该用户动作预测的该游戏的预测状态，并且该方法还包括根据表示该游戏的实际状态的信息与表示由该多个帧中的帧表示的预测状态的信息之间的比较来确定显示该多个帧中的哪个帧。

在一个实施方案中，对于该多个帧中的每个帧，该元数据包括表示由所述帧表示的该游戏的该状态的信息。

在一个实施方案中，表示该游戏的实际状态的信息和表示由该多个帧中的帧表示的预测状态的信息是表示用户动作序列的信息。

在第二方面，本发明实施方案中的一个或多个实施方案提供了一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的显示的方法，该方法包括：从用户系统接收表示用户动作的信息，该信息包括所述用户动作的标识符；根据该用户动作预测该游戏的至少一个状态；对于至少一个预测状态，渲染表示所述预测状态的帧；在视频流的一部分中用包括所述用户动作的该标识符的元数据编码至少一个渲染帧；以及将视频流的该部分传输到该用户系统。

在一个实施方案中，该元数据包括表示延时的信息，该延时固定预测对应于该用户动作的预测动作的时间。

在一个实施方案中，用包括表示每个预测状态的信息的元数据来渲染和编码多个帧，每个帧表示根据该用户动作预测的该游戏的预测状态。

在一个实施方案中，表示该游戏的预测状态的该信息表示用户动作序列。

在一个实施方案中，该多个帧的该编码使用多层编码，该多层编码考虑到表示该游戏的至少一个真实状态或预测状态的信息。

在第三方面，本发明实施方案中的一个或多个实施方案提供了一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的编码的方法，该方法包括：从用户系统接收表示用户动作的信息，该信息包括所述用户动作的标识符；根据该用户动作预测该游戏的被称为预测状态的多个状态；对于每个预测状态，渲染表示所述预测状态的帧；以及编码该渲染帧，每个帧在视频流的多个层中的一个层中使用多层编码进行编码，该多层编码考虑到表示该游戏的至少一个真实状态或预测状态的信息。

在一个实施方案中，表示预测状态的信息是所述预测状态的概率。

在一个实施方案中，对应于最高概率的帧在被称为基底层的层中被编码，在没有来自任何其他层的任何预测的情况下被编码，并且该帧可用作某个其他层的预测的参考。

在一个实施方案中，为每个层分配比特率，以根据所述层的概率编码所述层。

在一个实施方案中，表示真实状态的信息是表示由多个帧被传输到的用户系统显示的所述多个帧中的帧的信息。

在一个实施方案中，根据由用户系统显示的多个帧中的帧来确定提供用于第二层的当前帧的时间预测的帧的第一层。

在一个实施方案中，表示由用户系统显示的多个帧中的帧的信息是表示从该用户系统所接收的用户动作的信息。

在一个实施方案中，表示预测状态的信息包括该预测状态之间的差异。

在第四方面，本发明实施方案中的一个或多个实施方案提供了一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的显示的设备，该设备包括：用于向服务器发送表示用户动作的信息的装置；用于接收表示根据该用户动作预测的该游戏的预测状态的至少一个帧的装置；获得允许确定所述至少一个帧是否对应于该用户动作的信息的装置；以及；用于以下操作的装置：在所述至少一个帧对应于所述用户动作的情况下，根据执行此用户动作的时间和所述信息来确定何时显示所述至少一个帧中的一个帧。

在一个实施方案中，所述信息表示在执行此用户动作的时间与显示对应于所述用户动作的帧的时间之间的延时。

在一个实施方案中，该信息通过允许将该设备的时钟与该服务器的时钟同步来允许确定何时显示该至少一个帧中的一个帧。

在一个实施方案中，以包括元数据的编码视频流的形式接收该至少一个帧，所述元数据包括所述信息。

在一个实施方案中，传输到该服务器的表示该用户动作的该信息包括该用户动作的标识符，并且该元数据包括所述标识符。

在一个实施方案中，该元数据包括表示延时的信息，该延时固定预测对应于该用户动作的预测动作的时间。

在一个实施方案中，接收多个帧，每个帧表示根据用户动作预测的游戏的预测状态，并且其中该设备还包括用于根据表示该游戏的实际状态的信息与表示由该多个帧中的帧表示的预测状态的信息之间的比较来确定显示该多个帧中的哪个帧的装置。

在一个实施方案中，对于该多个帧中的每个帧，该元数据包括表示由所述帧表示的该游戏的该状态的信息。

在一个实施方案中，表示该游戏的实际状态的信息和表示由该多个帧中的帧表示的预测状态的信息是表示用户动作序列的信息。

在第五方面，本发明实施方案中的一个或多个实施方案提供了一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的显示的设备，该设备包括：用于从用户系统接收表示用户动作的信息的装置，该信息包括所述用户动作的标识符；用于根据该用户动作预测该游戏的至少一个状态的装置；用于对于至少一个预测状态，渲染表示所述预测状态的帧的装置；用于在视频流的一部分中用包括所述用户动作的该标识符的元数据编码至少一个渲染帧的装置；和用于将视频流的该部分传输到该用户系统的装置。

在一个实施方案中，该元数据包括表示延时的信息，该延时固定预测对应于该用户动作的预测动作的时间。

在一个实施方案中，用包括表示每个预测状态的信息的元数据来渲染和编码多个帧，每个帧表示根据该用户动作预测的该游戏的预测状态。

在一个实施方案中，表示该游戏的预测状态的该信息表示用户动作序列。

在一个实施方案中，该多个帧的该编码使用多层编码，该多层编码考虑到表示该游戏的至少一个真实状态或预测状态的信息。

在第六方面，本发明实施方案中的一个或多个实施方案提供了一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的编码的设备，该设备包括：用于从用户系统接收表示用户动作的信息的装置，该信息包括所述用户动作的标识符；用于根据该用户动作预测该游戏的被称为预测状态的多个状态的装置；用于对于每个预测状态渲染表示所述预测状态的帧的装置；和用于编码该渲染帧的装置，每个帧在视频流的多个层中的一个层中使用多层编码进行编码，该多层编码考虑到表示该游戏的至少一个真实状态或预测状态的信息。

在一个实施方案中，表示预测状态的信息是所述预测状态的概率。

在一个实施方案中，对应于最高概率的帧在被称为基底层的层中被编码，在没有来自任何其他层的任何预测的情况下被编码，并且该帧可用作某个其他层的预测的参考。

在一个实施方案中，为每个层分配比特率，以根据所述层的概率编码所述层。

在一个实施方案中，表示真实状态的信息是表示由多个帧被传输到的用户系统显示的所述多个帧中的帧的信息。

在一个实施方案中，根据由用户系统显示的多个帧中的帧来确定提供用于第二层的当前帧的时间预测的帧的第一层。

在一个实施方案中，表示由用户系统显示的多个帧中的帧的信息是表示从该用户系统所接收的用户动作的信息。

在一个实施方案中，表示预测状态的信息包括该预测状态之间的差异。

在第七方面，本发明实施方案中的一个或多个实施方案提供了一种装置，该装置包括根据第四方面、第五方面或第六方面所述的设备。

在第八方面，本发明实施方案中的一个或多个实施方案提供了一种信号，该信号是由第二方面的方法或由第五方面或第六方面的设备生成的。

在第九方面，本发明实施方案中的一个或多个实施方案提供了一种计算机程序，该计算机程序包括用于实现根据第一方面、第二方面或第三方面所述的方法的程序代码指令。

在第十方面，本发明实施方案中的一个或多个实施方案提供了一种非暂态信息存储介质，该非暂态信息存储介质存储用于实现根据第一方面、第二方面或第三方面所述的方法的程序代码指令。

4.附图说明

图1A示意性地表示云游戏基础结构；

图1B示意性地示出了能够实现各种方面和实施方案的处理模块的硬件架构的示例；

图1C示出了在其中实现各种方面和实施方案的服务器的示例的框图；

图1D示出了在其中实现各种方面和实施方案的用户游戏系统的示例的框图；

图2示意性地描述了传统游戏应用程序中的典型运动到光子路径；

图3示意性地描述了云游戏应用程序中的典型运动到光子路径；

图4A和图4B分别表示在没有状态预测和有状态预测的情况下执行图2的方法的示例；

图5示意性地示出了用于减少云游戏应用程序中的延迟的方法的实施方案的示例；

图6示意性地示出了其中发生预测误差的状态预测过程；

图7表示对游戏的状态进行建模的二态马尔可夫模型；

图8示意性地示出了多层视频编码的示例；并且，

图9示出了编码步骤的应用程序的示例。

5.具体实施方式

在下文中，在网络(云)游戏上下文中呈现各种实施方案。然而，这些实施方案也适用于其他上下文，并且具体地适用于任何基于网络的应用程序，其中用户在客户端设备上执行动作，并且此动作的结果由远程服务器计算并由客户端设备从远程服务器接收。这里的目的是改善应用程序的流动性。

各种方法解决了过去延迟减少的问题。这些方法可被分为两类：

·基于状态预测的方法；和，

·基于近似渲染的方法。

基于状态预测的方法(诸如基于扩展卡尔曼滤波器(EKF)或基于粒子滤波器的方法)在于预测游戏的未来状态以便在游戏的当前实际状态之前计算渲染。在图2的过程中，引入了状态预测201的可选步骤。

图4A和图4B分别表示在没有状态预测步骤201和有状态预测步骤的情况下执行图2的方法的示例。

在图4A中，在时间t＝0，用户例如按下输入设备上的向前按钮。该动作被解释为速度v为“1”。从速度v＝1和先前位置x0＝0计算新位置。现在新位置是x1＝1。从该新位置，执行渲染并且将其发送到显示设备。在时间t＝3，用户可以看到其动作的结果，其中延迟为“3”(从t＝0到t＝3)。最佳地，在没有任何延迟的情况下，用户会在t＝0时看到带有位置“0”的帧，在t＝1时看到带有位置“1”的帧，等等。

在图4B中，在时间t＝0，用户按下输入设备上的向前按钮。该动作被解释为速度v为“1”。从速度v＝1和先前位置x0＝0计算新的“实际”位置。现在新的“实际”位置是x1＝1。使用函数f()，从实际位置和其它当前状态信息(例如这里是速度)计算预测位置(步骤201)。预测位置旨在预测在时间“t”＝3的位置，而不是仅使用当前状态。这里，预测位置是x1’＝3。从预测位置，执行渲染并且将其发送到显示器。在时间t＝3，用户可以看到其动作的结果，其中延迟为“3”(从t＝0到t＝3)，但状态预测“擦除”该延迟并且用户在时间t＝3看到其动作的结果(这里假设状态预测因子正确地预测了状态演化)。最佳地，如果状态预测因子是“完美的”，则用户将在t＝0时看到带有位置“0”的帧，在t＝1时看到带有位置“1”的帧，等等。在实施过程中，函数f()基于当前状态值和用户运动模型的组合。典型示例在于使用卡尔曼滤波来预测此类运动。在实施过程中，使用更复杂的预测因子(模型预测控制)或ad-hoc模型。近来，基于深度学习的方法允许在视频帧预测上的显著改进。例如，在文档“C.Finn,I.Goodfellow and S.Levine,unsupervised learning for physicalinteraction through video prediction,in Advances in Neural InformationProcessing Systems,2012”(在下文中被称为FINN)中，建立神经网络(NN)以使用过去帧和动作/状态作为输入来预测视频序列的未来帧。FINN引入了一类视频预测模型，该类视频预测模型直接使用来自先前帧的外观信息来构建像素预测。此类模型通过首先预测图像片段的运动并且然后经由掩蔽合并这些预测来计算下一帧。

在图2中通过插入步骤204和步骤205来表示基于近似渲染的方法的示例。此类方法被称为时间扭曲或异步时间扭曲(ATW)。

步骤204在于获得比在步骤200中获得的用户动作更新的新用户动作。

在步骤205中，在步骤203处生成的帧(基于在步骤200处获得的用户动作)和该新动作用于创建将由步骤202和步骤203使用新用户动作渲染的帧的近似版本。快速渲染过程用于生成所述近似版本。典型的快速渲染过程在于仅从用户旋转运动计算扭曲图像(即，扭曲变换可以被计算为单应性变换)。更先进的方法还使用其他信息(深度图、动态对象位置等)来改善近似渲染。

图1B示意性地示出了能够实现由服务器1实现的游戏应用程序的步骤或由用户游戏系统2实现的游戏应用程序的步骤的处理模块100的硬件架构的示例。因此，该处理模块被包括在服务器1中或用户游戏系统2中。作为非限制性示例，处理模块100包括由通信总线1005连接的以下项：包含一个或多个微处理器的处理器或CPU(中央处理单元)1000、通用计算机、专用计算机和基于多核心架构的处理器；随机存取存储器(RAM)1001；只读存储器(ROM)1002；存储单元1003，该存储单元可包括非易失性存储器和/或易失性存储器，包括但不限于电可擦除可编程只读存储器(EEPROM)、只读存储器(ROM)、可编程只读存储器(PROM)、随机存取存储器(RAM)、动态随机存取存储器(DRAM)、静态随机存取存储器(SRAM)、闪存、磁盘驱动器和/或光盘驱动器，或者存储介质读取器，诸如SD(安全数字)卡读取器和/或硬盘驱动器(HDD)和/或可访问网络的存储设备；至少一个通信接口1004，该至少一个通信接口用于与其他模块、设备或装备交换数据。通信接口1004可包括但不限于被配置为通过通信信道传输和接收数据的收发器。通信接口1004可包括但不限于调制解调器或网卡。

如果处理模块100实现由服务器1执行的游戏应用程序的步骤，则通信接口1004启用例如处理模块100以从用户游戏系统2接收表示用户动作的信息并且将嵌入所编码的帧和元数据的视频流传输到所述用户游戏系统2。如果处理模块100实现由用户游戏系统2执行的游戏应用程序的步骤，则通信接口1004启用例如处理模块100以将表示用户动作的信息发送到服务器1并且接收包括所编码的帧和元数据的视频流。

处理器100能够执行从ROM 1002、外部存储器(未示出)、存储介质或通信网络加载到RAM 1001中的指令。当处理模块100上电时，处理器1000能够从RAM 1001读取指令并执行这些指令。这些指令形成计算机程序，该计算机程序导致例如由处理器1000实现由服务器1执行的游戏应用程序的步骤(如下文在图5的左侧部分中所描述的)或者由用户游戏系统2执行的游戏应用程序的步骤(如下文在图5的右侧部分中所述)。

所述游戏应用程序的全部或一些算法和步骤可通过由诸如DSP(数字信号处理器)或微控制器的可编程机器执行一组指令而以软件形式实现，或者可通过诸如FPGA(现场可编程门阵列)或ASIC(专用集成电路)的机器或专用部件而以硬件形式实现。

图1D示出了在其中实现各种方面和实施方案的用户游戏系统2的示例的框图。用户游戏系统2可实施为包括以下描述的各种部件的设备，并且被配置为执行本文档中所述的方面和实施方案中的一者或多者。此类设备的示例包括但不限于各种电子设备，诸如个人计算机、膝上型计算机、智能电话、平板计算机、游戏控制台和头戴式显示器。用户游戏系统2的元件可单独地或组合地具体体现在单个集成电路(IC)、多个IC和/或分立部件中。例如，在至少一个实施方案中，用户游戏系统2包括实现关于用户游戏系统的游戏应用程序的步骤的一个处理模块100。在各种实施方案中，用户游戏系统2经由例如通信总线或通过专用输入端口和/或输出端口通信地耦接到一个或多个其他系统或其他电子设备。在各种实施方案中，用户游戏系统2被配置为实现本文档中所述的方面中的一个或多个方面。

处理模块100的输入可通过如框101所示的各种输入模块来提供。此类输入模块包括但不限于：(i)射频(RF)模块，其接收例如由广播器通过空中传输的RF信号；(ii)分量(COMP)输入模块(或一组COMP输入模块)；(iii)通用串行总线(USB)输入模块；和/或(iv)高清晰度多媒体接口(HDMI)输入模块。图1D中未示出的其他示例包括复合视频。

在各种实施方案中，框101的输入模块具有如本领域所已知的相关联的相应输入处理元件。例如，RF模块可与适用于以下的元件相关联：(i)选择所需的频率(也称为选择信号，或将信号频带限制到一个频带)，(ii)下变频选择的信号，(iii)再次频带限制到更窄频带以选择(例如)在某些实施方案中可称为信道的信号频带，(iv)解调下变频和频带限制的信号，(v)执行纠错，以及(vi)解复用以选择所需的数据包流。各种实施方案的RF模块包括用于执行这些功能的一个或多个元件，例如频率选择器、信号选择器、频带限制器、信道选择器、滤波器、下变频器、解调器、纠错器和解复用器。RF部分可包括执行这些功能中的各种功能的调谐器，这些功能包括例如下变频接收信号至更低频率(例如，中频或近基带频率)或至基带。在一个机顶盒实施方案中，RF模块及其相关联的输入处理元件接收通过有线(例如，电缆)介质发射的RF信号，并且通过滤波、下变频和再次滤波至所需的频带来执行频率选择。各种实施方案重新布置上述(和其他)元件的顺序，移除这些元件中的一些元件，和/或添加执行类似或不同功能的其他元件。添加元件可包括在现有元件之间插入元件，例如，插入放大器和模数变换器。在各种实施方案中，RF模块包括天线。

另外，USB和/或HDMI模块可包括用于跨USB和/或HDMI连接将用户游戏系统2连接到其他电子设备的相应接口处理器。应当理解，输入处理(例如，Reed-Solomon纠错)的各个方面可根据需要例如在单独的输入处理IC内或在处理模块100内实现。类似地，USB或HDMI接口处理的各方面可根据需要在单独的接口IC内或在处理模块100内实现。解调、纠错和解复用的流被提供给处理模块100。

用户游戏系统2的各种元件可设置在集成壳体内。在集成壳体内，各种元件可使用合适的连接布置(例如，本领域已知的内部总线，包括IC间(I2C)总线、布线和印刷电路板)互连并且在这些元件之间传输数据。例如，在用户游戏系统2中，处理模块100通过总线1005与所述用户游戏系统2的其他元件互连。

处理模块100的通信接口1004允许用户游戏系统2在通信信道3上通信。如上所述，通信信道3可以例如在有线介质和/或无线介质内实现。

在各种实施方案中，使用无线网络诸如Wi-Fi网络，例如IEEE802.11(IEEE是指电气和电子工程师协会)将数据流式传输或以其他方式提供给用户游戏系统2。这些实施方案中的Wi-Fi信号通过适于Wi-Fi通信的通信信道3和通信接口1004进行接收。这些实施方案的通信信道3通常连接到接入点或路由器，该接入点或路由器提供对包括互联网的外部网络的访问，以用于允许流传输应用程序和其他越过运营商的通信。其他实施方案使用输入框101的RF连接向用户游戏系统2提供流传输数据。如上所述，各种实施方案以非流式的方式提供数据。另外，各种实施方案使用除了Wi-Fi以外的无线网络，例如蜂窝网络或蓝牙网络。

用户游戏系统2可向各种输出设备(包括显示系统105、扬声器106和其他外围设备107)提供输出信号。各种实施方案的显示系统105包括例如触摸屏显示器、有机发光二极管(OLED)显示器、曲面显示器和/或可折叠显示器中的一者或多者。显示器105可用于电视机、平板计算机、膝上型计算机、蜂窝电话(移动电话)、头戴式显示器或其他设备。显示系统105还可与其他部件集成(例如，如在智能电话中)，或可为独立的(例如，膝上型计算机的外部监视器)。在实施方案的各种示例中，其他外围设备107包括一个或多个输入设备，诸如独立数字视频光盘(或数字通用光盘)(DVR，可表示这两个术语)、光盘播放器，以及用户动作采集设备(诸如游戏手柄)和一个或多个输出设备(诸如立体声系统或照明系统)。

在各种实施方案中，使用诸如AV.Link、消费电子产品控制(CEC)或其他通信协议的信令在用户游戏系统2与显示系统105、扬声器106或其他外围设备107之间传送控制信号，该其他通信协议使得能够在有或没有用户干预的情况下进行设备到设备控制。输出设备/输入设备可通过相应的接口102、接口103和接口104经由专用连接通信地耦接到用户游戏系统2。另选地，输出设备/输入设备可使用通信信道3经由通信接口1004连接到用户游戏系统2，或者使用对应于该通信信道通信接口1004的专用通信信道连接到该系统。显示系统105和扬声器106可与电子设备(诸如例如电视机)中的用户游戏系统2的其他部件集成在单个单元中。在各种实施方案中，显示器接口102包括显示驱动器，例如定时控制器(T Con)芯片。

显示系统105和扬声器106可另选地与其他部件中的一个或多个部件分离。在显示系统105和扬声器106为外部部件的各种实施方案中，可经由专用输出连接(包括例如HDMI端口、USB端口或COMP输出)提供输出信号。

图1C示出了在其中实现各种方面和实施方案的服务器1的示例的框图。服务器1非常类似于用户游戏系统2。服务器1可实施为包括以下描述的各种部件的设备，并且被配置为执行本文档中所述的方面和实施方案中的一者或多者。此类设备的示例包括但不限于各种电子设备，诸如个人计算机、膝上型计算机和服务器。服务器1的元件可单独地或组合地具体体现在单个集成电路(IC)、多个IC和/或分立部件中。例如，在至少一个实施方案中，服务器1包括一个处理模块100，该处理模块实现关于服务器1的游戏应用程序的步骤，如下由图5的左侧所表示的。在各种实施方案中，服务器1经由例如通信总线或通过专用输入端口和/或输出端口通信地耦接到一个或多个其他系统或其他电子设备。在各种实施方案中，服务器1被配置为实现本文档中所述的方面中的一个或多个方面。

对处理模块100的输入可通过如关于图1D已经描述的框101中所示的各种输入模块来提供。

服务器1的各种元件可设置在集成壳体内。在集成壳体内，各种元件可使用合适的连接布置(例如，本领域已知的内部总线，包括IC间(I2C)总线、布线和印刷电路板)互连并且在这些元件之间传输数据。例如，在服务器1中，处理模块100通过总线1005与所述服务器1的其他元件互连。

处理模块100的通信接口1004允许服务器1在通信信道3上通信。

在各种实施方案中，使用诸如Wi-Fi网络的无线网络，例如IEEE802.11(IEEE是指电气和电子工程师协会)将数据(例如表示用户动作的数据)提供给服务器1或(例如视频流)由服务器1传输(流式传输)。这些实施方案中的Wi-Fi信号通过适于Wi-Fi通信的通信信道3和通信接口1004进行接收。这些实施方案的通信信道3通常连接到接入点或路由器，该接入点或路由器提供对包括互联网的外部网络的访问，以用于允许流传输应用程序和其他越过运营商的通信。其他实施方案向服务器1提供数据或者允许服务器使用输入框101的RF连接来传输数据。

另外，各种实施方案使用除了Wi-Fi以外的无线网络，例如蜂窝网络或蓝牙网络。

提供给服务器1或由服务器传输的数据可以不同的格式来提供或传输。在各种实施方案中，在传输的情况下，这些数据被编码并符合已知的视频压缩格式，诸如MPEG-4/AVC(ISO/CEI14496-10)、HEVC(ISO/IEC23008-2-MPEG-H部分2，高效视频编码/ITU-T H.265))、EVC(基本视频编码/MPEG-5)、AV1、VP9或由ITU-T和ISO/IEC专家的联合合作小组(被称为联合视频专家组(JVET))正在开发的名称为通用视频编码(VVC)的国际标准。

服务器1可以向能够存储、解码和/或显示输出信号的各种输出设备(诸如用户游戏系统)提供输出信号。

各种具体实施参与解码。如本申请中所用，“解码”涵盖例如对所接收的编码视频流执行以便产生适于显示的最终输出的全部过程。在各种实施方案中，此类过程包括通常由解码器执行的过程，例如熵解码、逆量化、逆变换和预测。

各种具体实施参与编码。以与上文关于“解码”的讨论类似的方式，如在本申请中使用的“编码”涵盖例如对由渲染步骤203生成的帧执行以便产生编码视频流的全部过程。在各种实施方案中，此类过程包括通常由编码器执行的过程，例如，分区、预测、变换、量化和熵编码。

需注意，下文中所使用的语法元素名称是描述性术语。因此，它们不排除使用其他语法元素名称。

当附图呈现为流程图时，应当理解，其还提供了对应装置的框图。类似地，当附图呈现为框图时，应当理解，其还提供了对应的方法/过程的流程图。

本文所述的具体实施和方面可在例如方法或过程、装置、软件程序、数据流或信号中实现。即使仅在单个形式的具体实施的上下文中讨论(例如，仅作为方法讨论)，讨论的特征的具体实施也可以其他形式(例如，装置或程序)实现。装置可在例如适当的硬件、软件和固件中实现。方法可在例如一般是指处理设备的处理器中实施，

该处理设备包括例如计算机、微处理器、集成电路或可编程逻辑设备。处理器还包括通信设备，诸如例如计算机、手机、便携式/个人数字助理(“PDA”)以及便于最终用户之间信息通信的其他设备。

提及“一个实施方案”或“实施方案”或“一个具体实施”或“具体实施”以及它们的其他变型，意味着结合实施方案描述的特定的特征、结构、特性等包括在至少一个实施方案中。因此，短语“在一个实施方案中”或“在实施方案中”或“在一个具体实施中”或“在具体实施中”的出现以及出现在本申请通篇的各个地方的任何其他变型不一定都是指相同的实施方案。

另外，本申请可涉及“确定”各种信息。确定信息可包括例如估计信息、计算信息、预测信息、从存储器检索信息或例如从另一设备、模块或从用户获得信息中的一者或多者。

此外，本申请可涉及“访问”各种信息。访问信息可包括例如接收信息、检索信息(例如，从存储器)、存储信息、移动信息、复制信息、计算信息、确定信息、预测信息或估计信息中的一者或多者。

另外，本申请可涉及“接收”各种信息。与“访问”一样，接收旨在为广义的术语。接收信息可包括例如访问信息或检索信息(例如，从存储器)中的一者或多者。此外，在诸如例如存储信息、处理信息、发射信息、移动信息、复制信息、擦除信息、计算信息、确定信息、预测信息或估计信息的操作期间，“接收”通常以一种方式或另一种方式参与。

应当理解，例如，在“A/B”、“A和/或B”以及“A和B中的至少一者”、“A和B中的一者或多者”的情况下，使用以下“/”、“和/或”以及“至少一种”、“一者或多者”中的任一种旨在涵盖仅选择第一列出的选项(A)，或仅选择第二列出的选项(B)，或选择两个选项(A和B)。作为进一步的示例，在“A、B和/或C”和“A、B和C中的至少一者”、“A、B和C中的一者或多者”的情况下，此类短语旨在涵盖仅选择第一列出的选项(A)，或仅选择第二列出的选项(B)，或仅选择第三列出的选项(C)，或仅选择第一列出的选项和第二列出的选项(A和B)，或仅选择第一列出的选项和第三列出的选项(A和C)，或仅选择第二列出的选项和第三列出的选项(B和C)，或选择所有三个选项(A和B和C)。如对于本领域和相关领域的普通技术人员显而易见的是，这可扩展到所列出的尽可能多的项目。

而且，如本文所用，词语“发信号通知”是指(除了别的以外)向对应解码器指示某物。例如，在某些实施方案中，视频编码器发信号通知一些编码工具的使用。这样，在一个实施方案中，在编码器侧和解码器侧两者均可使用相同的参数。因此，例如，编码器可将特定参数发射(显式信令)到解码器，使得解码器可使用相同的特定参数。相反，如果解码器已具有特定参数以及其他，则可在不发射(隐式信令)的情况下使用信令，以简单允许解码器知道和选择特定参数。通过避免传输任何实际功能，在各种实施方案中实现了比特节省。应当理解，信令可以各种方式实现。例如，在各种实施方案中，使用一个或多个语法元素、标志等将信息发信号通知至对应解码器。虽然前面涉及词语“signal(发信号通知)”的动词形式，但是词语“signal(信号)”在本文也可用作名词。

对于本领域的普通技术人员将显而易见的是，具体实施可产生格式化为携带例如可存储或可传输的信息的各种信号。信息可包括例如用于执行方法的指令或由所述具体实施中的一个具体实施产生的数据。例如，可格式化信号以携带所述实施方案的编码视频流和SEI消息。可格式化此类信号例如为电磁波(例如，使用频谱的射频部分)或基带信号。格式化可包括例如对编码视频流进行编码以及使用编码视频流调制载波。信号携带的信息可以是例如模拟或数字信息。已知的是，信号可通过各种不同的有线或无线链路发射。信号可存储在处理器可读介质上。

图5示意性地示出了用于减少云游戏应用程序中的延迟的方法的示例。

在图5的用于减少延迟的方法中，用户游戏系统2能够注册用户的动作(称为当前动作)，并向服务器1传输表示所述当前动作的信息。服务器端能够根据当前动作和游戏的当前状态预测至少一个未来游戏状态，以生成至少一个帧(称为预测帧)。每个预测帧对应于一个未来状态。至少一个预测帧被传输到用户游戏系统2。对于每个传输的预测帧，由用户游戏系统2获得允许在预测帧与当前动作之间建立链接的信息，以确定何时显示预测帧。

图5的方法来源于图3的方法。与图3相比，步骤被分成在左侧由服务器1执行的步骤和在右侧由用户游戏系统2执行的步骤。

在步骤200中，用户游戏系统2的处理模块100注册用户动作(即，当前动作)。

图3的步骤301被分成步骤301A和步骤301B。在步骤301A中，用户游戏系统2的处理模块100传输表示当前动作的信息。

在步骤301B中，服务器1的处理模块100接收表示当前动作的信息。

由服务器1的处理模块100使用此信息来预测游戏应用步骤201、202和203的至少一个未来状态。

在步骤201中，服务器1的处理模块100使用例如基于状态预测的方法来预测对应于时间t的至少一个游戏状态。预测游戏状态包括例如根据当前动作预测用户的未来动作(称为预测动作)。

在步骤202中，服务器1的处理模块100使用游戏引擎来针对预测动作中的至少一个预测动作确定游戏的对应于所述预测动作的状态(称为预测状态)。

在步骤203中，对于在步骤202中确定的预测状态中的至少一个预测状态，服务器1的处理模块100根据所述预测状态应用渲染步骤以生成预测帧(称为帧t)。由于可在步骤202中预测游戏的多个预测状态，因此服务器1的处理模块100可针对多个预测状态中的每个预测状态预测帧t。在一个实施方案中，每个预测帧是较大帧的一部分。较大帧例如是表示游戏的场景的背景，而每个预测帧表示在场景中演变的角色或化身。较大帧例如由用户游戏系统2的处理模块100生成，因为较大帧(即，较大帧所表示的背景)不依赖于用户动作。

在步骤304bis中，服务器1的处理模块100编码视频流中的帧t中的至少一个帧。因此，服务器1的处理模块100实现了视频编码模块。在步骤304bis中，可以使用任何已知的编码方法，诸如AVC、HEVC、VVC、EVC、AV1或VP9。

因此，步骤201、202、203和304bis允许获得至少一个编码的帧t。

图3的步骤305被分成图5中的步骤305A和步骤305B。

在步骤305A中，服务器1的处理模块100向用户游戏系统2传输对应于帧t中的至少一个帧的视频流的一部分。

在步骤305B中，用户游戏系统2的处理模块100接收对应于至少一个帧t的视频流的该部分。

在步骤306bis中，用户游戏系统2的处理模块100解码比特流的所述部分以重建至少一个帧t。因此，用户游戏系统2的处理模块100实现视频解码模块。在步骤306bis中使用对应于在步骤304bis中使用的编码方法的解码方法。

在步骤500中，用户游戏系统2的处理模块100确定何时显示解码帧t中的一个解码帧。

在步骤207bis中，在步骤500中确定的时间，在用户游戏系统2的处理模块100的控制下显示所述帧t。

在图5的方法的第一实施方案中，在步骤201中预测一个动作。因此，生成一个帧t，并且用户游戏系统2的处理模块100接收并解码所述帧t。

在第一实施方案的第一变型中，用户游戏系统2的处理模块100在步骤200中注册当前动作发生的时间 。此外，由服务器1的处理模块100和用户游戏系统2的处理模块100获得表示时间t_a与时间t_d之间的延时的信息，在该延时处，在用户游戏系统端上显示对应于所述当前动作的帧(在下文中称为往返延迟(RTL))。在步骤201中，使用表示往返延迟RTL的信息，服务器1的处理模块100调整超前延时Δt，该超前延时固定需要预测对应于当前动作的未来状态的时间t，以至少补偿往返延迟RTL。换句话讲，超前延时Δt应至少等于往返延迟RTL(即，Δt≥RTL)。减小Δt(即，使Δt尽可能接近RTL)允许更准确的游戏状态预测。增加Δt允许对网络延迟变化更具弹性。假设帧是以恒定的帧速率和显示顺序编码的，知道所述往返延迟RTL允许用户游戏系统2的处理模块100在接收帧时在步骤500中根据所述帧的接收时间推断出所述帧对应于哪个用户动作。因此，当所接收的帧对应于用户在时间t_a执行的动作时，往返延迟RTL是允许用户游戏系统2的处理模块100确定所述帧是否对应于所述动作的信息。然后，用户游戏系统2的处理模块100可在帧t的时间戳与对应于所述帧t的当前动作发生的时间t_a之间建立链接。用户游戏系统2的处理模块100每次在帧t的时间戳与用户动作发生的时间t_a之间建立链接时，用户游戏系统2中的处理模块100可将用户游戏系统2的处理模块100的时钟与服务器1的处理模块100的时钟重新同步。具有同步时钟并知道帧速率允许用户游戏系统2的处理模块100在步骤500中使用时间戳来确定何时显示帧。

往返延迟RTL可通过测量分组的传输与此分组的确认接收之间的往返时间(RTT)来近似。RTT可由服务器1的处理模块100(分别由用户游戏系统2的处理模块100)来估计，并且表示基于RTT的估计的往返延迟RTL的信息可被传输到用户游戏系统2的处理模块100(分别传输到服务器1的处理模块100)。RTT也可由服务器1的处理模块100和用户游戏系统2的处理模块100两者来估计。

在第一实施方案的第二变型中，服务器1没有获得表示往返延迟RTL的信息。因此，在没有表示往返延迟RTL的信息的情况下，服务器1的处理模块100不能将超前延时Δt调整到所述往返延迟RTL。在这种情况下，在服务器1端预先定义超前延时Δt。然后，用户游戏系统2的处理模块100使用与第一变型中相同的过程来将其时钟与服务器1的处理模块100的时钟同步，然后确定何时显示帧。

在第一实施方案的第三变型中，为使用户游戏系统2的处理模块100更准确地估计往返延迟RTL，在用户游戏系统2与服务器1之间交换新的SEI消息。在步骤301A中，表示用户动作的信息包括所述用户动作的标识符input_timing。

在步骤304bis中，服务器1的处理模块100将包括用户动作标识符input_timing的SEI消息frame_timing_sei()与对应于帧t的视频流的部分相关联。

frame_timing_sei(){
	input_timing
}

表TAB1

表TAB1中描述了旨在输送标识input_timing的SEI消息frame_timing_sei()的语法的示例。使用标识符input_timing，用户游戏系统2的处理模块100可很容易检索对应的注册时间t_a。然后往返延迟RTL可被计算为时间t_a与SEI消息frame_timing_sei()的接收时间之间的差值。在一个实施方案中，标识符input_timing表示已注册用户动作的时间t_a。

在第一实施方案的第四变型中，SEI消息frame_timing_sei()用附加信息lookahead_timing来补充，该附加信息表示超前延时Δt，该超前延时延固定预测对应于用户动作的预测状态的时间t。

frame_timing_sei(){
	input_timing
Lookahead_timing
	}

表TAB2

在表TAB2中描述了包括信息lookahead_timing的SEI消息frame_timing_sei()的语法示例。用户游戏系统2的处理模块100知道对应于标识符input_timing和信息lookahead_timing的注册时间t_a，就可直接确定帧t的显示时间T：

T＝t_a+Δt

具有表示Δt＝0的信息lookahead_timing指示不存在服务器1端的状态预测。

当超前延时Δt为高时(Δt>100ms)，这通常是往返延迟RTL为高时的情况，步骤201期间不良预测的风险高。

图6示意性地示出了其中发生预测误差的状态预测过程。

从起始真实状态x＝0开始，用户执行由速度v＝1表示的动作。假设速度恒定且具有超前延时Δt＝2，则状态预测器在时间t＝1预测对于时间t＝3的状态x＝3。当用户立即停止其动作(速度v＝0)时，对于时间t＝2、3和4，真实状态保持在x＝1。因此，当t＝3时，状态误差为e＝预测状态-真实状态＝3-1＝2。

处理不良预测的一种可能的解决方案是允许预测多个可能的未来状态。

预测器可使用例如贝叶斯模型来对预测进行建模。

在图6的示例中，假设仅两个可能的速度值v＝{0,1}(仅两个动作是可能的)，状态预测过程可例如使用如图7中表示的2-态马尔可夫模型。

图7表示对游戏的状态进行建模的二态马尔可夫模型。

根据图7的模型，当用户在时间t执行对应于速度v＝0的动作时，则在时间t+1具有速度v＝0的概率为p＝0.7，并且在时间t+1具有速度v＝1的概率为1-p＝0.3。

当用户在时间t执行对应于速度v＝1的动作时，则在时间t+1保持速度v＝1的概率为q＝0.8，并且在时间t+1具有速度v＝0的概率为1-q＝0.2。

假设当前状态x＝0且当前速度v＝0，以及以上模型，则获得表TAB3中表示的状态的概率：

时间	概率x＝0	概率x＝1	概率x＝2	概率x＝3
					t＝0	1	0	0	0
t＝1	0.7	0.3	0	0
					t＝2	0.49	0.21+0.06＝0.27	0.24	0
t＝3	0.343	0.147+0.042+0.042＝0.231	0.168+0.018+0.048＝0.234	0.192

表TAB3

对于Δt＝3的超前延时，则在时间t＝3按照最可能到较不可能的顺序的未来状态是状态x＝0、x＝1以及x＝2和x＝3。

上述示例是用户动作的非常简单的马尔可夫模型，但在实践中可使用更复杂的模型，尤其是学习模型等。

在图5的方法的第二实施方案中，在步骤201中预测多个状态。因此，由服务器1的处理模块100生成多个帧t。

在这种情况下，在步骤304bis中，使用多层视频编码器来生成多层视频流，并且在步骤306bis中使用对应的多层视频解码器来解码所述多层视频流。这些多层视频编码器和解码器可基于例如AVC的可伸缩扩展(即，SVC(可伸缩视频编码))、HEVC(即，SHVC(可伸缩高效视频编码)或VVC，或者基于AVC的多视图扩展(即，MVC(多视图视频编码))、HEVC或VVC。

多个帧t中的每个帧t在多层视频流的一个层中被编码。

在第二实施方案的第一变型中，对应于游戏的最可能状态的帧t(即最可能帧t)在多层视频流的基底层中被编码。表示游戏的至少一个状态的信息(这里是由帧t的概率表示的游戏的预测状态)用于控制多层视频流的多层编码。这里，基底层是指未从任何其他视频层预测性编码的编码视频层，并且其可用作某个其他层的预测的参考。多个帧中的每个其他帧t在另一层(称为增强层)中被编码。增强层的编码使用基底层作为层间预测的参考层和/或在所述增强层之前编码的任何其他层。在第二实施方案的此第一变型中，多个帧t按照概率递减的顺序进行编码。因此，最可能帧t在较不可能帧t之前被编码。需注意，由于每个状态仅与最可能的状态略有不同，因此多个帧t将是相似的，并且可使用层间预测来有效地编码每个增强层。

在第二实施方案的第二变型中，增强层中较不可能帧t的编码顺序取决于由每个帧t表示的状态与在另一层中已编码的帧t中表示的状态之间的差异。表示游戏的至少一个状态的信息(这里是游戏的预测状态之间的差异)用于控制多层视频流的多层编码。例如，在第一增强层中编码的帧t是多个帧中对应于最接近由在基底层中编码的帧t所表示的状态的状态的帧t。在第二增强层中编码的帧t是多个帧中对应于最接近由在基底层中编码的帧t和/或由在第一增强层中编码的帧t表示的状态的状态的帧t。在表TAB3的示例中，对应于状态x＝0的最可能帧t在基底层中被编码。状态x＝1最接近于状态x＝0。对应于状态x＝1的帧t因此在第一增强层中被编码。状态x＝2最接近于状态x＝0和x＝1。对应于状态x＝2的帧t因此在第二增强层中被编码。

图8示意性地示出了多层视频编码的示例。

在图8中，箭头示出了层间预测或时间预测的帧间依赖性。例如，在时间t＝0，层2的帧t使用基底层的帧t作为用于层间预测的参考帧。对于每个帧t，示出了用于渲染帧t的游戏状态(x值)。在竖直轴线上，多层视频编码器使用基底层进行层间预测，因为对应于同一时间的帧t非常相似。在水平轴线上，取决于游戏状态差异，多层视频编码器可有利地使用来自不同层的过去帧作为参考帧(例如，在时间t＝2，基底层的帧t＝2可使用层1的帧t＝1，因为游戏状态相同)。

在时间t＝3在用户游戏系统2侧显示的帧用带纹理的背景来表示。此显示的帧对应于层2的帧t＝0，因为所述帧对应于最接近真实状态(x＝2)的预测状态。

在图5的方法的第二实施方案中，所述方法包括步骤501，在该步骤期间，用户游戏系统2的处理模块100根据表示游戏的实际状态的信息与表示由多个帧中的帧表示的预测状态的信息之间的比较来确定显示其所接收的多个帧t(即，多个层)中的哪个帧t(即，哪个层)。

在第二实施方案的第一变型或第二变型中，为了允许用户游戏系统2的处理模块100选择对应于最接近真实状态的游戏状态的要解码的帧t，将SEI消息layer_state_sei()与表示多个帧t的视频流的部分相关联。

表TAB4

在表TAB4中描述了SEI消息layer_state_sei()的语法的第一示例。SEI消息layer_state_sei()包括：

·语法元素number_of_state，其表示服务器1的处理模块100在步骤201中所考虑的不同游戏状态的数量(即，未来游戏状态的数量)。状态的数量number_of_state等于层的数量。在图8的示例中，number_of_state＝3。在一个实施方案中，每个游戏状态与层相关联。换句话讲，每个状态号与层号相关联。例如，在图8中，状态“0”与基底层相关联，状态“1”与层“1”相关联，并且状态“2”与层“2”相关联。

·对于每个游戏状态，语法元素state_id，其表示服务器1的处理模块100和用户游戏系统2的处理模块100同意识别表示状态的特定类型的信息的唯一标识符。例如，在上述示例中，可将state_id“0”设置为用户位置x。

·对于每个游戏状态，语法元素state，其表示代表类型state_id的状态的信息的值。

在图8的示例中，在t＝1，以下SEI消息与帧t＝1相关联：

在t＝3，在步骤500中，用户游戏系统2的处理模块100知道真实游戏状态(x＝2)并读取SEI消息。根据SEI消息frame_timing_sei()，用户游戏系统2的处理模块100知道视频流的包括多个帧t的部分对应于由语法元素input_timing的值(这里为“1”)识别的动作，并且服务器1的处理模块100根据具有由look_ahead_timing表示的值(这里为“3”)的超前延时的所述动作预测未来动作。根据这些信息，用户游戏系统2的处理模块100知道何时显示多个帧t中的一个帧。

根据SEI消息layer_state_sei()，在步骤501中，用户游戏系统2的处理模块100知道服务器1的处理模块100在步骤201中考虑了number_of_state(这里为“3”)个未来状态。此外，用户游戏系统2的处理模块100知道表示最接近真实状态的预测状态的帧t在层2中。然后在步骤501中选择所述帧t进行显示。

到目前为止，认为用户游戏系统的处理模块100可例如从用户动作导出游戏的当前状态。例如，在简单游戏中，可从由速度v表示的用户动作导出用户在游戏中的位置x。

然而，在复杂的游戏中，例如由于用户与游戏中的对象或与其他用户的交互，从用户动作导出游戏状态是困难的。实际上，模拟复杂的游戏状态很难在用户游戏系统2侧执行，特别是因为它既没有游戏引擎也没有渲染引擎。因此，在这些情况下，用户游戏系统2的处理模块100难以确定由语法元素state[]识别的游戏状态是否对应于其最后一个动作。

在表TAB5中描述了当前状态计算不可知的SEI消息layer_state_sei()的语法的第二示例。

表TAB5

SEI消息layer_state_SEI()不是表示游戏状态，而是表示预测用户动作序列。SEI消息layer_state_SEI()包括：

·语法元素num_sequence，其表示服务器1的处理模块100所考虑的用于生成多个帧t的预测用户动作序列的数量。在图8的示例中，序列的数量num_sequence等于“3”。每个序列号与层相关联。例如，在图8中，序列号“0”与基底层相关联，序列号“1”与层“1”相关联，并且序列号“2”与层“2”相关联。

·语法元素input_sequence_count，其表示由服务器1的处理模块100所考虑的用于生成多个帧t的预测用户动作序列中的预测用户动作的数量；

·对于序列的每个用户动作，语法元素input_id[][]。语法元素input_id是服务器1的处理模块100和用户游戏系统2的处理模块100同意识别表示用户动作的特定类型的信息(或表示表示用户动作的信息的组合)的唯一标识符。例如，在图8的上述示例中，可将语法元素input_id[]设置为速度v的“0”。

·对于序列的每个用户动作，语法元素input_value[][]，其提供表示类型input_id[][]的用户动作的信息(或信息的组合)的值。

在图8的示例中，获得以下SEI消息layer_state_sei()：

这意味着第一用户动作序列(在图8中表示)由以下速度值序列v＝[0，0，1]表示，第二用户动作序列(在图8中未表示)由以下速度值序列v＝[1，1，1]表示，并且第三用户动作序列(在图8中未表示)由以下速度值序列v＝[0，1，1]表示。

SEI消息layer_state_sei()的第二示例的一个优点在于，在用户游戏系统2侧，不需要复杂的状态计算。仅需要用户动作的序列。在步骤501中，用户游戏系统2的处理模块100将真实用户动作序列与在SEI消息layer_state_sei()中表示的用户动作的序列进行比较以确定最接近的序列。然后，用户游戏系统2的处理模块100根据SEI消息layer_state_sei()中表示的用户动作序列推断出要显示的哪个帧t(哪个层)最接近用户动作的真实序列。

到目前为止，除了预测未来状态(即，未来动作)之外，不考虑在用户游戏系统2侧实际显示的帧t，也不考虑在编码处理中由用户执行的实际动作来执行多层编码。可以注意到，表示在步骤301B中接收的用户动作的信息表示在用户游戏系统2侧上显示的帧t。实际上，服务器1的处理模块100知道哪个帧t是从与实际用户动作(或实际用户动作序列)最接近的预测动作(或预测动作序列)生成的。

在步骤304bis的第二实施方案中，服务器1的处理模块100使用表示在用户游戏系统2侧实际显示的帧t的信息来控制哪个帧或哪个层将被用于下一帧的时间预测。在此第二实施方案中，对于多层视频流的编码，考虑表示游戏的至少一个状态(这里为由显示的帧表示的真实状态)的信息。例如，假设时间预测使用一个帧作为参考帧，则当编码当前帧t＝T时，服务器1的处理模块100使用与服务器1的处理模块100已知的最后显示的层相对应的帧t＝T-1来进行帧t＝T的时间预测。

图9示出了步骤304bis的第二实施方案的应用示例。

在图9中，假设超前延时为Δt＝2。

在用户游戏系统2侧实际显示的帧用带纹理的背景表示。

在每个帧中，示出该帧被渲染的时间，例如在时间t＝0，渲染帧t＝2。

在时间t＝2，在步骤301B中，服务器1的处理模块100接收表示用户动作的信息(其也表示用户游戏系统2在时间t＝0处实际显示的帧)。当在时间t＝0显示的帧在基底层中时，服务器1的处理模块100使用基底层的帧作为用于基底层的未来帧的时间预测的参考帧来继续编码。

在时间t＝3，在步骤301B中，服务器1的处理模块100接收表示由用户游戏系统2在时间t＝1实际显示的帧的信息。由于在时间t＝1处显示的帧在层1中，因此服务器1的处理模块100使用层1中的帧作为用于基底层的未来帧的时间预测的参考帧。通过这样做，新的参考帧可能更接近要编码的未来帧。

到目前为止，在多层视频流的编码期间没有考虑网络3上可用的带宽。然而，已知网络带宽通常是有限的，并且优选的是在编码视频流时应用速率控制以确保所述视频流符合可用带宽。

在步骤304bis的第三实施方案中，在多层视频流的编码期间应用速率控制。此速率控制可例如基于在带宽约束下的编码的速率失真优化。

如前所述，一些层比其他层更不可能，因为它们是基于比其他层更不可能的未来游戏状态来编码的。在步骤304bis的第三实施方案中，根据每个层的概率在层之间划分可用带宽。在此第三实施方案中，对于多层视频流的编码，考虑到表示游戏的至少一个状态的信息，这里是由它们的概率表示的游戏的预测状态。例如，在图8的示例中，将70％分配给对应于最可能层的基底层的编码，将10％分配给对应于较不可能层的层2，并且将20％分配给基底层与层2之间具有中间概率的层1。

以上描述了多个实施方案。这些实施方案的特征可以单独提供或以任何组合形式提供。此外，实施方案可包括以下特征、设备或方面中的一个或多个，单独地或以任何组合，跨各种权利要求类别和类型：

·包括所描述的语法元素中的一个或多个语法元素或其变型的比特流或信号。

·对包括所描述的语法元素中的一个或多个语法元素或其变型的比特流或信号进行创建和/或传输和/或接收和/或解码。

·执行所述的实施方案中的至少一个实施方案的移动电话、平板计算机、游戏控制台、服务器、个人计算机或其他电子设备。

·执行所述的实施方案中的至少一个实施方案并且显示(例如，使用监视器、屏幕或其他类型的显示器)得到的图像的移动电话、平板计算机、游戏控制台、服务器、个人计算机或其他电子设备。

·调谐(例如，使用调谐器)信道以接收包括编码视频流的信号并且执行所述的实施方案中的至少一个实施方案的移动电话、平板计算机、游戏控制台、个人计算机或其他电子设备。

·通过空中接收(例如，使用天线)包括编码视频流的信号并且执行所述的实施方案中的至少一个实施方案的移动电话、平板计算机、游戏控制台、个人计算机或其他电子设备。

·调谐(例如，使用调谐器)信道以传输包括编码视频流的信号并且执行所述的实施方案中的至少一个实施方案的服务器、个人计算机或其他电子设备。

·通过空中传输(例如，使用天线)包括编码视频流的信号并且执行所述的实施方案中的至少一个实施方案的服务器、个人计算机或其他电子设备。

Claims (50)

1.一种用于控制基于网络的应用程序中表示应用程序的状态的帧的显示的方法，所述方法包括：

向服务器发送(301A)表示用户动作的信息；

接收(305B)表示根据所述用户动作预测的所述应用程序的预测状态的至少一个帧；

获得允许确定所述至少一个帧是否对应于所述用户动作的信息；以及；

在所述至少一个帧对应于所述用户动作的情况下，根据执行此用户动作的时间和所述信息来确定何时显示所述至少一个帧中的一个帧。

2.根据权利要求1所述的方法，其中所述信息表示在执行此用户动作的所述时间与显示对应于所述用户动作的帧的时间之间的延时。

3.根据权利要求1或2所述的方法，其中所述方法由用户系统执行，并且其中所述信息允许通过允许将所述用户系统的时钟与所述服务器的时钟同步来确定何时显示所述至少一个帧中的一个帧。

4.根据权利要求1所述的方法，其中以包括元数据的编码视频流的形式接收所述至少一个帧，所述元数据包括所述信息。

5.根据权利要求4所述的方法，其中传输到所述服务器的表示所述用户动作的所述信息包括所述用户动作的标识符，并且所述元数据包括所述标识符。

6.根据权利要求5所述的方法，其中所述元数据包括表示延时的信息，所述延时固定预测对应于所述用户动作的预测状态的时间。

7.根据任一前述权利要求所述的方法，其中接收多个帧，每个帧表示根据所述用户动作预测的所述应用程序的预测状态，并且其中所述方法还包括根据表示所述应用程序的实际状态的信息与表示由所述多个帧中的帧表示的预测状态的信息之间的比较来确定显示所述多个帧中的哪个帧。

8.根据权利要求7所述的方法，其中对于所述多个帧中的每个帧，所述元数据包括表示由所述帧表示的所述应用程序的所述状态的信息。

9.根据权利要求7或8所述的方法，其中表示所述应用程序的实际状态的所述信息和表示由所述多个帧中的帧表示的预测状态的所述信息是表示用户动作序列的信息。

10.一种用于控制基于网络的应用程序中表示应用程序的状态的帧的显示的方法，所述方法包括：

从用户系统接收(301A)表示用户动作的信息，所述信息包括所述用户动作的标识符；

根据所述用户动作预测(201)所述应用程序的至少一个状态；

对于至少一个预测状态，渲染(202,203)表示所述预测状态的帧；

在视频流的一部分中用包括所述用户动作的所述标识符的元数据编码(304bis)至少一个渲染帧；以及，

将视频流的所述部分传输(305A)到所述用户系统。

11.根据权利要求10所述的方法，其中所述元数据包括表示延时的信息，所述延时固定预测对应于所述用户动作的预测动作的时间。

12.根据权利要求10或11所述的方法，其中用包括表示每个预测状态的信息的元数据来渲染和编码多个帧，每个帧表示根据所述用户动作预测的所述应用程序的预测状态。

13.根据权利要求12所述的方法，其中表示所述应用程序的预测状态的所述信息表示用户动作序列。

14.根据权利要求12或13所述的方法，其中所述多个帧的所述编码使用多层编码，所述多层编码考虑到表示所述应用程序的至少一个真实状态或预测状态的信息。

15.一种用于控制基于网络的应用程序中表示应用程序的状态的帧的显示的设备，所述设备包括：

用于向服务器发送(301A)表示用户动作的信息的装置；

用于接收(305B)表示根据所述用户动作预测的所述应用程序的预测状态的至少一个帧的装置；

获得允许确定所述至少一个帧是否对应于所述用户动作的信息的装置；和；

用于以下操作的装置：在所述至少一个帧对应于所述用户动作的情况下，根据执行此用户动作的时间和所述信息来确定何时显示所述至少一个帧中的一个帧。

16.根据权利要求15所述的设备，其中所述信息表示在执行此用户动作的所述时间与显示对应于所述用户动作的帧的时间之间的延时。

17.根据权利要求15或16所述的设备，其中所述信息通过允许将所述设备的时钟与所述服务器的时钟同步来允许确定何时显示所述至少一个帧中的一个帧。

18.根据权利要求15所述的设备，其中以包括元数据的编码视频流的形式接收所述至少一个帧，所述元数据包括所述信息。

19.根据权利要求18所述的设备，其中传输到所述服务器的表示所述用户动作的所述信息包括所述用户动作的标识符，并且所述元数据包括所述标识符。

20.根据权利要求19所述的设备，其中所述元数据包括表示延时的信息，所述延时固定预测对应于所述用户动作的预测动作的时间。

21.根据权利要求15至20中任一前述权利要求所述的设备，其中接收多个帧，每个帧表示根据所述用户动作预测的所述应用程序的预测状态，并且其中所述设备还包括用于以下操作的装置：根据表示所述应用程序的实际状态的信息与表示由所述多个帧中的帧表示的预测状态的信息之间的比较来确定显示所述多个帧中的哪个帧。

22.根据权利要求21所述的设备，其中对于所述多个帧中的每个帧，所述元数据包括表示由所述帧表示的所述应用程序的所述状态的信息。

23.根据权利要求21或22所述的设备，其中表示所述应用程序的实际状态的所述信息和表示由所述多个帧中的帧表示的预测状态的所述信息是表示用户动作序列的信息。

24.一种用于控制基于网络的应用程序中表示应用程序的状态的帧的显示的设备，所述设备包括：

用于从用户系统接收(301A)表示用户动作的信息的装置，所述信息包括所述用户动作的标识符；

用于根据所述用户动作预测(201)所述应用程序的至少一个状态的装置；

用于对于至少一个预测状态，渲染(202,203)表示所述预测状态的帧的装置；

用于在视频流的一部分中用包括所述用户动作的所述标识符的元数据编码(304bis)至少一个渲染帧的装置；和，

用于将视频流的所述部分传输(305A)到所述用户系统的装置。

25.根据权利要求24所述的设备，其中所述元数据包括表示延时的信息，所述延时固定预测对应于所述用户动作的预测动作的时间。

26.根据权利要求24或25所述的设备，其中用包括表示每个预测状态的信息的元数据来渲染和编码多个帧，每个帧表示根据所述用户动作预测的所述应用程序的预测状态。

27.根据权利要求26所述的设备，其中表示所述应用程序的预测状态的所述信息表示用户动作序列。

28.根据权利要求26或27所述的设备，其中所述多个帧的所述编码使用多层编码，所述多层编码考虑到表示所述应用程序的至少一个真实状态或预测状态的信息。

29.一种用于控制基于网络的应用程序中表示应用程序的状态的帧的编码的方法，所述方法包括：

从用户系统接收(301A)表示用户动作的信息，所述信息包括所述用户动作的标识符；

根据所述用户动作预测(201)所述应用程序的被称为预测状态的多个状态；

对于每个预测状态，渲染(202,203)表示所述预测状态的帧；以及，

编码(304bis)所述渲染帧，每个帧在视频流的多个层中的一个层中使用多层编码进行编码，所述多层编码考虑到表示所述应用程序的至少一个真实状态或预测状态的信息。

30.根据权利要求29所述的方法，其中表示预测状态的信息是所述预测状态的概率。

31.根据权利要求30所述的方法，其中对应于最高概率的所述帧在称为基底层的层中被编码，在没有来自任何其他层的任何预测的情况下被编码，并且所述帧可用作某个其他层的预测的参考。

32.根据权利要求30或31所述的方法，其中为每个层分配比特率，以根据所述层的所述概率编码所述层。

33.根据权利要求29所述的方法，其中表示真实状态的信息是表示由多个帧被传输到的用户系统显示的所述多个帧中的帧的信息。

34.根据权利要求33所述的方法，其中根据由用户系统显示的多个帧中的帧来确定提供用于第二层的当前帧的时间预测的帧的第一层。

35.根据权利要求33或34所述的方法，其中表示由用户系统显示的多个帧中的帧的所述信息是表示从所述用户系统所接收的用户动作的信息。

36.根据权利要求29所述的方法，其中表示预测状态的信息包括所述预测状态之间的差异。

37.一种用于控制基于网络的游戏应用程序中表示游戏的状态的帧的编码的设备，所述设备包括：

用于从用户系统接收(301A)表示用户动作的信息的装置，所述信息包括所述用户动作的标识符；

用于根据所述用户动作预测(201)所述游戏的被称为预测状态的多个状态的装置；

用于对于每个预测状态渲染(202,203)表示所述预测状态的帧的装置；和，

用于编码(304bis)所述渲染帧的装置，每个帧在视频流的多个层中的一个层中使用多层编码进行编码，所述多层编码考虑到表示所述游戏的至少一个真实状态或预测状态的信息。

38.根据权利要求37所述的设备，其中表示预测状态的信息是所述预测状态的概率。

39.根据权利要求38所述的设备，其中对应于所述最高概率的所述帧在称为基底层的层中被编码，在没有来自任何其他层的任何预测的情况下被编码，并且所述帧可用作某个其他层的预测的参考。

40.根据权利要求37或38所述的设备，其中为每个层分配比特率，以根据所述层的所述概率编码所述层。

41.根据权利要求37所述的设备，其中表示真实状态的信息是表示由多个帧被传输到的用户系统显示的所述多个帧中的帧的信息。

42.根据权利要求41所述的设备，其中根据由用户系统显示的多个帧中的帧来确定提供用于第二层的当前帧的时间预测的帧的第一层。

43.根据权利要求41或42所述的设备，其中表示由用户系统显示的多个帧中的帧的所述信息是表示从所述用户系统所接收的用户动作的信息。

44.根据权利要求37所述的设备，其中表示预测状态的信息包括所述预测状态之间的差异。

45.根据任一前述权利要求所述的方法或设备，其中所述应用程序是基于网络的游戏应用程序。

46.根据任一前述权利要求所述的方法或设备，其中表示预测状态的至少一个帧是表示所述应用程序的较大帧的一部分。

47.一种装置，所述装置包括根据权利要求15至28和37至46中任一前述权利要求所述的设备。

48.一种信号，所述信号是由根据权利要求10至14中任一前述权利要求所述的方法或由根据权利要求24至28中任一前述权利要求所述的设备生成的。

49.一种计算机程序，所述计算机程序包括用于实现根据权利要求1至14和29至36中任一前述权利要求所述的方法的程序代码指令。

50.一种非暂态信息存储介质，所述非暂态信息存储介质存储用于实现根据权利要求1至14和29至36中任一前述权利要求所述的方法的程序代码指令。