一种硬解测试方法和终端及服务器与流程

本发明涉及计算机技术领域，尤其涉及一种硬解测试方法和终端及服务器。

背景技术：

近年以来，多媒体信息技术发展快速，用户越来越习惯于手持终端来播放视频，并且用户对视频播放质量的要求也越来越高。在当前的视频播放技术时，视频专用硬件集成芯片起了非常重要的作用，视频专用硬件集成芯片是通过专门的集成电路(IC，Integrated Circuit)芯片单独完成视频解码工作，硬解的IC芯片专用于视频数据的解码，从而使得解码效率得到极大的提高。

由于视频专用硬件集成芯片在固定成型出厂之后，其能够支持的编解码格式和对硬件系统资源的计算分配方式也就会固定下来，而无法再进行调整，这将导致视频专用硬件集成芯片只能对特定编码格式的视频文件进行解码，而无法对所有编码格式的视频文件进行解码。因此，在使用终端播放视频文件之前，需要先测试视频专用硬件集成芯片能否对视频文件进行解码，即需要先测试硬解能否成功，若硬解成功才能使用视频专用硬件集成芯片，这种需要针对每个终端进行实地能否硬解测试的方案，这降低了终端的硬解测试效率，也降低了终端播放视频文件的效率，用户需要等待终端进行硬解测试，用户体验不好，若等待后得到的结果还是无法硬解，用户的体验会进一步降低。

另外，在现有技术提供的对终端进行硬解测试的技术方案中，需要通过线下用户交互方式去测试终端，然后根据回传的日志来分析硬解是否成功。用户交互方式需要人工与对方人工联系实现指导对方测试，并且需要人工来观确定硬解测试是否成功，这种硬解测试效率很低。

技术实现要素：

本发明实施例提供了一种硬解测试方法和终端及服务器，用于提高终端的硬解测试效率，提高用户对视频的播放体验。

为解决上述技术问题，本发明实施例提供以下技术方案：

第一方面，本发明实施例提供一种硬解测试方法，包括：

服务器接收终端发送的解码方式请求指令，所述解码方式请求指令中携带所述终端的机型信息；

所述服务器根据所述解码方式请求指令从机型管理数据库中获取与所述机型信息对应的硬解测试报告；

所述服务器将所述硬解测试报告发送给所述终端，以使所述终端根据所述硬解测试报告确定是否启用对视频文件硬解的硬件解码器。

第二方面，本发明实施例还提供另一种硬解测试方法，包括：

终端获取需要解码播放的视频文件；

所述终端向服务器发送解码方式请求指令，所述解码方式请求指令中携带所述终端的机型信息；

所述终端接收所述服务器根据所述机型信息获取到的硬解测试报告；

所述终端根据所述硬解测试报告确定是否启用对所述视频文件硬解的硬件解码器。

第三方面，本发明实施例还提供一种服务器，包括：

接收模块，用于接收终端发送的解码方式请求指令，所述解码方式请求指令中携带所述终端的机型信息；

获取模块，用于根据所述解码方式请求指令从机型管理数据库中获取与所述机型信息对应的硬解测试报告；

发送模块，用于将所述硬解测试报告发送给所述终端，以使所述终端根据所述硬解测试报告确定是否启用对视频文件硬解的硬件解码器。

第四方面，本发明实施例还提供一种终端，包括：

接收模块，用于接收终端发送的解码方式请求指令，所述解码方式请求指令中携带所述终端的机型信息；

获取模块，用于根据所述解码方式请求指令从机型管理数据库中获取与 所述机型信息对应的硬解测试报告；

发送模块，用于将所述硬解测试报告发送给所述终端，以使所述终端根据所述硬解测试报告确定是否启用对视频文件硬解的硬件解码器。

从以上技术方案可以看出，本发明实施例具有以下优点：

在本发明实施例中，服务器首先接收终端发送的解码方式请求指令，解码方式请求指令中携带终端的机型信息，服务器根据解码方式请求指令从机型管理数据库中获取与机型信息对应的硬解测试报告，服务器将硬解测试报告发送给终端，以使终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中在服务器中建立有机型管理数据库，机型管理数据库中保存有机型信息对应的硬解测试报告，服务器按照终端的请求向其发送硬解测试报告，终端根据接收到的硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终端对接，能够满足多终端的同时请求需要。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种硬解测试方法的流程方框示意图；

图2为本发明实施例提供的一种硬解测试方法的流程方框示意图；

图3为本发明实施例提供的终端与服务器交互实现硬解测试方案的一种实现方式示意图

图4-a为本发明实施例提供的一种服务器的组成结构示意图；

图4-b为本发明实施例提供的另一种服务器的组成结构示意图；

图5-a为本发明实施例提供的一种终端的组成结构示意图；

图5-b为本发明实施例提供的另一种终端的组成结构示意图；

图6为本发明实施例提供的硬解测试方法应用于服务器的组成结构示意图

图7为本发明实施例提供的硬解测试方法应用于终端的组成结构示意图。

具体实施方式

本发明实施例提供了一种硬解测试方法和终端及服务器，用于提高终端的硬解测试效率，提高用户对视频的播放体验。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域的技术人员所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

