CN115920372A - 数据处理方法及装置、计算机可读存储介质、终端 - Google Patents

Abstract

一种数据处理方法及装置、计算机可读存储介质、终端，数据处理方法，由边缘服务器执行包括：当接收到游戏客户端发送的游戏启动请求时，为游戏客户端创建对应的进程；将动态链接库注入进程并启动动态链接库，以将钩子函数注入至进程，通过钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管系统API，系统API包括画面API和/或音频API；对画面API进行接管后，采集画面数据，并对画面数据进行编码，得到编码后的视频数据；对音频API进行接管后，采集音频数据，并对音频数据进行音频编码，得到编码后的音频数据；将编码后的视频数据以及音频数据分发至游戏客户端。上述方案能够提高游戏的并发路数以及降低每路的成本。

Description

数据处理方法及装置、计算机可读存储介质、终端

技术领域

本发明实施例涉及数据处理领域，尤其涉及一种数据处理方法及装置、计算机可读存储介质、终端。

背景技术

随着移动端的游戏越来越重度化，很多用户的终端(手机、电视等)的配置如图形处理器(Graphics Processing Unit，GPU)等性能无法满足需求，在玩游戏时出现卡顿不流畅等问题。将游戏放在云端基本是未来的趋势。

然而，目前云端游戏主要采用虚拟机或者采用类似docker方案实现，其中docker为一种应用容器引擎。然而，目前采用虚拟机或者docker方案实现的云端游戏，所支持的并发路数少，且每路的成本较高。

发明内容

本发明实施例解决的技术问题是如何提高游戏的并发路数以及降低每路的成本。

为解决上述技术问题，本发明实施例提供一种数据处理方法，由边缘服务器执行，所述数据处理方法包括：当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程；将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管所述系统API，所述系统API包括：画面API和/或音频API；对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据；对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据；将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。

可选的，所述系统API还包括控制方式API，所述方法还包括：对控制方式API进行接管后，获取所述游戏客户端通过触发各控制方式产生的控制指令，所述控制方式包括以下至少一种：键盘、手柄、鼠标；根据所述控制指令控制预先构造的虚拟控制方式执行对应的操作，响应于所述虚拟控制方式执行的操作，得到所述画面数据以及所述音频数据。

可选的，所述根据所述控制指令控制预先构造的底层虚拟控制方式执行对应的操作，包括：当所述游戏客户端所使用的操作系统与所述边缘服务器的操作系统不同时，根据预设的键值映射信息，将所述游戏客户端所使用的系统对应的键值映射至所述边缘服务器的操作系统对应的键值；结合映射至所述边缘服务器的操作系统对应的键值，根据所述控制指令控制所述虚拟控制方式执行对应的操作。

可选的，所述数据处理方法还包括：为所述游戏客户端创建对应的进程后，根据目标游戏的预配置控制方式，为所述进程创建相应数目及相应类型的虚拟控制方式；获取所述游戏客户端的用户标识，将所述用户标识与创建的虚拟控制方式进行绑定。

可选的，所述数据处理方法还包括：根据所述目标游戏的游戏类型确定所述目标游戏支持多人组队时，参与所述目标游戏的多个游戏客户端共用同一进程，在所述进程内，分别为每个游戏客户端创建相应数目及相应类型的虚拟控制方式；针对每个游戏客户端，根据各游戏客户端对应的用户标识，分别将各用户标识与对应的虚拟控制方式进行绑定。

可选的，所述数据处理方法还包括：根据所述目标游戏的游戏类型，当所述目标游戏支持观看直播时，将所述编码后的视频数据以及所述编码后的音频数据分发至参与观看直播的游戏客户端。

可选的，所述系统API还包括存档API，所述方法还包括：对存档API进行接管后，隔离存档路径，并将存档路径定位至指定位置。

可选的，所述将存档路径定位至指定位置，包括：将所述存档路径定位至NAS。

可选的，所述对所述画面数据进行编码，得到编码后的视频数据，包括：每获取一帧画面数据，则对获取的画面数据进行编码，得到编码后的视频数据。

可选的，所述对所述画面数据进行编码，得到编码后的视频数据，包括：通过预设的画面API系统库共享GPU内存，将多种不同类型的画面API转换成指定类型的画面API；采用所述指定类型的画面API对应的渲染方式对所述画面数据进行编码，得到所述编码后的视频数据。

可选的，所述对所述音频数据进行音频编码，得到编码后的音频数据，包括：将所述目标游戏的声音渲染类型转换成指定声音渲染类型；基于创建的声音缓存通道环境，采用所述指定类型的声音渲染类型对所述音频数据进行音频编码，得到所述编码后的音频数据。

可选的，所述将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，包括：获取所述游戏客户端所支持的视频解码类型，采用所述游戏客户端所支持的视频解码类型对所述编码后的视频数据进行打包封装，采用所述游戏客户端支持的传输协议，将封装后的视频数据发送至所述游戏客户端；获取所述游戏客户端所支持的音频解码类型，采用所述游戏客户端所支持的音频解码类型对所述编码后的音频数据进行打包封装，采用所述游戏客户端支持的传输协议，将封装后的音频数据发送至所述游戏客户端。

可选的，采用如下方式确定所述边缘服务器：当检测到所述游戏客户端打开所述目标游戏时，各候选边缘服务器分别向所述游戏客户端发送测试数据，并记录各候选边缘服务器发送所述测试数据到达所述游戏客户端的时间；根据各候选边缘服务器发送所述测试数据到达所述游戏客户端的时间，确定各候选边缘服务器将所述测试数据传输至所述游戏客户端的数据传输耗时，选取数据传输耗时最短的候选边缘服务器作为所述游戏客户端对应的所述边缘服务器。

可选的，所述数据处理方法还包括：定期接收所述游戏客户端反馈的数据消费消息；将当前编码的帧数与所述数据消费消息中反馈的消费帧数进行差比；根据差比结果确定所述编码后的视频数据的分发情况。

可选的，所述根据差比结果确定所述视频数据的分发情况，包括：当差比大于设定第一阈值时，暂停向所述游戏客户端分发所述编码后的视频数据，直至所述差比不超过所述设定第一阈值，恢复向所述游戏客户端分发所述编码后的视频数据。

可选的，所述数据处理方法还包括：根据所述差比与设定第二阈值之间的关系，在对所述视频数据进行编码时，动态调整所述视频数据的编码方式、比特率以及分辨率中的至少一种。

