CN110769904B

CN110769904B - 输出内容处理方法、输出方法、电子设备及存储介质

Info

Publication number: CN110769904B
Application number: CN201880003422.0A
Authority: CN
Inventors: 吴东; 李光耀
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2018-05-09
Filing date: 2018-05-09
Publication date: 2021-01-05
Anticipated expiration: 2038-05-09
Also published as: WO2019213879A1; CN110769904A

Abstract

本发明实施例公开了一种输出内容处理方法、输出方法、电子设备和计算机存储介质。应用于应用服务器中的输出内容处理方法，包括：接收至少一个运行有应用客户端的终端发送的操作指令；基于所述操作指令，确定输出对象的状态数据和/或事件消息；其中，所述状态数据，用于指示所述输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧。

Description

输出内容处理方法、输出方法、电子设备及存储介质

技术领域

本发明涉及互联网技术领域，尤其涉及一种输出内容处理方法、输出方法、电子设备和计算机存储介质。

背景技术

在游戏或体育节目等播出的过程中，可能涉及部分视频的立即重播。在现有技术中，这种重播通常需要应用服务器端将重播的所有视频数据都发动给播放终端；播放终端对接收的数据进行处理，进而重播。

研究发现，这种重播技术对带宽及播放终端的处理资源的消耗都很高，故只能在性能较为优越的高性能的播放终端进行，而在性能较低的播放终端中可能会出现卡死等问题。

发明内容

有鉴于此，本发明实施例期望提供一种输出内容处理方法、输出方法、电子设备和计算机存储介质，至少部分解决播放消耗的处理资源及能耗大的问题。

为达到上述目的，本发明实施例的技术方案是这样实现的：

第一方面，本发明实施例提供一种输出内容处理方法，应用于应用服务器中，包括：

接收至少一个运行有应用客户端的终端发送的操作指令；

基于所述操作指令，确定输出对象的状态数据和/或事件消息；其中，所述状态数据，用于指示所述输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧。

第二方面，本发明实施例提供一种输出方法，应用于终端中，包括：

检测操作指令；

向应用服务器发送所述操作指令；

接收所述应用服务器基于至少一个终端发送的操作指令返回的状态数据和/或事件消息，其中，所述状态数据，用于指示输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

基于所述状态数据和/或所述事件消息模拟当前待输出帧的输出内容；

输出所述当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧。

第三方面，本发明实施例提供一种电子设备，所述电子设备为应用服务器，包括：

第一接收单元，用于接收至少一个运行有应用客户端的终端发送的操作指令；

确定单元，用于基于所述操作指令，确定输出对象的状态数据和/或事件消息；其中，所述状态数据，用于指示所述输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

第一发送单元，用于将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧。

第四方面，本发明实施例提供一种电子设备，所述电子设备为终端，包括：

检测单元，用于检测操作指令；

第二发送单元，用于向应用服务器发送所述操作指令；

第二接收单元，用于接收所述应用服务器基于所述操作指令返回的状态数据和/或事件消息，其中，所述状态数据，用于指示输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

模拟单元，用于基于所述状态数据和/或所述事件消息模拟当前待输出帧的输出内容；

输出单元，用于输出所述当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧。

第五方面，本发明实施例提供一种电子设备，所述电子设备为应用服务器或终端，包括：

存储器，用于存储信息；

处理器，与所述存储介质连接，用于通过执行所述存储介质中存储的计算机可执行代码，实现前述技术方案提供的输出内容处理方法和/或输出方法。

第六方面，本发明实施例提供一种计算机存储介质，所述计算机存储介质存有计算机可执行代码，所述计算机可执行代码被执行后，实现前述技术方案提供的输出内容处理方法和/或输出方法。

本发明实施例所提供的输出内容处理方法、输出方法、电子设备和计算机存储介质。

第一方面，应用服务器不会直接给应用客户端提供视频输出的全部数据时，而是会接收至少一个终端的操作指令，结合这些操作指令确定出输出场景中的输出对象的状态数据和/或事件消息；仅将状态数据和/或事件消息发送给对应的终端，由终端基于接收到的状态数据和/或事件消息模拟输出场景，显然比将所有输出场景的输出数据直接发送给终端，减少了带宽，减少了数据流量。

第二方面，应用服务器给出的状态数据和/或事件消息是用于应用客户端输出当前待输出帧，这里的当前待输出帧可以为首播帧，也可以是重播输出的重播帧；应用服务器不再利用不同线程或不同的模拟场景分别维护首播帧和重播帧；这样的话，应用客户端接收的当前待输出帧也仅是基于前一个输出帧的状态数据和/或事件消息，应用客户端的本地也不用维护分别模拟首播场景和重播场景的两个线程和两个模拟场景，降低了应用客户端的软件资源的消耗，不局限于应用于高性能的终端中。

第三方面，在本实施例中，应用客户端基于状态数据和/或事件消息进行输出场景的模拟，可以是基于前一个输出帧的进行模拟，而不用每次都基于输出数据进行输出场景的整体模拟，减少了终端自身因为输出场景模拟所消耗的系统资源。这样的话，即便处理资源较少或处理能力较弱，或当前比较繁忙的终端，也能够基于接收的数据量较小的状态数据和/或事件消息进行输出场景的模拟，同时模拟出画面质量优良和/或音效好的输出场景。

总之，本实施例提供的输出内容确定方法、输出方法等技术方案，具有输出效果好且消耗的带宽资源、存储资源及计算资源的至少其中之一少的特点。

附图说明

图1为本发明实施例提供的输出系统的结构示意图；

图2为本发明实施例提供的第一种输出内容处理方法的流程示意图；

图3为本发明实施例提供的第一种状态数据和/或事件消息的传输示意图；

图4为本发明实施例提供的第二种状态数据和/或事件消息的传输示意图；

图5为本发明实施例提供的第三种状态数据和/或事件消息的传输示意图；

图6为本发明实施例提供的第二种输出内容处理方法的流程示意图；

图7为本发明实施例提供的第四种状态数据和/或事件消息的传输示意图；

图8A为本发明实施例提供的第五种状态数据和/或事件消息的传输示意图；

图8B为本发明实施例提供的第六种状态数据和/或事件消息的传输示意图；

图9为本发明实施例提供的一种输出方法的流程示意图；

图10为本发明实施例提供的一种应用服务器的结构示意图；

图11为本发明实施例提供的一种终端的结构示意图；

图12为本发明实施例提供的第一种电子设备的结构示意图；

图13为本发明实施例提供的第二种电子设备的结构示意图；

图14为本发明实施例提供的首播和重播的播放效果比对示意图；

图15为本发明实施例提供的一种输出内容处理及输出方法示意图；

图16为本发明实施例提供的另一种输出方法的流程示意图；

图17为本发明实施例提供的重播效果比对示意图；

图18为本发明实施例提供的一种从第一人称视角切换到第三人称视角播放的流程示意图；

图19为本发明实施例提供的一种从第三人称视角切换回第一人称视角播放的流程示意图。

具体实施方式

以下结合附图对本发明的优选实施例进行详细说明，应当理解，以下所说明的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

对本发明进行进一步详细说明之前，对本发明实施例中涉及的名词和术语进行说明，本发明实施例中涉及的名词和术语适用于如下的解释。

终端，可包括：台式机电脑、电视机顶盒、Xbox/PS3游戏机、户外广告展示屏等固定终端；也可以为智能手机、笔记本电脑、平板电脑和车载广告展示屏等移动终端。本发明实施例中的所述终端可为运行有所述应用客户端的移动终端或固定终端等电子设备。

输出场景：输出场景与输出内容对应的业务场景相关；所述业务场景可以基于应用确定。例如，游戏应用的游戏场景、社交应用的社交场景。

在本实施例中所述游戏可分为显示二维游戏画面的2D游戏和至少部分画面或显示对象为三维画面或三维对象的3D游戏。

所述游戏可包括：多人在线的对战游戏或联盟游戏、单人与应用服务器对战的单机游戏、基于虚拟显示的多人在线的对战游戏、联盟游戏和/或单机游戏等。