以下分别进行详细说明。

本发明硬解测试方法的一个实施例，具体可以应用于终端对视频文件的硬解测试中，请参阅图1所示，本发明一个实施例提供的硬解测试方法，可以包括如下步骤：

101、服务器接收终端发送的解码方式请求指令，解码方式请求指令中携带终端的机型信息。

在本发明实施例中，终端首先获取到需要解码播放的视频文件，终端为了降低视频文件对中央处理器(CPU，Central Processing Unit)的占用，需要考虑能否启用硬件解码器来对视频文件进行解码播放，但是硬件解码器在启用前需要先进行硬解测试，只有通过硬解测试能够使用硬件解码器，其中，硬件解码器具体可以是视频专用硬件集成芯片。本发明中终端自身不再直接进行硬解测试以确定能否对视频文件进行硬解，而是建立一个能够与一个或 多个终端交互的服务器，终端从服务器侧来获取能否对视频文件进行硬解的测试结论，终端获取到自身的机型信息，终端的机型信息可以指终端的操作系统版本以及硬件配置信息，例如对于安卓系统的智能终端，安卓智能终端多样化，硬件也很难统一，不同用户还可能使用多个安卓系统版本，再加上安卓系统源代码的开放性，也可能出现多种优化的版本，这些都会造成安卓智能终端的不统一，如果每个安卓智能终端都直接启动硬件解码器来解码播放视频文件，极有可能出现不匹配、启动错误或者无法启动的情况。因此，本发明中终端首先确定出自己的机型信息，然后终端向服务器发送解码方式请求指令，即终端向服务器请求应该采用哪种视频解码方式，终端在解码方式请求指令中携带自己的机型信息，则服务器接收到解码方式请求指令之后，可以从解码方式请求指令中获取到终端的机型信息。

102、服务器根据解码方式请求指令从机型管理数据库中获取与机型信息对应的硬解测试报告。

在本发明实施例中，服务器侧建立有一个机型管理数据库，服务器通过机型管理数据库来记录各种机型对应的终端能否对视频文件进行硬解的测试结论，其中，各种机型的终端能否对视频文件进行硬解的测试结论记录在硬解测试报告中，若在机型管理数据库中保存有某种机型的终端对应的硬解测试报告，则说明该种机型的终端已经由服务器分析过该机型的终端是否可以启用硬件解码器。本发明中服务器可用于与不同机型信息的终端对接，所以服务器中的机型管理数据库中可保存多种机型的终端对应的硬解测试报告。其中机型管理数据库可以设置在服务器的本地存储中，也可以设置在服务器的远端，服务器通过远程交互读取机型管理数据库。

在本发明实施例中，服务器接收到解码方式请求指令之后，服务器从解码方式请求指令中获取到是哪个机型的终端发起解码方式请求，服务器以机型信息来查询机型管理数据库，从机型管理数据库中获取到与该机型信息对应的硬解测试报告。

需要说明的是，在本发明实施例中，服务器可以与多种机型的终端进行硬解测试交互，服务器在与一种机型的终端完成硬解测试交互之后，服务器可以得到该种机型的终端能否对视频文件进行硬解的测试结论，服务器将这 种测试结论以硬解测试报告的方式保存到机型管理数据库中，从而在后续的同类型的终端需要硬解测试时，服务器可以从机型管理数据库中查找到该类型的终端对应的硬解测试报告。

在本发明的一些实施例中，步骤201服务器根据解码方式请求指令从机型管理数据库中获取与机型信息对应的硬解测试报告之前，本发明提供的硬解测试方法还可以包括如下步骤：

A1、服务器查找机型管理数据库中是否存在与机型信息对应的硬解测试报告；

A2、若机型管理数据库中不存在与机型信息对应的硬解测试报告，服务器向终端发送硬解测试指令。

也就是说，本发明中服务器获取到终端的机型信息之后，服务器先查找机型管理数据库，确定在机型管理数据库中是否保存有与上述机型信息对应的硬解测试报告，若机型管理数据库中存在与机型信息对应的硬解测试报告，则可以直接触发执行步骤102，若机型管理数据库中不存在与机型信息对应的硬解测试报告，则按照步骤A2执行，服务器触发终端进行硬解测试，服务器通过硬解测试指令来指示终端进行硬解测试。

进一步的，在发明的一些实施例中，步骤A2服务器向终端发送硬解测试指令执行之后，本发明提供的硬解测试方法还可以包括如下步骤：

B1、服务器接收终端上报的异常日志和状态信息；

B2、服务器根据异常日志和状态信息确定终端是否通过硬解测试，生成硬解测试报告；

B3、服务器将生成的硬解测试报告存储到机型管理数据库中。

在本发明实施例中，机型管理数据库中不存在与机型信息对应的硬解测试报告，则说明服务器与该种机型的终端是首次进行硬解测试交互，此时机型管理数据库中还没有保存与该机型信息对应的硬解测试报告，服务器需要自己为该机型信息对应的终端来生成硬解测试报告，服务器触发终端进行硬解测试后，终端按照服务器的要求在该终端中进行硬解测试，终端还需要实时收集自己的异常日志和在硬解测试过程中产生的状态信息，服务器通过对异常日志和状态信息的分析判断，从而确定出该种机型信息对应的终端能否 对视频文件进行硬解的测试结论，生成针对该种机型信息的硬解测试报告，然后服务器将新生成的硬解测试报告存储到机型管理数据库中，以备下次同类型的终端进行硬解测试的需要。

