CN110113641B - 视频数据的传输方法、装置、边缘服务节点及介质 - Google Patents

Abstract

本公开提供了一种视频数据的传输方法、装置、边缘服务节点及介质。该方法包括：缓存从视频数据发送端要发送到视频数据接收端的视频数据；获取视频数据发送端和视频数据接收端之间的信道状态信息；当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码。本公开实施例缓存要发送到视频数据接收端的视频数据，自动监测发送端和接收端之间的信道状态信息，并当信道状态信息指示的信道状态差时，发送缓存的视频数据的降容量版本，保证视频播放的流畅度，避免卡顿。

Description

视频数据的传输方法、装置、边缘服务节点及介质

技术领域

本公开涉及计算机及通信技术领域，具体而言，涉及一种视频数据的传输方法、装置、边缘服务节点及介质。

背景技术

随着信息技术的快速发展，信息的表现形式和传输方式已经发生改变：从传统的文字(如：书籍、报纸)和音频(如：广播)等方式，转变成具有生动表现力且具有更多信息量的视频方式。如今的电视和互联网将各类影视节目、新闻、广告、聊天、教育以及游戏等等丰富的综合性资源以视频形式进行展现共享，从而视频已经成为人们学习、社交以及休闲娱乐而不可替代的重要方式。

然而，由于视频容量大，当接收端网络状态不好时，难以快速处理并显示接收到的视频数据，造成接收端观看的卡顿。

发明内容

本公开的一个目的在于提出一种视频数据的传输方法、装置、边缘服务节点及介质，能够提高视频播放的流畅度，减少卡顿。

根据本公开实施例的一方面，公开了一种视频数据的传输方法，所述方法包括：

缓存从视频数据发送端要发送到视频数据接收端的视频数据；

获取视频数据发送端和视频数据接收端之间的信道状态信息；

当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；

将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码。

在一个实施例中，所述缓存从视频数据发送端要发送到视频数据接收端的视频数据，包括：在预定视频播放时间窗口中，缓存从视频数据发送端要发送到视频数据接收端的视频数据，其中，在该预定视频播放时间窗口中，按照先进先出缓存方式进行缓存。

在一个实施例中，所述预定视频播放时间窗口的大小预先按照以下方式设置：

从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积。

在一个实施例中，所述历史卡顿日志按照以下方式生成：

接收所述视频数据接收端响应于检测到卡顿开始而发送的卡顿开始通知消息；

触发预设的计时器开始计时；

接收所述视频数据接收端响应于检测到卡顿停止而发送的卡顿停止通知消息；

触发预设的计时器停止计时；

将停止计时时计时器的计时作为一次卡顿记录的卡顿时长，记录到该视频数据接收端的历史卡顿日志。

在一个实施例中，所述预定视频播放时间窗口的大小预先按照以下方式设置：

从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

计算所述最长的卡顿时长与预定比例的乘积；

基于所述乘积、以及缓存所述视频数据的视频处理服务器的最大缓存容量，设置所述预定视频播放时间窗口的大小。

在一个实施例中，所述基于所述乘积、以及缓存所述视频数据的视频处理服务器的最大缓存容量，设置所述预定视频播放时间窗口的大小，包括：

按照所述乘积和所述最大缓存容量的加权和，设置所述预定视频播放时间窗口的大小。

在一个实施例中，所述获取视频数据发送端和视频数据接收端之间的信道状态信息，包括：

调用预先设置的电信网络能力获取服务，所述电信网络能力获取服务用于基于视频数据发送端和视频数据接收端之间的通信，确定视频数据发送端和视频数据接收端之间的信道状态信息。

在一个实施例中，所述信道状态信息包括所述视频数据发送端和视频数据接收端之间的信道上的丢包率，所述丢包率通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率。

在一个实施例中，所述信道状态信息包括所述视频数据发送端和视频数据接收端之间的信道上的平均传输延迟，所述平均传输延迟通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间的差除以2，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟。

在一个实施例中，所述信道状态信息包括基于所述视频数据发送端和视频数据接收端之间的信道上的丢包率和平均传输延迟确定的信道状态分数，所述信道状态分数通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率；

根据丢包率，确定第一分数，其中所述第一分数与丢包率成反相关关系；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟；

根据平均传输延迟，确定第二分数，其中所述第二分数与平均传输延迟成反相关关系；

基于第一分数和第二分数，确定信道状态分数。

在一个实施例中，所述基于第一分数和第二分数，确定信道状态分数，包括：将第一分数和第二分数的加权和，确定为信道状态分数。

在一个实施例中，所述第一预定条件包括：所述信道状态分数低于预定信道状态分数阈值。

在一个实施例中，所述获取缓存的视频数据的降容量版本包括以下中的任一项：

缓存的视频数据的I帧；

缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧。

在一个实施例中，所述降容量版本包括第一降容量版本和第二降容量版本，所述当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，包括：

当所述信道状态信息满足第二预定条件时，获取缓存的视频数据的第一降容量版本，其中第二预定条件指示的信道状态比第一预定条件指示的信道状态差；

当所述信道状态信息满足第一预定条件，但不满足第二预定条件时，获取缓存的视频数据的第二降容量版本，其中第二降容量版本的传输容量高于第一降容量版本的传输容量。

在一个实施例中，所述第一降容量版本包括缓存的视频数据的I帧，所述第二降容量版本包括缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧。

在一个实施例中，所述缓存从视频数据发送端要发送到视频数据接收端的视频数据，包括：

接收从视频数据发送端要发送到视频数据接收端的数据；

从接收的数据中过滤出视频数据；

缓存过滤出的视频数据。

在一个实施例中，所述从接收的数据中过滤出视频数据包括：

按照预定规则，基于接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项，从接收的数据中过滤出视频数据，其中，所述预定规则指示接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项与视频数据的对应关系。

在一个实施例中，所述缓存从视频数据发送端要发送到视频数据接收端的视频数据，包括：将从视频数据发送端要发送到视频数据接收端的视频数据，与所述视频数据接收端的标识关联缓存；

所述获取缓存的视频数据的降容量版本，包括：获取与该信道状态信息对应的视频数据接收端标识关联缓存的降容量版本。

在一个实施例中，所述缓存从视频数据发送端要发送到视频数据接收端的视频数据，包括：

从多个候选视频处理服务器中选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器；

将所述视频数据缓存到选择的视频处理服务器。

在一个实施例中，所述从多个候选视频处理服务器中选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：

获取各候选视频处理服务器的已缓存视频数据大小；

获取各候选视频处理服务器与视频数据接收端的距离；

基于各候选视频处理服务器的已缓存视频数据大小、和所述距离，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述基于各候选视频处理服务器的已缓存视频数据大小、和所述距离，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：

基于各候选视频处理服务器的已缓存视频数据大小，确定第三分数，其中第三分数与所述已缓存视频数据大小成反相关关系；

基于各候选视频处理服务器的所述距离，确定第四分数，其中第四分数与所述距离成反相关关系；

基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：将所述加权和最大的视频处理服务器，作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：将所述加权和超过预定加权和阈值的视频处理服务器中，随机选择一个，作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，在获取视频数据发送端和视频数据接收端之间的信道状态信息之后，所述方法还包括：

当所述信道状态信息不满足第一预定条件时，获取缓存的视频数据，

将获取的视频数据发送给视频数据接收端，以供所述视频数据接收端解码。

在一个实施例中，所述获取视频数据发送端和视频数据接收端之间的信道状态信息是定期执行的。在将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码之后，所述方法还包括：

当获取到的信道状态信息由不满足第一预定条件转变为满足第一预定条件时，获取缓存的视频数据；

将获取的视频数据发送给视频数据接收端，以供所述视频数据接收端解码。

根据本公开实施例的一方面，公开了一种视频数据的传输装置，包括：

缓存单元，用于缓存从视频数据发送端要发送到视频数据接收端的视频数据；