输出对象可包括：环境对象和/或角色对象；所述环境对象可包括：显示画面中的各种景物搭建的环境，例如，游戏场景中的战斗场等。所述角色对象可包括：可被终端或应用服务器操作的主体对象。例如，游戏场景中的游戏角色。例如，游戏王者荣耀，若用户A在游戏中扮演的是角色项羽；则项羽这个角色即为所述游戏角色的一种。例如，在赛车游戏中，赛道及赛道周边的设施(如加油站)均可构成所述环境对象。而被用户操作的赛车即为所述角色对象的一种。

若所述输出场景为社交场景，则社交场景的社交界面可为环境对象的一种，而社交场景中被用户操作的社交角色可为角色对象的一种。

状态数据，可用于描述环境对象的状态，也可以用于描述角色对象的状态。所述状态可包括：运动状态、属性状态、表征状态及对象数据的一种。

所述运动状态，可包括：当前是前进、后退、还是静止不同；是奔跑、还是行走，还是隐藏等各种与运动相关的状态。

所述属性状态，可包括：描述当前环境对象和/或角色对象的属性对应的状态的信息。例如，在游戏场景中游戏角色剩余生命值为所述属性状态的一种，在游戏场景中游戏战场的武器的武力值业务所述属性状态的一种。

所述表征状态，可包括：可隐藏场景中的是否隐藏、隐藏后到可见度；角色对象上衣服配饰的状态，和/或环境对象中环境的变化。在游戏场景中，在一段时间的战斗之后，同一个游戏场景从春景切换到夏景等状态。

所述对象数据，可为用于应用客户端建立环境对象和/或角色对象的基本图像的图像数据。例如，游戏角色的角色数据，可以用于应用客户端模拟出对应的游戏角色等。

所述状态数据可为：全量状态数据和/或增量状态数据。

所述全量状态数据可为：描述了一个输出场景中所有输出对象的状态的数据。全量状态数据又可分为：处理前的全量状态数据和处理后的全量状态数据。处理前的全量状态数据包括：某一个输出场景当前帧内所有输出对象的状态数据，而处理后的全量状态数据为：将相邻两次输出的处理前的状态数据进行比对等差量计算的，得到本次处理前的全量状态数据，与前一次处理前的全量状态数据的差异状态数据，而这一部分差异状态数据即为本次处理后的全量状态数据。处理后的全量状态数据的数据量是小于处理前的全量状态数据。

事件消息可为由应用服务器发送给终端，指示当前输出场景中输出对象的状态切换的通知。该通知内可以携带有触发状态切换的触发事件的标识信息。终端接收到这种携带有触发事件的标识信息之后，就可以知道当前是哪一个触发事件触发了输出场景中的输出对象的状态切换，可以基于该触发事件对应的触发逻辑，计算出状态切换导致的状态变化量和/或最终的状态结果等信息。例如，所述事件消息，可用于指示当前待输出帧中每一个输出对象的全部状态切换的通知。

在一些应用场景中，所述事件消息，也可以不携带所述触发事件的标识信息，可仅为一个提示终端输出场景中输出对象有状态变化的通知。这样终端接收到之后可以基于通知，查询状态数据，结合状态数据进行输出场景的模拟和输出。

首播帧，为第一次在应用客户端中输出的视频帧，又可以称为首次输出帧。

重播帧，为已经在应用客户端中输出了至少一次且再次输出的视频帧。所述重播帧，可包括：实时重播帧和非实时重播帧。

实时重播帧为：首次播放结束后立即重播的重播帧。实时重播应用在游戏领域，可为一种战斗内进行重播的重播技术，重播结束后，需要回到战斗当前最新时刻，继续进行战斗。

非实时重播帧为：首次播放结束后，再插播一些其他内容后的重播帧。

模拟，在应用场景中可以对一个或多个对象进行更新、演算得到对应对象的当前输出，可称为模拟。

图1所示的为一种输出系统，包括：运行应用客户端的终端及应用后台。所述应用后台包括一台或多台应用服务器。在图1中显示有三种不同类型的终端，分别均是运行有与应用后台连接的应用客户端的终端1、终端2及终端3。终端1可为以个人电脑(PC)为代表的固定终端；终端2可为以非通信设备如笔记本电脑等移动网络终端；终端3可以为以通信设备如手机或平板电脑等移动通信设备为例的移动通信终端。这些终端均运行有对应版本的应用客户端，可与应用后台内的应用服务器进行信息交互。在本申请实施例中，运行应用客户端的终端可为固定终端、移动网络终端及移动通信终端中的一种或多种。

如图1所示，所述终端内的应用客户端可以以有线方式或无线方式，与应用后台交互操作指令、状态数据和/或事件消息的至少其中之一，以使应用服务器协助终端利用可能少的带宽资源、计算资源和存储资源进行输出场景的模拟和输出。

如图2所示，本实施例提供一种输出内容处理方法，应用于应用服务器中，包括：

步骤S110：接收至少一个运行有应用客户端的终端发送的操作指令；

步骤S120：基于所述操作指令，确定输出对象的状态数据和/或事件消息；其中，所述状态数据，用于指示所述输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

例如，在一些实施例中，所述步骤S120可为：基于操作指令，确定出输出场景的输出对象的状态数据和/或事件消息；所述输出场景为：当前在所述应用客户端的输出的场景或者需要在所述应用客户端中输出的场景，例如，不同场次的游戏对应了不同的游戏场景、或者有些上不同的空间场景。例如，在一个视频或游戏中，将具有相关性的游戏片段或视频帧编辑到同一个输出场景中，同一个输出场景的不同图像帧展示的空间位置相同。

步骤S130：将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：首次输出帧的首播帧或重播输出的重播帧。可选地，所述当前待输出帧为：同一所述输出场景的首播帧或重播输出的重播帧。

根据不同的业务场景，确定同一个输出场景显示应用客户端可为一个或多个。例如，所述应用客户端为单机游戏应用，则应用服务器仅接收一个运行应用客户端的终端发送的操作指令。再例如，所述应用客户端为对战游戏应用或多人联盟游戏应用等，则所述应用服务器接收的可为两个或两个以上的均运行有应用客户端的终端发送的操作指令，且这些操作指令可为作用于同一个输出场景的操作指令，不同的是：这些操作指令可为作用于同一个输出场景中不同的输出对象。例如，对战游戏应用中，两个游戏角色对战是作用于各自游戏角色的战斗指令等。在某些联盟游戏中，不同的应用客户端虽然操作不同的角色对象，但是可能同时攻击另一个游戏角色，这样的话，这些来自不同应用客户端的操作指令可能是作用于同一个输出场景中的相同输出对象的。可选地为：所述步骤S110可包括：接收至少两个终端作用于同一个所述输出场景的操作指令。

总之，在本实施例中，所述应用服务器接收一个或多个运行应用客户端的终端发送的操作指令。

基于该操作指令，确定出输出对象的状态数据和/或事件消息。

所述步骤S120可至少包括以下三种实现方式：

方式一：所述步骤S120中可以仅分发状态数据；

方式二：所述步骤S120也可仅分发送事件消息；

方式三：所述步骤120会同时向应用客户端分发状态数据和事件消息。

在方式一，所述状态数据可为输出对象的当前状态或者是结果状态，接到该状态数据之后，所述应用客户端可以直接基于状态数据重现出在应用服务器中已经模拟出的输出场景。

在方式二中，所述应用客户端接收到事件消息，基于事件消息至少知道有哪些输出对象有状态切换，并可以基于触发事件的标识信息及事件逻辑，自动计算出所述状态数据，再模拟出对应的输出场景。

在方式三中应用服务器同时将所述状态数据和事件消息发送给应用客户端(即终端)，虽然存在着一定的数据冗余，但是当其中一个接收失败或出现错误时，可以基于另一个实现输出场景的模拟和重新，确保输出场景的输出的可靠性。

若在一些情况下，出现状态数据和事件消息的冲突，则根据携带的优先级确定是以状态数据为准还是以事件消息为准，进行模拟和输出。在本实施例中可选为：状态数据的优先级高于事件消息的优先级，当然在另一些场景中可为：事件消息的优先级高于状态数据的优先级。在还有一些实施例中，若出现冲突，则应用客户端可以向应用服务器直接请求重传。