本发明实施例还提供一种数据处理装置，包括：进程创建单元，用于当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程；进程虚拟化单元，用于将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管所述系统API，所述系统API包括：画面API和/或音频API；视频编码单元，用于对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据；音频编码单元，用于对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据；分发单元，用于将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述任一种数据处理方法的步骤。

本发明实施例还提供一种终端，包括存储器和处理器，所述存储器上存储有能够在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行上述任一种数据处理方法的步骤。

与现有技术相比，本发明实施例的技术方案具有以下有益效果：

当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程。同时将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管系统API。通过对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据。对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据。将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。在边缘服务器上，通过将钩子函数注入至所述进程，从而可以对系统API进行钩子操作，让目标游戏认为自身运行在一个正常的操作系统(如WINDOW OS)上面，通过对系统API进行钩子操作，以采集游戏的音频数据和/或画面数据，并将采集到音频数据以及画面数据进行编码，并传输至游戏客户端即可。如此，可以有效地将降低性能损耗，基本上没有额外的性能损耗，从而可以提高游戏的并发路数以及降低每路的成本。此外，游戏客户端只需对收到的编码的视频数据以及所述编码后的音频数据进行渲染并呈现即可，游戏相关的数据处理均是在边缘服务器上实现，游戏客户端相当于充当一个播放器角色，故还可以降低对游戏客户端的配置性能要求。

附图说明

图1是本发明实施例中的一种数据处理方法的流程图；

图2是本发明实施例中的一种用于实现数据处理方法的数据处理系统的结构示意图；

图3是本发明实施例中的一种数据处理装置的结构示意图。

具体实施方式

如上所述，目前采用虚拟机或者采用类似docker方案实现，所支持的并发路数少，且每路的成本较高。

为解决上述问题，在本发明实施例中，在边缘服务器上，通过将钩子函数注入至所述进程，从而可以对系统API进行钩子操作，让目标游戏认为自身运行在一个正常的操作系统(如WINDOW OS)上面，通过对系统API进行钩子操作，以采集游戏的音频数据和/或画面数据，并将采集到音频数据以及画面数据进行编码，并传输至游戏客户端即可。如此，可以有效地将降低性能损耗，基本上没有额外的性能损耗，从而可以提高游戏的并发路数以及降低每路的成本。此外，游戏客户端只需对收到的编码的视频数据以及所述编码后的音频数据进行渲染并呈现即可，游戏相关的数据处理均是在边缘服务器上实现，游戏客户端相当于充当一个播放器角色，故还可以降低对游戏客户端的配置性能要求。

为使本发明实施例的上述目的、特征和有益效果能够更为明显易懂，下面结合附图对本发明的具体实施例做详细的说明。

本发明实施例提供一种数据处理方法，数据处理方法可以由边缘服务器执行。在一些非限制性实施例中，边缘服务器可以采用边缘x86服务器，其中边缘x86服务器也可以称为CISC(复杂指令集)架构服务器，即通常所讲的电脑(PC)服务器，它是基于PC机体系结构，使用英特尔(Intel)或其它兼容x86指令集的处理器芯片和Windows操作系统的服务器。

参照图1，给出了本发明实施例中的一种数据处理方法的流程图，具体可以包括如下步骤：

步骤S11，当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程。

在具体实施中，游戏客户端可以为手机、电脑(PC)、也可以为平板电脑等。可以通过游戏客户端上的游戏网页的网址，也可以通过游戏客户端上的游戏图标，还可以通过游戏客户端上的小程序等入口进入目标游戏。在用户通过游戏客户端进入目标游戏之后，可以触发游戏启动，游戏客户端发送游戏启动请求。当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程。为游戏客户端创建对应的进程之后，可以将游戏客户端与该进程进行绑定。具体而言，在一些非限制性实施例中，在游戏启动请求中可以包括用户标识，可以建立用户标识与线程的绑定。

为了进一步提高游戏过程中的数据传输的时效性，降低数据传输时延，在一些非限制性实施例中，选取距离游戏客户端最近的边缘服务器作为游戏客户端对应的边缘服务器。

在一些实施例中，可以采用如下方式确定游戏客户端对应的边缘服务器：当检测到游戏客户端打开目标游戏时，各候选边缘服务器可以分别向游戏客户端发送测试数据，记录各候选边缘服务器发送的测试数据到达游戏客户端的时间数据传输时长。根据各候选边缘服务器发送所述测试数据到达所述游戏客户端的时间，确定各候选边缘服务器将所述测试数据传输至所述游戏客户端的数据传输耗时，选取数据传输耗时最短的候选边缘服务器作为所述游戏客户端对应的边缘服务器。通过数据传输耗时，可以选取出距离游戏客户端最近的边缘服务器，并采用距离游戏客户端最近的边缘服务器为游戏客户端服务器，如此，不仅可以降低数据传输时延，提高数据传输的时效性，提高用户(也可以称为玩家)的游戏体验。

为进一步提高游戏客户端对应的服务器的确定效率以及降低开销，在本发明一些非限制性实施例中，测试数据可以采用1字节的文本数据，以降低测试数据对网络的占用率，降低测试数据传输时对网络的利用率。可以理解的是，还可以采用其他大小或者其他类型的数据作为测试数据，此处不再一一举例。

为进一步提高游戏客户端对应的服务器的确定效率，可以根据游戏客户端的位置，选取需要进行数据传输耗时测试的候选边缘服务器。如根据游戏客户端的位置，选取处于所述游戏客户端设定区域范围内的边缘服务器作为候选边缘服务器。也即选取处于所述游戏客户端设定区域范围内的边缘服务器作为候选边缘服务器并向游戏客户端发送测试数据，并记录数据传输耗时。从处于所述游戏客户端设定区域范围内的边缘服务器中，选取数据传输耗时最短的候选边缘服务器作为所述游戏客户端对应的边缘服务器。

步骤S12，将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管所述系统API。

在具体实施中，为游戏客户端创建对应的进程时，可以同时将动态链接库(Dynamic Link Library，DLL)注入所述进程，并启动DLL，以将钩子函数注入至进程。通过将核心代码DLL注入至进程，可以实现核心功能与目标游戏在同一个进程运行，通过所述钩子函数对目标游戏所用到的系统应用程序编程接口(Application ProgrammingInterface，API)全部进行钩子(HOOK)，操作，以接管所述系统API。在接管所述系统API后，能够采集游戏的音频数据和画面数据。