信道状态信息获取单元，用于获取视频数据发送端和视频数据接收端之间的信道状态信息；

降容量版本获取单元，用于当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；

降容量版本发送单元，用于将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码。

根据本公开实施例的一方面，公开了一种边缘服务节点，包括：存储器，存储有计算机可读指令；处理器，读取存储器存储的计算机可读指令，以执行如上所述的方法。

根据本公开实施例的一方面，公开了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行如上所述的方法。

本公开的实施例提供的技术方案可以包括以下有益效果：本公开提供的技术方案，通过在视频数据没有发送到视频数据接收端之前，中途缓存所述视频数据，并且监视视频数据发送端和视频数据接收端之间的信道状态信息，当所述信道状态信息指示的信道状态差时，获取缓存的视频数据的降容量版本发送给视频数据接收端，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，这样可以使得在视频数据接收端显示时不卡顿，同时保证视频数据的解码。本公开实施例不依赖于视频数据接收端监测卡顿，避免了视频数据接收端监测卡顿存在的滞后性，能够反映信道实时的状况。另外，它只需要在视频数据接收端和视频数据发送端之间增加一个执行上述功能的部件，不需要维护一个专门的控制系统。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1示出了根据本公开一个实施例的视频数据传输方法应用的系统构架图。

图2A-2C示出了根据本公开一个实施例的视频数据传输方法应用在云游戏的应用场景下的界面图。

图3示出了根据本公开一个实施例的视频数据传输方法的流程图。

图4示出了根据本公开一个实施例的设置预定视频播放时间窗口的流程图。

图5示出了根据本公开一个实施例的设置预定视频播放时间窗口的流程图。

图6示出了根据本公开一个实施例的步骤S310的详细流程图。

图7示出了根据本公开另一个实施例的步骤S310的详细流程图。

图8示出了根据本公开另一个实施例的步骤S3101’的详细流程图。

图9示出了根据本公开另一个实施例的步骤S31013’的详细流程图。

图10示出了根据本公开一个实施例的视频数据传输方法应用在云游戏的应用场景下的交互流程图。

图11示出了根据本公开一个实施例的视频数据传输方法应用在云游戏的应用场景下的逻辑判断过程流程图。

图12示出了根据本公开一个实施例的视频数据的传输装置的框图。

图13示出了根据本公开一个实施例的边缘服务节点的硬件图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些示例实施方式使得本公开的描述将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。

此外，所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的示例实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、步骤等。在其它情况下，不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本公开的各方面变得模糊。

附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

下面先参照图1描述一下本公开实施例的视频数据传输方法所应用的体系构架。

如图1所示，本发明应用的系统架构可以包括视频数据接收端101、无线基站102、边缘服务节点103、移动核心网络设备106和视频数据发送端107。视频数据发送端107是发送视频数据的设备，其可以是服务器，也可以是智能手机、是平板电脑、便携式计算机、台式计算机等用户终端。视频数据接收端101是接收视频数据的设备，其可以是智能手机，还可以是平板电脑、便携式计算机、台式计算机等等。

边缘服务节点103是分布在靠近用户的位置(即接近视频数据接收端101的位置)的设备，它是本公开实施例的视频数据的传输方法的执行主体。它插入在视频数据接收端101和视频数据发送端107之间的信道上靠近视频数据接收端101的一侧，起到缓存要发送给视频数据接收端101的视频数据，并当检测到信道状态差时获取缓存的视频数据的降容量版本给视频数据接收端101发送的作用。它可以包括视频处理服务器104和移动边缘计算服务器105。移动边缘计算服务器105是在靠近用户(即靠近视频数据接收端101)的位置为用户进行各种贴近用户的服务时处理服务中需要的各种计算的设备，包括本公开实施例如下所述的检测视频数据发送端和视频数据接收端之间的信道状态信息、以及从视频数据发送端发送到视频数据接收端的数据流中过滤出视频数据。视频处理服务器104是执行数据视频在发送到视频数据接收端101之前进行的各种处理的设备，包括本公开实施例如下所述的缓存要发送到视频数据接收端的视频数据、获取缓存的视频数据的降容量版本等。虽然图1中示出边缘服务节点103包括视频处理服务器104和移动边缘计算服务器105两个独立的硬件设备，但实际上，边缘服务节点103也可以是一个独立的硬件设备，其能够执行视频处理服务器104和移动边缘计算服务器105的功能，视频处理服务器104和移动边缘计算服务器105的硬件并不存在。

移动核心网设备106是部署在视频数据接收端101和视频数据发送端107之间的信道上靠近核心网一侧(靠近视频数据发送端107，如果是从核心网向边缘用户发送视频数据的话)的设备，它负责将核心网中产生的数据流(如核心网中的视频数据发送端107产生的数据流)发送到边缘用户侧(视频数据接收端101侧)。视频数据发送端107通过SGi接口与移动核心网设备106连接。

视频数据接收端101通过无线链路接入无线基站102，并经由边缘服务节点103、移动核心网设备106与视频数据发送端107建立信道连接。应该理解，图1中的视频数据接收端101、无线基站102、视频处理服务器104、视频数据发送端107的数目仅仅是示意性的。根据实现需要，可以具有任意数目的视频数据接收端101、无线网络接入点102、视频处理服务器104和视频数据发送端107。

下面结合图2A-2C描述根据本公开实施例的视频数据传输方法应用在云游戏应用场景下的界面图。

图2A-2C是视频数据接收端的界面示意图。在云游戏的应用场景中，视频数据发送端107是云游戏服务器。云游戏服务器完成游戏数据的处理及游戏图像的渲染，并将渲染后的视频数据通过边缘服务节点103转发给视频数据接收端101。边缘服务节点103接收到该视频数据，会将其先缓存起来。具体地说，图1的移动边缘计算服务器105将视频数据缓存到视频处理服务器104。同时，移动边缘计算服务器105还检测云游戏服务器和作为视频数据接收端101的用户终端之间的信道状态。如果视频数据接收端101侧网络状况良好，移动边缘计算服务器105直接将缓存的视频数据取出，发送给用户终端。在用户终端侧将会看到图2A所示的画面。

如果移动边缘计算服务器105检测到视频数据接收端101侧网络状况不好，移动边缘计算服务器105直接将缓存的视频数据的I帧取出，发给用户终端。视频数据中原来有I、P、B三种帧，其中I帧是帧间压缩编码中的重要帧。它是一个全帧压缩的编码帧，解码时仅用I帧的数据就可重构完整图像。传输I帧相比于传输整个的视频数据，大大减少了传输容量，但又可以保证视频数据解码。图2B所示的是仅传输I帧的情况下用户终端看到的画面。如图2A相比，用户能看清画面，但清晰度变差。

由于移动边缘计算服务器105检测信道状况是定期的，当其检测到视频数据接收端101侧网络状况又变好，其又将缓存的视频数据整个取出(而不是仅取出I帧)，发给用户终端。用户终端上看到的是如图2C所示的画面，其与图2A的清晰度是一致的。

根据本公开的一个实施例，提供了一种视频数据的传输方法。在边缘服务节点103包括视频处理服务器104和移动边缘计算服务器105的情况下，该方法是由移动边缘计算服务器105执行的。视频处理服务器104是步骤S310中视频数据缓存到的对象。在边缘服务节点103不分视频处理服务器104和移动边缘计算服务器105的情况下，该方法是由边缘服务节点103整体执行的。

如图3所示，所述方法包括：

步骤S310、缓存从视频数据发送端要发送到视频数据接收端的视频数据；

步骤S320、获取视频数据发送端和视频数据接收端之间的信道状态信息；

步骤S330、当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；

步骤S340、将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码。

下面对这些步骤进行详细描述。

在步骤S310中，视频是指连续的图像帧构成的序列。视频数据是将视频编码后得到的数据。视频编码是为了便于传输，将视频数据解码可以还原视频。

