本发明涉及互联网游戏中录像文件的播放领域，尤其指一种对帧同步录像功能进行优化的方法。
背景技术：
目前网络游戏中，MOBA是一种最受玩家欢迎的游戏。MOBA是MultiplayerOnlineBattleArena的缩写，中文译为多人在线战术竞技游戏，是类DOTA的统称。Multiplayeronlinebattlearena（MOBA），也被称为Actionreal-timestrategy（ActionRTS，ARTS）。是视频游戏（VideoGame）——即时战略游戏（RTS）的一个子类。在这类游戏中，在战斗中一般需要购买装备，玩家通常被分为两队，两队在分散的游戏地图中互相竞争，每个玩家都通过一个RTS风格的界面控制所选的角色。这类游戏通常无需操作RTS游戏中常见的建筑群、资源、训练兵种等组织单位，玩家只控制自己所选的角色。
MOBA作为一款视频游戏，玩家依靠指令来实现对自己角色各个动作的控制，而目前玩家的操作指令集主要是MOBA游戏所用的录像文件。操作指令集中包括多个操作指令，每个操作指令包含一个时间帧数据和操作数据，现有的游戏观战模式都是采用操作指令集文件，根据指令的时间点来运行游戏逻辑，实现整个游戏画面的还原，这种模式的视频文件容量小，对电脑内存要求低，其录像不会保存状态数据（帧数据），因此录像文件存在一大缺点：玩家在观看录像文件时，只能顺着录像文件默认的顺序播放，或者点击快进、暂停或者快退，而无法实现自由拖动到任意时间点来播放，玩家也就无法通过观战学习他人操作技巧及提高自身操作水平。也就是说玩家在观看录像文件过程中，如果想回头看看前面时间点的游戏画面，不可以直接拖动观战进度，只能重新播放一遍录像文件。这样严重影响了玩家在观战上的自由度，浪费重复观战的时间，也影响游戏玩家的体验和感觉。
在计算机网络游戏行业里，凡是提供服务的一方我们称为伺服端（Server）------相当于我们常说的服务器端。而接受服务的另一方我们称作客户端（Client）。游戏客户端，游戏库客户使用端，相对于游戏服务端的另一端，服务端是为游戏数据库服务的，而客户端就是游戏数据使用端。几乎现在任何游戏都有其客户端，用来连接服务端而为玩家服务。游戏观战中服务器端与游戏客户端的传输速度快慢对游戏运行和画面显示流程与否起着重大关系，传输速度越快，网游的画面显示和游戏角色的行动流畅度越高，玩家及观战者的体验感更加良好，能提高游戏者对游戏的体验好感和后续继续玩该游戏的忠诚度。
现有技术中，公开号为CN104469433A的专利申请，公开了一种视频直播回看方法，包括：接收视频的实时视频分片数据；分别将所述实时视频分片数据存入缓存及文件系统；查询所述缓存及所述文件系统，获取从当前时间之前预定的回看时间段内所有的实时视频分片数据的索引信息；根据所述索引信息生成索引文件，并将所述索引文件发送至客户端，所述索引文件用于使所述客户端显示播放进度条，并通过所述播放进度条接收用户的回看请求；根据所述客户端的回看请求返回对应的实时视频分片数据至所述客户端。该方案虽然通过将直播节目的视频分片存入分布式系统，提高回看直播节目的速度，增强回看直播节目的实效性，但它只能实现用户通过客户端实现对该直播视频的任意时段的实时回看，时效性强，能回看较长时段的直播视频，因服务器的缓存有限，服务器的缓存中存储的实时视频分片数据播放时长较短，一般为几分钟。该方法只能分片分段播放，视频分片较大，回播的位置精确度不够高，不能任意拉取进度条到精确位置，无法实现整个视频的任意点或者最小程度帧的回放；该方法中设置了索引文件，对服务器和客户端的要求更高，其运行的步骤工序和耗时也相对增加了，也就影响了最后客户端画面回放的需要的缓冲时间。而且普通流媒体视频文件确认文件格式就可解码播放视频，但是游戏录像文件不一样，游戏录像文件格式只能在游戏中播放，而现有游戏录像文件并不具备任意拉动从某一点开始回播的功能。
技术实现要素：
本发明的目的是为了解决上述问题，提供一种对帧同步录像功能进行优化的方法，能实现游戏录像文件帧同步回看，也就是在录像文件中任意选取一个点作为开始观看的起点，而不必全部从头开始观看。
为了达到上述发明目的，本发明采用以下技术方案：
一种对帧同步录像功能进行优化的方法，其特征在于，该方法包括以下步骤：
1）提取待回看的录像文件，对该录像文件进行读取；
2）对录像的每一帧进行循环读取文件，取出其对应的操作指令；
3）逻辑处理，取出第n帧的状态变化数据，并将该状态变化数据进行保存，其中，n为自然数，n≥1；
4）每隔一段时间T，T＞0，以N帧为保存间隔，保存一次包含第n帧到第n+N-1帧之间的所有数据的全局数据Sn，其中N为自然数，N≥2，每一个全局数据S作为录像回放的还原点，保存Sn;
5）当客户端取出当前帧的状态变化数据，读取离当前帧最接近的第一全局数据K；
6）将从第一全局数据K开始的所有状态变化数据保存成一个新的录像文件，显示从K开始的的游戏画面；
7）重复步骤2），直至整个录像文件读取完毕。
进一步的，所述步骤3）中的状态变化数据保存于文件系统中。
进一步的，所述步骤4）中的全局数据Sn按创造时间的先后有顺序的保存在文件系统中。
进一步的，所述全局数据Sn保存于内存和文件系统中。
进一步的，所述第一全局数据K保存于寄存器中。
进一步的，所述步骤5）还包括客户端将当前第n帧的状态变化数据发送到服务器端，所述服务器端调取第一全局数据K并将其发送给客户端。
进一步的，所述步骤6）新的录像文件保存在文件系统中。
进一步的，所述步骤1）中为采用第一操作工具进行对录像文件的第一次操作，讲录像文件从对应文件系统的具体位置中调出，通过第一操作工具进行第二次操作进行读取。
进一步的，所述步骤2）中采用第一操作工具、第二操作工具交互使用对操作指令的读取。
进一步，所述步骤4）中所述时间T和N的设置通过第二操作工具来实现，所述第一操作工具进行实现该步骤中的保存。
进一步，操作指令包括时间帧数据和操作数据。
进一步，步骤3）为逻辑处理，保存录像文件第一帧的状态变化数据，然后以k帧为间隔，保存第1+k帧的状态变化数据，k为自然数，k≥2。
进一步，按照播放顺序从第一全局数据K开始依序播放位于其后面的所有全局数据Sn，包括：多个全局数据中播放顺序相邻的两个全局数据之间为无缝衔接播放。服务器返回的一个或多个全局数据Sn中时间顺序相邻的两个全局数据之间没有时间间隔，在客户端接收服务器返回的第一全局数据K后，按时间顺序无缝衔接播放相邻的两个全局数据，可以保证用户顺畅地回看直播节目，避免出现跳帧、卡顿等情况。
本发明与现有技术相比，其有益效果是：采用本发明的方法，在状态数据的保存上做了大量工作，创建了录像回放的还原点，观看录像只需读取录像文件再生成对应的状态数据，保存一个新的录像文件，在游戏界面里可以实现任意拖动观看游戏状态。玩家观看录像文件时，如果想回头看看前面的时间点的游戏画面，精确度更高，用本发明的方法，玩家可以任意选择时间点，观战上有更高的自由度。
附图说明
图1是本发明的流程示意图。
图2是本发明的观战界面进度条的示意图。
具体实施方式
为了使本发明的技术方案更加清楚明白，下面结合实施例进行进一步阐述。
实施例一
如图1所示，一种对帧同步录像功能进行优化的方法，该方法包括以下步骤：
1）提取待回看的录像文件，对该录像文件进行读取；
2）对录像文件的每一帧进行循环读取文件，取出其对应的操作指令（也就是时间帧数据和操作数据）；
3）逻辑处理，取出当前第n帧的状态变化数据，并将该状态变化数据进行保存，其中，n为自然数，n≥1；
4）每隔一段时间T，T＞0，以N帧为保存间隔，保存一次包含当前第n帧到第n+N-1帧之间状态的全局数据S，其中N为自然数，N≥2，每一个全局数据S作为录像回放的还原点，保存S;
5）当客户端取出当前第n帧的状态变化数据，读取离当前第n帧最接近的第一全局数据K；
6）保存成一个新的录像文件，显示从K开始的游戏画面；
7）重复步骤2），直至整个录像文件读取完毕。
该过程中，游戏中的录像文件只能在游戏界面播放。步骤1）中的录像文件是指玩家操作指令的集合，是在游戏过程中，服务器发下来，游戏结束自动保存在硬盘上，读取时也是在硬盘上读取，步骤2）即为对每一帧的帧数据和操作数据进行保存，步骤3)为对每一帧的状态变化数据进行保存，步骤4）保存一定时间一定间隔的每个全局数据，即保存时间帧数据、操作数据以及状态变化数据，步骤5）则相当于是客户端的观战者拉动游戏的进度条，拉到需要看的当前某一帧位置时，客户端收到信号读取出离当前某一帧最近的第一全局数据K，显示对应的帧画面，即操作者在客户端有个界面（图2所示），该界面在观看录像文件的时候会读取录像文件信息且显示录像时间和进度，步骤6）新的录像文件就是状态数据的集合，是从第一全局数据K开始到录像文件结束的全部的状态数据的集合。
该方法中，状态变化数据保存是本发明的重点。操作指令是来自玩家的，比如玩家点击移动时发出的操作指令等，而状态变化数据是该操作指令执行后产生的变化数据，比如操作者在客户端操作移动的动作使得单位位置坐标发生改变，那么状态数据就是该改变后的坐标数据。
实施例二
所谓数据帧（Dataframe），就是数据链路层的协议数据单元，它包括三部分：帧头，数据部分，帧尾。其中，帧头和帧尾包含一些必要的控制信息，比如同步信息、地址信息、差错控制信息等；数据部分则包含网络层传下来的数据，比如IP数据包。
具体举例说明，如以下一条数据的文件存储格式：
1.数据头都是4个字节
unsignedintdwFrame:19;//帧
unsignedintdwSeat:5;//座位号
unsignedintdwQueue:1;//是否是队列命令
unsignedintdwCmd:7;//命令类型
2.数据头后面是以下内容
intiDataSize;//数据流大小
characData[SSD_ENDSTR_LEN];//不定长数组，数据内容，需根据命令类型来解析其详细内容
操作数据和状态变化数据都包含相同的帧数据头，也就是类似上述中1的4个字节的数据头，这4个字节分别记录了数据类型、玩家的ID、时间数据以及指令类型，判断了指令类型后，根据数据类型来获取数据的大小；录像文件即以数据的文件存储格式的数据组成，假设每10帧保存一次全局数据，
第1帧数据
第2帧数据
第3帧数据
…
第10帧数据
第10帧的全局数据
第11帧数据
第12帧数据
第20帧数据
第20帧的全局数据
等
录像拖动时间即从最接近的那一帧的全局数据开始播放。观战界面示意图可以参考图1,观看者将进度条拉到某一帧如拉到第18帧数据所在位置，系统调用离这一帧最接近的全局数据第20帧的全局数据，然后开始播放该第20帧全局数据所在位置帧的游戏画面，直至整个录像文件播放结束。
实施例三
与实施例二不同，本方案设置为每5帧保存一次全局数据S，
第1帧数据
第2帧数据
第3帧数据
…
第5帧数据
第5帧的全局数据
第6帧数据
第7帧数据
第8帧数据
第10帧数据
第10帧的全局数据
等
该实施例中，每5帧保存一次，调取的精度更高，能进一步让观看者实现关键动作点的那一帧画面，举例说如果游戏角色的某个动作在第56帧，观看者项观看该动作，进度条拉到该时间点时，全局数据为第55帧的位置，客户端取出状态变化数据第55帧，能准确显示56帧的游戏画面。
而如果依靠实施例二中10帧保存一次，其最接近56帧的全局数据为第60帧，客户端进度条拉到该时间点，客户端取出的全局变化数据为第60帧，就会错过第56帧的动作画面，除非将时间点再前移到靠近50-55帧之间的位置才行，但这样观战者等待观看该动作画面的时间就延长了，也就是重复查看了前面50-55帧的游戏画面，整体上需要更耗费服务器和客户端的交互操作时间。
实施例四
与实施例一不同的是，本方案步骤4）不一样，其帧数据的保存根据操作指令的多少及频繁程度来设置保存全局数据的时间。
一种对帧同步录像功能进行优化的方法，其中步骤4）为：每隔一段时间T，T＞0，根据该段时间间隔内的帧总的数据大小M，当帧大小M≥设定值H（H为预设的帧大小的数据值）时，以N1帧为保存间隔，保存一次包含当前第n帧到第n+N1-1帧之间状态的全局数据S；当帧总的数据大小M＜设定值H时，以N帧为保存间隔；保存一次包含当前第n帧到第n+N-1帧之间状态的全局数据S；其中N、N1为自然数，N＞N1≥2，每一个全局数据S作为录像回放的还原点，保存。
举例说明，假设N取10，N1取5，T时间内帧总的数据大小M＜设定值H，以5帧为一次保存全局数据，当帧总的数据大小M≥设定值H，以10帧为保存单位。T时间内帧总的数据大小M越大，说明其角色画面的操作或者运行动作更多，为了让观看者能更准确看到该画面，有必要在该位置设置一个回放点，也就是保存该位置的全局数据。该方式可以解决数据过大的问题。
第1帧数据
第2帧数据
…
第10帧数据
第10帧的全局数据
第11帧数据
第12帧数据
第15帧数据
第15帧的全局数据
第16帧数据
第17帧数据
第20帧数据
第20帧的全局数据
第21帧数据
第30帧数据
第30帧的全局数据
等
实施例五
作为实施例一的选择之一，状态变化数据进行保存时将其保存到文件系统，也就是计算机硬盘之中。当客户回看硬盘中调用数据时，需要较大内存，因此对客户的计算机内存配置要求较高。
实施例六
作为实施例一的选择之一，步骤4）中的全局数据S按创造时间的先后有顺序的保存在文件系统和/或内存中。即将多个全局数据S按照创建的时间点的先后顺序进行排序，保存，以便后期客户端的进度条回拉到某个帧，能有序取到最接近该帧的一个全局数据。
实施例七
作为实施例一的选择之一，所述全局数据保存于内存和文件系统中。大型网游中，计算机对内存的调取速度明显快于硬盘等文件系统的速度。
实施例八
作为实施例一的选择之一，客户端取出状态变化数据，第一全局数据K保存于寄存器或随机存储器中。
计算机的存储层次（memoryhierarchy）之中，寄存器（register）最快，内存其次，最慢的是硬盘。寄存器的工作方式很简单，只有两步：（1）找到相关的位，（2）读取这些位。内存的工作方式就要复杂得多：（1）找到数据的指针；（指针可能存放在寄存器内，所以这一步就已经包括寄存器的全部工作了。）（2）将指针送往内存管理单元（MMU），由MMU将虚拟的内存地址翻译成实际的物理地址；（3）将物理地址送往内存控制器（memorycontroller），由内存控制器找出该地址在哪一根内存插槽（bank）上；（4）确定数据在哪一个内存块（chunk）上，从该块读取数据；（5）数据先送回内存控制器，再送回CPU，然后开始使用。而MOBA这种大型游戏，速度作为一大重要指标，其数据存储以寄存器中能实现最快。
寄存器可以采用具有各种单一或者多种功能的寄存器，实现对本方案中数据或者指令等的存储。如数据寄存器-用来储存整数数字,这样在某些简单/旧的CPU，特别的数据寄存器是累加器，作为数学计算之用；也可以采用目的寄存器（GPRs）-可以保存数据或地址两者，也就是说它们是结合数据/地址寄存器的功用；通用目的寄存器（GPRs）-可以保存数据或地址两者，也就是说它们是结合数据/地址寄存器的功用；特殊目的寄存器-储存CPU内部的数据，像是程序计数器（或称为指令指针），堆栈寄存器，以及状态寄存器（或称微处理器状态字组）；指令寄存器（instructionregister）-储存现在正在被运行的指令；索引寄存器（indexregister）-是在程序运行时用来更改运算对象地址之用。虽然寄存器对电脑配置要求高一点，但相对的实现游戏录像文件数据及指令等的调用的效率更高，要优于存储在计算机硬盘或者其他非CPU或内存文件的调用速度。
随机存储器的特点是可读可写，断电后一切数据都消失，因此，客户拉动进度条到某一帧，该帧数据的储存，以及离这帧最接近的第一全局数据K的储存，随机存储器作为临时存储为较佳选择。
本发明中，全局数据S、第n帧的状态变化数据、第一全局数据K或者多次回看的第n次全局数据中任意一种数据的的存储并不限定于cpu寄存器或者计算机硬盘系统等，也可以为U盘、或者光盘、或者手机等类似移动设备，部分数据可以存入缓存中。
实施例九
与实施例一不同的是，步骤5）还包括客户端将当前第n帧的状态变化数据发送到服务器端，所述服务器端调取第一全局数据K并将其发送给客户端。
实施例十
与实施例一不同的是，所述步骤6）新的录像文件保存在内存中。新的录像文件是放在内存中，并没有保存在硬盘上，不会替换原来的录像文件。新的录像文件是状态数据的集合，原始录像文件是操作指令的集合。
实施例十一
与实施例一不同的是，步骤1）中为采用第一操作工具进行对录像文件的第一次操作，讲录像文件从对应文件系统的具体位置中调出，通过第一操作工具进行第二次操作进行读取。所述第一操作工具、第二操作工具可以为鼠标、键盘或者触屏等操作。
实施例十二
与实施例一不同的是，步骤2）中采用第一操作工具、第二操作工具交互使用对操作指令的读取。
实施例十三
与实施例一不同的是，步骤4）中所述时间T和N的设置通过第二操作工具或第一操作工具来实现，所述第一操作工具进行实现该步骤中的保存。
实施例十四
与实施例一不同的是，客户端提取当前帧采用的方式为触摸或非触摸式，点选当前直播时间点之前的播放时间点的指令，服务器接收该指令，读取该指令对应帧，读取离该帧最接近的第一全局数据K。
实施例十五
与实施例一不同的是，本方案中步骤3）为逻辑处理，保存录像文件第一帧的状态变化数据，然后以k帧为间隔，保存第1+k帧的状态变化数据，k为自然数，k≥2。该步骤与实施例一不同，不是每个状态变化数据都保存，而且保存特定间隔的状态变化数据，能解决存储数据过大的问题，能相对减少对内存的需求。
以上为本发明的较佳实施例，并不是对本发明技术方案的限制，本领域业的技术人员，在不脱离本发明技术方案范围内，利用本发明的技术内容，依据本发明的技术实质对方案所作的简单修改、等同变化与修饰，均落入本发明技术方案的保护范围内。