在一些非限制性实施例中，可以利于Easyhook开源库将动态链接库注入所述进程。

在具体实施中，所述系统API可以包括画面API和/或音频API。

具体地，以Window系统为例，钩子函数(HOOk)是利用Window系统所提供的事件捕获机制，当对系统API进行HOOk之后，即可以获知该系统API对应的函数地址，进而即可以通过系统API对应的函数地址获取对应的数据。

步骤S13，对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据。

由于不同游戏客户端所支持的画面API类型不同，为了兼容不同操作系统的游戏客户端。在一些非限制性实施例中，通过预设的画面API系统库共享GPU内存，将多种不同类型的画面API转换成指定类型的画面API；采用所述指定类型的画面API对应的渲染方式对所述画面数据进行编码，得到所述编码后的视频数据。

例如，通过Directx3D系统库共享GPU内存，以实现从Directx3D、Directx3D10、Directx3D11至Directx3D12的转换，以将多种不同类型的画面API转换成指定类型的画面API。采用Directx3D12进行构造编码上下文数据，以充分利用高效的Directx3D12渲染方式进行视频编码，得到编码后的视频数据。

在一些非限制性实施例中，可以采用低延时编码，以提高游戏体验。具体而言，每获取一帧画面数据，则对获取的画面数据进行编码，得到编码后的视频数据。具体而言，每输入至所述视频编码器一帧画面数据，则对输入至所述视频编码器的画面数据进行编码，得到编码后的视频数据。

步骤S14，对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据。

由于不同游戏的声音渲染类型不同，有的游戏声音渲染是多通道的，有的是64位浮点型(Float)类型，有的是整数型(INT)类型，有的是短整型(Short)类型。不同类型的游戏客户端所支持的声音渲染类型不同，对于游戏客户端不支持的声音渲染类型，则可能会导致声音播放失败。例如，安卓一些低版本不能兼容64位Float类型的声音播放。

为了兼容不同类型的游戏客户端，在一些非限制性实施例中，将所述目标游戏的声音渲染类型转换成指定声音渲染类型；基于创建的声音缓存通道环境，采用所述指定类型的声音渲染类型对所述音频数据进行音频编码，得到所述编码后的音频数据。

例如，指定声音渲染类型为Short类型时，若目标游戏的声音渲染类型不是Short类型，则转换成Short类型。创建的游戏声音通道缓存环境可以为16位通道缓存。

步骤S15，将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端。

在具体实施中，将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端时，可以通过帧同步的方式确保视频数与音频数据的同步。所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。边缘服务器在发送时提供每帧的起始标记，在游戏客户端接收端检测并获取这一标志的过程称为帧同步。

在一些非限制性实施例中，上述步骤S15可以通过如下方式实现，获取所述游戏客户端所支持的视频解码类型，采用所述游戏客户端所支持的视频解码类型对所述编码后的视频数据进行打包封装，采用所述游戏客户端支持的传输协议，将封装后的视频数据发送至所述游戏客户端。获取所述游戏客户端所支持的音频解码类型，采用所述游戏客户端所支持的音频解码类型对所述编码后的音频数据进行打包封装，采用所述游戏客户端支持的传输协议，将封装后的音频数据发送至所述游戏客户端。

在具体实施中，可以在检测到游戏客户端进入目标游戏时，建立与游戏客户端的连接。在建立游戏客户端的连接时或建立连接后，边缘服务器可以与游戏客户端之间进行数据传输，并可以获取游戏客户端所支持的视频解码类型、音频解码类型以及传输协议等。

在实际应用中，在采用低时延编码以及传输时，由于网络抖动等影响，游戏客户端可能来不及消费分发的视频数据，从而导致延迟。为了解决上述问题，在本发明一非限制性实施例中，可以定期接收游戏客户端反馈的数据消费消息，将当前编码的帧数与所述数据消费消息中反馈的消费帧数进行差比；根据差比结果确定所述编码后的视频数据的分发情况。

具体而言，若差比大于设定第一阈值时，暂停向所述游戏客户端分发所述编码后的视频数据，继续接收下一周期游戏客户端反馈的数据消费消息，并基于下一周期游戏客户端反馈的数据消费消息中指示的消费帧数计算差比，直至差比不超过所述设定第一阈值，恢复向所述游戏客户端分发所述编码后的视频数据。若差比小于设定第一阈值，则继续向游戏客户端分发编码后的视频数据。

例如，游戏客户端在每完成预设帧的画面显示之后，也即每消费预设帧的视频数据和音频数据后，反馈一次数据消费消息。数据消费消息用于反馈游戏客户端对预设帧的视频数据和音频数据的消费情况。根据数据消费消息即可以获知游戏客户端消费到了第几帧。将当前编码的帧数与数据消费消息反馈的游戏客户端消费帧数进行差比。其中，差比即将当前编码的帧数与数据消费消息反馈的游戏客户端消费帧数进行差值运算。根据差比结果确定所述编码后的视频数据的分发情况。

差比可以选取3帧、4帧或者其他数据，具体可以根据对延时的接受程度进行配置。

在一些非限制性实施例中，还可以根据所述差比与设定第二阈值之间的关系，在对所述视频数据进行编码时，动态调整所述视频数据的编码方式、比特率以及分辨率中的至少一种。若差比大于第二阈值，则确定游戏客户端的网络状态不佳，可以降低比特率以及分辨率，还可以采用解码时占用资源较少的编码类型进行编码，以提高游戏播放流程度，提高游戏体验。有助于实现当前网络环境下达到最低传输延时，使得游戏高清流畅。

采用如上方案，当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程。同时将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管系统API。通过对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据。对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据。将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。在边缘服务器上，通过将钩子函数注入至所述进程，从而可以对系统API进行钩子操作，让目标游戏认为自身运行在一个正常的操作系统(如WINDOWOS)上面，通过对系统API进行钩子操作，以采集游戏的音频数据和/或画面数据，并将采集到音频数据以及画面数据进行编码，并传输至游戏客户端即可。如此，可以有效地将降低性能损耗，基本上没有额外的性能损耗，从而可以提高游戏的并发路数以及降低每路的成本。此外，游戏客户端只需对收到的编码的视频数据以及所述编码后的音频数据进行渲染并呈现即可，游戏相关的数据处理均是在边缘服务器上实现，游戏客户端相当于充当一个播放器角色，无须游戏客户端具有较高的配置，只需能够播放视频以及能够进行操控游戏即可，故还可以降低对游戏客户端的配置性能要求。