从视频数据发送端要发送到视频数据接收端的视频数据包括两种情况。一种情况是视频数据发送端本身产生了视频数据，将其发送到视频数据接收端。另一种情况是当视频数据接收端需要获取视频数据时，则向视频数据发送端发送请求，视频数据发送端在接收到请求后，产生所请求的视频数据，并将视频数据发送至视频数据接收端。

在步骤S320中，获取视频数据发送端和视频数据接收端之间的信道状态信息。

信道状态信息就是表示通信信道处于何种状态的情形的信息，例如信道拥塞、信道空闲、信道完全不能用、信道能用但是产生丢包、信道能用但是产生延迟等。后文将会信道状态信息的种类进行详细描述。

在步骤S330中，第一预定条件是指示信道状态差的条件，具体情形在后文中详述。

降容量版本是指传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码的版本。由于传输容量低，可以在信道状态差时减少卡顿。由于能够保证解码，保证用户能看到画面中的基本内容，仅仅是清晰度变差。

在步骤S340中，将所述降容量版本发送给视频数据接收端后，所述视频数据接收端解码后可以看到视频的基本内容，尽管清晰度变差。

在一个实施例中，步骤S310中缓存视频数据可以是无限缓存，即只要是从视频数据发送端要发送到视频数据接收端的视频数据，都缓存在一个缓冲池中。

在另一个实施例中，可以采用固定时间窗口缓存的方式，即只保留缓存的预定窗口长度的视频数据，新进入缓存的视频数据会挤走最早进入该窗口的视频数据。

在该实施例中，步骤S310包括：在预定视频播放时间窗口中，缓存从视频数据发送端要发送到视频数据接收端的视频数据，其中，在该预定视频播放时间窗口中，按照先进先出缓存方式进行缓存。

视频播放时间窗口是指一个时间区间，包括时间起始点和时间结束点，分别指示缓存的视频数据代表的视频的开始的时间点和结束的时间点。该时间区间长度是一定的。当按照先进先出缓存方式进行缓存时，新进入该时间窗口的视频数据会挤掉最早进入该时间窗口的相等时间长度的视频数据。例如，视频播放时间窗口是10ms,已经存储满了视频数据，如果新进入该时间窗口2ms的视频数据，会挤走该时间窗口中最先进入的2ms的视频数据，使存储的视频数据仍然维持10ms的长度。

该实施例的优点是，避免缓存空间的浪费。边缘服务节点103面对很多用户终端进行服务，其中的存储空间非常宝贵。如果所有视频数据都无限制存储，会造成存储空间不足，导致边缘服务节点103处理能力受到影响，甚至崩溃。

如果预定视频播放时间窗口设置得过大，会导致占用边缘服务节点103过大的存储空间，造成资源浪费，如果太小，发生信道状况变差发生卡顿时，无法保证存储的视频数据量足够消除卡顿。因此，在一个实施例中，统计历史上视频数据接收端的最长卡顿时长，按照该时长设置窗口大小，保证了对于大多数卡顿，窗口中存储的视频数据量都足够消除卡顿。

如图4所示，在一个实施例中，所述预定视频播放时间窗口的大小预先按照以下方式设置：

步骤S410、从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

步骤S420、确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

步骤S430、将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积。

步骤S410中，历史卡顿日志是记录历史上视频数据接收端发生的卡顿的具体参数的日志，这些具体参数可以包括卡顿起始时间、结束时间、卡顿时长、卡顿严重程度、消除措施等。它的前提是，视频数据接收端发生卡顿和结束卡顿时都要向边缘服务节点103报告，摘要边缘服务节点103才能记录形成日志。在边缘服务节点103包括视频处理服务器104和移动边缘计算服务器105的情况下，视频数据接收端发生卡顿和结束卡顿时都要向移动边缘计算服务器105报告。

在一个实施例中，所述历史卡顿日志按照以下方式生成：

接收所述视频数据接收端响应于检测到卡顿开始而发送的卡顿开始通知消息；

触发预设的计时器开始计时；

接收所述视频数据接收端响应于检测到卡顿停止而发送的卡顿停止通知消息；

触发预设的计时器停止计时；

将停止计时时计时器的计时作为一次卡顿记录的卡顿时长，记录到该视频数据接收端的历史卡顿日志。

在该实施例中，视频数据接收端检测卡顿，当检测到卡顿开始时，向边缘服务节点103发送一个卡顿开始通知消息。在一个实施例中，卡顿开始通知消息的特定字段中含有一个卡顿开始标志位。当边缘服务节点103接收到来自视频数据接收端的消息，而该消息中特定字段中含有所述卡顿开始标志位时，确定接收到卡顿开始通知消息，触发预设的计时器开始计时。

在一个实施例中，所述计时器与视频数据接收端对应设置。接收到来自一个视频数据接收端的卡顿开始通知消息后，触发与该视频数据接收端对应的计时器开始计时。

在一个实施例中，卡顿停止通知消息的特定字段中含有一个卡顿停止标志位。当边缘服务节点103接收到来自视频数据接收端的消息，而该消息中特定字段中含有所述卡顿停止标志位时，确定接收到卡顿停止通知消息，触发预设的计时器停止计时。具体地，可以触发与该视频数据接收端对应的计时器开始计时。

然后，将停止计时时计时器的计时作为一次卡顿记录的卡顿时长，记录到该视频数据接收端的历史卡顿日志。历史卡顿日志可能还包括卡顿起始时间、结束时间、卡顿严重程度、消除措施等，它们通过其它方式获取，由于其在本公开实施例中不使用，故省去对它们的讨论。

上述历史卡顿日志的生成方式以简单易行的方式快速获得日志中的卡顿时长，提高获得日志卡顿时长的效率。

由于历史卡顿日志中记录了视频数据接收端的所有卡顿记录，从中可以获得该视频数据接收端历史上所有卡顿记录的卡顿时长。

获得了所有卡顿记录的卡顿时长后，步骤S420中，就可以找到其中最长的卡顿时长。在步骤S430中，设置一个预定比例，将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积。之所以乘以预定比例，是因为，如果完全按照历史上最长的一次卡顿占用的时长来设定预定视频播放时间窗口，该窗口基本上会大于一般情况下所有卡顿占用的时间，该窗口内缓存的视频数据足够一般情况下卡顿时的视频恢复，但历史上最长的一次卡顿可能是一次很异常的情况，一般发生概率很小，这样得到的窗口大小可能造成存储资源的浪费。为了不浪费存储资源，又能在大多情况下保证该窗口内缓存的视频数据足够大多数情况下卡顿时的视频恢复，将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积。

另外，预定视频播放时间窗口也可以结合视频处理服务器的最大缓存容量来设置。如果视频处理服务器中缓存容量很大，预定视频播放时间窗口设置得大些，可能对视频处理服务器的处理能力影响不大。如果视频处理服务器中缓存容量很小，预定视频播放时间窗口设置得大些，可能对视频处理服务器的处理能力产生比较大的影响。

如图5所示，在一个实施例中，所述预定视频播放时间窗口的大小预先按照以下方式设置：

步骤S410、从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

步骤S420、确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

步骤S431、计算所述最长的卡顿时长与预定比例的乘积；

步骤S440、基于所述乘积、以及缓存所述视频数据的视频处理服务器的最大缓存容量，设置所述预定视频播放时间窗口的大小。

上述步骤S410-420与图4中的步骤S410-420相同，步骤S431是图4中的步骤S430的一部分，故不赘述。

在步骤S440中，要结合视频数据接收端一般卡顿的时长、和视频处理服务器的最大缓存容量两者，来设置所述预定视频播放时间窗口的大小。即，基于所述乘积、以及缓存所述视频数据的视频处理服务器的最大缓存容量，设置所述预定视频播放时间窗口的大小。

