直播混流服务动态调整方法及装置与流程

1.本技术涉及互联网技术领域，具体涉及一种直播混流服务动态调整方法及装置。


背景技术：

2.直播连麦是一种非常常见的直播场景，主要完成主播和主播之间的互动。其中有三个角色，直播间里最开始的主播我们称为大主播，请求连麦的称为小主播，然后就是第三方观众。大致流程是，大主播端推一路自己的画面，拉一路小主播的画面；小主播端推一路自己的画面，拉一路大主播的画面；第三方观众拉一路大小主播混流后的画面。其中混流是中间最重要的功能，需要将主播的流进行合并。
3.现有技术主要是采用云端混流方案，由专门的混流服务器进行混流。而这种混流方案采用的是物理混流服务器，物理混流服务器具有资源固定等特性，不方便动态调整资源以及存在资源浪费等风险。


技术实现要素：

4.本技术的目的是提供一种直播混流服务动态调整方法及装置，以解决现有技术存在的资源固定，无法满足突发流量以及直播混流服务资源利用率低等问题。
5.根据本技术实施例的一个方面，提供了一种直播混流服务动态调整方法，直播混流服务基于容器化部署实现，方法包括：
6.针对启动的直播混流服务，获取直播混流服务对应的混流质量影响参数；
7.根据混流质量影响参数判断直播混流服务对应的服务资源是否充足；
8.若否，则动态启动新的直播混流服务，以利用新启动的直播混流服务进行混流处理。
9.进一步地，方法还包括：对多路待混流的原始直播流及混合直播流进行直播流流质量分析，得到多路待混流的原始直播流及混合直播流对应的流质量结果，其中，混合直播流是对多路待混流的原始直播流进行混流处理而生成的；
10.判断混合直播流的流质量结果及任一路待混流的原始直播流的流质量结果是否符合预设条件；
11.若是，则获取直播混流服务对应的混流质量影响参数。
12.进一步地，流质量结果包括：流质量异常及流质量异常时段；或者，流质量结果包括：流质量正常。
13.进一步地，预设条件进一步包括：混合直播流的流质量异常、任一路待混流的原始直播流的流质量异常且混合直播流与任一路待混流的原始直播流非同时段流质量异常，或者，混合直播流的流质量异常且多路待混流的原始直播流的流质量均正常。
14.进一步地，判断混合直播流的流质量结果及任一路待混流的原始直播流的流质量结果是否符合预设条件进一步包括：
15.判断混合直播流的流质量结果是否为流质量异常；
16.若混合直播流的流质量结果为流质量异常，则判断是否存在任一路待混流的原始直播流的流质量结果为流质量异常；
17.若存在任一路待混流的原始直播流的流质量结果为流质量异常，则判断该待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段是否相同；
18.若流质量异常时段不相同或者若不存在任一路待混流的原始直播流的流质量结果为流质量异常，则获取直播混流服务对应的混流质量影响参数。
19.进一步地，针对任一直播流，利用如下方法分析确定流质量结果：
20.在任一流质量分析周期内，获取n个流质量采集点，相邻流质量采集点之间的时间间隔为预设值；根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算直播流的流质量参数；
21.若流质量参数大于或等于预设直播流质量阈值，则确定流质量结果为流质量正常；
22.若流质量参数小于预设直播流质量阈值，则确定流质量结果为流质量异常，并将流质量采集点对应的时间段确定为流质量异常时段。
23.进一步地，根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算直播流的流质量参数进一步包括：
24.针对每个质量采集点，根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算流质量采集点对应的卡顿值；
25.若卡顿值大于或等于预设卡顿阈值，则将该流质量采集点确定为卡顿点；
26.根据卡顿点数及n计算直播流的流质量参数。
27.进一步地，混流质量影响参数包括：带宽使用率、cpu使用率、内存使用率、丢包率、当前承载流数、直播混流服务质量。
28.进一步地，获取直播混流服务对应的直播混流服务质量进一步包括：
29.统计流质量正常的混合直播流对应的第一数量及总的混合直播流对应的第二数量；
30.根据第一数量及第二数量计算直播混流服务对应的直播混流服务质量。
31.进一步地，获取直播混流服务对应的丢包率进一步包括：
32.统计接收到的数据包对应的第三数量以及获取直播混流服务发送的数据包对应的第四数量；
33.根据第三数据量和第四数据量计算丢包率。
34.进一步地，利用如下方法确定直播混流服务对应的预设承载流阈值：
35.动态调整向直播混流服务分发的原始直播流的第五数量，计算在分发第五数量的原始直播流时直播混流服务对应的混流服务使用率；
36.根据第五数量及第五数据对应的混流服务使用率确定斜率计算点；
37.若当前斜率计算点与相邻的斜率计算点之间的斜率大于预设斜率阈值，则将相邻的斜率计算点对应的第五数量确定为直播混流服务对应的预设承载流阈值。
38.进一步地，计算在分发第五数量的原始直播流时直播混流服务对应的混流服务使用率进一步包括：
39.根据带宽使用率、cpu使用率及内存使用率计算在分发第五数量的原始直播流时
直播混流服务对应的混流服务使用率。
40.进一步地，根据混流质量影响参数判断直播混流服务对应的服务资源是否充足进一步包括：
41.根据如下至少一个判断条件确定直播混流服务对应的服务资源是否充足：判断带宽使用率是否小于预设带宽使用率阈值；和/或
42.判断cpu使用率是否小于预设cpu使用率阈值；和/或
43.判断内存使用率是否小于预设内存使用率阈值；和/或
44.判断丢包率是否小于预设丢包率阈值；和/或
45.判断当前承载流数是否小于预设承载流阈值；和/或
46.判断直播混流服务质量是否大于或等于预设直播混流服务质量阈值；
47.若任一判断条件不满足则确定直播混流服务对应的服务资源不充足；
48.若所有判断条件都满足，则确定直播混流服务对应的服务资源充足。
49.进一步地，方法还包括：根据混流质量影响参数判断直播混流服务对应的服务资源是否正在使用，若未使用，则动态缩减直播混流服务。
50.进一步地，根据混流质量影响参数判断直播混流服务对应的服务资源是否正在使用进一步包括：
51.根据如下至少一个判断条件确定直播混流服务对应的服务资源是否正在使用：判断带宽使用率是否为0；和/或
52.判断cpu使用率是否为0；和/或
53.判断内存使用率是否为0；和/或
54.判断当前承载流数是否为0；
55.若任一判断条件不满足，则确定直播混流服务对应的服务资源正在使用；
56.若所有判断条件都满足，则确定直播混流服务对应的服务资源未使用。
57.进一步地，在动态启动新的直播混流服务之后，方法还包括：若判断出多个直播混流服务对应的服务资源充足，则将多路待混流的原始直播流调度至当前承载流数最多的直播混流服务上。
58.进一步地，直播混流服务基于容器化部署实现具体为：将直播混流服务转化为对应的二进制文件；启动二进制文件以完成直播混流服务的容器化部署。
59.根据本技术实施例的另一方面，提供了一种直播混流服务动态调整装置，直播混流服务基于容器化部署实现，装置包括：
60.获取模块，适于针对启动的直播混流服务，获取直播混流服务对应的混流质量影响参数；
61.第一判断模块，适于根据混流质量影响参数判断直播混流服务对应的服务资源是否充足；
62.动态调整模块，适于若判断出直播混流服务对应的服务资源不足，则动态启动新的直播混流服务，以利用新启动的直播混流服务进行混流处理。
63.根据本技术实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；
64.存储器用于存放至少一可执行指令，可执行指令使处理器执行上述直播混流服务
动态调整方法对应的操作。
65.根据本技术实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述直播混流服务动态调整方法对应的操作。
66.根据本技术实施例提供的方案，利用混流质量影响参数综合判断直播混流服务是否能够继续支撑更多的混流服务，在确定直播混流服务对应的服务资源不足的情况下，动态启动新的直播混流服务，实现了混流资源按需分配，有效提高了混流质量，避免由于混流质量不佳而导致用户观看出现卡顿现象，影响用户观看体验，同时也进一步提高了直播混流服务的服务资源利用率。
67.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
68.通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本技术的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
69.图1为现有技术中云端混流的架构示意图；
70.图2示出了根据本技术中的一个实施例的直播混流服务动态调整方法的流程示意图；
71.图3a示出了根据本技术中的另一个实施例的直播混流服务动态调整方法的流程示意图；
72.图3b为边缘计算混流的架构示意图；
73.图3c为确定丢包率的示意图；
74.图3d为根据直播混流服务对应的混流服务使用率确定预设承载流阈值的示意图；
75.图3e为判断直流混流服务对应的服务资源是否充足的具体实施方式的流程示意图；
76.图3f为判断是否缩减直流混流服务的具体实施方式的流程示意图；
77.图4示出了根据本技术中的一个实施例的直播混流服务动态调整装置的结构示意图；
78.图5示出了根据本技术中的一个实施例的计算设备的结构示意图。
具体实施方式
79.下面将参照附图更详细地描述本技术的示例性实施例。虽然附图中显示了本技术的示例性实施例，然而应当理解，可以以各种形式实现本技术而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本技术，并且能够将本技术的范围完整的传达给本领域的技术人员。
80.首先，对本技术一个或多个实施例涉及的名词术语进行解释。
81.直播流：直播音视频数据的传输，它能够被作为一个稳定的和连续的流通过网络
传输给观众观看
82.直播拉流：拉流是指通过直播云平台到用户指定的源站拉取直播流的过程。
83.cdn：内容分发网络
84.cdn云服务器：提供内容分发网络的服务器
85.边缘计算节点：用于接收推流的服务节点
86.连麦：主播在直播的过程中，可以选择一个主播，和他进行实时的互动。观众看到的是2个人互动后的画面，而非单纯的主播画面。
87.混流：是描述视频和音频数据流的控制、同步以及混合方式(英文multiplexing，简写为mux)。简单地讲就是把视频与音频合并，将各路输入源混流成一个新的流，可实现直播互动效果。
88.容器：内核轻量级的操作系统层虚拟化技术。它是独立运行的一个或一组应用，及他们的运行环境。可以看为最轻量级的虚拟服务器。和虚拟服务器最大的区别在于虚拟服务器需要消耗的资源很大，是完整的一个操作系统，而容器只需要包含运行服务的最基础资源。同样的资源，只能部署一个虚拟服务器，但是却可以生成几十个甚至上百个容器。
89.直播连麦是现有非常常见的一种直播场景。主要完成主播和主播之间的互动。其中有三个角色，直播间里最开始的主播我们称为大主播，请求连麦的称为小主播，然后就是第三方观众。具体流程是，大主播端推一路自己的画面，拉一路小主播的画面；小主播端推一路自己的画面，拉一路大主播的画面；第三方观众拉一路大小主播混流后的画面。其中混流是中间最重要的功能，需要将主播的流进行合并。图1为现有技术中云端混流的架构示意图。云端混流，就是让cdn云服务器来完成混流操作，具体地，a主播将直播流a推流到cdn云服务，b主播将直播流b推流到cdn云服务器上，如果需要连麦，cdn云服务器会将直播流a和直播流b发送至专门的混流服务器，这里的混流服务器是屋里机，由专门的混流服务器将直播流a和直播流b进行混流。
90.这样的架构存在以下问题：
91.①
资源固定：现有的混流集群普遍是采用部署物理混流服务器。物理混流服务器一般硬件配置较高，可以同时混n路流，承载的流数较大。物理混流服务器是物理机，物理机的正常使用需要完成申请、采购、测试验收、部署程序四个步骤，且整体流程耗时很长，少则一个月，多则半年，无法满足突发流量，扩容和缩容困难。
92.②
风险高，资源浪费：物理混流服务器由于配置高，可以承载的流的数量也大，在上面混流的流数也多。当机器出现异常或者网络抖动的时候，也意味着影响的流的数量很多，进而影响流质量。如果减少一个机器上承载的流数，机器的资源就会出现大量浪费。如果降低物理混流服务器配置，降低承载流量，意味着需要部署足够多的小的混流服务器，运维成本较高。
93.③
无质量考虑：每个混流服务器都进行无脑的混流，并不考虑混流前后的质量判断。
94.为了能够有效解决上述问题，发明人通过付出创造性劳动提出了一种直播混流服务动态调整方案。
95.图2示出了根据本技术中的一个实施例的直播混流服务动态调整方法的流程示意图。直播混流服务基于容器化部署实现，如图2所示，该方法包括以下步骤：
96.步骤s201，获取直播混流服务对应的混流质量影响参数。
97.直播混流服务是用于进行直播流混流处理的服务进程，直播混流服务在进行直播流混流处理时，可能会存在不足以支撑更多地混流而导致混流质量不佳的情况，因此，需要获取直播混流服务对应的混流质量影响参数，以通过混流质量影响参数来综合判断直流混流服务是否可以继续支撑更多地混流，其中，混流质量影响参数是影响直播混流服务混流质量的参数。
98.步骤s202，根据混流质量影响参数判断直播混流服务对应的服务资源是否充足；若否，则执行步骤s203。
99.在获取直播混流服务对应的混流质量影响参数之后，根据混流质量影响参数判断直播混流服务对应的服务资源是否充足，通过判断直播混流服务对应的服务资源是否充足来确定是否需要新启动直播混流服务，若确定直播混流服务对应的服务资源不足，则执行步骤s203；若确定直播混流服务对应的服务资源充足，则方法结束。
100.步骤s203，动态启动新的直播混流服务，以利用新启动的直播混流服务进行混流处理。
101.在确定直播混流服务对应的服务资源不足的情况下，需要动态启动新的直播混流服务，例如，通过命令启动容器来实现启动新的直播混流服务，以利用新启动的直播混流服务进行混流处理。
102.直播混流服务是基于容器化部署实现的，使得直播混流服务启动所需时间非常短，因此，在判断出直播混流服务对应的服务资源不充足时，能够快速地启动新的直播混流服务，并控制利用新启动的直播混流服务进行混流处理，而不需要经过物理混流服务器那样漫长的过程(物理混流服务器的正常使用需要完成申请、采购、测试验收、部署程序四个步骤，且整体流程耗时很长)，从而简便地实现了直播混流服务的扩容处理，而且每个直播混流服务的服务资源都得到了充分地利用，提高了直播混流服务的服务资源利用率。
103.根据本技术实施例提供的方法，利用混流质量影响参数综合判断直播混流服务是否能够继续支撑更多的混流服务，在确定直播混流服务对应的服务资源不足的情况下，动态启动新的直播混流服务，实现了混流资源按需分配，有效提高了混流质量，避免由于混流质量不佳而导致用户观看出现卡顿现象，影响用户观看体验，同时也进一步提高了直播混流服务的服务资源利用率。
104.图3a示出了根据本技术中的另一个实施例的直播混流服务动态调整方法的流程示意图。直播混流服务基于容器化部署实现，如图3a所示，该方法包括以下步骤：
105.步骤s301，对多路待混流的原始直播流及混合直播流进行直播流流质量分析，得到多路待混流的原始直播流及混合直播流对应的流质量结果，其中，混合直播流是对多路待混流的原始直播流进行混流处理而生成的。
106.具体地，原始直播流是主播推送的直播流，混合直播流是对多路原始直播流进行混流处理后而生成的一路新的直播流，例如，主播a和主播b需要进行连麦，那么主播a推送的直播流a和主播b推送的直播流b称为待混流的原始直播流，而对直播流a和直播流b进行混流处理后生成直播流c，直播流c称为混合直播流，这里仅是举例说明，不具有任何限定作用，实际直播场景中可能存在3个以上主播进行连麦的情况。
107.为了能够精准进行直播混流服务的动态调整，本实施例需要对多路待混流的原始
直播流及混合直播流进行直播流流质量分析，得到多路待混流的原始直播流及混合直播流对应的流质量结果，其中，直播流流质量分析是对直播流进行质量分析，分析直播流的质量情况，流质量结果是直播流流质量分析结果，反映了直播流本身的质量情况，流质量结果包括：流质量异常及流质量异常时段，或者，流质量结果包括：流质量正常。流质量异常时段指直播流在哪个时间段发生了流质量异常。
108.下面描述了直播流的流质量结果的具体分析过程，针对每个原始直播流及混合直播流，可以利用该方法分析确定其流质量结果：
109.在任一流质量分析周期内，获取n个流质量采集点，相邻流质量采集点之间的时间间隔为预设值；根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算直播流的流质量参数。优选地，可以利用如下方法来计算直播流的流质量参数：针对每个质量采集点，根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算流质量采集点对应的卡顿值，其中，卡顿值等于(流质量采集点对应的每秒传输帧数-流质量分析周期对应的平均每秒传输帧数)的绝对值/流质量分析周期对应的平均每秒传输帧数；若卡顿值大于或等于预设卡顿阈值，则将该流质量采集点确定为卡顿点；根据卡顿点数及n计算直播流的流质量参数，例如，根据如下公式计算直播流的流质量参数：流质量参数＝1-卡顿点数/n。
110.在计算得到直播流的流质量参数后，将流质量参数与预设直播流质量阈值进行比较，若流质量参数大于或等于预设直播流质量阈值，则确定流质量结果为流质量正常；若流质量参数小于预设直播流质量阈值，则确定流质量结果为流质量异常，并将流质量采集点对应的时间段确定为流质量异常时段。
111.本实施例采用边缘计算混流架构，混流是多个输入，一个输出，图3b为边缘计算混流的架构示意图，如图3b所示，主播a和主播b分别将原始直播流a和原始直播流b推到集群a和集群b中的边缘计算上行节点，边缘计算上行节点负责接收推流。其中，集群a和集群b中的所有服务已经实现容器化部署(集群的底层是n个物理服务器，物理服务器上部署容器，例如，可以是n个边缘计算节点)，即，边缘计算上行节点和直播混流服务1-直播混流服务3均已实现容器化部署。当主播a和主播b连麦需要混流时，直播混流服务3会拉主播a和主播b的流，即图中直播混流服务3拉流a和拉流b，并输出混合直播流c。
112.直播混流服务基于容器化部署实现，具体是将直播混流服务转化为对应的二进制文件；在容器中启动二进制文件以完成直播混流服务的容器化部署。容器和容器之间是相互隔离的，互不影响。直播混流服务1、直播混流服务2和直播混流服务3均是容器化部署。
113.这里主要是通过在边缘计算节点上部署kubernetes系统，简称k8s，来实现边缘计算节点上的服务容器化，kubernetes可用于自动部署，扩展和管理容器化应用程序的开源系统。它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现。通过控制kubernetes原生接口，实现启动容器和停止容器，以及参数传递。
114.本实施例具体是利用直播流每秒传输帧数fps来分析计算直播流的流质量结果，这里使用fps来进行直播流的流质量结果分析计算因素的原因是：fps是每秒传输的帧数，在混流中，直播混流服务是拉多路待混流的原始直播流，而在网络或机器性能稳定的情况下，接收的fps传输速率是恒定的。若直播混流服务发生网络异常或者负载过高，无法处理更多的帧数，只能接收多路待混流的原始直播流的部分帧数，其他帧数会存储在传输相应
原始直播流的边缘计算节点，等待容器负载恢复正常，直播混流服务会在瞬间接收之前未接收的传输帧数，这样就导致前后传输的帧率变动幅度较大，从而能够准确地分析出直播流的流质量结果。边缘计算上行节点及直播混流服务可以通过kubernetes原生接口将直播流fps值传输给中心服务，中心服务是一种服务进程，是独立于集群外部的。
115.预先设置流质量分析周期对应的时长，例如，可以是5分钟，分析5分钟内直播流的流质量。获取流质量分析周期内接收到的直播流的所有fps值，计算平均fps值，其中，平均fps值＝总fps值/流质量分析周期的时长。
116.当一路直播流的fps值在在短时间内变化超过一定的幅度，则说明该直播流发生流抖动，会导致用户观看卡顿。因此，可以在任一流质量分析周期内，获取n个流质量采集点，相邻流质量采集点之间的时间间隔为预设值，例如，5s，计算每个流质量采集点的卡顿值，一个流质量采集点的卡顿值等于(流质量采集点的fps值-平均fps值)的绝对值/平均fps值，在计算得到一个流质量采集点的卡顿值之后，将该卡顿值与预设卡顿阈值(例如，设置为30％，这里仅是举例说明，不具有任何限定作用)进行比较，来确定该流质量采集点是否发生了卡顿，若卡顿值大于或等于预设卡顿阈值，则可以确定该流质量采集点发生了卡顿，将该流质量采集点确定为卡顿点；若卡顿值小于预设卡顿阈值，则可以确定该流质量采集点未发生卡顿。统计卡顿点的数量，根据卡顿点数及流质量采集点数n来确定该流质量分析周期对应的流质量参数，流质量参数＝1-卡顿点数/n。
117.在计算得到直播流的流质量参数后，将流质量参数与预设直播流质量阈值进行比较，若流质量参数大于或等于预设直播流质量阈值，则确定流质量结果为流质量正常；若流质量参数小于预设直播流质量阈值，则确定流质量结果为流质量异常，并将流质量采集点对应的时间段确定为流质量异常时段。
118.流质量结果包括：流质量异常及流质量异常时段或流质量正常，在确定了混合直播流的流质量结果及任一路待混流的原始直播流的流质量结果之后，判断混合直播流的流质量结果及任一路待混流的原始直播流的流质量结果是否符合预设条件，其中，预设条件进一步包括：混合直播流的流质量异常、任一路待混流的原始直播流的流质量异常且混合直播流与任一路待混流的原始直播流非同时段流质量异常，或者，混合直播流的流质量异常且多路待混流的原始直播流的流质量均正常。具体可以通过如下方法进行判断：
119.步骤s302，判断混合直播流的流质量结果是否为流质量异常；若是，则执行步骤s303。
120.在利用步骤s201得到混合直播流的流质量结果以及多路待混流的原始直播流的流质量结果后，判断混合直播流的流质量结果是否为流质量异常，若混合直播流的流质量结果为流质量异常，则执行步骤s303；若混合直播流的流质量结果为流质量正常，则方法结束。
121.步骤s303，判断是否存在任一路待混流的原始直播流的流质量结果为流质量异常，若是，则执行步骤s304；若否，则执行步骤s305。
122.在判断出混合直播流的流质量结果为流质量异常的情况下，还需要进一步判断是否存在任一路待混流的原始直播流的流质量结果为流质量异常，这里判断是否存在任一路待混流的原始直播流的流质量结果为流质量异常主要是为了确定是否是由原始直播流引发的混流质量下降，以及混流质量下降是否属于正常现象，若存在任一路待混流的原始直
播流的流质量结果为流质量异常，则执行步骤s304，做进一步地判断；若不存在任一路待混流的原始直播流的流质量结果为流质量异常，则可以确定混流服务质量不佳，执行步骤s305。
123.步骤s304，判断该待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段是否相同，若否，则执行步骤s305。
124.在存在任一路待混流的原始直播流的流质量结果为流质量异常的情况下，可以通过判断该待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段是否相同来确定是否是由原始直播流引发的混流质量下降，以及混流质量下降是否属于正常现象。
125.具体地，混合直播流的流质量异常以及任一路待混流的原始直播流的流质量异常时，将该待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段逐一进行比较，来确定流质量异常时段是否相同，如果任一路待混流的原始直播流的流质量异常的异常时段与混合直播流的流质量异常的异常时段相同，可以认为是原始直播流引发了混流质量下降，属于正常现象；如果任一路待混流的原始直播流的流质量异常的异常时段与混合直播流的流质量异常的异常时段不同，则可以确定不是由原始直播流引发混流质量下降，可以认定混流服务质量不佳。
126.在实际应用中，可能存在多路待混流的原始直播流的流质量异常的情况，在判断多路待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段是否相同时，主要是将混合直播流的每个流质量异常时段分别与每一路流质量异常的原始直播流的流质量异常时段进行比较，若混合直播流的每个流质量异常时段与任一路流质量异常的原始直播流的流质量异常时段相同，则确定多路待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段相同，若混合直播流的任一流质量异常时段与每一路流质量异常的原始直播流的流质量异常时段不同，则确定多路待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段不同。
127.举例说明，多路待混流的原始直播流包括直播流a和直播流b，混合直播流为直播流c，直播流a的流质量异常时段为0-5秒，直播流b的流质量异常时段为10-15秒，直播流c的流质量异常时段为0-5秒、5-10秒，其中，直播流c的流质量异常时段5-10秒并未出现在直播流a、直播流b的流质量异常时段中，可以确定多路待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段不同。
128.通过上述判断能够有效减少后续判断直播混流服务的服务资源是否充足的次数，节省资源。
129.步骤s305，获取直播混流服务对应的混流质量影响参数。
130.其中，混流质量影响参数包括：带宽使用率、cpu使用率、内存使用率、丢包率、当前承载流数、直播混流服务质量。
131.通常情况下，混流的基本过程为：拉流、解码、混流、编码、转推流。
132.其中，影响混流质量的因素有：
133.①
带宽：由于混流处理是拉多路直播流，然后混合成一路直播流，和正常的直播一进一出对比，混流对进的带宽有更高的要求。如果带宽不够，网络数据包无法发给混流服务器，或者混流后的数据无法发送出去，就会导致网络拥塞，进而影响直播质量
134.②
cpu：解码、混流、编码过程都需要对流进行实时转码，这需要消耗很高的计算资源，占据较大的cpu。因此当cpu使用率超过一定的cpu使用率时，再进行混流，就会导致混流质量下降。
135.③
内存：混流过程中还会占用较大的处理内存，当内存使用率超过一定内存使用率，再进行混流处理就会导致混流质量下降。
136.④
丢包率：图3c为确定丢包率的示意图，混流之后会把数据发送给中心服务，容器可以向中心服务传输发送的数据包的第四数量。中心服务可以统计接收到的数据包的第三数量。(第四数量-第三数量)/第四数量，就是整体链路传输的丢包率。当丢包率较高的时候，说明当前的直流混流服务不再适合混流。
137.⑤
当前承载流数：容器是运行在物理机器上，由于物理机器的差别，即使承载相同的直播流，也可能出现带宽/cpu/内存的使用率是完全不同的，性能好的机器，使用率就会低，而性能差的机器使用率可能就会高。带宽/cpu/内存的使用率是从整体的维度进行配置，而当前承载流数则是从容器维度来监控，因此，这里还配置承载流数，不完全使用带宽/cpu/内存。
138.⑥
直播混流服务质量：
①②③④
都是从硬件或者网络层面的判断的混流的质量，直播混流服务质量是从业务层面判断是否混流的质量真不好。
139.具体地，直播混流服务是基于容器实现的，通常情况下，在容器内部会部署采集容器基础信息的程序，可以利用该程序来实时获得带宽使用率、cpu使用率、内存使用率。容器可以向中心服务传输参数：带宽使用率、cpu使用率、内存使用率
140.可以利用如下方法获取直播混流服务对应的丢包率：统计接收到的数据包对应的第三数量以及获取直播混流服务发送的数据包对应的第四数量；根据第三数据量和第四数据量计算丢包率，例如，利用如下公式计算丢包率：丢包率＝(第四数量-第三数量)/第四数量。
141.具体地，容器内部的程序，定时向中心服务发送数据包，并向中心服务传输发送数据包对应的第四数量，中心服务可以统计接收到的数据包对应的第三数量，通过将接收到的数据包的第三数量和发送数据包的第四数量的进行对比，即可获得网络的丢包率，丢包率＝第四数量-第三数量/第四数量*100％
142.下面详细描述确定直播混流服务对应的预设承载流阈值的实现过程：动态调整向直播混流服务分发的原始直播流的第五数量，计算在分发第五数量的原始直播流时直播混流服务对应的混流服务使用率，例如，可以根据带宽使用率、cpu使用率及内存使用率计算在分发第五数量的原始直播流时直播混流服务对应的混流服务使用率；根据第五数量及第五数据对应的混流服务使用率确定斜率计算点；若当前斜率计算点与相邻的斜率计算点之间的斜率大于预设斜率阈值，则将相邻的斜率计算点对应的第五数量确定为直播混流服务对应的预设承载流阈值。
143.图3d为根据直播混流服务对应的混流服务使用率确定预设承载流阈值的示意图，如图3d所示，是使用压测的方式来探测一个直播混流服务的最大承载流数，最大承载流数称为预设承载流数阈值，当直流混流服务容器上的流超过最大承载流数的时候，直流混流服务性能会发生大幅度的下降。因此，这里采用的是不断增加一个容器上的流数，即，第五数量(对应x轴)，计算该流数下直流混流服务的混流服务使用率(对应y轴)，混流服务使用
率等于(带宽使用率+cpu使用率+内存使用率)/3，其中，同一种物理机器类型上的容器能够承载流数是一样的。
144.流数与混流服务使用率唯一确定一个斜率计算点，例如图3d所示的b点及a点为斜率计算点，假设a点为当前斜率计算点，那么b点为在前相邻的斜率计算点，计算当前斜率计算点与在前相邻的斜率计算点之间的斜率，将斜率与预设斜率阈值进行比较，若当前斜率计算点与相邻的斜率计算点之间的斜率大于预设斜率阈值，则将在前相邻的斜率计算点对应的第五数量确定为直播混流服务对应的预设承载流阈值，在图3d中，在到达临界点b后，整体的混流服务使用率就开始陡增，最大承载流数为350。
145.具体地，虽然能够确定混流质量不佳，但是为了能够更精准地确定直播混流服务是否真的混流质量不佳，还可以对直播混流服务上的所有流进行上诉判断，利用如下方法来获取直播混流服务对应的直播混流服务质量：统计流质量正常的混合直播流对应的第一数量及总的混合直播流对应的第二数量；根据第一数量及第二数量计算直播混流服务对应的直播混流服务质量，例如，根据如下公式计算直播混流服务质量：直播混流服务质量＝第一数量/第二数量。
146.步骤s306，根据混流质量影响参数判断直播混流服务对应的服务资源是否充足，若否，则执行步骤s307。
147.具体地，可以根据如下至少一个判断条件确定直播混流服务对应的服务资源是否充足：判断带宽使用率是否小于预设带宽使用率阈值；和/或
148.判断cpu使用率是否小于预设cpu使用率阈值；和/或
149.判断内存使用率是否小于预设内存使用率阈值；和/或
150.判断丢包率是否小于预设丢包率阈值；和/或
151.判断当前承载流数是否小于预设承载流阈值；和/或
152.判断直播混流服务质量是否大于或等于预设直播混流服务质量阈值；
153.若任一判断条件不满足则确定直播混流服务对应的服务资源不充足；
154.若所有判断条件都满足，则确定直播混流服务对应的服务资源充足。
155.图3d为判断直流混流服务对应的服务资源是否充足的具体实施方式的流程示意图，如图3d所示，该具体实施方式包括如下步骤：
156.步骤s3061，判断带宽使用率是否小于预设带宽使用率阈值；若否，则执行步骤s3068；若是，则执行步骤s3062；
157.步骤s3062，判断cpu使用率是否小于预设cpu使用率阈值；若否，则执行步骤s3068；若是，则执行步骤s3063；
158.步骤s3063，判断内存使用率是否小于预设内存使用率阈值；若否，则执行步骤s3068；若是，则执行步骤s3064；
159.步骤s3064，判断丢包率是否小于预设丢包率阈值；若否，则执行步骤s3068；若是，则执行步骤s3065；
160.步骤s3065，判断当前承载流数是否小于预设承载流阈值；若否，则执行步骤s3068；若是，则执行步骤s3066；
161.步骤s3066，判断直播混流服务质量是否大于或等于预设直播混流服务质量阈值；若是，则执行步骤s3067；若否，则执行步骤s3068。
162.步骤s3067，确定直播混流服务的服务资源充足。
163.步骤s3068，确定直播混流服务的服务资源不足。
164.其中，预设带宽使用率阈值、预设cpu使用率阈值、预设内存使用率阈值、预设丢包率阈值、预设承载流阈值、预设直播混流服务质量阈值是评价服务资源是否充足的一个临界值，例如，可以设置预设内存使用率阈值、预设cpu使用率阈值、预设内存使用率阈值为80％，设置预设丢包率阈值为50％，设置预设承载流阈值为350，设置预设直播混流服务质量阈值为70％。
165.若判断出带宽使用率大于或等于80％，表明服务资源不足；若带宽使用率小于80％，还需要辅助其他参数进一步来判断服务资源是否充足；若cpu使用率大于或等于80％，表明服务资源不足；若cpu使用率小于80％，还需要辅助其他参数进一步来判断服务资源是否充足；若内存使用率大于或等于80％，表明服务资源不足；若内存使用率小于80％，还需要辅助其他参数进一步来判断服务资源是否充足。若丢包率大于或等于50％，表明服务资源不足；若丢包率小于50％，还需要辅助其他参数进一步来判断服务资源是否充足；若当前承载流数大于或等于350，表明服务资源不足；若当前承载流数小于350，还需要辅助其他参数进一步来判断服务资源是否充足；若直播混流服务质量大于或等于70％，表明服务资源充足；若直播混流服务质量小于70％，可以确定服务资源不足。
166.通常情况下，可以通过如下方法来确定预设带宽使用率阈值、预设cpu使用率阈值、预设内存使用率阈值、预设丢包率阈值：
167.预设带宽使用率阈值的确定过程如下：通过缩小正常的带宽配置，压测流的带宽，例如配置100m，推一个70m的流，此时带宽使用率超过70％，判断混流后的混合直播流是否产生观看卡顿现象，如果观看不卡顿，则缩小带宽配置，直到肉眼观看产生卡顿，发生卡顿时对应的带宽使用率即为预设带宽使用率阈值。
168.预设cpu使用率阈值的确定过程如下：在一个容器内部运行一个很耗费cpu的程序，不断的增加cpu使用率，并且正常混流，判断cpu使用率超过多少，会产生观看卡顿，则发生卡顿时对应的cpu使用率即为预设cpu使用率阈值。
169.预设内存使用率阈值的确定过程如下：在容器内部放在一个文件，利用文件的大小来控制内存的使用率，且正常进行混流，判断内存使用率超过多少，会产生观看卡顿，则发生卡顿时对应的内存使用率即为预设内存使用率阈值。
170.预设丢包率阈值的确定过程如下：正常推流，混流的时候随机丢包，判断当丢包率大于多少的时候，会产生观看卡顿，则发生卡顿时对应的丢包率即为预设丢包率阈值
171.需要说明的是，本实施例并不限定上述各判断步骤的执行顺序。
172.步骤s307，动态启动新的直播混流服务，以利用新启动的直播混流服务进行混流处理。
173.在确定直播混流服务对应的服务资源不足的情况下，需要动态启动新的直播混流服务，例如，通过动态调用kubernetes原生接口发送启动命令来启动容器来实现增加新的直播混流服务，以利用新启动的直播混流服务进行混流处理，比如，当存在新的混流需求时，可以利用新启动的直播混流服务来处理。结合图3b，通过向kubernetes系统发送启动新的直播混流服务的命名，kubernetes系统调用kubernetes原生接口来动态新启动直播混流服务1，每个直播混流服务都对应有相应的ip地址，当存在混流需求时，例如流d推流上来需
要混流，边缘计算上行节点向中心服务发送携带有流d信息的调度请求，中心服务根据启动的直播混流服务的服务资源是否充足以及直播混流服务当前当前承载流数来确定执行混流处理的直播混流服务，例如，确定直播混流服务1来执行混流处理，则向边缘计算上行节点返回直播混流服务1的ip地址，边缘计算上行节点根据直播混流服务1的ip地址将流d被调度到直播混流服务1上，对于新启动的直播混流服务1，也会执行上述方法。
174.由于直播混流服务的启动非常快，因此，在动态启动直播混流服务时，每次可以启动一个新的直播混流服务，在启动的直播混流服务的服务资源不充足的情况下，继续再启动一个新的直播混流服务。当然，也可能出现混流需求突增的情况，此时可以根据待混流的原始直播流的数量并结合直播混流服务的预设承载流阈值来确定动态启动的直播混流服务的数量。
175.为了有效节约资源，可以在服务资源未使用的情况下，动态缩减直播混流服务，具体地，根据混流质量影响参数判断直播混流服务对应的服务资源是否正在使用，若未使用，则动态缩减直播混流服务；若正在使用，则不做任何处理。例如，根据如下至少一个判断条件确定直播混流服务对应的服务资源是否正在使用：判断带宽使用率是否为0；和/或，判断cpu使用率是否为0；和/或，判断内存使用率是否为0；和/或，判断当前承载流数是否为0；若任一判断条件不满足，则确定直播混流服务对应的服务资源正在使用；若所有判断条件都满足，则确定直播混流服务对应的服务资源未使用。
176.图3e为判断是否缩减直流混流服务的具体实施方式的流程示意图，如图3e所示，该具体实施方式包括如下步骤：
177.步骤s308，判断带宽使用率是否为0；若是，则执行步骤s309；若否，则执行步骤s312；
178.步骤s309，判断cpu使用率是否为0；若是，则执行步骤s310；若否，则执行步骤s312；
179.步骤s310，判断内存使用率是否为0；若是，则执行步骤s311；若否，则执行步骤s312；
180.步骤s311，判断当前承载流数是否为0；若是，则执行步骤s313；若否，则执行步骤s312；
181.步骤s312，确定服务资源正在使用，不做处理。
182.当带宽使用率不为0和/或cpu使用率不为0和/或内存使用率不为0和/或当前承载流数不为0时，可以确定服务资源正在使用，未避免对现有的混流服务产生影响，这里不做任何处理。
183.步骤s313，确定服务资源未使用，动态缩减直播混流服务。
184.当带宽使用率为0且cpu使用率为0且内存使用率为0且当前承载流数为0时，可以确定服务资源未使用，动态缩减直播混流服务，例如，通过动态kubernetes原生接口发送关掉命令来关掉容器，以实现缩减直播混流服务。通过缩减直播混流服务能够有效避免服务资源浪费，提高服务资源利用率。
185.由于主播直播时间是不一样的，因此在缩减直播混流服务时，通常只缩减一个直播混流服务，当多个直播混流服务的服务资源都未使用时，也可以同时缩减多个。
186.需要说明的是，本实施例并不限定上述各判断步骤的执行顺序。
187.在本发明一种可选实施方式中，在动态启动新的直播混流服务之后，方法还包括：若判断出多个直播混流服务对应的服务资源充足，则将多路待混流的原始直播流调度至当前承载流数最多的直播混流服务上。在动态启动新的直播混流服务之后，此时就已经启动了多个直播混流服务，针对每个启动的直播混流服务会获取直播混流服务对应的混流质量影响参数，并根据混流质量影响参数判断直播混流服务对应的服务资源是否充足；若判断出多个直播混流服务对应的服务资源充足，则将多路待混流的原始直播流调度至当前承载流数最多的直播混流服务上。通过将多路待混流的原始直播流调度至当前承载流数最多的直播混流服务上，能够有效利用该直播混流服务的服务资源，并在其他启动的直播混流服务的服务资源未使用的情况下，关掉该直播混流服务。
188.根据本技术实施例提供的方法，通过对多路待混流的原始直播流及混合直播流进行流质量分析，并在判断出混合直播流的流质量结果及任一路待混流的原始直播流的流质量结果符合预设条件的情况下，进一步获取混流质量影响参数，实现有针对性地获取，节省资源，利用混流质量影响参数综合判断直播混流服务是否能够继续支撑更多的混流服务，在确定直播混流服务对应的服务资源不足的情况下，动态启动新的直播混流服务，实现了混流资源按需分配，有效提高了混流质量，避免由于混流质量不佳而导致用户观看出现卡顿现象，影响用户观看体验，同时也进一步提高了直播混流服务的服务资源利用率。
189.图4示出了根据本技术中的一个实施例的直播混流服务动态调整装置的结构示意图。直播混流服务基于容器化部署实现，如图4所示，该装置包括：获取模块401、第一判断模块402、动态调整模块403。
190.获取模块401，适于针对启动的直播混流服务，获取直播混流服务对应的混流质量影响参数；
191.第一判断模块402，适于根据混流质量影响参数判断直播混流服务对应的服务资源是否充足；
192.动态调整模块403，适于若判断出直播混流服务对应的服务资源不足，则动态启动新的直播混流服务，以利用新启动的直播混流服务进行混流处理。
193.可选地，装置还包括：分析模块，适于对多路待混流的原始直播流及混合直播流进行直播流流质量分析，得到多路待混流的原始直播流及混合直播流对应的流质量结果，其中，混合直播流是对多路待混流的原始直播流进行混流处理而生成的；
194.第二判断模块，适于判断混合直播流的流质量结果及任一路待混流的原始直播流的流质量结果是否符合预设条件。
195.可选地，流质量结果包括：流质量异常及流质量异常时段；或者，流质量结果包括：流质量正常。
196.可选地，预设条件进一步包括：混合直播流的流质量异常、任一路待混流的原始直播流的流质量异常且混合直播流与任一路待混流的原始直播流非同时段流质量异常，或者，混合直播流的流质量异常且多路待混流的原始直播流的流质量均正常。
197.可选地，第二判断模块进一步适于：判断混合直播流的流质量结果是否为流质量异常；
198.若混合直播流的流质量结果为流质量异常，则判断是否存在任一路待混流的原始直播流的流质量结果为流质量异常；
199.若存在任一路待混流的原始直播流的流质量结果为流质量异常，则判断该待混流的原始直播流对应的流质量异常时段与混合直播流对应的流质量异常时段是否相同；
200.若流质量异常时段不相同或者若不存在任一路待混流的原始直播流的流质量结果为流质量异常，则获取直播混流服务对应的混流质量影响参数。
201.可选地，分析模块进一步适于：在任一流质量分析周期内，获取n个流质量采集点，相邻流质量采集点之间的时间间隔为预设值；根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算直播流的流质量参数；
202.若流质量参数大于或等于预设直播流质量阈值，则确定流质量结果为流质量正常；
203.若流质量参数小于预设直播流质量阈值，则确定流质量结果为流质量异常，并将流质量采集点对应的时间段确定为流质量异常时段。
204.可选地，分析模块进一步适于：针对每个质量采集点，根据流质量采集点对应的每秒传输帧数及流质量分析周期对应的平均每秒传输帧数计算流质量采集点对应的卡顿值；
205.若卡顿值大于或等于预设卡顿阈值，则将该流质量采集点确定为卡顿点；
206.根据卡顿点数及n计算直播流的流质量参数。
207.可选地，混流质量影响参数包括：带宽使用率、cpu使用率、内存使用率、丢包率、当前承载流数、直播混流服务质量。
208.可选地，获取模块进一步适于：统计流质量正常的混合直播流对应的第一数量及总的混合直播流对应的第二数量；
209.根据第一数量及第二数量计算直播混流服务对应的直播混流服务质量。
210.可选地，获取模块进一步适于：统计接收到的数据包对应的第三数量以及获取直播混流服务发送的数据包对应的第四数量；
211.根据第三数据量和第四数据量计算丢包率。
212.可选地，装置还包括：计算模块，适于动态调整向直播混流服务分发的原始直播流的第五数量，计算在分发第五数量的原始直播流时直播混流服务对应的混流服务使用率；
213.根据第五数量及第五数据对应的混流服务使用率确定斜率计算点；
214.若当前斜率计算点与相邻的斜率计算点之间的斜率大于预设斜率阈值，则将相邻的斜率计算点对应的第五数量确定为直播混流服务对应的预设承载流阈值。
215.可选地，计算模块进一步适于：根据带宽使用率、cpu使用率及内存使用率计算在分发第五数量的原始直播流时直播混流服务对应的混流服务使用率。
216.可选地，第一判断模块进一步适于：根据如下至少一个判断条件确定直播混流服务对应的服务资源是否充足：判断带宽使用率是否小于预设带宽使用率阈值；和/或
217.判断cpu使用率是否小于预设cpu使用率阈值；和/或
218.判断内存使用率是否小于预设内存使用率阈值；和/或
219.判断丢包率是否小于预设丢包率阈值；和/或
220.判断当前承载流数是否小于预设承载流阈值；和/或
221.判断直播混流服务质量是否大于或等于预设直播混流服务质量阈值；
222.若任一判断条件不满足则确定直播混流服务对应的服务资源不充足；
223.若所有判断条件都满足，则确定直播混流服务对应的服务资源充足。
224.可选地，第一判断模块还适于：根据混流质量影响参数判断直播混流服务对应的服务资源是否正在使用，若未使用，则动态缩减直播混流服务。
225.可选地，第一判断模块还适于：根据如下至少一个判断条件确定直播混流服务对应的服务资源是否正在使用：判断带宽使用率是否为0；和/或
226.判断cpu使用率是否为0；和/或
227.判断内存使用率是否为0；和/或
228.判断当前承载流数是否为0；
229.若任一判断条件不满足，则确定直播混流服务对应的服务资源正在使用；
230.若所有判断条件都满足，则确定直播混流服务对应的服务资源未使用。
231.可选地，装置还包括：调度模块，适于若判断出多个直播混流服务对应的服务资源充足，则将多路待混流的原始直播流调度至当前承载流数最多的直播混流服务上。
232.可选地，直播混流服务基于容器化部署实现具体为：将直播混流服务转化为对应的二进制文件；启动二进制文件以完成直播混流服务的容器化部署。
233.根据本技术实施例提供的装置，利用混流质量影响参数综合判断直播混流服务是否能够继续支撑更多的混流服务，在确定直播混流服务对应的服务资源不足的情况下，动态启动新的直播混流服务，实现了混流资源按需分配，有效提高了混流质量，避免由于混流质量不佳而导致用户观看出现卡顿现象，影响用户观看体验，同时也进一步提高了直播混流服务的服务资源利用率。
234.本技术实施例还提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的直播混流服务动态调整方法。
235.图5示出了根据本技术中的一个实施例的计算设备的结构示意图，本技术具体实施例并不对计算设备的具体实现做限定。
236.如图5所示，该计算设备可以包括：处理器(processor)502、通信接口(communications interface)504、存储器(memory)506、以及通信总线508。
237.其中：处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。
238.通信接口504，用于与其它设备比如客户端或其它服务器等的网元通信。
239.处理器502，用于执行程序510，具体可以执行上述直播混流服务动态调整方法实施例中的相关步骤。
240.具体地，程序510可以包括程序代码，该程序代码包括计算机操作指令。
241.处理器502可能是中央处理器cpu，或者是特定集成电路asic(application specific integrated circuit)，或者是被配置成实施本技术实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个cpu；也可以是不同类型的处理器，如一个或多个cpu以及一个或多个asic。
242.存储器506，用于存放程序510。存储器506可能包含高速ram存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
243.程序510具体可以用于使得处理器502执行上述任意方法实施例中的直播混流服务动态调整方法。程序510中各步骤的具体实现可以参见上述直播混流服务动态调整实施
例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。
244.在此提供的算法或显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本技术实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本技术的内容，并且上面对特定语言所做的描述是为了披露本技术的最佳实施方式。
245.在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本技术的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
246.类似地，应当理解，为了精简本技术并帮助理解各个发明方面中的一个或多个，在上面对本技术的示例性实施例的描述中，本技术实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本技术要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本技术的单独实施例。
247.本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
248.此外，本领域的技术人员能够理解，尽管在此的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本技术的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
249.本技术的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本技术实施例的一些或者全部部件的一些或者全部功能。本技术还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本技术的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
250.应该注意的是上述实施例对本技术进行说明而不是对本技术进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，
不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本技术可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。上述实施例中的步骤，除有特殊说明外，不应理解为对执行顺序的限定。