用于游戏生成的运动向量的系统和方法与流程

文档序号:20274872发布日期:2020-04-03 19:31阅读:327来源:国知局
用于游戏生成的运动向量的系统和方法与流程

相关申请的交叉引用

本申请要求于2017年4月21日提交的第62/488,526号和于2017年12月8日提交的第62/596,325号美国临时申请的优先权。



背景技术:

远程游戏应用程序,其中服务器端游戏由客户端玩家控制,该应用程序已经尝试使用现有的或定制的编码器实时对来自三维(3d)图形引擎的视频输出进行编码。然而,视频游戏的交互性质,特别是视频输出和玩家输入之间的玩家反馈循环,使得游戏视频流比传统视频流对延迟更为敏感。现有的视频编码方法能够用计算量来换取编码时间的减少,而几乎没有其他方法。将编码过程集成到视频渲染过程中的新方法能够显著减少编码时间,同时还降低了计算量,提高了经编码视频的质量,并保留了原始比特流数据格式,以保持现有硬件设备的互操作性。

现有的视频编码标准仅包含图像序列中的颜色和时间信息,以改善视频编码时间、大小或质量。一些编码标准,如mpeg标准系列中的那些,基于视频中包含的颜色数据使用计算密集的基于块的运动估计方法来近似计算对象运动。这些基于块的运动估计方法历来显著减少了经编码的视频大小,但却是实时视频流环境中显著延迟的根源。

将编码过程集成到视频渲染过程中提供了对能够用于编码改进的其他数据源的访问。例如,一些3d图形引擎,比如包含在游戏引擎中的那些引擎,可能已经生成了完美描述每个视频帧上每个像素运动的运动向量。通过提供最终渲染帧并将适当格式化的运动向量数据注入编码器中,能够为每个帧跳过视频编码器中计算复杂度最高、最耗时的步骤——运动估计。另外,由图形引擎提供的运动向量比基于块的运动估计算法所估算的运动向量更精确,这会提高编码视频的质量。

视频编码和实时图形渲染这两个领域传统上是分开独立运行的。通过将图形引擎和编码器进行集成,以利用它们各自的优势,能够将编码时间减少到足以支持对延迟高度敏感的流应用程序。

通过下文描述的技术不足,本发明的这些优点和其他伴随的优点会变得显而易见。

例如,美国专利申请公开号2015/0228106a1(“‘106公开”)公开了对视频数据进行解码以生成视频图像的已解码的块序列的技术。该技术允许在编解码器引擎生成解码块时,将视频图像的每个解码块用作几何表面的对应多边形的单独纹理。‘106公开技术描述了编解码器引擎和3d图形引擎之间的集成,其中,编解码器引擎对经编码的视频数据进行解码以生成待映射的视频图像,3d图形引擎通过执行视频图像到几何表面的纹理映射来部分渲染显示图片。然而,与本发明相比,该技术是不足的,至少因为:它没有公开或使用提供用于注入视频编解码器引擎的适当格式化的运动向量数据和最终渲染帧的图形引擎,以使得在将经编码的视频数据传输到远程客户端编码引擎之前视频编解码器引擎不需要执行任何运动估计。相比之下,本发明对计算机技术的改进减少了编码时间和计算量,改善了经编码视频的质量,并且保留了原始比特流数据格式以保持互操作性。

美国专利申请公开号2011/0261885a1(“‘885公开”)公开了通过运动估计和宏块编码的集成来减少带宽的系统和方法。在该系统中,可以使用获取的视频数据来执行运动估计以生成运动估计相关信息,包括运动向量。利用缓冲区中缓存的相应视频数据,这些运动向量可以对应到当前宏块。同样,与本发明相比,‘885公开技术是不足的,至少因为:它没有公开或使用提供用于注入视频编解码器引擎的适当格式化的运动向量数据和最终渲染帧的图形引擎,使得视频编解码器引擎在将经编码的视频数据传输到远程客户端编码引擎之前不需要执行任何运动估计。因此,‘885公开的技术没有提供本发明提供的编码时间和计算量的减少,以及编码视频质量的改善。

从以上对本技术领域的现有技术的讨论中显而易见的是,本领域中需要对与游戏环境中的视频编码相关的当前的计算机技术进行改进。



技术实现要素:

因此,本文公开的示例性实施例的目的是解决本领域的缺点,并提供用于图形生成的系统和方法,所述系统和方法使用运行图形引擎、视频编解码器引擎和远程客户端编码引擎的联网服务器体系结构来传输经编码的视频数据,其中,图形引擎提供用于注入视频编解码器引擎的适当格式化的运动向量数据和最终渲染帧。

本发明的另一目的是提供用于图形生成的系统和方法,其中,视频编解码器引擎在将经编码的视频数据传输到远程客户端编码引擎之前不需要执行任何运动估计。

本发明的另一目的是提供用于图形生成的系统和方法,其中,图形引擎将每像素运动向量转换为每块运动向量。

本发明的又一目的是提供用于图形生成的系统和方法,其中,通过以下方式来生成每像素运动矢量:使用计算着色器将每像素运动向量添加到相机速度以获得每像素结果,并且其中,将每像素结果存储在运动向量缓冲区中。

本发明的还有一目的是提供用于图形生成的系统和方法,其中,每块运动向量数据由图形引擎实时地与色度亚采样(chromasubsampled)视频帧一起注入视频编码引擎。

附图说明

当结合附图考虑时,通过参考以下详细描述将更好地理解本发明,将容易地获得对本发明及其许多伴随的优点的更全面的了解,其中:

图1是示出3d图形引擎渲染视频以进行编码和传输到客户端的框图。

图2是示出通过将3d图形引擎生成的运动向量注入图4的经修改的编码过程中来减少延迟所需的步骤的流程图;

图3是示出在图形引擎中生成的每像素运动向量到每宏块运动向量的变换以注入编码引擎中的图;

图4是示出对图1中使用的视频编码过程所需的更改的流程图。

具体实施方式

在描述附图中所示的本发明的优选实施例时,为了清楚起见,将采用特定术语。然而,本发明并不旨在限于这样选择的特定术语,并且应该理解,每个特定术语包括以类似方式操作以实现类似目的的所有技术等同物。为了说明的目的,描述了本发明的几个优选实施例,可以理解,本发明可以以未在附图中具体示出的其他形式来实施。

在3d图形引擎正在渲染视频以进行实时编码和传输的应用中,图形引擎和编码器能够更紧密地耦合以减少总的计算时间和计算开销。对于每个视频帧,已经由图形引擎生成的每像素运动向量数据能够转换为每块运动向量数据,并注入编解码器引擎,来规避运动估计步骤,该运动估计步骤是编码过程中仅有的最复杂且计算密集的步骤。在似真运动模糊方法中使用重建过滤器的图形引擎中,可以已经为每个视频帧计算出每像素运动向量。能够通过为每个16×16像素的宏块找到平均向量来执行从每像素运动向量到每块运动向量的转换。该转换是在3d图形引擎中执行的,因此仅需要将原始运动向量数据的一小部分从3d图形引擎传递到编码引擎。在图形引擎和编码引擎不共享存储器的情况下,这还有助于减少存储器带宽消耗。将每块运动向量注入编解码器引擎中,完全跳过了运动估计步骤,而不会显著地改变编码过程的其余部分。

图1至图4示出了用于改进视频流应用中的视频编码的示例技术,其中,3d图形引擎在渲染视频帧的过程中生成伴随的运动向量数据。

图1示出了示例系统,在该示例系统中,视频被渲染和编码以传输到远程客户端116。在某个服务器体系结构120上的存储器106中运行的3d图形引擎100将有关已渲染的视频帧的视频和补充运动向量信息传递到编解码器引擎(这里称为编解码器或编码器)102,该编解码器引擎生成经编码的比特流108以传输到客户端计算机系统116。服务器体系结构120是能够支持图形引擎和编解码器引擎的功能的硬件或软件的任何组合。在所给定的示例中,图形引擎100能够被实现为例如执行加载到某个计算机可读存储器106中的视频游戏软件104的gpu,而编解码器引擎102可以被实现为运行视频编码软件的cpu。编码引擎102生成经编码的视频数据108以传输到某个远程客户端计算机系统116,该计算机系统包括远程编码引擎(编解码器)110,该编码引擎对比特流进行解码以在由显示控制器112驱动的显示器114上播放。远程客户端计算机系统116是能够对经编码的比特流108进行解码和显示的硬件、设备或软件的任何组合。