该实施例的优点是，使得窗口的大小设置既考虑到了视频数据接收端一般卡顿的时长，从而在大多数情况下缓存的视频数据能满足恢复卡顿的要求，同时又考虑到视频处理服务器的容量的限制，不至于影响到视频处理服务器的处理能力。

步骤S440有多种实现方式。

在一种实现方式中，可以根据缓存所述视频数据的视频处理服务器的最大缓存容量确定一个微调因子(可正可负)，然后在所述乘积基础上加上所述微调因子，得到预定视频播放时间窗口的大小。根据缓存所述视频数据的视频处理服务器的最大缓存容量确定一个微调因子，可以采用查找预先设置的最大缓存容量与微调因子对应关系表的方式。这样，微调因子反映了缓存所述视频数据的视频处理服务器的最大缓存容量的影响，使得最后的窗口大小既与所述乘积有关，又与所述最大缓存容量有关。

在另一个实现方式中，步骤S440包括：按照所述乘积和所述最大缓存容量的加权和，设置所述预定视频播放时间窗口的大小。可以对所述乘积和所述最大缓存容量设置不同的权重，权重的高低反映了视频数据接收端一般卡顿的时长的影响、以及视频处理服务器的容量的限制的影响的不同重要程度。该实施例的优点是，可以通过调节权重的方式，灵活控制视频数据接收端一般卡顿的时长的影响、以及视频处理服务器的容量的限制的影响的重要程度。

在一个实施例中，步骤S320包括：调用预先设置的电信网络能力获取服务，所述电信网络能力获取服务用于基于视频数据发送端和视频数据接收端之间的通信，确定视频数据发送端和视频数据接收端之间的信道状态信息。

该实施例采用服务化的体系构架，即，预先针对电信网络中的各种可能产生的需求，定义好若干服务，每种服务设置在一个电信网络节点中，包括一系列预先编程好的动作序列，每种服务能够满足一种上述需求。服务化体系构架目前已在电信网络中应用。这些服务中的一种是电信网络能力获取服务。其能够自动监测视频数据发送端和视频数据接收端之间的通信，确定视频数据发送端和视频数据接收端之间的信道状态信息。因此，在一个实施例中，可以直接调用该服务，获取视频数据发送端和视频数据接收端之间的信道状态信息。该实施例的优点是简单易行。

在一个实施例中，电信网络能力获取服务存在于移动边缘计算服务器105中，因此，直接调用移动边缘计算服务器105以及存在的该服务即可。在另一个实施例中，该服务存在于其它边缘节点或核心节点中，设置查询服务器(未示)，其中维护各种服务与存储该服务的节点的对应关系列表。向查询服务器发送服务所在节点的查询请求，由查询服务器返回查询到的服务所在节点，然后向该查询到的服务所在节点发送电信网络能力获取服务的调用请求，调用该服务。

除了采用直接调用电信网络能力获取服务的方式，也可以由边缘服务节点103或移动边缘计算服务器105自身确定信道状态信息。信道状态信息就是表示通信信道处于何种状态的情形的信息，其可以用丢包率表示，也可以用平均传输延迟表示，也可以用综合考虑丢包率和平均传输延迟得到的信道状态分数表示。

丢包率是单位时间内传输的包丢失的百分比，即单位时间内传输丢失的包的个数除以单位时间内传输的包的个数。在信道状态信息用丢包率表示的情况下，所述丢包率可以通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率。

为了统计丢包，必须要求边缘服务节点103或移动边缘计算服务器105记录发过去的包，同时要求视频数据接收端每接收到一个包，要向边缘服务节点103或移动边缘计算服务器105发送一个确认响应。如果在足够长的时间内没有收到确认响应，就认为该包已经丢失。用单位时间丢包的个数除以单位时间已发包的个数，就得到了丢包率。

边缘服务节点103或移动边缘计算服务器105每次转发视频数据包，要维护一个发包记录，其中关联记录转发过去的包的标识和转发时间。包的标识是为了与接收到确认响应的包比对，转发时间是为了确定衡量包已经丢失的截止时间点，即转发时间加上预定间隔时间。边缘服务节点103或移动边缘计算服务器105还维护一个收包记录，每次接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识，如果该标识与发包记录中的一个包的标识对应，则说明该包没有丢失。如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包。然后，用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，可以得到丢包率。

该实施例的优点是，用丢包率表征信道状态，充分体现了信道的可信度，即发出去的包是否由于信道质量差导致丢失。

平均传输延迟是从边缘服务节点103或移动边缘计算服务器105发送视频数据包到视频数据接收端101所用的时间，它反映了边缘服务节点103或移动边缘计算服务器105与视频数据接收端101之间的信道传输速度。在信道状态信息用平均传输延迟表示的情况下，所述平均传输延迟可以通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间的差除以2，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟。

上述过程的前两个步骤与丢包率的确定过程的前两个步骤的差别仅在于在收包记录中还记录确认响应接收时间，故不赘述。由于在发包记录中记录有包的转发时间，在收包记录中可以找到同一个标识的包的确认响应接收时间，两者的差是在边缘服务节点103或移动边缘计算服务器105与视频数据接收端101之间发送一个包，并接收一个响应的时间，相当于一去一返的时间，将其除以2，就是该包从边缘服务节点103或移动边缘计算服务器105传输到视频数据接收端101的时间，即传输延迟。然后，将针对发包记录中的各包的标识得到的传输延迟求平均，就得到了平均传输延迟。

该实施例的优点是，用平均传输延迟表征信道状态，体现了信道的效率，即，数据包发到信道上传输得是否快。

在另一个实施例中，可以用基于所述视频数据发送端和视频数据接收端之间的信道上的丢包率和平均传输延迟确定的信道状态分数来表征信道状态信息。所述信道状态分数通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率；

根据丢包率，确定第一分数，其中所述第一分数与丢包率成反相关关系；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟；

根据平均传输延迟，确定第二分数，其中所述第二分数与平均传输延迟成反相关关系；

基于第一分数和第二分数，确定信道状态分数。

上述过程中确定丢包率和平均传输延迟的过程与前述过程一致。下面描述根据丢包率确定第一分数、根据平均传输延迟确定第二分数的方法。

在一个实施例中，根据丢包率确定第一分数可以采取查找预先设置的丢包率与第一分数对应关系表的方式，在该表中，预先设置成第一分数与丢包率成反相关关系。反相关是指变化趋势相反，即丢包率越高，说明信道质量越差，衡量其的第一分数越低；丢包率越低，第一分数越高。

在另一个实施例中，根据丢包率确定第一分数可以采用反比公式：

S1＝a1/L 公式1

其中，S1是第一分数，L是丢包率，a1是预先设置的正常数。

在一个实施例中，根据平均传输延迟确定第二分数可以采取查找预先设置的平均传输延迟与第二分数对应关系表的方式，在该表中，预先设置成第二分数与平均传输延迟成反相关关系。平均传输延迟越大，说明信道质量越差，衡量其的第二分数越低；平均传输延迟越小，第二分数越高。

在另一个实施例中，根据平均传输延迟确定第二分数可以采用反比公式：

S2＝a2/T 公式2

其中，S2是第二分数，T是平均传输延迟，a2是预先设置的正常数。

在一个实施例中，可以将第一分数和第二分数的和或平均数，确定为信道状态分数。这样做的前提是默认信道的可信度(丢包率)和信道的效率(平均传输延迟)是两个同等重要的指标。

实际中，在不同需要中，这两个指标的重要性是不同的。因此，在另一个实施例中，将第一分数和第二分数的加权和，确定为信道状态分数。第一分数和第二分数的权重是预先设置的，反映了预先对信道的可信度(丢包率)和信道的效率(平均传输延迟)的重要性的判断。这样做的好处是，可以根据不同应用需要，调节对第一分数和第二分数的权重，反映不同需求中信道的可信度(丢包率)和信道的效率(平均传输延迟)的不同重要性。