在本发明的实施例中，异常日志指的是终端在执行硬解测试过程中对于该终端产生的异常情况的记录日志，在一些详细的实施例中，具体的，终端实时记录的异常日志，可包括：崩溃日志、卡顿日志、花屏日志。崩溃日志指的是针对终端在执行硬解测试过程中发生崩溃而直接退出应用程序的情况记录的日志，卡顿日志指的是针对终端在执行硬解测试过程中应用程序没有响应(即卡住)或者发生卡顿而将硬解测试停止在某个解码过程或者无法流畅执行解码过程的情况而记录的日志，花屏日志指的是针对终端在执行硬解测试过程中视频播放过程中出现的犹如马赛克般不正常或者非正常的画面而记录的日志。

在本发明的实施例中，状态信息指的是终端在执行硬解测试过程中对于该终端针对一些关键点产生的状态的记录日志，在一些详细的实施例中，具体的，终端记录的状态信息，可以包括：终端硬件信息、解码进度信息、视频样片的视频格式信息、视频样片的尺寸信息等。通过终端记录的状态信息，服务器可以获取到终端执行硬解测试过程中关键点的状态，可以作为服务器判断终端是否通过硬解测试的依据。

需要说明的是，在本发明的前述实施例中，步骤B2服务器根据异常日志和状态信息确定终端是否通过硬解测试，生成硬解测试报告，终端在执行硬解测试过程中对自身进行全程的实时监控，终端向服务器上报全程监控中的异常日志和状态信息，服务器对终端上报的异常日志和状态信息进行分析，从而可以确定出终端是否能够通过硬解测试，服务器生成的硬解测试报告中包含服务器对终端能否通过硬解测试的测试结果。其中，对于异常日志的具体多种实现方式，以及终端的状态信息包括的多种内容，服务器根据异常日志和状态信息确定终端是否通过硬解测试的方式也有多种不同的实现方式，具体需要结合中的监测场景采集到的异常日志和状态信息来决定，接下来进行举例说明。

进一步的，在本发明的一些实施例中，步骤B2服务器根据异常日志和状 态信息确定终端是否通过硬解测试，具体可以包括如下步骤：

服务器分别执行如下步骤：B21、根据异常日志判断终端在硬解测试过程中产生的异常次数是否超过异常阈值，和，B22、服务器判断终端在硬解测试过程记录的状态信息是否满足预置的状态条件；

若终端在硬解测试过程中产生的异常次数超过异常阈值，确定终端未通过硬解测试，若状态信息不满足状态条件，确定终端未通过硬解测试；若终端在硬解测试过程中产生的异常次数没有超过异常阈值且状态信息满足状态条件，确定终端通过硬解测试。

也就是说，服务器可以分别设置异常阈值和状态条件，用以对异常日志和状态信息分别进行判断，举例说明，异常日志可以记录的是产生异常情况的次数，若异常日志指的是崩溃日志，则异常阈值可以指的是崩溃阈值，若异常日志指的是卡顿阈值，则异常阈值可以指的是卡顿阈值，若异常日志指的是花屏阈值，则异常阈值可知指的是花屏阈值。举例说明，终端在执行硬解测试过程中产生的状态信息可以是终端硬件信息、解码进度信息、视频样片的视频格式信息、视频样片的尺寸信息等，则服务器针对终端硬件信息、解码进度信息、视频样片的视频格式信息、视频样片的尺寸信息可以分别设置不同的状态条件，具体的，状态条件可以是终端硬件条件、解码进度条件、视频样片的视频格式条件、视频样片的尺寸条件，则对于状态信息的具体实现方式，分别判断能否满足状态条件。针对异常日志和状态信息分别设置的异常阈值和状态条件，则只有两者同时满足的情况下，服务器才可以确定终端通过硬解测试，若两者中至少有一个不满足的情况下，服务器直接确定终端未通过硬解测试。

在本发明执行前述步骤B1至步骤B3的实现场景下，进一步的，步骤B1服务器接收终端上报的异常日志和状态信息之后，本发明提供的硬解测试方法还可以包括如下步骤：

C1、服务器根据异常日志判断终端在硬解测试过程中产生的异常次数是否超过异常次数连续值，若终端在硬解测试过程中产生的异常次数超过异常次数连续值，则向终端下发硬解停止指令；

C2、服务器根据状态信息判断终端在硬解测试过程中已经完成的视频样 片播放次数，若视频样片播放次数超过播放次数连续值，则向终端下发硬解停止指令。