图2示出了通过在视频编码过程中重用来自渲染过程的现有补充数据来实现更快的编码时间所需的步骤。在步骤202中,作为位于服务器120的图形引擎100的正常操作功能,必须首先生成补充数据。随着gpu变得越来越强大和普及,实时每像素运动向量生成已成为现代视频游戏引擎的常见功能。在从3d场景渲染2d视频帧期间,3d图形引擎会在颜色生成过程期间生成辅助输出,以用作后续后处理过程的输入。辅助输出可包括写入累积、颜色或速度缓冲区三个存储器位置的信息,该三个存储器位置分别被分配用于临时存储有关像素深度、像素颜色和像素运动的信息。

在运动模糊的常用实现方式(称为似真运动模糊的重建过滤器)中,首先将来自速度缓冲区的每像素速度向降采样成较少数量的切片,其中每个切片均假设是来自像素组的最大速度。然后,使用累积缓冲区中的每像素深度对切片进行遮盖(mask),并将结果应用于颜色缓冲区中的每像素颜色,以生成运动模糊。存在重构过滤器方法的多种变体,其提高保真度、性能或同时提高两者,但是构思仍然相似,并且速度缓冲区包含两个相邻帧之间的每像素运动。尽管“速度”是图形引擎术语中使用的术语,“运动向量”是视频编码术语中使用的术语,但这些术语在功能上是等效的,并且每像素速度与每像素运动向量是相同的事物。速度缓冲区包含像素运动向量形式的补充数据,这些数据将在视频编码过程中被重用。

在步骤204中,位于服务器120处的图形引擎100基于待用于编码的宏块大小将每像素运动向量转换为每块运动向量。h.264编解码器默认使用16x16像素宏块,并且可以选择进一步细分。能够将256个每像素运动向量平均在一起,以提供单个平均向量,作为每块运动向量。结合图3进一步详细描述该过程。

在步骤206中,将每宏块运动向量信息注入位于服务器120处的编码引擎/编码器102中,从而规避运动估计步骤。在编码器的软件实现中,能够完全禁用运动估计步骤,从而显著节省cpu计算时间。cpu中节省的时间应该足以抵消在gpu中计算平均向量(在步骤204中)并将其传输到cpu所需的附加时间。

在步骤208中,由于由图形引擎100提供的每块运动向量与在典型运动估计步骤中计算出的运动向量可互换,因此编码从运动补偿步骤开始(步骤208)。如结合图4进一步详细描述的,视频编码处理的其余部分与使用运动估计技术的编码标准执行的典型运动补偿、残差计算和编码步骤没有明显的不同。

图3进一步详细示出了在图形引擎100中发生的从每像素运动向量到每宏块运动向量的变换。在颜色生成阶段期间,位于服务器120的3d图形引擎100生成每像素运动向量,并将该数据存储在同样位于服务器120的速度缓冲区300中。速度缓冲区300可以仅包含用于动态对象的数据,但不包括玩家相机运动所赋予的运动信息。为了获得图像空间中每个像素的运动向量信息,计算着色器302将速度缓冲区300中的向量与尚未包含在速度缓冲区中的所有静态对象的相机速度相结合,并将每像素结果存储在运动向量缓冲区304中。相机速度是在帧期间旋转和平移相机运动的2d投影。特定的图形引擎可以使用稍有不同的方法来计算整个屏幕空间的这些每像素运动向量,但是构思保持不变。

h.264编码器使用的默认宏块大小为16×16,但能够细分为更小的大小,最小为4×4。在图3的示例中,4×4宏块306用作简化情况,但是应该外推该方法来匹配编码器中使用的宏块大小。对于4×4宏块306,在运动向量缓冲区304中存储了16个每像素运动向量308。这些每像素运动向量308需要变换312为单个的每宏块运动向量310,该单个的每宏块运动向量能够被注入编码器中以用于如图4所示的运动补偿。一组每像素向量308的算术平均是一种具有低计算复杂度和较短计算时间的变换312方法。

能够对算术平均变换312进行可选的修改,以附加的计算复杂度或计算量为代价提高质量。例如,在算术平均值计算之前,能够使用向量中值过滤技术来去除宏块向量域中的不连续性,以确保每宏块运动向量310代表宏块306中的大多数像素。由于最终的每宏块运动向量是从最初基于已知对象运动数据计算出的像素完美运动向量中得出的,所以每宏块运动向量始终是比现有的基于块的运动估计算法计算的运动向量更精确的表示,其中,这些运动估计算法只能基于像素颜色数据得出运动。