在本实施例中步骤S120中确定出所述状态数据和/或事件消息，具体可包括：所述应用服务器基于接收到的操作指令和各个输出对象的状态，模拟所述输出对象的状态变化，和/或，基于默认设置的触发事件，模拟出所述输出对象的状态变化，从而得到所述状态数据和/或事件消息。

在步骤S130中直接将所述状态数据及所述事件消息中的至少其中之一发送给对应的应用客户端。

例如，在游戏场景中，应用客户端1和应用客户端2在进行游戏对战，在某一个时刻应用客户端1发送了战斗指令，而应用客户端2的用户还未来的及反应，则由于应用客户端检测到的战斗指令，已经导致输出场景的角色对象在当前帧发送的变化，应用服务器基于应用客户端1所在终端发送的战斗指令，在步骤S120中结合之前输出场景的角色对象的状态，模拟出在执行所述战斗指令之后的角色对象的状态数据和/或携带有所述战斗指令的指令标识的事件消息。然后将所述状态数据和/或携带有所述事件消息，分别分发给应用客户端1和应用客户端2所在的终端，用于终端模拟出执行战斗指令之过后的输出场景。

在本实施例中当前待输出的当前待输出帧可为首次输出的首播帧，也可以非首次输出的重播帧。故在本实施例中，当前待输出帧可包括：首播帧和重播帧。

在本实施例中实质上对于应用客户端仅基于状态数据和/或事件消息进行当前待输出帧的输出，不会区分首次播放场景还是重播场景，故不用分配两套资源，分别用于首播模拟输出和重播模拟输出，从而减少了占用应用客户端的资源的使用，且是基于状态数据和/或事件消息进行输出模拟，并非直接从应用客户端接收输出数据，从而对于首次播放及重播都减少了带宽资源的占用。

可选地，所述步骤S120还可包括：

根据所述操作指令，确定出所述当前待输出帧相对于前一个输出帧的增量状态数据和/或事件消息；其中，所述增量状态数据，用于指示在当前待输出帧中状态发生过变化的输出对象的当前状态。

所述步骤S130可包括：

将所述增量状态数据和/或所述事件消息，分发所述终端，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧。

在本实施例中所述增量状态数据和事件消息，都是表征的相邻输出的两帧之间的差异确定的。

如图4所示，应用服务器在一个输出场景的待输出的首帧，将整个输出场景的全量状态数据和/或事件消息分发给应用客户端1，在第k帧时，将相对于第k-1帧的增量状态数据和/或事件消息发送给应用客户端1，在第k+1帧时，将第k帧相对于第k帧的增量状态数据和/或事件消息发送给应用客户端。一直到第k+m帧发送增量状态数据和/或事件消息。这样的话，应用客户端将结合增量状态数据及事件消息，在前一个输出帧的输出内容的基础上调整对应的输出对象的状态，得到当前待输出帧的输出内容，从而通过增量状态数据和/或事件消息，结合前一个输出帧的输出内容，可以模拟输出场景的待输出内容，具有充分的利用前后两帧的关联性，尽可能减少了模拟所消耗的计算资源及带宽资源等，具有资源消耗小且输出效果好的特点。这样的话，除了首帧以外，所述应用服务器均可以通过增量状态数据及事件消息中的至少之一，使得应用客户端可以简便模拟出输出场景当前的待输出内容。

在一些实施例中，所述步骤S120可包括：

基于所述操作指令，确定当前待输出帧每一输出对象的全量状态数据和/或事件消息；其中，所述全量状态数据，用于指示当前待输出帧中每一个输出对象全部状态；所述事件消息，用于指示当前待输出帧中每一个输出对象的全部状态切换的通知。

所述步骤S130可包括：

将所述全量状态数据和/或所述事件消息，分发给所述终端，其中，所述全量状态数据和/或所述事件消息，分别用于所述终端模拟出当前待输出帧的输出内容并显示所述当前待输出帧。

如图3所示，应用服务器在第k帧的全量状态数据和/或事件消息都发送给应用客户端1。在第k+1帧的全量状态数据和/或事件消息发送给应用客户端1，一直到第k+m帧发送全量状态数据和/或事件消息。这样的话，所述应用客户端1可以直接基于当前接收到的全量状态数据和/或事件消息直接模拟当前输出帧。

在一些实施例中，所述步骤S120还可包括：

在满足全量发送条件时，基于所述操作指令生成所述全量状态数据和/或事件消息；

在不满足全量发送条件时，基于操作指令生成所述增量状态数据和/或事件消息。

则所述步骤S130可包括：

在满足所述全量发送条件时，发送所述全量状态数据和/或事件消息；

在不满足所述全量发送条件时，发送所述增量状态数据和/或事件消息。

如图5所示，所述应用服务器设置有增量缓冲区和全量缓冲区；在全量缓冲区内存储全量状态数据和/或事件消息；在增量缓冲区内存储增量状态数据和/或事件消息。

所述步骤S120可包括：

应用服务器将全量缓冲区内第k帧的全量状态数据发送给应用客户端；

应用服务器将增量缓冲区内第k+1至第k+n-1帧增量数据和/或事件消息发送给应用客户端；

应用服务器将全量缓冲区内第k+n帧的全量状态数据发送给应用客户端；

应用服务器将增量缓冲区内第k+n+1至第k+2n-1帧的增量数据和/或事件消息发送给应用客户端。

在本实施例中为了尽可能的减少数据的发送，应用客户端在发送全量状态数据时，一般不再同步发送对应的事件消息。

故在上述实施例中，所述应用服务器每隔n帧向应用客户端发送一次所述全量状态数据。在本实施例中n为1或2或3等取值。故判断是否满足所述全量发送条件可包括：判断与上一次全量状态数据的发送是否已经隔了n帧。

在还有一些实施例中，所述方法还包括：自动触发全量发送条件的判断，例如，在升级游戏中，用户每过一关每升一级都认为满足所述全量发送条件。在还有些实施例中，输出场景变化可包括：应用场景的切换，例如，应用场景从执行业务逻辑1的应用场景1切换到执行业务逻辑2的应用场景2，则可认为满足所述全量发送条件。

在还有一些实施例中，若一个输出场景中新增了预定个数的全新输出对象，这里的输出对象可为环境对象和/或角色对象，则可认为满足所述全量发送条件。

总之，在本实施例中，所述应用服务器同时维护有全量缓冲区和增量缓冲区，在满足全量发送条件时，才向应用客户端发送全量状态数据，否则就发送增量状态数据和/或事件消息。

在一些实施例中，为了进一步减少带宽的使用，避免在带宽比较小时发送全量状态数据导致的带宽不够的问题。如图6所示，在本实施例中所述步骤S120可包括：

步骤S121：基于所述操作指令，确定出当前待输出帧的本次所述全量状态数据；

步骤S122：将本次全量状态数据与前一次全量状态数据进行差量计算，以得到本次全量状态数据相对于前一次全量状态数据的处理后的本次全量状态数据。

首先计算出本次需要发送的全量状态数据，然后进行前后两次发送全量数据的差量计算，得到本次全量状态数据与前一次全量状态数据的差异状态数据，删除与前一次全量状态数据相同的状态数据，仅保留所述差异状态数据作为本次处理后的全量状态数据，这样的话，显然可以减少发送给应用客户端的全量状态数据的数据量。

具体如图7所示，所述方法包括：

应用服务器在第k帧进行差量计算，将第k帧的处理后的全量状态数据，并发送给应用客户端；该出后的全量数据可为如优化后的全量状态数据，此处的优化后可包括：数据量压缩后的全量状态数据。

应用服务器对第k+n帧相对于第k帧对应的全量状态数据进行差量计算，得到第k+n帧的处理后的全量状态数据，并发送应用客户端；

针对第k帧及第k+n帧以外的帧(相当于每隔n个帧进行一次差量计算)，应用服务器进行增量计算，得到增量状态数据，并增量状态数据和/或事件消息发送给应用客户端。此处的增量计算可为相邻两帧之间的增量计算，也可以是第k+m帧相对于第k帧的增量计算，其中，m为小于n的正整数。