也就是说，在本发明的一些实施例中，终端在执行硬解测试过程中，终端全程向服务器上报异常日志和状态信息，对于终端执行的硬解测试过程，若总是会产生异常情况以及状态信息记录有不良的信息，硬解测试会对终端造成伤害，本发明中服务器可以根据终端上报的异常日志和状态信息来确定是否向终端发送硬解停止指令，若终端接收到服务器发送的硬解停止指令，则终端会中断硬解测试过程，即不再继续执行硬解测试，以避免终端因强行执行硬解测试而造成软硬件的伤害。具体的，在步骤C1和步骤C2中详细记载了在什么情况下应该停止硬解，当然，本发明中服务器向终端下发硬解停止指令的实现方式可不拘于步骤C1和步骤C2的实现情况，此处仅作示例说明。

在本发明执行前述步骤A1至步骤A2的实现场景下，进一步的，若解码方式请求指令中还携带终端需要解码播放的视频文件的文件属性信息，在这种实现场景下，步骤A2服务器向终端发送硬解测试指令，具体为如下步骤：

服务器判断文件属性信息是否满足预置的硬解条件，若文件属性信息满足硬解条件，服务器向终端发送硬解测试指令。

也就是说，在本发明的一些实施例中，服务器向终端发送硬解测试指令除了需要满足前述机型管理数据库中不存在与机型信息对应的硬解测试报告这一条件，还需要对终端获取到的视频文件的文件属性信息进行判断，需要判断文件属性信息是否满足预置的硬解条件，例如，文件属性可以指的是视频文件的编码协议、视频宽高、视频复杂度等，服务器可以针对视频文件的编码协议、视频宽高、视频复杂度来设置硬解条件，例如硬解条件中可以设置视频文件必须采用的特定编码协议、特定视频宽高、特定视频复杂度，则只有视频文件的文件属性信息都满足硬解条件的要求时，服务器才会向终端发送硬解测试指令，否则，服务器不会像终端发送硬解测试指令，终端无需为上述视频文件开启硬件解码器，而是可以直接选择软件解码器。

103、服务器将硬解测试报告发送给终端，以使终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。

在本发明实施例中，服务器从机型管理数据库中获取到硬解测试报告之后，服务器向终端反馈硬解测试报告，终端接收到硬解测试报告之后，终端可以依据硬解测试报告的指示来决定是否可以启用硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终端对接，能够满足多终端的同时请求需要。

通过以上实施例对本发明的描述可知，服务器首先接收终端发送的解码方式请求指令，解码方式请求指令中携带终端的机型信息，服务器根据解码方式请求指令从机型管理数据库中获取与机型信息对应的硬解测试报告，服务器将硬解测试报告发送给终端，以使终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中在服务器中建立有机型管理数据库，机型管理数据库中保存有机型信息对应的硬解测试报告，服务器按照终端的请求向其发送硬解测试报告，终端根据接收到的硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终端对接，能够满足多终端的同时请求需要。

前述实施例从服务器侧介绍了本发明提供的硬解测试方法，接下来从与服务器交互的终端侧介绍本发明提供的硬解测试方法，请参阅如图2所示，为本发明提供的一种硬解测试方法，具体可以包括如下步骤：

201、终端获取需要解码播放的视频文件。

在本发明实施例中，用户操作终端来播放视频文件，例如，用户操作终端上安装的qq浏览器来播放文件，则终端首先获取到需要解码播放的视频文件。其中，终端获取到的视频文件具备一定的文件属性，例如，文件属性可以视频文件的编码协议、视频宽高、视频复杂度等。

202、终端向服务器发送解码方式请求指令，解码方式请求指令中携带终 端的机型信息。

在本发明实施例中，终端为了降低视频文件对CPU的占用，需要考虑能否启用硬件解码器来对视频文件进行解码播放，但是硬件解码器在启用前需要先进行硬解测试，只有通过硬解测试能够使用硬件解码器，其中，硬件解码器具体可以是视频专用硬件集成芯片。本发明中终端自身不再直接进行硬解测试以确定能否对视频文件进行硬解，而是建立一个能够与一个或多个终端交互的服务器，终端从服务器侧来获取能否对视频文件进行硬解的测试结论，终端获取到自身的机型信息，终端的机型信息可以指终端的操作系统版本以及硬件配置信息，例如对于安卓系统的智能终端，安卓智能终端多样化，硬件也很难统一，不同用户还可能使用多个安卓系统版本，再加上安卓系统源代码的开放性，也可能出现多种优化的版本，这些都会造成安卓智能终端的不统一，如果每个安卓智能终端都直接启动硬件解码器来解码播放视频文件，极有可能出现不匹配、启动错误或者无法启动的情况。因此，本发明中终端首先确定出自己的机型信息，然后终端向服务器发送解码方式请求指令，即终端向服务器请求应该采用哪种视频解码方式，终端在解码方式请求指令中携带自己的机型信息。

在本发明的一些实施例中，可选的，前述解码方式请求指令中除了携带机型信息之外，还可以携带视频文件的文件属性信息，其中文件属性信息用于服务器判断是否向终端发送硬解测试指令的一个依据，具体实现过程请参阅前述实施例的描述。

在本发明的一些实施例中，步骤202终端接收服务器根据机型信息获取到的硬解测试报告之前，本发明提供的硬解测试方法还可以包括如下步骤：

步骤1：终端接收服务器在机型管理数据库中未查找到与机型信息对应的硬解测试报告之后下达的硬解测试指令；