图4示出了通过将在图1的服务器120的图形引擎100中生成的运动向量注入图1的服务器120的编码引擎102中来跳过计算复杂的运动估计过程的方法。如下面详细说明的,经编码的视频数据108的结果比特流被传输到远程客户端计算机系统116。图4所示的方法示出了单个帧间的编码过程,特别是由mpeg视频编解码器标准系列定义的p帧的编码过程。由于在i帧生成中未执行运动补偿406,因此不会更改帧内(i帧)生成。一旦色度亚采样视频帧402和每块运动向量数据404可用,它们将被从图形引擎100传输。游戏生成的运动向量404用于规避原本会在典型运动估计426步骤中发生的运动向量生成,如h.264/mpeg-4avc标准中所述的那样。运动估计426步骤将被跳过,并且能够在编码引擎的软件实现中被禁用。跳过基于块的运动估计426步骤将显著减少编码时间,这将大大抵消如结合图3所述的将速度缓冲数据转换为适当格式的时间。

已经转换为适当宏块大小的运动向量404能够被直接使用,而不需要对运动补偿406进行任何更改。运动补偿406的结果与输入色度亚采样视频帧402相结合以形成残差图像430,该残差图像通常由残差变换&缩放408、量化410以及扫描412步骤处理,这些步骤通常在现有硬件或软件视频编码器内发生。

如果实施方案选择的解码标准需要解块步骤,则必须执行解块步骤。解块设置420和已解块的图像428通过应用编码标准的算法进行逆量化414、逆变换&缩放416然后进行解块418来计算。已扫描的系数412与解块设置420组合并在熵编码器422中进行编码,然后作为比特流108传输到远程客户端计算机系统116以在远程客户端计算机系统的编解码器110处进行解码。已解块的图像428成为下一帧的运动补偿406的输入。比特流(包括经编码的视频数据)108保留与实施方式中使用的编码标准例如h.264/mpeg-4avc所定义的相同的格式。该示例特定于h.264/mpeg-4avc标准,通常能够用于使用运动估计426和运动补偿406技术的类似编码标准。

示例1:基准测试表明减少了编码时间

传统h.264兼容编码中的运动估计步骤通常是计算最复杂且最耗时的步骤。如本文所讨论的,重用游戏生成的运动向量能够显著减少编码时间。

在测试环境中,图形引擎以每秒60帧的速度以1280×720的分辨率产生输出。编码时间是从运行单线程的x264编码器捕获的。运行单线程编码器将产生比实际使用更长的编码时间,但将测量标准化为一个核,以便它们彼此直接比较。编码时间首先在编码器内使用未经修改的运动估计进行测量,然后在相同的环境中使用启用的游戏生成的运动估计功能重新测量。

选择一个低运动区域,包括玩家的手、武器和固定墙的第一人称玩家视图。玩家的手和武器通过轻微的“摆动”动画进行循环,在相对较小的屏幕空间中产生少量像素运动。该测试的结果显示在下面的表1中,其中示出了使用和不使用本文描述的游戏生成的运动估计技术时的延迟结果。在低强度下,其中游戏生成的运动估计被禁用,未经修改的编码时间为12ms。当启用游戏生成的运动估计后,编码时间减少了3ms,降至9ms。针对平均运动强度场景和高运动强度场景,示出了类似的延迟减少,对于平均运动强度场景,延迟减少了17.6%,而在高延迟场景中,延迟减少了15%至30%。这些结果表明,当启用游戏生成的运动估计时,延迟显著减少。

表1:不同运动强度下的延迟结果

测试环境还显示了将游戏生成的每像素运动向量转换为用于编码器的每宏块运动向量时存在附加的开销。然而,该开销明显低于上一部分中描述的编码时间减少。利用图形引擎以1280×720的分辨率生成视频,从每像素到每宏块的运动向量转换需要0.02ms。所测得的节省的编码器时间比使用游戏生成的运动向量进行编码所增加的时间成本高三个数量级。

前述说明和附图应该被理解为仅是对本发明原理的说明。本发明不限于该优选实施例,并且可以以本领域普通技术人员所清楚的多种方式来实施。本领域技术人员容易想到本发明的许多应用。因此,不希望将本发明局限于所公开的具体示例或所示出和所描述的确切体系结构和操作。是在本发明的范围内,可以采用所有合适的修改和等同方案。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1