在一些实施例中，所述步骤S120可包括：

基于所述终端的全量请求或所述应用服务器中的内部触发事件，将所述全量状态数据和/或所述事件消息发送给所述终端。在另一些实施例中，所述步骤S120可包括：基于所述终端的全量请求或所述应用服务器中的内部触发事件，将所述增量状态数据和/或所述事件消息发送给所述终端。

例如，应用客户端自动通过发送请求的发送，向应用客户端请求全量状态数据。应用服务器若接收到了请求全量状态数据的全量请求，可认为是满足所述全量发送条件。在还有一些实施例中应用自动预设了很多发送全量状态数据的内部触发事件，基于当前输出场景的输出状态和/或应用的进程状态等确定是否满足所述内部触发事件，若满足了内部触发事件，则可认为满足所述全量发送条件，向应用客户端发送全量状态数据。当然，这里仅是举例，具体实现，不局限于上述任意一种。例如，所述应用服务器在模拟输出场景的输出时，发现本次模拟的输出场景发生了应用场景的切换，则可认为满足了所述全量发送条件，需要计算出当前待输出帧的全量状态数据。

在一些实施例中，应用服务器发送了第k+n帧的增量状态数据和事件消息之后，需要重播第k帧的输出内容，则本实施例所述的方法具有两种以上的实现方式：

方式一：

如图8A所示，将需要重播的第k帧的全量状态数据给应用客户端，由应用客户端基于第k帧的全量状态数据进行输出场景的模拟和输出。

方式二：

如图8B所示，将需要重播的第k帧相对于上一个输出帧(即第k+n-帧)的增量状态数据和/或事件消息发送给所述应用客户端，由应用客户端结合重播的第k帧的增量状态数据和/或事件消息，与第k+n帧的输出内容，模拟出重播的重播帧，并输出重播帧。

总之，在本实施例中不管是进行首次播放帧还是重播帧的播放，都可以仅涉及一套输出场景的线程处理，无需开辟两套线程及分配两个输出场景的资源分别对首次播放和重播的处理，减少应用客户端资源的使用。

在一些场景中，所述方法还包括：

计算第一客户端以第一视角重播预定应用场景的插值延时；

分别将所述插值延时发送给第一客户端和所述第二客户端；其中，所述插值延时，用于所述第一客户端以第一视角重播所述预定应用场景，并用于原本以第二视角首次输出所述预定应用场景的所述第二客户端，以所述第一视角重播所述预定应用场景。

这里的第一视角和第二视角是不同的视角。例如，第一视角可为第一客户端的主视角，第二视角可为第二客户端的主视角。例如，在游戏应用中，第一客户端操作角色对象A，第二客户端操作角色对象B；所述第一客户端的主视角即为所述角色对象A的主观视角；第二客户端的主视角可为角色对象B的主观视角。

在一些重播场景，例如，游戏对战场景或游戏联盟对战场景，进行游戏角色死亡或者升级场景的重播时，是需要切换视角进行播放的。

但是两个应用客户端中其中一个的播放视角切换一下重播。在模拟输出场景的过程中，通常重播时可能播放速度会比首次播放时稍微延迟一些，而在延迟时间内需要进行角色对象可能需要进行插值运动。这里的插值运动为，基于接收到运动数据通过插值算法，增加两个运动节点之间的中间运动节点，以避免网络抖动导致的不能够及时接收运动数据(为状态数据的一种)导致的输出效果差的问题，实现角色对象的平滑运动。若实现了平滑运动则在应用客户端输出时，不会出现卡顿等问题。

在本实施例中计算的是第一客户端以第一视角重播时的插值延时，将该插值延时发送给第二客户端，第二客户端接收到后能够从第一视角切换到第二视角，并基于所述插值延时播放特定应用场景，例如，游戏角色死亡和/或升级场景等。这样不会因为，第二客户端直接以第二视角的插值延时来播放第一视角的插值延时重播，导致的播放异常或播出效果差的问题。

如图9所示，本实施例提供一种输出方法，应用于运行有应用客户端的终端中，包括：

步骤S210：检测操作指令；该操作指令可包括：基于从用户界面检测的用户输入的操作指令，还可以是某一个应用场景的预设触发的操作指令；该操作指令可包括：启动指令和/或作用于应用客户端已经输出的输出场景的操作指令；

步骤S220：向应用服务器发送所述操作指令；

步骤S230：接收所述应用服务器基于至少一个终端发送的操作指令返回的状态数据和/或事件消息，其中，所述状态数据，用于指示输出场景中输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

步骤S240：基于所述状态数据和/或所述事件消息模拟当前待输出帧的输出内容；

步骤S250：输出所述当前待输出帧，其中，所述当前待输出帧可为：首播帧或重播输出的重播帧。

在本实施例中提供的输出方法，为应用于终端中的方法。

在步骤S210中可以从人机交互接口检测所述操作指令。例如，利用鼠标检测鼠标操作指令，利用键盘检测键盘操作指令，利用语音交互装置检测用户输入的语音操作指令，或者，利用触摸屏幕检测触摸操作指令等。

在本实施例中将检测到的操作指令发送给应用服务器。

应用服务器可能会接收到一个或多个操作同一个输出场景的应用客户端的操作指令。基于应用服务器基于接收到的操作指令，会自动模拟出当前的输出场景，从而获得表征相对于前一个输出帧中各个输出对象的状态变化，从而会获得状态数据，与此同时还可以获得事件消息。并将状态数据和/或事件消息发送给应用客户端，这样在步骤S230中会接收到状态数据和/或事件消息。

应用客户端在接收到状态数据和/或事件消息之后，至少基于接收到的状态数据及事件消息中的一个或两个，模拟出输出场景中的当前待输出帧的输出内容，并在模拟出当前待输出帧后输出。这里的当前待输出帧可为首播帧或重播的重播帧。

这里的首播帧和重播帧，利用应用客户端内同一套线程和同一批分配的计算资源及存储资源进行处理，并不会区分重播模拟和首播模拟，这样减少了输出场景模拟所消耗的资源。且在本实施例中，所述终端将根据状态数据和事件消息中的至少一个进行模拟，并不会直接从应用客户对端接收输出数据直接输出。

在一些实施例中，所述步骤S230可包括：

接收所述应用服务器返回的全量状态数据和/或事件消息。在本实施例中若所述应用服务器接收到是全量状态数据，则可以直接基于全量状态数据模拟出输出场景。

所述步骤S240可包括：基于所述全量状态数据和/或所述事件消息模拟所述当前待输出帧的输出内容。

在另一些实施例中，所述步骤S230可包括：

接收处理后的本次全量状态数据和/或所述事件消息。这里应用客户端相当于接收到的不全的全量状态数据。故在所述步骤S240，包括：

基于本次全量状态数据及前一次的全量状态数据及前一次的事件消息，模拟当前待输出帧的输出内容。

将本次接收到的全量状态数据结合上一次的全量状态数据，得到本次所有的全量状态数据，然后基于得到的所有的全量状态数据模拟出当前待输出帧的输出内容。

在一些实施例中，所述应用客户端还会接收到对象数据，该对象数据为可为全量状态数据中的一种，该对象数据可用于环境对象和/或角色对象的模拟。例如，当前输出场景新增一个角色对象，需要显示该角色对象的一些基本数据，而这些数据即为所述全量状态数据中特殊的对象数据。该对象数据可以是对象标识。应用客户端中存储有应用中各种可显示的输出对象的对象标识和用于模拟该对象的对象模拟数据，故接收到该对象标识之后，查询本地存储介质中的对象模拟数据，则可以输出对应的对象图像。

在另一些实施例中，所述步骤S230可包括：

接收所述应用服务器发送的增量状态数据和/或事件消息，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧；

所述步骤S240可包括：基于所述增量状态数据和/或所述事件消息，并结合前一个输出帧的输出内容，模拟所述当前待输出帧的输出内容。