此外，在边缘服务器上，通过将钩子函数注入至所述进程，从而可以对系统API进行钩子操作，让目标游戏认为自身运行在一个正常的操作系统(如WINDOW OS)上面，通过对系统API进行钩子操作，以采集游戏的音频数据和/或画面数据不需要为虚拟化开销而外的GPU、CPU，在和虚拟机方案同等的配置下，并发路数更高，每路的成本更低。

此外，在边缘服务器上，通过将钩子函数注入至所述进程，从而可以对系统API进行钩子操作，可以实现API的虚拟化，且API的虚拟化和游戏在同一个进程，可以针对不同的游戏引擎优化游戏GPU底层渲染逻辑，从而降低每路消耗的GPU资源。

进一步，所述系统API还包括存档API。存档API用于提供存档服务，以保存用户的游戏进度等相关数据。对存档API进行接管之后，可以隔离存档路径，并将存档路径定位指定至指定位置。

进一步，将存档路径定位至网络附属存储(Network Attached Storage，NAS)。NAS指连接在网络上，具备资料存储功能的装置，因此也称为网络存储器，是一种专用数据存储服务器。NAS以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本。存档API可以包括保存文件方式(CreateFile)的API以及通过写注册表方式(RegCreate)的API。有助于部署一个游戏包体，可以实现跨平台、跨系统以及跨终端运行。

进一步，系统API还包括控制方式API。控制方式API用于提供键盘、手柄、鼠标等控制方式的接口服务。对控制方式API进行接管后，获取所述游戏客户端通过触发各控制方式产生的控制指令，所述控制方式包括以下至少一种：键盘、手柄、鼠标；根据所述控制指令控制预先构造的虚拟控制方式执行对应的操作，响应于所述虚拟控制方式执行的操作，得到所述画面数据以及所述音频数据。对控制方式API进行HOOK后，有助于根据不同的终端来定制游戏操控方式。

进一步，所述根据所述控制指令控制预先构造的底层虚拟控制方式执行对应的操作，可以通过如下方式实现：当所述游戏客户端所使用的操作系统与所述边缘服务器的操作系统不同时，根据预设的键值映射信息，将所述游戏客户端所使用的系统对应的键值映射至所述边缘服务器的操作系统对应的键值；结合映射至所述边缘服务器的操作系统对应的键值，根据所述控制指令控制所述虚拟控制方式执行对应的操作。

在具体实施中，为所述游戏客户端创建对应的进程后，可以根据目标游戏的预配置控制方式，为所述进程创建相应数目及相应类型的虚拟控制方式；获取所述游戏客户端的用户标识，将所述用户标识与创建的虚拟控制方式进行绑定。以避免不同进程或者不同游戏的控制方式交叉以及串掉，确保目标游戏的正常运行。

在具体实施中，根据所述目标游戏的游戏类型确定所述目标游戏支持多人组队时，参与所述目标游戏的多个游戏客户端共用同一进程，在所述进程内，分别为每个游戏客户端创建相应数目及相应类型的虚拟控制方式；针对每个游戏客户端，根据各游戏客户端对应的用户标识，分别将各用户标识与对应的虚拟控制方式进行绑定。针对同一进程产生的视频数据和音频数据，分别分发至该进程的游戏客户端。或者根据实际场景需求，分别响应于不同游戏客户端产生对应的视频数据以及音频数据，并将产生的视频数据和音频数据分发至对应的游戏客户端。

在具体实施中，根据所述目标游戏的游戏类型，当所述目标游戏支持观看直播时，将所述编码后的视频数据以及所述编码后的音频数据分发至参与观看直播的游戏客户端。具体而言，可以将观看直播的游戏客户端对应的用户标识与已建立的线程进行绑定，以便于后续向观看直播的游戏客户端发送视频数据和音频数据。

为便于本领域技术人员更好的理解本发明实施例，参照图2，给出了一种用于实现数据处理方法的数据处理系统的结构示意图，下面结合图2对数据处理方法进行说明。

在具体实施中，数据处理系统可以包括若干个边缘服务器100和若干个游戏客户端500，图2以一个边缘服务器100以及一个游戏客户端500为例进行示意，本领域技术人员可以理解的是，边缘服务器100以及游戏客户端500的数量还可以为其他取值，图2中示意的边缘服务器100的数量以及游戏客户端500的数量并不构成对本发明保护范围的影响。其中，边缘服务器100可以作为上述实施例提供的数据处理方法的执行主体，并用于实现上述实施例提供的数据处理方法。

边缘服务器100可以包括：游戏存放单元10、环境初始化单元20、游戏进程虚拟化服务单元30以及分发单元40。

游戏存放单元10用于实现游戏相关的数据的存放，游戏相关的数据可以包括游戏包体等。游戏存放单元10可以包括：包体文件数量及大小计算模块11、网络环境智能验证模块12、游戏打包传输模块13以及边缘服务器测速模块14。具体而言，游戏开发商(cp)把游戏打包成.exe格式(window版本)并通过游戏存放单元上传至边缘服务器。边缘服务器可以采用边缘x86服务器。

包体文件数量及大小计算模块11用于对游戏包体的完整性以及安全进行验证。通常在将游戏包体上传至边缘服务器100时，需要对游戏包体进行加密。包体文件数量及大小计算模块11可以对加密的游戏包体进行解密(如做md5等)，以验证游戏包体的完整性和安全性。在本发明实施例中，可以通过文件数量以及大小对游戏包体进行验证，以确保必要验证的同时，起到最小性能验证游戏包体的完整性。

网络环境智能验证模块12与环境初始化单元20建立传送链接测试，以确保能够正常链接，这也是保证游戏包体完整性的一个前提，如果检测到网络不好，提醒用户检测网络。

游戏打包传送13可以通过ftp协议(也可以为其他支持的传输协议)将游戏包体安全性传送到环境初始化模块20，等待返回成功通知后可以测试启动游戏。

边缘服务器测速模块14可以用于寻找离用户(也即游戏客户端)最近的边缘服务器。例如，游戏客户端通过获取候选边缘服务器上的1字节的文本数据，记录每个边缘服务器的到达游戏客户端的时间，选取时间最少的边缘服务器作为游戏客户端的游戏服务器，这样用户游戏体验的时间延时最低，有效降低宽带利用率。该边缘服务器测速模块14可用于上述数据处理方法中为游戏客户端就近分配对应的边缘服务器。