用基于所述视频数据发送端和视频数据接收端之间的信道上的丢包率和平均传输延迟确定的信道状态分数来表征信道状态信息的好处是，综合考虑了信道的可信度(丢包率)和信道的效率(平均传输延迟)对信道状态的影响，使信道状态的评价更全面。

在信道状态信息用丢包率衡量的实施例中，步骤S330中的所述第一预定条件包括：所述丢包率高于预定丢包率阈值。该丢包率阈值是预先根据经验设定的。

在信道状态信息用平均传输延迟衡量的实施例中，步骤S330中的所述第一预定条件包括：所述平均传输延迟高于预定平均传输延迟阈值。该平均传输延迟阈值是预先根据经验设定的。

在信道状态信息是基于所述视频数据发送端和视频数据接收端之间的信道上的丢包率和平均传输延迟确定的信道状态分数来衡量的实施例中，步骤S330中的所述第一预定条件包括：所述信道状态分数低于预定信道状态分数阈值。该信道状态分数阈值是预先根据经验设定的。

在步骤S330中，获取缓存的视频数据的降容量版本包括以下中的任一项：

缓存的视频数据的I帧；

缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧。

I帧又称帧内编码帧，是一种自带全部信息的独立帧，无需参考其它图像帧便可独立进行解码，可以简单理解为一张静态画面。P帧又称帧间预测编码帧，需要参考前面的I帧才能进行编码，其表示的是当前帧画面与前一帧(前一帧可能是I帧也可能是P帧)的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别生成最终画面。B帧又称双向预测编码帧，也就是B帧记录的是本帧与前后帧的差别，也就是说要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面。因此，只要把视频数据的I帧作为降容量版本，发送给视频数据接收端，就能够保证视频数据的解码，使视频数据接收端能够看到视频的基本内容，同时又降低了传输容量。但是，也可以把P帧的一部分、B帧的一部分、以及I帧一起作为降容量版本，发送给视频数据接收端，这样占用的传输容量相比于只传输I帧可能更大一些，但观看的清晰度会更高。选取的视频数据的P帧的一部分、B帧的一部分可以是根据预定规则选取的，例如预定规则规定P、B帧中每隔一个像素选取一个像素的像素值，等等。

相对于生成视频数据时生成不同清晰度的视频数据，作为降容量版本的方式，直接采用I帧，或者P帧的一部分、B帧的一部分、以及I帧，简单易行，降低了生成视频数据的视频数据发送端的处理开销。

另外，降容量版本可以不只一个。可以有不同容量的降容量版本，对应于不同的信道状态。当信道状态很差时，使用一个容量降得很低的降容量版本，应对卡顿。当信道状态不算太好，但也算不上很差时，使用一个容量比较低的降容量版本，应对卡顿。该实施例的好处是，针对各种信道状态进行不同的降容量版本的选取，在避免卡顿的同时尽量提高视频的清晰度。

在一个实施例中，所述降容量版本包括第一降容量版本和第二降容量版本，所述步骤S320包括：

当所述信道状态信息满足第二预定条件时，获取缓存的视频数据的第一降容量版本，其中第二预定条件指示的信道状态比第一预定条件指示的信道状态差；

当所述信道状态信息满足第一预定条件，但不满足第二预定条件时，获取缓存的视频数据的第二降容量版本，其中第二降容量版本的传输容量高于第一降容量版本的传输容量。

这里的所述第一降容量版本可以包括缓存的视频数据的I帧，所述第二降容量版本可以包括缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧。

第二预定条件与第一预定条件一样，也可以用丢包率、平均传输延迟、基于所述视频数据发送端和视频数据接收端之间的信道上的丢包率和平均传输延迟确定的信道状态分数等来表征。当用丢包率表征时，第二预定条件的丢包率比第一预定条件的丢包率高。当用平均传输延迟表征时，第二预定条件的平均传输延迟比第一预定条件的平均传输延迟大。当用信道状态分数表征时，第二预定条件的信道状态分数比第一预定条件的信道状态分数小。

当所述信道状态信息满足第二预定条件时，第二预定条件指示的信道状态比第一预定条件指示的信道状态差，这时要获取传输容量最低的那个降容量版本，即第一降容量版本，例如缓存的视频数据的I帧，因为这时信道状态非常差，能够让视频数据接收端顺利解码并显示，成为首要考量的因素。

当所述信道状态信息满足第一预定条件，但不满足第二预定条件时，此时信道状态虽然差，但不是非常差，可以获取一个传输容量比较低、但不是最低的降容量版本，即第二降容量版本，例如缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧，因为这时的信道状态还不是非常差，可以在让视频数据接收端顺利解码并显示的前提下，保证一定的清晰度。

如图6所示，在一个实施例中，从视频数据发送端107发送到边缘服务节点103或移动边缘计算服务器105的可能不仅是视频数据，还要音频数据和其它数据。对于视频数据，要采用S310-S340的处理过程，在可能发生卡顿时，采用降容量方式减少卡顿。对于音频数据或其它数据，少传一部分数据，可能造成整个音频错误，或无法识别等，因此，对于音频数据或其它数据要直接透传到视频数据接收端。该实施例的优点是，对要发送到视频数据接收端的不同数据采取区别的处理方式，保障了每种数据在接收端都有可接受的质量。

在该实施例中，步骤S310包括：

步骤S3101、接收从视频数据发送端要发送到视频数据接收端的数据；

步骤S3102、从接收的数据中过滤出视频数据；

步骤S3103、缓存过滤出的视频数据。

在一个实施例中，步骤S3102包括：按照预定规则，基于接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项，从接收的数据中过滤出视频数据，其中，所述预定规则指示接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项与视频数据的对应关系。

例如，该预定规则是：如果源IP地址是XXX.XXX.XXX.XXX，目的IP地址是XXX.XXX.XXX.XXX，采用的传输层协议是XXXXXXXX。当接收到视频数据发送端107发送来的数据包后，分别获取数据包中相应字段中的源IP地址、目的IP地址、传输层协议。如果这些内容与上述规则中的源IP地址、目的IP地址、传输层协议，则认为是视频数据包，对其进行缓存。

基于接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项，从接收的数据中过滤出视频数据的优点是，简单易行，提高过滤的处理效率。

另外，图1虽然示出了一个视频数据接收端101，但视频数据接收端101有可能是多个。视频数据发送端107可能会给多个不同的视频数据接收端101发送不同的视频数据。它们都存储在边缘服务节点103或视频处理服务器104中。这样，当步骤S330中获取缓存的视频数据的降容量版本时会产生不知道对应哪个存储的视频数据的问题。因此，在一个实施例中，通过将视频数据与视频数据接收端的标识对应存储的方式，解决了这一问题。

在该实施例中，步骤S310包括：将从视频数据发送端要发送到视频数据接收端的视频数据，与所述视频数据接收端的标识关联缓存。步骤S330中，所述获取缓存的视频数据的降容量版本，包括：获取与该信道状态信息对应的视频数据接收端标识关联缓存的降容量版本。

在一个实施例中，在从视频数据发送端要发送到视频数据接收端的视频数据包的特定字段中，可以含有视频数据接收端的标识，可以将该标识取出与视频数据对应存储。当获取降容量版本时，只需按照视频数据接收端的标识，获取与其对应存储的视频数据的降容量版本，解决了上述问题。

该实施例的优点是，该存储方式使得本公开实施例可以应用于同时进行要发送到不同视频数据接收端的不同视频数据的防卡顿处理的情形。