在本实施例中所述应用客户端，可能接收到的是增量状态数据和/或事件消息，若接收到增量状态消息，则应用客户端基于前一帧的输出内容，根据所述增量状态数据微调输出内容的部分内容，就可以得到当前待输出帧的输出内容。例如，在游戏对战场景中，仅需基于增量状态数据调整游戏场景中游戏角色的部分动作即可，显然尽可能的减少了模拟当前待输出帧的所需的操作及消耗的资源，该资源可包括模拟输出场景的计算资源及模拟过程中存储数据的存储资源等资源。

如图10所示，本实施例提供一种电子设备，所述电子设备为应用服务器，其中，包括：

第一接收单元110，用于接收至少一个运行有应用客户端的终端发送的操作指令；

确定单元120，用于基于所述操作指令，确定输出对象的状态数据和/或事件消息；其中，所述状态数据，用于指示所述输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

第一发送单元130，用于将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧，例如，同一所述输出场景的首播帧或重播输出的重播帧。

本实施例提供的电子设备为应用服务器。这里的第一接收单元110及第一发送单元130可对应于应用服务器中的通信接口，可以用于应用服务器与应用客户端的数据交互。

所述确定单元120，可对应于应用服务器中的处理器。所述处理器，可用于通过计算机程序等计算机可执行代码，实现上述状态数据和/或事件消息的确认。

在本实施例中，所述处理器可为：应用处理器AP(AP，Application Processor)、中央处理器(CPU，Central Processing Unit)、数字信号处理器(DSP，Digital SignalProcessor)或可编程门阵列(FPGA，Field Programmable Gate Array)、微处理器(MCU，Mirco Processing Unit)或专用集成电路(ASIC，Application Specific IntegratedCircuit)。

在本实施例中所述应用服务器会基于至少一个应用客户端的终端发送的操作指令，通过自行模拟得到状态数据和/或消息事件，发送给应用客户端，而不区分是重播帧还是首次播放帧，通过状态数据和/或消息事件的发送，减少了应用客户端接收数据所需的带宽，另一方面是应用客户端不再区分重播帧和首次播放帧，从而应用客户端不用分别维护重播输出场景和首次输出场景的所需的资源(计算资源和存储资源)，减少了应用客户端中资源的使用，可以用于资源少或低能力的终端的输出场景的模拟和输出。

在一些实施例中，应用服务器计算得到的增量状态数据，则对应地，所述确定单元120，用于根据所述第一操作指令和/或所述第二操作指令，确定出所述当前待输出帧相对于前一个输出帧的增量状态数据和/或事件消息；其中，所述增量状态数据，用于指示在在当前待输出帧中状态发生过变化的输出对象的当前状态。对应地，所述第一发送单元130，用于将所述增量状态数据和/或所述事件消息，分发所述终端，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧。

结合增量状态数据及前一个输出帧的输出内容，在前一个输出帧的基础上通过环境对象和/或角色对象的微调，就可以得到当前待输出帧，进可能的减少应用客户端所消耗的模拟输出场景所需的资源。

在另一些实施例中，所述应用客户端会在满足全量发送条件时，发送全量状态数据。则所述确定单元120，用于基于所述第一操作指令和第二操作指令，确定输出场景中当前待输出帧每一输出对象的全量状态数据和/或事件消息；其中，所述全量状态数据，用于指示当前待输出帧中每一个输出对象全部状态。对应地，所述第一发送单元130为将所述全量状态数据和/或所述事件消息，分发给所述终端，其中，所述全量状态数据和/或所述事件消息，分别用于所述终端模拟出当前待输出帧的输出内容并显示所述当前待输出帧。

若应用客户端接收到是全量状态数据，则应用客户端可以直接基于全量状态数据进行输出场景的当前帧的模拟。这样，应用客户端在进行应用场景切换等情况下，可以获得全量状态数据，实现前后两帧变化较大的输出场景的当前待输出帧的模拟。

可选地，所述确定单元120，用于基于所述操作指令，确定出所述输出场景中当前待输出帧的本次所述全量状态数据；将本次全量状态数据与前一次全量状态数据进行差量计算，以得到本次全量状态数据相对于前一次全量状态数据的处理后的本次全量状态数据；

所述第一发送单元130，用于将处理后的本次全量状态数据和/或所述事件消息，发送给所述终端，其中，处理后的本次全量状态数据，用于所述终端结合所述前一次全量状态数据模拟出当前待输出帧的输出内容，并显示所述当前待输出帧。

在本实施例中需要减少全量状态数据的发送，会基于前后两次的全量状态数据的差值计算，得到处理后的全量状态数据，从而应用客户端接收到的数据量是减少的，可以减少带宽并减少传输时延和输出时延。

在一些实施例中，所述应用服务器还包括：

计算单元，用于计算第一客户端以第一视角重播预定应用场景的插值延时；

所述第一发送单元130，还可用于分别将所述插值延时发送给第一客户端和所述第二客户端；其中，所述插值延时，用于所述第一客户端以第一视角重播所述预定应用场景，并用于原本以第二视角首次输出所述预定应用场景的所述第二客户端，以所述第一视角重播所述预定应用场景。

所述计算单元可对应于计算器或处理器等。

所述第一发送单元130会将一个应用客户端的插值延时，发送给需要切换视角进行重播的另一个应用客户端，从而实现重播过程中的视角切换重播，且由于插值延时的发送，减少了输出帧的抖动，使得输出更加顺畅。

在一些实施例中，所述第一接收单元110，可用于接收至少两个终端作用于同一个所述输出场景的操作指令。这里至少两个终端均为运行同一个应用客户端的两个终端设备。例如，游戏应用中两台对战的终端等。

如图11所示，本实施例一种电子设备，所述电子设备为终端，包括：

检测单元210，用于检测操作指令；

第二发送单元220，用于向应用服务器发送所述操作指令；

第二接收单元230，用于接收所述应用服务器基于所述操作指令返回的状态数据和/或事件消息，其中，所述状态数据，用于指示输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

模拟单元240，用于基于所述状态数据和/或所述事件消息模拟当前待输出帧的输出内容；

输出单元250，用于输出所述当前待输出帧。

本实施例提供了一种终端，这里的终端可为移动终端，也可以为前述的固定终端。

所述检测单元210可包括各种类型的人机交互接口，例如，键盘、鼠标、语音识别采集装盒子、触摸屏等各种可用于终端与人交互的接口设备。

在本实施例中，所述第二发送单元220及所述第二接收单元230可对应于终端的外部通信接口，该接口可以用于运行在终端中的应用客户端与应用客户端的信息交互。这里的信息交互，可包括：状态数据和/或事件消息及操作指令等交互。

所述模拟单元240可对应于处理器，这里的处理器可为前述的CPU、MCU、DSP、AP、PLC或ASIC等。

所述输出单元250，至少对应于显示屏；所述显示屏可为液晶显示屏、电子墨水显示屏或投影显示屏或有机发光二级管(OLED)显示屏等可以显示信息的显示结果。

在一些实施例中，所述输出单元250除了对应于所述显示屏以外，还对应于音频输出模组，例如，扬声器或耳机输出声道，这样输出音频信息。

总之，本实施例提供了一种终端，可以以更少的资源的进行输出场景的模拟并输出。

可选地，所述第二接收单元230，用于接收所述应用服务器返回的全量状态数据和/或事件消息；所述模拟单元240，用于基于所述全量状态数据和/或所述事件消息模拟所述当前待输出帧的输出内容。

在本实施例中接收的状态数据为全量状态数据，这样模拟单元240是基于全量状态数据及事件消息中的至少一个模拟当前待输出帧的输出内容。

在另一些实施例中，所述第二接收单元230，用于接收处理后的本次全量状态数据和/或所述事件消息；所述模拟单元240，用于基于本次全量状态数据及前一次的全量状态数据及前一次的事件消息，模拟当前待输出帧的输出内容。

第二接收单元230在本实施例中实质上接收的处理后的全量状态数据，减少了接收的状态数据量，从而减少了带宽的占用。

可选地，所述第二接收单元230，用于接收所述应用服务器发送的增量状态数据和/或事件消息，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧。对应地，所述模拟单元240，用于基于所述增量状态数据和/或所述事件消息，并结合前一个输出帧的输出内容，模拟所述当前待输出帧的输出内容。