环境初始化单元20，用于进行边缘服务器的中央处理器(Central ProcessingUnit，CPU)、图形处理器(Graphics Processing Unit，GPU)等资源初始化、资源管理和统计、用于动态接收游戏的上传和卸载等，是游戏进程虚拟化服务单元30必备初始化工作。环境初始化单元20可以包括游戏包体文件解压验证模块21、服务器资源统计模块22、DLL注入游戏模块、进程虚拟化基础库初始化模块23以及游戏虚拟化配置生成模块25。

游戏包体文件解压验证模块21用于当接收到游戏存放单元10传来的游戏包体的指令时，先会通过计算并验证游戏包体的数量和大小确保游戏是完整的、可运行的。

服务器资源统计22用于在没有启动游戏前，统计服务器的目前的CPU、GPU以及内存等资源的占比，然后启动该游戏后，如可以采用类似monkey智能测试工具进行性能测试，一般会跑一定时长后会记录CPU、GPU或者内存的占比最高值，将占比最高值和之前没有启动游戏前统计的值进行做减法得出上传的游戏的资源消耗结果，然后保存资源消耗结果至游戏虚拟化配置生成25。

DLL注入游戏模块23可以利用Easyhook开源库将核心代码DLL注入至线程，以使得使的我们的核心功能和游戏再同一个进程运行，通过注入至线程的钩子函数能够采集游戏声音及画面的数据，改变游戏控制方式等。

进程虚拟化基础库初始化模块24这个库主要是HOOk外面的库，用于保障后面程序运行，比如保障服务一直在存活状态，检查各个库是否初始化完成等。

游戏虚拟化配置生成模块25，新的游戏会通知测试人员进行通过API检测(API-Monitor)工具测出游戏是用的那种画面渲染类型，也即采用的是哪种画面API，画面API的类型可以包括Direct3D9、Directx3D10、Directx3D11、Directx3D12、vulkan以及openGL等。还可以判断键盘及手柄接入方式是DirectInput、XInput、RawInput或者HID USB设备等。还可以判断游戏存储方式是通过保存文件，还是通过写注册表方式等。最终判断得到的画面API类型、键盘以及手柄接入方式、游戏存储方式等写入游戏虚拟化配置里面供游戏进程虚拟化服务单元30进行服务更新。

游戏进程虚拟化服务单元30是整个边缘服务器的核心模块，是运行游戏的操作系统(Operating System，OS)，不管游戏的画面采集、声音采集、存档保存，还是输入控制都在通过游戏进程虚拟化服务单元30完成。游戏进程虚拟化服务单元30可以包括Window底层API虚拟化隔离子单元31、游戏画面共享视频编码子单元32、音视频编码子单元33、游戏手柄及键盘虚拟化子单元34。

Window底层API虚拟化隔离子单元31主要利用Easyhook开源库进行，对目标游戏所用到的系统API全部HOOK，以接管目标游戏所用到的所有的系统API，让游戏认为自己运行在一个正常的Window OS上面。这样做的好处是性能损耗小，基本上没有额外的损耗。Window底层API虚拟化隔离子单元31可以包括游戏控制虚拟化模块311、游戏画面渲染虚拟化模块312、游戏声音虚拟化模块313、游戏存档虚拟化模块314以及游戏进程多开限制虚拟化模块315。

游戏控制虚拟化模块311用于虚拟化实现游戏控制方式。游戏的控制方式可以包括手柄、键盘、鼠标等。对应的控制方式API(direct API)类型可以包括：DirectInput API、XInput API、RawInput API、人机交互设备(Human Interface Device，HID)API以及JoyStick API等。接管这些控制方式API后模拟这些API的实现。

游戏画面渲染虚拟化模块312，可以用于对画面API进行HOOK，并接管画面API后，可以获取画面数据。具体而言，通过对画面API进行HOOK后，可以获取GPU函数地址，基于GPU函数地址可以获取画面数据。画面API(也可称为图像API)主要包括以下类型：Directx3D9、Directx3D10、Directx3D11、Directx3D12、vulkan以及openGL等。接管这些画面API后可以把画面重定向到视频编码，如重定向至视频编码器进行视频编码，而不在屏幕上输出了。游戏画面渲染虚拟化模块312，可以用于实现上述步骤S13中的部分步骤。

游戏声音虚拟化模块313，用于对音频API进行HOOK，接管音频API后，可以采集音频数据。音频只要接管Windows音频会话(Audio Session)API就可以输出音频数据。后续可以对音频数据进行编码，音频编码类型可以包括高级音频编码(Advanced Audio Coding，AAC)等。

游戏存档虚拟化模块314用于对游戏存档API进行虚拟化，隔离存档路径。存档API可以包括保存文件方式(CreateFile)的API，以及通过写注册表方式(RegCreate)的API。通过对存档API进行HOOK，接管存档API后，可以隔离存档路径，采用共享存储来放这些需要存档的文件数据等。通常一个游戏需要几十个千兆(G)的容量，可以将存档虚拟化定位到NAS来共享这些文件。通过对存档API进行HOOK，可以实现数据的共享，当用户的所处的区域发生变化时，可以便于用户快速获取到最新的存档数据。此外，当有些游戏支持游戏组队时，因为一台游戏服务器共用一个Window系统，且共享存储，游戏存档系统不需要迁移，便于数据的更新。

游戏进程多开限制虚拟化模块315可以用于确定是否已经存在相应的进程来防止重复打开。影响多开的API有CreateMutant以及GetProcessImageFileNameA等，可以根据游戏使用限制多开的类型进行选择配置多开限制。

游戏画面共享视频编码子单元32可以用于对画面数据进行视频编码。由于游戏画面渲染使用的方式不一样，可以将视频编码方式转换成统一视频编码类型。在具体实施中，将游戏GPU画面到硬件编码过程，根据画面API的类型不同，具体实现方式不同，具体而言：

第一种方式：通过Directx3D系统库把GPU内存从Directx3D9、Directx3D10、Directx3D11、direct12等类型的画面API的GPU内存直接映射到控制面板硬件编码输入数据内存，其中控制面板可以为NVDIA控制面板。

第二种方式：当控制面板编码不支持游戏部分扩展Directx3D11、direct12等类型的画面API的时候，就需要从Directx3D11、direct12等类型的画面API的GPU内存通过共享内存的方式转换成Directx3D10的GPU内存，然后将Directx3D10的GPU映射到控制面板硬件编码输入数据内存。