步骤2：终端根据硬解测试指令打开硬件解码器，使用硬件解码器对视频样片进行硬解，并对硬解视频数据进行验证，记录硬解验证结果；

步骤3：终端使用硬件解码器对视频样片进行硬解之后，在终端的显示屏幕上播放硬解后的视频样片，并对显示视频数据进行验证，记录显示验证结 果；

在步骤1、步骤2、步骤3的执行过程中，终端监控终端是否出现异常，并将记录的异常日志向服务器反馈；

在步骤1、步骤2、步骤3的执行过程中，终端通过埋点工具收集终端的状态信息，并将状态信息向服务器反馈。

具体的，服务器获取到终端的机型信息之后，服务器先查找机型管理数据库，确定在机型管理数据库中是否保存有与上述机型信息对应的硬解测试报告，若机型管理数据库中不存在与机型信息对应的硬解测试报告，则按照步骤1执行，服务器触发终端进行硬解测试，服务器通过硬解测试指令来指示终端进行硬解测试。本发明中终端执行硬解测试主要包括两个过程，第一是解码，第二是显示，例如前述步骤2和步骤3，终端在执行解码和显示两个过程中都需要记录验证结果，终端会通过状态信息的方式向服务器上报解码验证结果和显示验证结果，同时，在本发明中，终端在执行步骤1至步骤3中还需要全程监控终端的异常情况和状态信息，服务器通过终端监控上报的异常情况和状态信息来分析终端能否通过硬解测试，对于服务器侧对终端硬解测试的判断过程，请参阅前述实施例的描述。

进一步的，在前述步骤2中使用硬件解码器对视频样片进行硬解，并对硬解视频数据进行验证，记录硬解验证结果，具体可以包括如下步骤：

步骤21、终端使用硬件解码器对视频样片进行硬解，生成硬解视频数据；

步骤22、终端在对视频样片进行硬解的同时，启动软件解码器对视频样片进行解码，生成软解视频数据；

步骤23、终端判断硬解视频数据和软解视频数据是否一致，若一致，记录硬解验证结果为通过，若不一致，记录硬解验证结果为未通过。

其中，本发明中终端为了验证硬件解码器的解码结果，需要启用软件解码器来进行验证，通过判断硬解视频数据和软解视频数据是否一致来生成硬解验证结果，其中软件解码器指的是采用手机中的CPU对视频样片的解码。

进一步的，在前述步骤3中在终端的显示屏幕上播放硬解后的视频样片，并对显示视频数据进行验证，记录显示验证结果，具体可以包括如下步骤：

步骤31、终端在终端的显示屏幕上播放硬解后的视频样片，从终端的本 地内存中获取到显示视频数据；

步骤32、终端判断硬解视频数据和显示视频数据是否一致，若一致，记录显示验证结果为通过，若不一致，记录显示验证结果为未通过。

其中，本发明中终端为了验证显示屏幕的显示结果，需要从终端的内存中来读取到显示视频数据进行验证，通过判断硬解视频数据和显示视频数据是否一致来生成显示验证结果，

203、终端接收服务器根据机型信息获取到的硬解测试报告。

在本发明实施例中，服务器侧建立有一个机型管理数据库，服务器通过机型管理数据库来记录各种机型对应的终端能否对视频文件进行硬解的测试结论，其中，各种机型的终端能否对视频文件进行硬解的测试结论记录在硬解测试报告中，若在机型管理数据库中保存有某种机型的终端对应的硬解测试报告，则说明该种机型的终端已经由服务器分析过该机型的终端是否可以启用硬件解码器。本发明中服务器可用于与不同机型信息的终端对接，所以服务器中的机型管理数据库中可保存多种机型的终端对应的硬解测试报告。其中机型管理数据库可以设置在服务器的本地存储中，也可以设置在服务器的远端，服务器通过远程交互读取机型管理数据库。

在本发明实施例中，服务器接收到解码方式请求指令之后，服务器从解码方式请求指令中获取到是哪个机型的终端发起解码方式请求，服务器以机型信息来查询机型管理数据库，从机型管理数据库中获取到与该机型信息对应的硬解测试报告，服务器向终端发送从机型管理数据库中提取到的硬解测试报告，终端从服务器侧接收到该硬解测试报告。

204、终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。

在本发明实施例中，服务器从机型管理数据库中获取到硬解测试报告之后，服务器向终端反馈硬解测试报告，终端接收到硬解测试报告之后，终端可以依据硬解测试报告的指示来决定是否可以启用硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终 端对接，能够满足多终端的同时请求需要。

通过以上实施例对本发明的描述可知，终端首先获取需要解码播放的视频文件，然后终端向服务器发送解码方式请求指令，解码方式请求指令中携带终端的机型信息，接下来终端接收服务器根据机型信息获取到的硬解测试报告，最后终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中在服务器中建立有机型管理数据库，机型管理数据库中保存有机型信息对应的硬解测试报告，服务器按照终端的请求向其发送硬解测试报告，终端根据接收到的硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终端对接，能够满足多终端的同时请求需要。

为便于更好的理解和实施本发明实施例的上述方案，下面举例相应的应用场景来进行具体说明。