在一些实施例中，所述应用客户端为第二客户端；所述第二接收单元220，可用于接收第一客户端以第一视角重播预定应用场景的插值延时；所述模块单元240，可用于基于所述插值延时从第二视角切换到第一视角重播所述预定应用场景。

在本实施例中进行预定应用场景的重播时，可能需要切换视角，故在本实施例中需要从应用服务器接收插值延时，需要结合插值延时切换视角重播预定应用场景。

如图12所示，本实施例还提供一种电子设备，所述电子设备为应用服务器或终端，包括：

存储器310，用于存储信息；

处理器320，与所述存储器310连接，用于通过执行所述存储介质中存储的计算机可执行代码，能够实现前述的一个或多个技术方案提供的输出内容确定方法及输出方法。

这里的存储器310可为各种类型的存储介质，例如，光盘、硬盘、磁带、随机存储介质或只读存储介质；所述存储介质可为非瞬间存储介质。

在本实施例中所述处理器320与存储器310相连，具体可如利用集成电路(IIC)总线等连接所述处理器。

这里的处理器可为前述的CPU、MCU、DSP、AP、PLC或ASIC等。

所述电子设备可为前述的应用处理器，也可以为前述的终端。若所述电子设备为终端，则所述电子设备还至少包括显示屏，所述显示屏用于显示输出场景等。若所述电子设备包括显示屏，所述显示屏同样连接到所述处理器，例如，通过IIC或串行外设接口(IPS)总线等连接到所述处理器。

参见图13示出的电子设备14的一个可选的软硬件结构示意图，电子设备14包括硬件层、驱动层(驱动层可包括：中间件145)、操作系统层(操作系统层可包括操作系统146)和软件层(软件层可包括安装在操作系统内的应用147)。然而，本领域的技术人员应当理解，图13示出的电子设备14的结构仅为示例，并不构成对电子设备14结构的限定。这里的电子设备可为前述应用服务器或运行有应用客户端的终端。

电子设备14的硬件层包括处理器141、输入/输出接口143，存储介质144以及网络接口142，组件可以经系统总线连接通信。

处理器141可以采用中央处理器、微处理器专用集成电路或逻辑可编程门阵列实现。

输入/输出接口143可以采用如显示屏、触摸屏、扬声器等输入/输出器件实现。

存储介质144可以采用闪存、硬盘、光盘等非易失性存储介质实现，也可以采用双倍率(DDR，Double Data Rate)动态缓存等易失性存储介质实现，其中存储有用以执行上述信息处理方法的可执行指令。

本实施例还提供一种计算机存储介质，所述计算机存储介质存有计算机可执行代码，所述计算机可执行代码被执行后，能够实现前述的一个或多个技术方案提供的输出内容确定方法及输出方法。

以下结合上述任意一个实施例提供几个具体示例：

示例1：

图14的上半图为首播效果示意图；图14的下半图为重播的效果示意图。首播和重播都发生为一个设备内，在同一场战斗的实时模拟结果。

图14中首播时，角色A被对面拿着枪2的角色B击杀，当角色A死亡后，立刻进行实时重播，进行死亡镜头的播放如图14中的下半图所示。即以击杀者拿着枪2的角色B的角度去重温是如何击杀拿着枪1的角色A的。当角色A重生时，需要结束死亡镜头，即结束重播，重新恢复游戏。

重播还可以用作更多的其他实时模拟情况，比如可以在合适的时候，用来播放一场战斗的某个精彩的时刻。

重播也可以用作非实时的情况。比如可以把玩家的战斗过程都记录下来，然后以文件形式保存到用户设备本地，用户可以按需使用该文件进行重播。

因为重播能够比较精确地重现历史情况，所以重播也可用于项目组开发过程中，进行调试、性能调优。

如图15所示，本示例提供一种输出方法，可用于游戏内的实时重播。

应用服务器分别从客户端1和客户端2接收的第k帧的操作指令；

接收到双方的操作指令之后，应用服务器进行模拟第k帧；

客户端1和客户端2也会各自基于本端的操作指令进行预先模拟；

应用服务器将基于自身对第k帧的模拟，分别向客户端1和客户端2发送第k帧的状态数据和事件消息；

客户端1和客户端2在接收到第k帧的状态数据和事件消息后，分别实用本端的预先模拟结果进行校验，结合两端操作的状态数据和事件消息进行整个输出场景的模拟；

客户端1和客户端2分别采集第k+1帧操作；

客户端1和客户端2分别上报第k+1帧操作指令。

所述校验可包括：对状态数据中本端的状态模拟结果对应的状态数据，与从应用服务器接收的本端的状态数据进行比对是否一致，一致则认为通过验证，否则可认为不通过；

在实时游戏过程中，我们采取客户端-服务器(Client-Server)的网络同步模式，即客户端把本客户端操作指令上报给应用服务器、应用服务器把应用服务器进行输出场景的模拟、将整个输出场景的状态数据和事件消息发送给各个客户端、客户端使用服务器下发的状态数据和事件消息进行模拟(包括预先模拟校验)，然后重复本过程，一帧一帧地重复执行下去。

如果客户端收到状态数据和事件消息，不会区分是历史时刻还是当前时刻的状态数据和事件消息，直接进行模拟输出。这样对于客户端的输出效果为，若接收到的是历史时刻的状态数据和事件消息，则客户端利用当前时刻的模拟输出场景的资源，进行历史时刻的模拟。

在客户端在模拟历史时刻的时候，如果服务器突然下发最新的世界状态和事件消息，则客户端又能立刻回到最新的时刻进行模拟。

这样简便的实现了历史时刻的重播和当前时刻的首播的简单切换，且能够尽可能的减少使用资源。

示例2：

本示例基于示例1的输出方法的进一步改进，区别点在于：应用服务器都把输出场景的全量状态数据、所有事件消息，每一帧都发送给客户端。在客户端已经回到历史时刻进行重播的时候，应用服务器也可以把最新时刻的输出场景的数据同时发给客户端。但是这样可能会导致发送的数据量比较大，有鉴于此，本示例提出了一种优化方法，包括：

应用服务器会在正常模拟输出场景的过程中，不断地把每一帧的增量状态数据和事件消息，保存在服务器的增量缓冲区(delta buffer)里，另外也会以稍微低的频率(比如1秒1次)，把输出场景的全量状态数据保存在全量缓冲区(snapshot buffer)里。即在本申请中所述全量状态数据的发送频次高于增量状态事件的发送频次。

这样的话，当且仅当客户端切换为重播模拟的第一帧、或切换为实时游戏模拟的第一帧，才需要从服务器的全量缓冲区将全量状态数据下发给客户端、其他大部分时间，都是从增量缓冲区里把增量状态数据和事件消息下发给客户端，从而大量节省带宽。

另外，客户端进行实时重播模拟的时候，应用服务器的实时输出场景并不会多余地把没用的实时游戏模拟数据也发送给客户端，仅仅把全量缓冲区、增量缓冲区的数据发给客户端。

另外，应用服务器下发全量状态数据之前，应用服务器也会就此全量状态数据再进行一次差量计算，计算出当前客户端的全量状态数据和当前服务器准备下发的全量状态数据之间的差别，从而再一次节省同步数据、从而节省带宽流量。

经过以上优化，从实际数据情况，可节省重播模拟的流量和带宽，传输速率要求可以从300KB/s优化到了6KB/s。

在一些情况下，应用服务器同时将实时游戏输出场景的数据、实时重播输出场景的数据都发给客户端，在客户端里同时进行实时游戏世界、实时重播世界两个输出场景的模拟。这种做法能比较方便地实现两个世界之间的切换。但这中方法简单粗暴的实现方法，因为这带来了没必要的(上一节提到的)带宽流量的同时，也给客户端带来了不必要的性能损耗，这在移动设备等运算能力比较差的设备上，会带来非常不好的体验。