第三种方式：OpenGL画面API从GPU内存映射到控制面板硬件编码输入数据内存。

第四种方式：Vulkan画面API从GPU内存映射到控制面板硬件编码。

游戏画面共享视频编码子单元32可以包含游戏渲染画面采集到共享GPU内存模块321、编码线程参数环境构建模块322、编码共享环境创建模块323以及游戏共享GPU内存转换同步编码模块324。

其中，游戏渲染画面采集到共享GPU内存模块321，分别从Directx3D9、Directx3D10、Directx3D11、Directx3D12、OpenGL以及Vulkan等类型的画面API，获取画面GPU内存环境上下文，并拷贝至编码线程参数环境构建322。

编码线程参数环境构建322，分别创建Directx3D9、Directx3D10、Directx3D11、Directx3D12、OpenGL以及Vulkan等画面API的游戏画面GPU存储上下文初始化，按照配置文件指定的大小、颜色格式来创建相关的API GPU内存。

编码共享坏境创建模块323针对控制面板编码不支持游戏部分扩展Directx3D11、direct12 API的时候，从编码线程参数环境构建模块322得到的Directx3D11以及direct12GPU内存通过共享内存的方式转换成Directx3D10GPU内存，并映射到控制面板硬件编码输入数据内存。

共享内存也是按照配置文件指定的大小、颜色格式来创建相关的API GPU共享内存。

游戏共享GPU内存转换同步编码模块324，最终视频编码的数据是从编码线程参数环境构建模块322和编码共享坏境创建模块323传输过来，该同步方式是采取多线程同步方式，即采集生成GPU内存和消费GPU内存到编码是两种线程并行运行，这样并行协作的方式延时更低，即视频编码不会阻塞游戏的运行，游戏也不会影响视频编码，最终调用控制面板API硬件编码进行H264或者H265编码。

音视频编码子单元33可以包括游戏声音归一化编码模块331和视频低延时编码模块332。通常不同游戏采用的声音渲染类型不同，有的游戏声音渲染是多通道类型，有的游戏是64位Float类型，有的是INT类型，有的是Short类型，然而不同游戏客户端所支持的声音渲染类型不同，可能出现游戏客户端对声音渲染类型不支持，从而影响声音的播放，如有些安卓低版本不能兼容Float类型的声音播放。为兼容不同的游戏客户端，游戏声音归一化编码模块331可以将各种声音渲染类型转换成指定的声音渲染类型，如转换成short类型的声音渲染，以使得各种类型的游戏客户端均能够支持，并正常进行声音的播放。具体而言，游戏声音归一化编码模块331可以进行游戏声音通道缓存环境创建，如创建的是16位声音通道缓存环境，在一些非限制性实施例中，采用的转码算法是audio＝audio*32768，其中，audio为音频数据。

视频低延时编码模块332用于实现视频的低延时编码，以实现视频的低延时，提高用户体验。例如，视频流采用的是H.264编码，主要是720P/30fps、1080P/60fps，可以定义一种封装格式，把H.264和AAC的裸流封装加上控制流数据构成低延时传输数据。低延时编码时使用B帧、把GOP设置为-1保证只有前几帧是I帧，这样传输的数据就会小很多，保证每一帧数据编码器都立刻输出这帧编码数据，以去掉编码器缓冲帧数据。比特率(bitrate)控制，游戏中经常会存在一段时间的静止画面，此时比特率很低，可以自适应调整比特率。经过音视频编码33把编码得到的视频数据以及音频数据传给分发单元40。GOP(Group ofPictures)是一组连续的画面，由一张I帧和数张B/P帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。I帧是内部编码帧(也称为关键帧)，P帧是前向预测帧(前向参考帧)，B帧是双向内插帧(双向参考帧)。

游戏手柄及键盘虚拟化子单元34可以用于构造手柄虚拟驱动底层，以解决每个游戏的鼠标及手柄实现方式不一样，导致要适配很多手柄的问题。从底层驱动来模拟手柄根本保证了游戏手柄的统一性。游戏手柄及键盘虚拟化子单元34可以包括构造特定手柄及键盘驱动数据模块341、虚拟化手柄及键盘win32底层接口模块342以及跨平台控制键值映射模块343。

构造特定手柄及键盘驱动数据模块341可以当游戏启动的时候该模块注册对应数目的手柄并绑定用户标识及游戏ID，以实现用户与手柄的绑定，这样手柄就不会和其它游戏交叉串掉。

通过虚拟化手柄及键盘win32底层接口模块342可以实现标准的win32手柄驱动，包含注册、创建、枚举、获取手柄数据等。其中，win32是指Microsoft Windows操作系统的32位环境，此处以win32为例就进行说明，可以理解的是也可以为win64等。

跨平台控制键值映射模块343该模块接收到用户传递来的不同操作系统的键值信息会转换成Window对应的键值，这样就实现了适配多平台以及不同操作系统的输入控制方式。

通过上述环境初始化单元20以及游戏进程虚拟化服务单元30的配合，可以实现上述步骤S11至步骤S13。

分发单元40用于视频数据以及音频数据的分发、游戏控制事件分发以及游戏存档分发等。分发单元40可以包括游戏控制事件分发模块41、游戏视频分发模块42、游戏音频分发模块43、游戏存档分发模块44以及游戏多路传输服务管理模块45。为了提高延时，本发明实施例中创建了一个单独的服务来服务于各个数据的发送，分为接收服务线程和发送服务线程。具体而言，当接收到游戏控制事件指令时，触发游戏控制事件分发模块41，该模块接收数据解析出键盘或者手柄消息，把解析出的键盘或者手柄消息数据发送给游戏手柄及键盘虚拟化子单元34。当接收到音视频编码子单元33传来的音频数据就会触发游戏音频分发模块43，该模块会根据游戏客户端500的解码能力选择游戏客户端支持的封装类型(如mp3、AAC等)对音频数据进行封装打包并发送至游戏客户端500。当接收到音视频编码子单元33传来的视频数据就会触发游戏视频分发模块42，该模块根据游戏客户端500支持的网络协议，其中网络传输协议可以包括：传输控制协议(Transmission Control Protocol，TCP)、用户数据报协议(User Datagram Protocol，UDP)、基于UDP的数据传输协议(UDP-basedData Transfer Protocol，UDT)、websocket(一种在单个TCP连接上进行全双工通信的协议)、源自网页即时通信(Web Real-Time Communication，WebRTC)等。采用游戏客户端500支持的网络协议，将视频数据发送到游戏客户端500。游戏控制事件分发模块41可以配合游戏控制虚拟化模块311实现上述数据控制方法中的对控制方式API进行接管后，获取所述游戏客户端通过触发各控制方式产生的控制指令，所述控制方式包括以下至少一种：键盘、手柄、鼠标；根据所述控制指令控制预先构造的虚拟控制方式执行对应的操作。