另外，图1中虽然仅示出了一个视频处理服务器104，但实际上可以由多个候选视频处理服务器。每当要缓存从视频数据发送端要发送到视频数据接收端的视频数据时，可以从这多个候选视频处理服务器中选择一个进行缓存。它的好处是，由于有众多的候选视频处理服务器可以缓存，可以当游戏终端数量变化时，针对数量一直变化的需要发给这些游戏终端的视频数据，可以灵活地从众多的候选视频处理服务器中选择视频处理服务器缓存。视频数据增加，就启动更多的候选视频处理服务器。视频数据减少，就启动更少的候选视频处理服务器。对计算资源进行弹性处理，提高计算资源利用率。

在该实施例中，如图7所示，步骤S310包括：

步骤S3101’、从多个候选视频处理服务器中选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器；

步骤S3102’、将所述视频数据缓存到选择的视频处理服务器。

在一个实施例中，步骤S3101’包括：

获取各候选视频处理服务器的已缓存视频数据大小；

基于各候选视频处理服务器的已缓存视频数据大小，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

获取各候选视频处理服务器的已缓存视频数据大小可以通过向各候选视频处理服务器发送已缓存视频数据大小的查询请求，并接收各候选视频处理服务器发送的对查询请求的应答来实现。移动边缘计算服务器105向各候选视频处理服务器发送查询请求，各候选视频处理服务器进行应答，该应答中含有当前已缓存视频数据大小。

基于各候选视频处理服务器的已缓存视频数据大小，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，可以包括：选择所述已缓存视频数据大小最小的候选视频处理服务器，作为缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。已缓存视频数据大小最小，意味着有更多存储新来的视频数据的余地。因此，基于各候选视频处理服务器的已缓存视频数据大小，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，具有使各候选视频处理服务器的存储负荷趋于均衡的作用。

在另一个实施例中，除了优先选择目前存储的数据比较少的候选视频处理服务器之外，还要考虑该候选视频处理服务器离用户的远近。如果一个候选视频处理服务器比较空闲，但其用户很远，把视频数据发送到该候选视频处理服务器缓存，在传输中要浪费很多时间，也是不经济的，因此，可以综合各候选视频处理服务器的已缓存视频数据大小、和各候选视频处理服务器与视频数据接收端的距离，来选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在该实施例中，如图8所示，步骤S3101’包括：

步骤S31011’、获取各候选视频处理服务器的已缓存视频数据大小；

步骤S31012’、获取各候选视频处理服务器与视频数据接收端的距离；

步骤S31013’、基于各候选视频处理服务器的已缓存视频数据大小、和所述距离，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在步骤S31011’中，获取各候选视频处理服务器的已缓存视频数据大小可以采用如上所述的方式。在步骤S31012’中，获取各候选视频处理服务器与视频数据接收端的距离可以采取获取各候选视频处理服务器与视频数据接收端的位置坐标，然后计算各候选视频处理服务器的位置坐标与视频数据接收端的位置坐标的距离的方式。各候选视频处理服务器的位置坐标是固定的，可以事先将其存储在移动边缘计算服务器105或边缘服务节点103中。视频数据接收端的位置坐标可以通过向视频数据接收端发送一个位置坐标的请求，并接收视频数据接收端的应答来获取。由于每个终端具有GPS等定位系统，能够将定位系统获得的自身的位置坐标放在应答中，发送给移动边缘计算服务器105或边缘服务节点103。

在一个实施例中，步骤S31013’包括：

步骤S310131’、基于各候选视频处理服务器的已缓存视频数据大小，确定第三分数，其中第三分数与所述已缓存视频数据大小成反相关关系；

步骤S310132’、基于各候选视频处理服务器的所述距离，确定第四分数，其中第四分数与所述距离成反相关关系；

步骤S310133’、基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，步骤S310131’中，基于各候选视频处理服务器的已缓存视频数据大小，确定第三分数，可以采取查找预先设置的已缓存视频数据大小与第三分数对应关系表的方式，在该表中，预先设置成第三分数与已缓存视频数据大小成反相关关系。已缓存视频数据大小越大，说明其能用于进一步存储的可能性越小，越不优选该候选视频处理服务器，第三分数越低；已缓存视频数据大小越小，第三分数越高。

在一个实施例中，步骤S310131’中，基于各候选视频处理服务器的已缓存视频数据大小，确定第三分数，可以采用反比公式：

S3＝a3/M 公式3

其中，S3是第三分数，M是已缓存视频数据大小，a3是预先设置的正常数。

在一个实施例中，步骤S310132’中，基于各候选视频处理服务器的所述距离，确定第四分数，可以采取查找预先设置的所述距离与第四分数对应关系表的方式，在该表中，预先设置成第四分数与所述距离成反相关关系。候选视频处理服务器与视频数据接收端的距离越大，说明传输耗时越长，越不优选该候选视频处理服务器，第四分数越低；候选视频处理服务器与视频数据接收端的距离越小，第四分数越高。

在一个实施例中，步骤S310132’中，基于各候选视频处理服务器的所述距离，确定第四分数，可以采用反比公式：

S4＝a4/D 公式4

其中，S4是第四分数，D是候选视频处理服务器与视频数据接收端的距离，a4是预先设置的正常数。

在一个实施例中，步骤S310133’包括：将所述加权和最大的视频处理服务器，作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。该实施例的优点是，加权和最大，说明已缓存视频数据大小和距离视频数据接收端的远近综合起来达到最佳，这样选取的视频处理服务器容易达到较佳的处理性能。

在一个实施例中，步骤S310133’包括：将所述加权和超过预定加权和阈值的视频处理服务器中，随机选择一个，作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。该实施例的优点是，只要所述加权和超过预定加权和阈值，这样的候选视频处理服务器，都认为其可以作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。在其中随机选择一个，有利于在较近的时间点都选择同一加权和最大的候选视频处理服务器，造成该候选视频处理服务器反而性能下降。

基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器的优点是，通过量化的方式，量化了各候选视频处理服务器的已缓存视频数据大小、各候选视频处理服务器与视频数据接收端的距离对选择视频处理服务器的不同影响。

在一个实施例中，在步骤S320之后，所述方法还包括：

当所述信道状态信息不满足第一预定条件时，获取缓存的视频数据；

将获取的视频数据发送给视频数据接收端，以供所述视频数据接收端解码。

第一预定条件是指示当前信道状态不佳，有可能发生卡顿的状态。当所述信道状态信息满足第一预定条件时，需要传输降容量版本以缓解卡顿。如果所述信道状态信息不满足第一预定条件，说明不会发生卡顿，可以直接获取缓存的视频数据，发送给视频数据接收端。

在一个实施例中，步骤S320是定期执行的。在步骤S340之后，所述方法还包括：

当获取到的信道状态信息由不满足第一预定条件转变为满足第一预定条件时，获取缓存的视频数据；

将获取的视频数据发送给视频数据接收端，以供所述视频数据接收端解码。

也就是说，每隔预定时间段，就会用于获取视频数据发送端和视频数据接收端之间的信道状态信息。一旦获取到的信道状态信息由不满足第一预定条件转变为满足第一预定条件，就应该停止发送降容量版本，因为降容量版本会影响观看的清晰度。如果此时的信道状态不会造成卡顿，就应该及时消除降容量措施，保证观看的清晰度。该实施例的优点是，通过定期监测信道状态，可以不断动态调节传输视频数据的版本的策略，能够自适应信道状态的变化，避免选择一种策略后无法更改。

图10示出了根据本公开一个实施例的视频数据传输方法应用在云游戏的应用场景下的交互流程图。