在实际情况下，两个全量状态数据之间，世界内的角色实例是差别不大的，仅仅是这些角色的一些位置、旋转、技能等状态数值的不一样而已，利用这一点特性，在实时游戏、实时重播互相切换时的全量状态数据下发时，重用同一批角色，当收到创建角色数据，如16所示，仅仅将这些数据应用到这些已经存在的角色里。最差情况下，两个全量状态数据之间的角色实例完全不一样。此时本将销毁所有旧角色、创建所有新角色，这将带来比较客观的性能损耗，但从实际情况看来，这种情况几乎不存在，基于统计，平均每次全量数据，只有2％左右的几率需要创建或销毁角色，98％的几率都是进行角色的状态数值更新，从而节省了大量的创建或销毁操作，从而优化了性能。

从而，在这个基础上，最关键地，在客户端里，一个时刻只进行一个输出场景的模拟，从而大幅地节省了同时模拟两个输出场景的额外消耗，这大幅地节省了客户端性能。

正如前面提到的，在实时重播模拟的时候，服务器不会发实时游戏的数据给客户端，这既节省带宽，也只用进行一个输出场景的实时游戏、实时重播两者情况的模拟。

如图16所示，在本示例中，输出方法可包括：

步骤S1：收到应用服务器的全量状态数据；

步骤S2：判断是哪一种对象操作，若是需要更新对象则进入步骤S5，若需要销毁对象则进入步骤S6，若需要进行创建对象，则进入步骤S3；

步骤S3：提取创建对象的数据；

步骤S4：判断对象A是否已存在，这里的对象A为所述创建对象的数据指向的待创建的对象；若不存在进入步骤S7，若已存在，则进入步骤S9；

步骤S5：获取更新对象的数据；

步骤S6：获取销毁对象的标识；

步骤S7：根据对象A的类型，创建对象A；

步骤S8：销毁对象B，这里销毁的对象B为根据步骤S6中获取的标识确定的；

步骤S9：将数据应用到对象A。

在本示例中获取的各种操作对象的数据，均可为从应用服务器中接收到的全量状态数据中提取。

示例3：

为了避免网络抖动带来的不流畅的感觉，在模拟的过程中，常对角色运动采取插值延迟的处理。即让角色稍微延迟一点移动，而在延迟的时间段内进行插值运动。从而如果有网络抖动导致客户端不及时收到运动数据时，也能做到平滑移动。

但这种重播时一般情况下将遇到问题。比如客户端A操作角色A、客户端B操作角色B，角色A把角色B杀死。在实时重播死亡镜头时，客户端B是以角色A的视角去观察的。因为客户端A中的角色B是有插值延迟A的，所以如果客户端B中的角色B以客户端B的插值延迟B进行，将导致位置不精确问题。

本示例解决了这个问题，在示例1和示例2的基础上做了进一步改进。在重播的时候，将重播视角的人的插值延迟也考虑进去，进行延迟补偿。接着上面的例子，即服务器会把客户端A的插值延迟A告诉客户端B，客户端B将以插值延迟A去重播角色B，从而达到和客户端A的插值延迟效果一样。

从图17可以看出，左部图像是没开启延迟补偿的情况，在重播中，远处的角色被杀死时，已经往左离开了准星。本发明实施例会基于插值延迟开启的延迟补偿。图17中右部图，远处被杀死的角色，被杀死时精确地到达准星。

以下结合上述任意实施例提供几个具体示例：

本示例提供两种输出对象的输出视角，例如，第一人称视角和第三人称视角，第一人称视角和第三人称视角可对同一个输出对象进行图像采集或输出的不同视角。例如，游戏玩家观看游戏场景中的视角为第一人称视角，而游戏玩家在游戏时旁观者的挂看游戏的视角可为所述第三人称视角。

例如，在游戏场景中，游戏玩家A枪杀了一个游戏角色B，游戏玩家A可以从自身的视角观测到游戏角色B被枪杀，但是游戏场景(输出场景的一种)中旁观者C或者玩家B是从第三人称视角看到游戏角色B被枪杀的，游戏玩家A和旁观者C或者玩家B看到的游戏角色B被枪杀的观看角度是不一样。在本示例中，所述游戏玩家A强杀游戏角色B的枪杀指令可为前述步骤S110中操作指令的一种；所述游戏角色B被枪杀从活着状态切换到死亡状态的状态数据可为前述输出对象的状态数据的一种；或者携带有游戏角色B被枪杀的信息可为前述事件消息的一种。游戏玩家A所使用的终端设备在发送了枪杀指令、接收到状态数据和/或事件消息之后，会从不同的人称视角来呈现游戏角色B被枪杀的过程。游戏玩家A所在终端的所述首播帧可为第一人称视角的输出帧，对应于该首播帧的重播帧可为第三人称视角的输出帧。如此，即便首播帧和重播帧输出的是同一个输出场景中同一输出事件，但是以不同的人称视角进行输出，从而会使得用户有不同的观看感受，从而提升用户的用户体验。

在一些情况下：在输出场景中某一个输出对象的发生预定状态变化之后，例如，游戏场景中游戏角色死亡或者掉血或者游戏角色变身等状态变化后，首先利用多个第一人称视角的首播帧展示上述预定变化的过程；然后利用多个第三人称视角的重播帧展示上述预定变化的过程。在终端模拟输出首播帧和重播帧时采用前述任意一个实施例中提供给的方法，通过状态数据和/或事件消息的接收，利用同一套线程来分别模拟并输出首播帧和重播帧。值得注意的是在本示例中首播帧和重播帧虽然是展示的同一个输出场景中的预定过程，但是是从不同的视角展示的。该预定过程可为预先确定需要重播的过程，在本示例中以区分首播的人称视角来重播该预定过程。

例如，在游戏场景中，增加死亡状态播放，在玩家死亡之后，会从第一人称视角转换为第三人称视角播放死亡动作并显示玩家死亡的位置。在死亡状态播放完之后播放死亡过程(Killcam)，直到角色重生，能够让玩家看到自己的游戏角色的死亡过程。与此同时，在播放死亡状态和死亡场景的时候，都提供更换角色的功能按钮。玩家角色死亡之后，摄像机从第一人称视角拉出，切换为第三人称视角，好像呈现一个玩家的死亡状态。玩家死亡状态播放完后，才开始播放Killcam。在上述两个阶段：呈现死亡状态阶段和播放Killcam阶段中，都允许选择游戏角色，但选择游戏角色会延时生效，在玩家重生的瞬间才会切换。

如图18所示，本示例提供一种信息内容处理方法，以实现从第一人称视角播放切换至第三人称视角播放，可包括：

输出对象发生预定状态变化，例如，游戏角色死亡；

终端中的画面抖动，以提示用户发生预定变化；

播出预定状态变化；

第一人称视角消失，在完成第一人称视角的首次输出之后，摄像机脱离第一人称视角；

第三人称视角出现，摄像机转向第三人称视角，即摄像机的采集视角与第三人称的观看视角相同；

重播预定状态变化过程完毕，摄像机静止；

在发生预定变化位置静止，完成了不同人称视角的同一个预定状态过程的首播和重播。

如图19所示，本示例还提供一种输出内容处理方法，以实现第三人称视角播放切换回第一人称视角播放，可包括：

以第三人称视角进入预定状态变换回放，例如，游戏角色死亡回放；

播放预定变化过程，并黑屏；

摄像机脱离第三人称视角；

转换为发生预定变化的角色A的视角，摄像头跟随角色A；

输出预定变化过程的最后画面，并跟随角色A的后续状态变化，例如，角色A的重生等；此处为以第一人称视角播放预定变化过程的最后画面。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理模块中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，凡按照本发明原理所作的修改，都应当理解为落入本发明的保护范围。

Claims

1.一种输出内容处理方法，应用于应用服务器中，包括：

接收至少一个运行有应用客户端的终端发送的操作指令；

将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧；

所述基于所述操作指令，确定输出对象的状态数据和/或事件消息，包括：

在不满足全量发送条件的情况下，根据所述操作指令，确定出所述当前待输出帧相对于前一个输出帧的增量状态数据和/或事件消息；其中，所述增量状态数据，用于指示在当前待输出帧中状态发生过变化的输出对象的当前状态；

所述将所述状态数据和/或所述事件消息分发给所述终端，包括：

2.根据权利要求1所述的方法，其中，