本发明实施例中，视频文件一般是将YUV数据通过视频压缩算法协议进行压缩，使得文件较小，以便于传播和存储。解码是压缩的方向过程，以还原YUV数据。显示是将YUV数据通过某种方式在屏幕上渲染出来，以便人眼观看，终端需要对视频文件执行一个完整的解码和显示过程才能被人眼看到。

接下来以终端为安卓智能终端为例，安卓终端的机型众多，浏览器用户在需要观看视频时，如果启用硬件解码(即硬解)，则能带来良好的体验，但由于安卓机型的差异性，每款机器需要经过测试才能确定能否启用硬解。通过硬解测试指的是能通过几种不同复杂度的视频样片测试，解码和显示均正确，本发明能够让线上用户在无感知情况下，就能确定能否使用硬件解码器来播放视频文件。

需要说明的是，本发明中硬解测试报告中只出现两个可能：在给定测试源(测试源即预先准备的几种不同复杂度的视频样片，例如一般至少3个)的情况下，通过或者不通过。不通过表现为崩溃(崩溃是指终端中的应用程 序直接退出)，卡住(卡住是指终端中的应用程序没有任何响应，也包括严重的卡顿)，花屏(花屏是指在视频样片播放过程中，画面犹如马赛克般不正常，非正常画面)。若硬解测试报告中为通过硬解测试，则需要解码正常，同时显示也正常。

接下来以一个终端执行硬解测试为例进行说明，终端通过全局唯一标识符(GUID，Globally Unique Identifier)来标识，保证对在同一时空中的所有终端机器都是唯一的。本发明中只需要对一个终端的硬解测试通过后即可，同机型的终端则无需再执行硬解测试，而是可以直接从服务器的机型管理数据中获取硬解测试报告。本发明中只对同机型的一个终端执行硬解测试，所以所耗费的服务器资源应该很少，但需要服务器做到实时保持与终端的联络。只要在一个机型的终端上验证成功，就可以推送到全网用户，对同一个机型而言，验证一个终端即可，这样，绝大部分的同款终端都会通过。其中，终端的机型信息可以通过设置--关于--机型号中来查找。

请参阅如图3所示，为本发明实施例中，终端与服务器交互实现硬解测试方案的一种实现方式示意图。

1，step1，服务器判断视频文件的文件属性信息是否满足硬解条件，服务器根据前述的文件属性信息确定向某个单点guid的终端下发硬解测试指令，触发终端打开硬解或者关闭硬解，这个功能只用来测试硬解使用。其中，终端打开硬解的条件是，指定用户guid，关闭硬解的条件是，根据终端上报的崩溃日志和状态数据来判断是否需要关闭硬解。

例如视频格式：可只针对h264协议才使用硬件解码器，而用户可能会观看例如rmvb这样的其他格式片源，所以要选择h264格式的，其他条件包括：视频宽高，例如宽×高为640×272，1104×622等，视频复杂度配置(例如复杂度为high)，依据这些硬解条件来打开硬解测试，这些可以从视频文件的文件属性信息得到。

2，step2，终端从测试源中选择某个复杂度的视频样片用来执行硬解测试。

3，step3，终端执行硬解，并对解码后数据验证，解码的同时启动软件解码器，软件解码器是指完全用终端的CPU进行解码和显示数据处理，有高可用性，基本不存在崩溃和花屏现象，用软件解码的结果与硬件解码的结果进 行比较，若发现数据一致，证明解码环节正常，具体的，可以只验证一秒(即25帧)的数据量即可，不会给用户造成太多卡顿感。

4，step4，终端执行显示数据验证，显示的数据即在屏幕上最终看到的视频数据，该数据应当与解码数据相同。

5，S1，崩溃数据监控，step1-step4之间，任何时候出现了崩溃，都应该上报(崩溃由s1监控，上报给服务器)，分析上报次数，比如当一个用户连续崩溃3次时即下发指令停止硬解。具体的，S1全程监控的step1-step4，一个完整的流程是一次播放，这期间发生了崩溃都算是一次，连续3次即连续播放3次都崩溃，或者当用户播放10次时不管结果如何即下发指令停止硬解。

6，S2，全程状态监控数据，step1-step4之间，收集一些播放时的信息，作为后续分析的依据。S2是埋点工具，即在播放过程中，收集一些关键点的状态信息，例如埋点的状态信息包括：视频格式，配置，尺寸，硬件解码器名字，解码了几帧，终端机型名称、终端的内存RAM大小，总存储空间ROM大小，能支持的网络制式等。

7，S3，终端将收集到的崩溃日志和选择所需的状态数据上传至服务器。

8，S4，服务器处理数据，例如服务器判定：视频格式是否h264，视频分辨率是否符合尺寸，视频复杂度是否符合要求，播放是否成功，播放了几次，有没有崩溃发生，对解码数据的验证结果和对显示数据的验证结果的分析，服务器实时处理来自于终端的数据，分析当前用户播放场景，并做出策略决定终端是否可以启用硬件解码器，生成硬解测试报告，保存到机型管理数据库。

9，S5，终端接收服务器发送的硬解测试报告，确定是否可以启用硬件解码器。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