在一些实施例中，由于在进行音频数据传输以及视频数据传输时采用零延迟发送，当因一些因素影响造成网络抖动时，如分发单元40发送数据(视频数据或音频数据)过快，可能导致游戏客户端500来不及消费，结果延迟很大，影响用户体验。

在一些非限制性实施例中，可以设计视频CS同步算法子模块421来解决这个边缘服务器100和游戏客户端500的同步问题，其中C为Client，指游戏客户端500；S为Server，指边缘服务器100。具体而言，游戏客户端500在完成预设帧画面的显示后向分发单元40反馈一个数据消费消息，分发单元40根据游戏客户端500反馈的数据消费消息可以获知游戏客户端500消费到了第几帧，将分发单元40现在编码的帧数与数据消费消息反馈的游戏客户端500消费的帧做差比。若差比不超过设定第一阈值，就继续向游戏客户端500传输下一帧。否则若差比超过设定第一阈值，则等待游戏客户端500的数据消费消息，直到游戏客户端500消费的帧数赶上来。从而当发生网络抖动时，分发单元40能及时感知并停止向游戏客户端500分发音频数据及视频数据，等网络抖动消除后再继续发送音频数据及视频数据，以提高用户游戏体验。

游戏多路传输服务管理模块45用于管理多路音视频传输，每路音视频都是独立的线程传输，互不干扰，音视频数据是来自于游戏视频分发42和游戏音频分发43。在一些实施例中，根据所述目标游戏的游戏类型确定所述目标游戏支持多人组队时，由于参与所述目标游戏的多个游戏客户端共用同一进程，从而分别向同一线程内的多个游戏客户端发送音视频数据。在另一些实施例中，根据所述目标游戏的游戏类型，当所述目标游戏支持观看直播时，对于同一进程中的参与观看直播的游戏客户端，将所述编码后的视频数据以及所述编码后的音频数据分发至参与观看直播的游戏客户端。

上述分发单元40可以用于实现上述步骤S15。

游戏客户端500可以提供用户操作游戏以及与边缘服务器100的连接，以及根据边缘服务器100输出的音频数据以及视频数据进行渲染显示对应的画面和声音。游戏客户端500可以包括音视频解码模块51、音视频渲染模块52、QOS模块53以及操控模块54。

当接收到边缘服务器100通过分发单元40分发的音视频数据(音频数据以及视频数据)则触发音视频解码模块51。在一些实施例中，游戏客户端500采用低延时解码。游戏客户端500解码可以根据游戏客户端500的机型进行软解适配和硬解适配。

其中，硬解适配指对接芯片厂商，由于芯片厂商会专门提供低延时接口，让把缓冲去掉直接输出画面。通过游戏客户端500中的芯片自带的低延时接口实现对音视频的低延时解码。

软解适配指采用软件解码的方式来支持低延迟的输出，如可以利用GPU做一些加速。

音视频渲染模块52根据音视频解码模块51解码出来的数据进行YUV到openGL GPU渲染，此种渲染方式相比传统的YUV至RGB，由RGB至GPU渲染省去了YUV到RGB的过程，可以简化渲染过程。openGL是GPU功能的调用规范，定义了用来操作图形和图片的一系列函数的API，GPU的硬件开发商则需要提供满足openGL规范的实现，这些实现通常被称为“驱动”，它们负责将openGL定义的API命令翻译为GPU指令。其中，YUV是一种颜色编码方法，Y表示明亮度(Luminance或Luma)，也就是灰阶值，U和V表示的则是色度(Chrominance或Chroma)，作用是描述影像色彩及饱和度，用于指定像素的颜色。RGB色彩模式是工业界的一种颜色标准，是通过对红(R)、绿(G)、蓝(B)三个颜色通道的变化以及它们相互之间的叠加来得到各式各样的颜色的，RGB即是代表红、绿、蓝三个通道的颜色。

服务质量(Quality of Service，QOS)模块53用于在网络变差或者变好时动态调整比特率(Bit Rate)、分辨率、码率，以增加玩家的流畅度。

操控模块54用于接收用户的手柄或者鼠标、遥控器的控制方式的操作数据，操控模块54可以发送接收到游戏控制事件指令等数据至分发单元40中的游戏控制事件分发模块41。

其中，上述图2所示意的数据处理系统只是用于实现数据处理方法的一种实现方法，在此基础上，本领域技术人员还可以进行相应的变形，如单元(或模块)的拆分或者合并，以及对单元或者模块的名称的变更等，应当理解的是，只要实现上述实施例中所描述的功能以及效果等均属于本发明的保护范围。在具体实施中，关于数据处理系统的具体工作流程及原理可以参见上述实施例中数据处理方法中的描述，相应地，关于上述数据处理方法的具体工作流程及原理也可以参见上述实施例中的数据处理系统终端中的描述。

本发明实施例还提供一种数据处理装置，参照图3给出的本发明实施例中的一种数据处理装置的结构示意图，数据处理装置60可以包括：

进程创建单元61，用于当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程；

进程虚拟化单元62，用于将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管所述系统API，所述系统API包括：画面API和/或音频API；

视频编码单元63，用于对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据；

音频编码单元64，用于对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据；

分发单元65，用于将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。

在具体实施中，数据处理装置60的具体工作原理及工作流程，可以参见上述实施例中提供的数据处理方法或者数据处理系统中的描述，此处不再赘述。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，所述计算机程序被处理器运行时执行上述任一种数据处理方法的步骤。

本发明实施例还提供一种终端，包括存储器和处理器，所述存储器上存储有能够在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序时执行上述任一种数据处理方法的步骤。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于任一计算机可读存储介质中，存储介质可以包括：ROM、RAM、磁盘或光盘等。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。

Claims (19)

1.一种数据处理方法，其特征在于，由边缘服务器执行，所述数据处理方法包括：

当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程；

将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管所述系统API，所述系统API包括：画面API和/或音频API；对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据；

对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据；

将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。

2.如权利要求1所述的数据处理方法，其特征在于，所述系统API还包括控制方式API，所述方法还包括：