在满足所述全量发送条件的情况下，基于所述操作指令，确定当前待输出帧每一输出对象的全量状态数据和/或事件消息；其中，所述全量状态数据，用于指示当前待输出帧中每一个输出对象全部状态；所述事件消息，用于指示当前待输出帧中每一个输出对象的全部状态切换的通知；

3.根据权利要求2所述的方法，其中，

基于所述操作指令，确定出当前待输出帧的本次所述全量状态数据；

将本次全量状态数据与前一次全量状态数据进行差量计算，以得到本次全量状态数据相对于前一次全量状态数据的处理后的本次全量状态数据；

所述将所述全量状态数据和/或所述事件消息，分发给所述终端，包括：

将处理后的本次全量状态数据和/或所述事件消息，发送给所述终端，其中，处理后的本次全量状态数据，用于所述终端结合所述前一次全量状态数据模拟出当前待输出帧的输出内容，并显示所述当前待输出帧。

4.根据权利要求1所述的方法，其中，

所述方法包括：

在全量缓冲区内存储全量状态数据和/或事件消息，其中，所述全量状态数据，用于指示当前待输出帧中每一个输出对象全部状态；所述事件消息，用于指示当前待输出帧中每一个输出对象的全部状态切换的通知；

在增量缓冲区内存储增量状态数据和/或事件消息，其中，所述增量状态数据，用于指示在当前待输出帧中状态发生过变化的输出对象的当前状态。

5.根据权利要求4所述的方法，其中，

基于所述终端的全量请求或所述应用服务器中的内部触发事件，将所述全量状态数据和/或所述事件消息发送给所述终端；

或者，

基于所述终端的全量请求或所述应用服务器中的内部触发事件，将所述增量状态数据和/或所述事件消息发送给所述终端。

6.根据权利要求1所述的方法，其特征在于，

所述方法还包括：

计算第一客户端以第一视角重播预定应用场景的插值延时；

分别将所述插值延时发送给第一客户端和第二客户端；其中，所述插值延时，用于所述第一客户端以第一视角重播所述预定应用场景，并用于原本以第二视角首次输出所述预定应用场景的所述第二客户端，以所述第一视角重播所述预定应用场景。

7.根据权利要求1所述的方法，其特征在于，

所述接收至少一个终端的操作指令，包括：

接收至少两个终端作用于同一个输出场景的操作指令，其中，所述输出场景为：当前在所述应用客户端的输出的场景或者需要在所述应用客户端中输出的场景。

8.一种输出方法，其中，应用于终端中，包括：

检测操作指令；

向应用服务器发送所述操作指令；

输出所述当前待输出帧，其中，所述当前待输出帧为：同一所述输出场景的首播帧或重播输出的重播帧；

所述接收所述应用服务器基于至少一个终端发送的操作指令返回的状态数据和/或事件消息，包括：

接收所述应用服务器在不满足全量发送条件的情况下发送的增量状态数据和/或事件消息，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧；

所述基于所述状态数据和/或所述事件消息模拟当前待输出帧的输出内容，包括：

基于所述增量状态数据和/或所述事件消息，并结合前一个输出帧的输出内容，模拟所述当前待输出帧的输出内容。

9.根据权利要求8所述的方法，其中，

接收所述应用服务器在满足所述全量发送条件的情况下返回的全量状态数据和/或事件消息；

所述基于所述状态数据和/或所述事件消息模拟输出场景中当前待输出帧的输出内容，包括：

基于所述全量状态数据和/或所述事件消息模拟所述当前待输出帧的输出内容。

10.根据权利要求9所述的方法，其中，

所述接收所述应用服务器在满足所述全量发送条件的情况下返回的全量状态数据和/或事件消息，包括：

接收处理后的本次全量状态数据和/或所述事件消息；

所述基于所述全量状态数据和/或所述事件消息模拟所述当前待输出帧的输出内容，包括：

11.根据权利要求8至10任一项所述的方法，其特征在于，所述应用客户端为第二客户端；

所述方法还包括：

接收第一客户端以第一视角重播预定应用场景的插值延时；

基于所述插值延时从第二视角切换到第一视角重播所述预定应用场景。

12.一种电子设备，所述电子设备为应用服务器，包括：

第一接收单元，配置为接收至少一个运行有应用客户端的终端发送的操作指令；

确定单元，配置为基于所述操作指令，确定输出场景中输出对象的状态数据和/或事件消息；其中，所述状态数据，用于指示所述输出对象的状态；所述事件消息，用于指示所述输出对象的状态切换的通知；

第一发送单元，用于将所述状态数据和/或所述事件消息分发给所述终端；其中，所述状态数据和/或所述事件消息，用于待输出所述输出场景的终端模拟出当前待输出帧的输出内容并显示当前待输出帧，其中，所述当前待输出帧为：同一所述输出场景的首次输出帧或重播输出的重播帧；

所述确定单元，用于在不满足全量发送条件的情况下，根据所述操作指令，确定出所述当前待输出帧相对于前一个输出帧的增量状态数据和/或事件消息；其中，所述增量状态数据，用于指示在当前待输出帧中状态发生过变化的输出对象的当前状态；

所述第一发送单元，用于将所述增量状态数据和/或所述事件消息，分发所述终端，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧。

13.根据权利要求12所述的电子设备，其中，

所述确定单元，用于在满足所述全量发送条件的情况下，基于所述操作指令，确定当前待输出帧每一输出对象的全量状态数据和/或事件消息；其中，所述全量状态数据，用于指示当前待输出帧中每一个输出对象全部状态；所述事件消息，用于指示当前待输出帧中每一个输出对象的全部状态切换的通知；

所述第一发送单元，用于将所述全量状态数据和/或所述事件消息，分发给所述终端，其中，所述全量状态数据和/或所述事件消息，分别用于所述终端模拟出当前待输出帧的输出内容并显示所述当前待输出帧。

14.根据权利要求13所述的电子设备，其特征在于，

所述确定单元，用于基于所述操作指令，确定出当前待输出帧的本次所述全量状态数据；将本次全量状态数据与前一次全量状态数据进行差量计算，以得到本次全量状态数据相对于前一次全量状态数据的处理后的本次全量状态数据；

所述第一发送单元，用于将处理后的本次全量状态数据和/或所述事件消息，发送给所述终端，其中，处理后的本次全量状态数据，用于所述终端结合所述前一次全量状态数据模拟出当前待输出帧的输出内容，并显示所述当前待输出帧。

15.一种电子设备，所述电子设备为终端，包括：

检测单元，用于检测操作指令；

第二发送单元，用于向应用服务器发送所述操作指令；

输出单元，用于输出所述当前待输出帧，其中，所述当前待输出帧为：首播帧或重播输出的重播帧；

所述第二接收单元，用于接收所述应用服务器在不满足全量发送条件的情况下发送的增量状态数据和/或事件消息，其中，所述增量状态数据和所述事件消息，用于所述终端结合前一个输出帧的输出内容，模拟出当前待输出帧的输出内容并显示当前待输出帧；

所述模拟单元，用于基于所述增量状态数据和/或所述事件消息，并结合前一个输出帧的输出内容，模拟所述当前待输出帧的输出内容。

16.根据权利要求15所述的电子设备，其中，

所述第二接收单元，用于接收所述应用服务器在满足所述全量发送条件的情况下返回的全量状态数据和/或事件消息；

所述模拟单元，用于基于所述全量状态数据和/或所述事件消息模拟所述当前待输出帧的输出内容。

17.根据权利要求16所述的电子设备，其中，

所述第二接收单元，用于接收处理后的本次全量状态数据和/或所述事件消息；

所述模拟单元，用于基于本次全量状态数据及前一次的全量状态数据及前一次的事件消息，模拟当前待输出帧的输出内容。

18.一种电子设备，所述电子设备为应用服务器或终端，包括：

存储器，用于存储信息；

处理器，与所述存储介质连接，用于通过执行所述存储介质中存储的计算机可执行代码，能够实现权利要求1至7或8至11任一项提供的方法。

19.一种计算机存储介质，所述计算机存储介质存有计算机可执行代码，所述计算机可执行代码被执行后，能够实现权利要求1至7或8至11任一项提供的方法。