在云游戏的应用场景中，视频数据接收端101是游戏终端601，视频数据发送端107是云游戏服务器607。在步骤S610中，游戏终端601向云游戏服务器607发送游戏会话建立请求，云游戏服务器607向游戏终端601发送对该请求的应答，从而双方建立游戏会话。在步骤S620中，云游戏服务器607向移动边缘计算服务器105发送游戏数据流，其中含有游戏中的视频数据、音频数据、其它数据等。在步骤S630中，移动边缘计算服务器105从游戏数据流中过滤出视频数据，发给游戏视频处理服务器104存储。在步骤S640中，移动边缘计算服务器105获取游戏终端601和云游戏服务器607之间的信道状态信息。在信道状态信息指示信道状态差时，在步骤S650中，移动边缘计算服务器105向游戏视频处理服务器104获取存储的游戏视频数据的I帧。在步骤S660中，游戏视频处理服务器104向移动边缘计算服务器105发送游戏视频数据的I帧。在步骤S670中，移动边缘计算服务器105向游戏终端601发送游戏视频数据的I帧，供游戏终端601解码显示。这样，游戏终端601的用户至少在信道状态不好时可以凭I帧看到游戏视频的大致内容，在信道状态好时可以看到清晰的游戏视频。

图11示出了根据本公开一个实施例的视频数据传输方法应用在云游戏的应用场景下的逻辑判断过程流程图。当边缘服务节点103包括视频处理服务器104和移动边缘计算服务器105时，它是由移动边缘计算服务器105执行的。当边缘服务节点103不分视频处理服务器104和移动边缘计算服务器105时，它是由边缘服务节点103整体执行的。

在步骤S620中，移动边缘计算服务器105或边缘服务节点103判断是否有要发送给游戏终端601的游戏数据流到达。如果有，在步骤S630中，移动边缘计算服务器105或边缘服务节点103从游戏数据流中过滤出视频数据，按照时间窗口存储。当边缘服务节点103包括视频处理服务器104和移动边缘计算服务器105时，其存储在视频处理服务器104中。当边缘服务节点103不分视频处理服务器104和移动边缘计算服务器105时，其存储在边缘服务节点103中。在步骤S640中，移动边缘计算服务器105或边缘服务节点103获取游戏终端601和云游戏服务器607之间的信道状态信息。在步骤S641中，判断信道状态信息是否指示差的信道状态。如果指示差的信道状态，在步骤S660中，从存储的视频数据中取出I帧发送给游戏终端601，供游戏终端601解码显示。如果指示好的信道状态，在步骤S670中，取出存储的视频数据发送给游戏终端601，供游戏终端601解码显示。

如图12所示，根据本公开的一个实施例，提供了一种视频数据的传输装置，其特征在于，所述装置包括：

缓存单元602，用于缓存从视频数据发送端要发送到视频数据接收端的视频数据；

信道状态信息获取单元604，用于获取视频数据发送端和视频数据接收端之间的信道状态信息；

降容量版本获取单元606，用于当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；

降容量版本发送单元608，用于将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码。

在一个实施例中，所述缓存单元602进一步用于：在预定视频播放时间窗口中，缓存从视频数据发送端要发送到视频数据接收端的视频数据，其中，在该预定视频播放时间窗口中，按照先进先出缓存方式进行缓存。

在一个实施例中，所述预定视频播放时间窗口的大小预先按照以下方式设置：

从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积。

在一个实施例中，所述历史卡顿日志按照以下方式生成：

接收所述视频数据接收端响应于检测到卡顿开始而发送的卡顿开始通知消息；

触发预设的计时器开始计时；

接收所述视频数据接收端响应于检测到卡顿停止而发送的卡顿停止通知消息；

触发预设的计时器停止计时；

将停止计时时计时器的计时作为一次卡顿记录的卡顿时长，记录到该视频数据接收端的历史卡顿日志。

在一个实施例中，所述预定视频播放时间窗口的大小预先按照以下方式设置：

从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

计算所述最长的卡顿时长与预定比例的乘积；

基于所述乘积、以及缓存所述视频数据的视频处理服务器的最大缓存容量，设置所述预定视频播放时间窗口的大小。

在一个实施例中，所述基于所述乘积、以及缓存所述视频数据的视频处理服务器的最大缓存容量，设置所述预定视频播放时间窗口的大小，包括：

按照所述乘积和所述最大缓存容量的加权和，设置所述预定视频播放时间窗口的大小。

在一个实施例中，所述信道状态信息获取单元604进一步用于：

调用预先设置的电信网络能力获取服务，所述电信网络能力获取服务用于基于视频数据发送端和视频数据接收端之间的通信，确定视频数据发送端和视频数据接收端之间的信道状态信息。

在一个实施例中，所述信道状态信息包括所述视频数据发送端和视频数据接收端之间的信道上的丢包率，所述丢包率通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率。

在一个实施例中，所述信道状态信息包括所述视频数据发送端和视频数据接收端之间的信道上的平均传输延迟，所述平均传输延迟通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间的差除以2，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟。

在一个实施例中，所述信道状态信息包括基于所述视频数据发送端和视频数据接收端之间的信道上的丢包率和平均传输延迟确定的信道状态分数，所述信道状态分数通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率；

根据丢包率，确定第一分数，其中所述第一分数与丢包率成反相关关系；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟；

根据平均传输延迟，确定第二分数，其中所述第二分数与平均传输延迟成反相关关系；

基于第一分数和第二分数，确定信道状态分数。

在一个实施例中，所述基于第一分数和第二分数，确定信道状态分数，包括：将第一分数和第二分数的加权和，确定为信道状态分数。

在一个实施例中，所述第一预定条件包括：所述信道状态分数低于预定信道状态分数阈值。

在一个实施例中，所述降容量版本获取单元606进一步用于执行以下中的任一项：

缓存的视频数据的I帧；

缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧。

在一个实施例中，所述降容量版本包括第一降容量版本和第二降容量版本，所述降容量版本获取单元606进一步用于：

当所述信道状态信息满足第二预定条件时，获取缓存的视频数据的第一降容量版本，其中第二预定条件指示的信道状态比第一预定条件指示的信道状态差；

当所述信道状态信息满足第一预定条件，但不满足第二预定条件时，获取缓存的视频数据的第二降容量版本，其中第二降容量版本的传输容量高于第一降容量版本的传输容量。

在一个实施例中，所述第一降容量版本包括缓存的视频数据的I帧，所述第二降容量版本包括缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧。

在一个实施例中，所述缓存单元602进一步用于：

接收从视频数据发送端要发送到视频数据接收端的数据；

从接收的数据中过滤出视频数据；

缓存过滤出的视频数据。

在一个实施例中，所述从接收的数据中过滤出视频数据包括：

按照预定规则，基于接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项，从接收的数据中过滤出视频数据，其中，所述预定规则指示接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项与视频数据的对应关系。

在一个实施例中，所述缓存单元602进一步用于将从视频数据发送端要发送到视频数据接收端的视频数据，与所述视频数据接收端的标识关联缓存；所述降容量版本获取单元606进一步用于获取与该信道状态信息对应的视频数据接收端标识关联缓存的降容量版本。

在一个实施例中，所述缓存单元602进一步用于：

从多个候选视频处理服务器中选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器；

将所述视频数据缓存到选择的视频处理服务器。

在一个实施例中，所述从多个候选视频处理服务器中选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：

获取各候选视频处理服务器的已缓存视频数据大小；

获取各候选视频处理服务器与视频数据接收端的距离；

基于各候选视频处理服务器的已缓存视频数据大小、和所述距离，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述基于各候选视频处理服务器的已缓存视频数据大小、和所述距离，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：

基于各候选视频处理服务器的已缓存视频数据大小，确定第三分数，其中第三分数与所述已缓存视频数据大小成反相关关系；

基于各候选视频处理服务器的所述距离，确定第四分数，其中第四分数与所述距离成反相关关系；

基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：将所述加权和最大的视频处理服务器，作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述基于第三分数和第四分数的加权和，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：将所述加权和超过预定加权和阈值的视频处理服务器中，随机选择一个，作为用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

在一个实施例中，所述装置还包括：

第一视频数据获取单元，用于当所述信道状态信息不满足第一预定条件时，获取缓存的视频数据，

第一视频数据发送单元，用于将获取的视频数据发送给视频数据接收端，以供所述视频数据接收端解码。