为便于更好的实施本发明实施例的上述方案，下面还提供用于实施上 述方案的相关装置。

请参阅图4-a所示，本发明实施例提供的一种服务器400，可以包括：接收模块401、获取模块402、发送模块403，其中，

接收模块401，用于接收终端发送的解码方式请求指令，所述解码方式请求指令中携带所述终端的机型信息；

获取模块402，用于根据所述解码方式请求指令从机型管理数据库中获取与所述机型信息对应的硬解测试报告；

发送模块403，用于将所述硬解测试报告发送给所述终端，以使所述终端根据所述硬解测试报告确定是否启用对视频文件硬解的硬件解码器。

在发明的一些实施例中，所述获取模块402，还用于根据所述解码方式请求指令从机型管理数据库中获取与所述机型信息对应的硬解测试报告之前，查找所述机型管理数据库中是否存在与所述机型信息对应的硬解测试报告；

所述发送模块403，还用于若所述机型管理数据库中不存在与所述机型信息对应的硬解测试报告，向所述终端发送硬解测试指令。

在发明的一些实施例中，请参阅如图4-b所示，所述服务器400还包括：生成模块404和存储模块405，其中，

所述接收模块401，还用于所述发送模块403向所述终端发送硬解测试指令之，接收所述终端上报的异常日志和状态信息；

所述生成模块404，用于根据所述异常日志和所述状态信息确定所述终端是否通过硬解测试，生成硬解测试报告；

所述存储模块405，用于将生成的所述硬解测试报告存储到所述机型管理数据库中。

在发明的一些实施例中，所述生成模块404，具体用于分别执行如下步骤：根据所述异常日志判断所述终端在硬解测试过程中产生的异常次数是否超过异常阈值，和，所述服务器判断所述终端在硬解测试过程记录的所述状态信息是否满足预置的状态条件；若所述终端在硬解测试过程中产生的异常次数超过异常阈值，确定所述终端未通过硬解测试，若所述状态信息不满足所述状态条件，确定所述终端未通过硬解测试；若所述终端在硬解测试过程中产生的异常次数没有超过异常阈值且所述状态信息满足所述状态条件，确定所 述终端通过硬解测试。

在发明的一些实施例中，所述获取模块402，还用于所述接收模块401接收所述终端上报的异常日志和状态信息之后，根据所述异常日志判断所述终端在硬解测试过程中产生的异常次数是否超过异常次数连续值；

所述发送模块403，还用于若所述终端在硬解测试过程中产生的异常次数超过异常次数连续值，则向所述终端下发硬解停止指令；根据所述状态信息判断所述终端在硬解测试过程中已经完成的视频样片播放次数，若所述视频样片播放次数超过播放次数连续值，则向所述终端下发硬解停止指令。

在发明的一些实施例中，若所述解码方式请求指令中还携带所述终端需要解码播放的视频文件的文件属性信息；

所述发送模块403，具体用于判断所述文件属性信息是否满足预置的硬解条件，若所述文件属性信息满足所述硬解条件，向所述终端发送硬解测试指令。

在发明的一些实施例中，所述异常日志，包括：崩溃日志、卡顿日志、花屏日志。

通过以上实施例对本发明的描述可知，服务器首先接收终端发送的解码方式请求指令，解码方式请求指令中携带终端的机型信息，服务器根据解码方式请求指令从机型管理数据库中获取与机型信息对应的硬解测试报告，服务器将硬解测试报告发送给终端，以使终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中在服务器中建立有机型管理数据库，机型管理数据库中保存有机型信息对应的硬解测试报告，服务器按照终端的请求向其发送硬解测试报告，终端根据接收到的硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终端对接，能够满足多终端的同时请求需要。

请参阅图5-a所示，本发明实施例提供的一种终端500，可以包括：获取模块501、发送模块502、接收模块503、硬解确定模块504，其中，

获取模块501，用于获取需要解码播放的视频文件；

发送模块502，用于向服务器发送解码方式请求指令，所述解码方式请求指令中携带所述终端的机型信息；

接收模块503，用于接收所述服务器根据所述机型信息获取到的硬解测试报告；

硬解确定模块504，用于根据所述硬解测试报告确定是否启用对所述视频文件硬解的硬件解码器。

在发明的一些实施例中，所述终端还包括：硬解模块505、显示模块506、异常监控模块507和埋点模块508，其中，

所述接收模块503，还用于执行如下步骤1：接收所述服务器根据所述机型信息获取到的硬解测试报告之前，接收所述服务器在机型管理数据库中未查找到与所述机型信息对应的硬解测试报告之后下达的硬解测试指令；

所述硬解模块505，用于执行如下步骤2：根据所述硬解测试指令打开硬件解码器，使用所述硬件解码器对视频样片进行硬解，并对硬解视频数据进行验证，记录硬解验证结果；

所述显示模块506，用于执行如下步骤3：使用所述硬件解码器对所述视频样片进行硬解之后，在所述终端的显示屏幕上播放硬解后的视频样片，并对显示视频数据进行验证，记录显示验证结果；

所述异常监控模块507，用于在所述接收模块执行步骤1、所述硬解模块执行步骤2、所述显示模块执行步骤3的执行过程中，监控所述终端是否出现异常，并将记录的异常日志向所述服务器反馈；