对控制方式API进行接管后，获取所述游戏客户端通过触发各控制方式产生的控制指令，所述控制方式包括以下至少一种：键盘、手柄、鼠标；

根据所述控制指令控制预先构造的虚拟控制方式执行对应的操作，响应于所述虚拟控制方式执行的操作，得到所述画面数据以及所述音频数据。

3.如权利要求2所述的数据处理方法，其特征在于，所述根据所述控制指令控制预先构造的底层虚拟控制方式执行对应的操作，包括：

当所述游戏客户端所使用的操作系统与所述边缘服务器的操作系统不同时，根据预设的键值映射信息，将所述游戏客户端所使用的系统对应的键值映射至所述边缘服务器的操作系统对应的键值；

结合映射至所述边缘服务器的操作系统对应的键值，根据所述控制指令控制所述虚拟控制方式执行对应的操作。

4.如权利要求2所述的数据处理方法，其特征在于，还包括：

为所述游戏客户端创建对应的进程后，根据目标游戏的预配置控制方式，为所述进程创建相应数目及相应类型的虚拟控制方式；

获取所述游戏客户端的用户标识，将所述用户标识与创建的虚拟控制方式进行绑定。

5.如权利要求4所述的数据处理方法，其特征在于，还包括：

根据所述目标游戏的游戏类型确定所述目标游戏支持多人组队时，参与所述目标游戏的多个游戏客户端共用同一进程，在所述进程内，分别为每个游戏客户端创建相应数目及相应类型的虚拟控制方式；

针对每个游戏客户端，根据各游戏客户端对应的用户标识，分别将各用户标识与对应的虚拟控制方式进行绑定。

6.如权利要求4所述的数据处理方法，其特征在于，还包括：

根据所述目标游戏的游戏类型，当所述目标游戏支持观看直播时，将所述编码后的视频数据以及所述编码后的音频数据分发至参与观看直播的游戏客户端。

7.如权利要求1所述的数据处理方法，其特征在于，所述系统API还包括存档API，所述方法还包括：

对存档API进行接管后，隔离存档路径，并将存档路径定位至指定位置。

8.如权利要求7所述的数据处理方法，其特征在于，所述将存档路径定位至指定位置，包括：将所述存档路径定位至NAS。

9.如权利要求1所述的数据处理方法，其特征在于，所述对所述画面数据进行编码，得到编码后的视频数据，包括：

每获取一帧画面数据，则对获取的画面数据进行编码，得到编码后的视频数据。

10.如权利要求1所述的数据处理方法，其特征在于，所述对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据，包括：

通过预设的画面API系统库共享GPU内存，将多种不同类型的画面API转换成指定类型的画面API；

采用所述指定类型的画面API对应的渲染方式对所述画面数据进行编码，得到所述编码后的视频数据。

11.如权利要求1所述的数据处理方法，其特征在于，所述对所述音频数据进行音频编码，得到编码后的音频数据，包括：

将所述目标游戏的声音渲染类型转换成指定声音渲染类型；

基于创建的声音缓存通道环境，采用所述指定类型的声音渲染类型对所述音频数据进行音频编码，得到所述编码后的音频数据。

12.如权利要求1所述的数据处理方法，其特征在于，所述将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，包括：

获取所述游戏客户端所支持的视频解码类型，采用所述游戏客户端所支持的视频解码类型对所述编码后的视频数据进行打包封装，采用所述游戏客户端支持的传输协议，将封装后的视频数据发送至所述游戏客户端；

获取所述游戏客户端所支持的音频解码类型，采用所述游戏客户端所支持的音频解码类型对所述编码后的音频数据进行打包封装，采用所述游戏客户端支持的传输协议，将封装后的音频数据发送至所述游戏客户端。

13.如权利要求1至12任一项所述的数据处理方法，其特征在于，采用如下方式确定所述边缘服务器：

当检测到所述游戏客户端打开所述目标游戏时，各候选边缘服务器分别向所述游戏客户端发送测试数据，并记录各候选边缘服务器发送所述测试数据到达所述游戏客户端的时间；

根据各候选边缘服务器发送所述测试数据到达所述游戏客户端的时间，确定各候选边缘服务器将所述测试数据传输至所述游戏客户端的数据传输耗时，选取数据传输耗时最短的候选边缘服务器作为所述游戏客户端对应的所述边缘服务器。

14.如权利要求1至12任一项所述的数据处理方法，其特征在于，还包括：

定期接收所述游戏客户端反馈的数据消费消息；

将当前编码的帧数与所述数据消费消息中反馈的消费帧数进行差比；

根据差比结果确定所述编码后的视频数据的分发情况。

15.如权利要求14所述的数据处理方法，其特征在于，所述根据差比结果确定所述视频数据的分发情况，包括：

当差比大于设定第一阈值时，暂停向所述游戏客户端分发所述编码后的视频数据，直至所述差比不超过所述设定第一阈值，恢复向所述游戏客户端分发所述编码后的视频数据。

16.如权利要求14所述的数据处理方法，其特征在于，还包括：

根据所述差比与设定第二阈值之间的关系，在对所述视频数据进行编码时，动态调整所述视频数据的编码方式、比特率以及分辨率中的至少一种。

17.一种数据处理装置，其特征在于，包括：

进程创建单元，用于当接收到游戏客户端发送的游戏启动请求时，为所述游戏客户端创建对应的进程；

进程虚拟化单元，用于将动态链接库注入所述进程并启动所述动态链接库，以将钩子函数注入至所述进程，通过所述钩子函数对目标游戏所用到的系统API全部进行钩子操作，以接管所述系统API，所述系统API包括：画面API和/或音频API；

视频编码单元，用于对画面API进行接管后，采集画面数据，并对所述画面数据进行编码，得到编码后的视频数据；

音频编码单元，用于对音频API进行接管后，采集音频数据，并对所述音频数据进行音频编码，得到编码后的音频数据；

分发单元，用于将所述编码后的视频数据以及所述编码后的音频数据分发至所述游戏客户端，使得所述游戏客户端根据接收到的所述编码后的视频数据以及所述编码后的音频数据进行渲染并呈现。

18.一种计算机可读存储介质，所述计算机可读存储介质为非易失性存储介质或非瞬态存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器运行时执行权利要求1至16任一项所述的数据处理方法的步骤。

19.一种终端，包括存储器和处理器，所述存储器上存储有能够在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序时执行权利要求1至16任一项所述的数据处理方法的步骤。

Images