在一个实施例中，所述获取视频数据发送端和视频数据接收端之间的信道状态信息是定期执行的。所述装置还包括：

第二视频数据获取单元，用于当获取到的信道状态信息由不满足第一预定条件转变为满足第一预定条件时，获取缓存的视频数据；

第二视频数据发送单元，用于将获取的视频数据发送给视频数据接收端，以供所述视频数据接收端解码。

如图13所示，边缘服务节点103以通用计算设备的形式表现。边缘服务节点103的组件可以包括但不限于：上述至少一个处理单元810、上述至少一个存储单元820、连接不同系统组件(包括存储单元820和处理单元810)的总线830。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元810执行，使得所述处理单元810执行本说明书上述示例性方法的描述部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元810可以执行如图3中所示的各个步骤。

存储单元820可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)8201和/或高速缓存存储单元8202，还可以进一步包括只读存储单元(ROM)8203。

存储单元820还可以包括具有一组(至少一个)程序模块8205的程序/实用工具8204，这样的程序模块8205包括但不限于：社交操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线830可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

边缘服务节点103也可以与一个或多个外部设备700(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该边缘服务节点103交互的设备通信，和/或与使得该边缘节点103能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口650进行。并且，边缘服务节点103还可以通过网络适配器860与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器860通过总线830与边缘服务节点103的其它模块通信。应当明白，尽管图中未示出，可以结合边缘服务节点103使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施方式的方法。

在本公开的示例性实施例中，还提供了一种计算机程序介质，其上存储有计算机可读指令，当所述计算机可读指令被计算机的处理器执行时，使计算机执行上述方法实施例部分描述的方法。

根据本公开的一个实施例，还提供了一种用于实现上述方法实施例中的方法的程序产品，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (15)

1.一种视频数据的传输方法，其特征在于，所述方法包括：

在预定视频播放时间窗口中，缓存从视频数据发送端要发送到视频数据接收端的视频数据，其中，所述预定视频播放时间窗口的大小根据历史上视频数据接收端的最长卡顿时间设置；

获取视频数据发送端和视频数据接收端之间的信道状态信息；

当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；

将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码；

所述预定视频播放时间窗口的大小根据历史上视频数据接收端的最长卡顿时间设置，包括：

从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；

确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；

将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积。

2.根据权利要求1所述的方法，其特征在于，在该预定视频播放时间窗口中，按照先进先出缓存方式进行缓存。

3.根据权利要求1所述的方法，其特征在于，所述获取视频数据发送端和视频数据接收端之间的信道状态信息，包括：

调用预先设置的电信网络能力获取服务，所述电信网络能力获取服务用于基于视频数据发送端和视频数据接收端之间的通信，确定视频数据发送端和视频数据接收端之间的信道状态信息。

4.根据权利要求1所述的方法，其特征在于，所述信道状态信息包括所述视频数据发送端和视频数据接收端之间的信道上的丢包率，所述丢包率通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识；

如果发包记录中的包的标识，在从所述转发时间起预定间隔时间内未加入收包记录中，确定发生丢包；

用单位时间发生丢包的次数除以该单位时间内发包记录中包的标识数，得到丢包率。

5.根据权利要求1所述的方法，其特征在于，所述信道状态信息包括所述视频数据发送端和视频数据接收端之间的信道上的平均传输延迟，所述平均传输延迟通过以下方式确定：

在向视频数据接收端转发来自所述视频数据发送端的包时，在发包记录中关联记录该包的标识和转发时间；

在接收到来自所述视频数据接收端的包接收确认响应时，在收包记录中关联记录该包的标识和确认响应接收时间；

如果针对发包记录中的每个包的标识，在收包记录中找到与该标识对应的确认响应接收时间，用该确认响应接收时间减去发包记录中该标识对应的转发时间的差除以2，得到该包的传输延迟；

将针对发包记录中的各包的标识得到的传输延迟求平均，得到平均传输延迟。

6.根据权利要求1所述的方法，其特征在于，所述降容量版本包括第一降容量版本和第二降容量版本，所述当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，包括：

当所述信道状态信息满足第一预定条件，但不满足第二预定条件时，获取缓存的视频数据的第一降容量版本；

当所述信道状态信息满足第二预定条件时，获取缓存的视频数据的第二降容量版本，其中第二预定条件指示的信道状态比第一预定条件指示的信道状态差，第一降容量版本的传输容量高于第二降容量版本的传输容量。

7.根据权利要求6所述的方法，其特征在于，所述第一降容量版本包括缓存的视频数据的P帧的一部分、B帧的一部分、以及I帧，所述第二降容量版本包括缓存的视频数据的I帧。

8.根据权利要求1所述的方法，其特征在于，所述缓存从视频数据发送端要发送到视频数据接收端的视频数据之前，包括：

接收从视频数据发送端要发送到视频数据接收端的数据；

从接收的数据中过滤出视频数据；

缓存过滤出的视频数据。

9.根据权利要求8所述的方法，其特征在于，所述从接收的数据中过滤出视频数据包括：

按照预定规则，基于接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项，从接收的数据中过滤出视频数据，其中，所述预定规则指示接收的数据的源IP地址，源端口，目的IP地址，目的端口、传输层协议、上下文信息中的至少一项与视频数据的对应关系。

10.根据权利要求1所述的方法，其特征在于，所述缓存从视频数据发送端要发送到视频数据接收端的视频数据，包括：将从视频数据发送端要发送到视频数据接收端的视频数据，与所述视频数据接收端的标识关联缓存；

所述获取缓存的视频数据的降容量版本，包括：获取与该信道状态信息对应的视频数据接收端标识关联缓存的降容量版本。

11.根据权利要求1所述的方法，其特征在于，所述缓存从视频数据发送端发送到视频数据接收端的视频数据之前，包括：

从多个候选视频处理服务器中选择用于缓存从视频数据发送端发送到视频数据接收端的视频数据的视频处理服务器；

将所述视频数据缓存到选择的视频处理服务器。

12.根据权利要求11所述的方法，其特征在于，所述从多个候选视频处理服务器中选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器，包括：

获取各候选视频处理服务器的已缓存视频数据大小；

获取各候选视频处理服务器与视频数据接收端的距离；

基于各候选视频处理服务器的已缓存视频数据大小、和所述距离，选择用于缓存从视频数据发送端要发送到视频数据接收端的视频数据的视频处理服务器。

13.一种视频数据的传输装置，其特征在于，所述装置包括：

缓存单元，用于在预定视频播放时间窗口中，缓存从视频数据发送端要发送到视频数据接收端的视频数据，其中，所述预定视频播放时间窗口的大小根据历史上视频数据接收端的最长卡顿时间设置，所述缓存单元还用于从所述视频数据接收端的历史卡顿日志，获得所述视频数据接收端历史上卡顿记录的卡顿时长；确定该所述视频数据接收端历史上卡顿记录的卡顿时长中最长的卡顿时长；将所述预定视频播放时间窗口的大小设置成所述最长的卡顿时长与预定比例的乘积；

信道状态信息获取单元，用于获取视频数据发送端和视频数据接收端之间的信道状态信息；

降容量版本获取单元，用于当所述信道状态信息满足第一预定条件时，获取缓存的视频数据的降容量版本，其中所述降容量版本的传输容量低于所述缓存的视频数据的传输容量，但保证视频数据的解码；

降容量版本发送单元，用于将所述降容量版本发送给视频数据接收端，以供所述视频数据接收端解码。

14.一种边缘服务节点，其特征在于，

存储器，存储有计算机可读指令；

处理器，读取存储器存储的计算机可读指令，以执行权利要求1-12中任一所述的方法。

15.一种计算机可读程序介质，其特征在于，其存储有计算机可读指令，当所述计算机可读指令被处理器执行时，使计算机执行权利要求1-12中任一所述的方法。

Images