所述埋点模块508，用于在所述接收模块执行步骤1、所述硬解模块执行步骤2、所述显示模块执行步骤3的执行过程中，通过埋点工具收集所述终端的状态信息，并将所述状态信息向所述服务器反馈。

在发明的一些实施例中，所述硬解模块505，具体用于使用所述硬件解码器对所述视频样片进行硬解，生成硬解视频数据；在对所述视频样片进行硬解的同时，启动软件解码器对所述视频样片进行解码，生成软解视频数据；判断所述硬解视频数据和所述软解视频数据是否一致，若一致，记录所述硬解验证结果为通过，若不一致，记录所述硬解验证结果为未通过。

在发明的一些实施例中，所述显示模块506，具体用于在所述终端的显示屏幕上播放硬解后的视频样片，从所述终端的本地内存中获取到显示视频数据；判断所述硬解视频数据和所述显示视频数据是否一致，若一致，记录所述显示验证结果为通过，若不一致，记录所述显示验证结果为未通过。

在发明的一些实施例中，所述解码方式请求指令中还携带所述视频文件的文件属性信息。

通过以上实施例对本发明的描述可知，终端首先获取需要解码播放的视频文件，然后终端向服务器发送解码方式请求指令，解码方式请求指令中携带终端的机型信息，接下来终端接收服务器根据机型信息获取到的硬解测试报告，最后终端根据硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中在服务器中建立有机型管理数据库，机型管理数据库中保存有机型信息对应的硬解测试报告，服务器按照终端的请求向其发送硬解测试报告，终端根据接收到的硬解测试报告确定是否启用对视频文件硬解的硬件解码器。本发明中改变了现有技术中终端对视频文件采用的实地硬解测试方案，而是终端只需要与服务器进行一次信令交互就可以确定是否能够启用硬件解码器，硬解测试的效率很高，另外服务器管理的机型管理数据库可用于与不同机型信息的终端对接，能够满足多终端的同时请求需要。

图6是本发明实施例提供的一种服务器结构示意图，该服务器600可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)622(例如，一个或一个以上处理器)和存储器632，一个或一个以上存储应用程序642或数据644的存储介质630(例如一个或一个以上海量存储设备)。其中，存储器632和存储介质630可以是短暂存储或持久存储。存储在存储介质630的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器622可以设置为与存储介质630通信，在服务器600上执行存储介质630中的一系列指令操作。

服务器600还可以包括一个或一个以上电源626，一个或一个以上有线或无线网络接口650，一个或一个以上输入输出接口658，和/或，一个或一个以上操作系统641，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM， FreeBSDTM等等。

上述实施例中由服务器所执行的硬解测试方法可以基于该图6所示的服务器结构。

本发明实施例还提供了另一种终端，如图7所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑等任意终端设备，以终端为手机为例：

图7示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。参考图7，手机包括：射频(Radio Frequency，RF)电路710、存储器720、输入单元730、显示单元740、传感器750、音频电路760、无线保真(wireless fidelity，WiFi)模块770、处理器780、以及电源790等部件。本领域技术人员可以理解，图7中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图7对手机的各个构成部件进行具体的介绍：

RF电路710可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器780处理；另外，将设计上行的数据发送给基站。通常，RF电路710包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。此外，RF电路710还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，GSM)、通用分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器720可用于存储软件程序以及模块，处理器780通过运行存储在存储器720的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器720可主要包括存储程序区和存储数据区，其中，存储程序区可 存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器720可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元730可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元730可包括触控面板731以及其他输入设备732。触控面板731，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板731上或在触控面板731附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板731可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器780，并能接收处理器780发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板731。除了触控面板731，输入单元730还可以包括其他输入设备732。具体地，其他输入设备732可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元740可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元740可包括显示面板741，可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板741。进一步的，触控面板731可覆盖显示面板741，当触控面板731检测到在其上或附近的触摸操作后，传送给处理器780以确定触摸事件的类型，随后处理器780根据触摸事件的类型在显示面板741上提供相应的视觉输出。虽然在图7中，触控面板731与显示面板741是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板731与显示面板741集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器750，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板741的亮度，接近传感器可在手机移动到耳边时，关闭显示面板741和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路760、扬声器761，传声器762可提供用户与手机之间的音频接口。音频电路760可将接收到的音频数据转换后的电信号，传输到扬声器761，由扬声器761转换为声音信号输出；另一方面，传声器762将收集的声音信号转换为电信号，由音频电路760接收后转换为音频数据，再将音频数据输出处理器780处理后，经RF电路710以发送给比如另一手机，或者将音频数据输出至存储器720以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块770可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图7示出了WiFi模块770，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器780是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器720内的软件程序和/或模块，以及调用存储在存储器720内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器780可包括一个或多个处理单元；优选的，处理器780可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器780中。

手机还包括给各个部件供电的电源790(比如电池)，优选的，电源可以通过电源管理系统与处理器780逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本发明实施例中，该终端所包括的处理器780还具有控制执行以上由终端执行的硬解测试方法流程。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘，U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

综上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照上述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对上述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。