本发明公开一种视频数据传输方法及系统，涉及流媒体通讯领域。本发明包括：顺序获取视频中的关键帧和预测帧；获取关键帧和预测帧的编组顺序；根据关键帧和预测帧的编组顺序将关键帧和预测帧分别打包为关键数据包和预测数据包；根据关键帧和预测帧的编组顺序获取关键数据包和预测数据包的编组顺序；建立与客户端连通的双向连通信道和单向连通信道；经由双向连通信道和/或单向连通信道发送关键数据包和/或预测数据包；经由双向连通信道获取客户端的视频缓冲时长以及单向连通信道的丢包率；根据客户端的视频缓冲时长以及单向连通信道的丢包率调整关键数据包和预测数据包的发送信道。本发明有效提高客户端接收视频数据的完整性和速率。
1.一种视频数据传输方法，其特征在于，包括，顺序获取视频中的关键帧和预测帧；
根据所述关键帧和所述预测帧的编组顺序将所述关键帧和所述预测帧分别打包为关键数据包和预测数据包；
根据所述关键帧和所述预测帧的编组顺序获取所述关键数据包和所述预测数据包的编组顺序；
经由所述双向连通信道和所述单向连通信道发送所述关键数据包和/或所述预测数据包；
经由所述双向连通信道获取所述客户端的视频缓冲时长以及所述单向连通信道的丢包率；
根据所述客户端的视频缓冲时长以及所述单向连通信道的丢包率调整所述关键数据包和所述预测数据包的发送信道；
其中，所述经由所述双向连通信道和所述单向连通信道发送所述关键数据包和/或所述预测数据包的步骤，包括，按照所述关键数据包的编组顺序经由所述双向连通信道发送所述关键数据包；
按照所述预测数据包的编组顺序经由所述双向连通信道或所述单向连通信道发送所述预测数据包；
控制已发送所述关键数据包和已发送所述预测数据包在视频中时间进度一致。
2.根据权利要求1所述的方法，其特征在于，所述控制已发送所述关键数据包和已发送所述预测数据包在视频中时间进度一致的步骤，包括，根据所述关键帧和所述预测帧在视频中的时间顺序将在时间顺序上相邻的两个关键帧之间的所述预测帧作为一个预测单元组；
将所述预测单元组在时间顺序上的前一个所述关键帧作为所述预测单元组从属的所述关键帧；
将所述关键帧从属的所述预测单元组内每个所述预测帧打包为若干个所述预测数据包；
将每个所述关键帧对应的所述关键数据包，以及所述关键帧从属的所述预测单元组内每个所述预测帧对应的所述预测数据包，分装至一个待发送分区内；
按照每个所述待发送分区内所述关键帧在视频中的时间顺序将每个所述待发送分区进行排序，得到所述待发送分区的时间序列；
按照所述待发送分区的时间序列的先后顺序发送每个所述待发送分区内的所述关键数据包和所述预测数据包。
3.根据权利要求1所述的方法，其特征在于，所述根据所述客户端的视频缓冲时长以及所述单向连通信道的丢包率调整所述关键数据包和所述预测数据包的发送信道的步骤，包括，获取所述双向连通信道和所述单向连通信道的数据包发送速率比值关于时间的对应关系作为信道发送速率比关于时间的对应关系；
根据信道发送速率比关于时间的对应关系获取所述单向连通信道的丢包率关于信道发送速率比的对应关系以及所述客户端的视频缓冲时长关于信道发送速率比的对应关系；
根据所述单向连通信道的丢包率关于信道发送速率比的对应关系、所述客户端的视频缓冲时长关于信道发送速率比的对应关系、设定的丢包率容错范围以及设定的视频缓冲时长范围调整所述关键数据包和所述预测数据包的发送信道。
4.根据权利要求3所述的方法，其特征在于，所述获取所述双向连通信道和所述单向连通信道的数据包发送速率比值关于时间的对应关系的步骤，包括，获取所述双向连通信道发送的所述关键数据包和所述预测数据包的时刻；
根据所述双向连通信道发送的所述关键数据包和所述预测数据包的时刻获取所述双向连通信道的数据包发送速率关于时间的对应关系；
根据所述单向连通信道发送的所述预测数据包的时刻获取所述单向连通信道的数据包发送速率关于时间的对应关系；
根据所述双向连通信道的数据包发送速率关于时间的对应关系以及所述单向连通信道的数据包发送速率关于时间的对应关系获取所述双向连通信道和所述单向连通信道的数据包发送速率比值关于时间的对应关系。
5.根据权利要求3所述的方法，其特征在于，所述根据信道发送速率比关于时间的对应关系获取所述单向连通信道的丢包率关于信道发送速率比的对应关系以及所述客户端的视频缓冲时长关于信道发送速率比的对应关系的步骤，包括，获取所述单向连通信道的丢包率关于时间的对应关系；
根据信道发送速率比关于时间的对应关系以及所述单向连通信道的丢包率关于时间的对应关系，得到所述单向连通信道的丢包率关于信道发送速率比的对应关系；
根据信道发送速率比关于时间的对应关系以及所述客户端的视频缓冲时长关于时间的对应关系，得到所述客户端的视频缓冲时长关于信道发送速率比的对应关系。
6.根据权利要求3所述的方法，其特征在于，所述根据所述单向连通信道的丢包率关于信道发送速率比的对应关系、所述客户端的视频缓冲时长关于信道发送速率比的对应关系、设定的丢包率容错范围以及设定的视频缓冲时长范围调整所述关键数据包和所述预测数据包的发送信道的步骤，包括，根据所述单向连通信道的丢包率关于信道发送速率比的对应关系以及设定的丢包率容错范围获取信道发送速率比的第一计算范围；
根据所述客户端的视频缓冲时长关于信道发送速率比的对应关系以及设定的视频缓冲时长范围获取信道发送速率比的第二计算范围；
截取所述单向连通信道的丢包率的第一计算范围和第二计算范围的交集作为信道发送速率比的规划范围；
根据信道发送速率比的规划范围调整所述关键数据包和所述预测数据包的发送信道。
7.根据权利要求3所述的方法，其特征在于，所述方法还包括，获取视频中的双向预测帧；
根据所述双向预测帧的编组顺序将所述双向预测帧打包为双向预测数据包；
根据所述双向预测帧的编组顺序获取所述双向预测数据包的编组顺序；
沿着所述双向预测数据包的编组顺序，将所述双向预测数据包按照信道发送速率比经由所述双向连通信道和/或所述单向连通信道进行发送。
8.一种视频数据传输方法，其特征在于，包括，接收根据权利要求1至7中任一项所述的视频数据传输方法生成的关键数据包和预测数据包；
根据关键数据包和预测数据包进行视频解码，得到在客户端的已解码视频；
根据客户端接收到的关键数据包和预测数据包的编组顺序获取单向连通信道的丢包率；
根据已解码视频以及客户端的已解码视频的播放进度获取客户端的视频缓冲时长；
经由双向连通信道发送客户端的视频缓冲时长以及单向连通信道的丢包率。
9.一种视频数据传输系统，其特征在于，包括，服务器，用于顺序获取视频中的关键帧和预测帧；
根据所述关键帧和所述预测帧的编组顺序将所述关键帧和所述预测帧分别打包为关键数据包和预测数据包；
根据所述关键帧和所述预测帧的编组顺序获取所述关键数据包和所述预测数据包的编组顺序；
经由所述双向连通信道和所述单向连通信道发送所述关键数据包和/或所述预测数据包；
经由所述双向连通信道获取所述客户端的视频缓冲时长以及所述单向连通信道的丢包率；
根据所述客户端的视频缓冲时长以及所述关键数据包和所述单向连通信道的丢包率调整所述关键数据包和所述预测数据包的发送信道；
还包括客户端，用于接收所述关键数据包和所述预测数据包；
根据所述关键数据包和所述预测数据包进行视频解码，得到在所述客户端的已解码视频；
根据所述客户端接收到的所述关键数据包和所述预测数据包的编组顺序获取所述单向连通信道的丢包率；
根据已解码视频以及所述客户端的已解码视频的播放进度获取所述客户端的视频缓冲时长；
经由所述双向连通信道发送所述客户端的视频缓冲时长以及所述单向连通信道的丢包率；
其中，所述经由所述双向连通信道和所述单向连通信道发送所述关键数据包和/或所述预测数据包的步骤，包括，按照所述关键数据包的编组顺序经由所述双向连通信道发送所述关键数据包；
按照所述预测数据包的编组顺序经由所述双向连通信道或所述单向连通信道发送所述预测数据包；
控制已发送所述关键数据包和已发送所述预测数据包在视频中时间进度一致。
一种视频数据传输方法及系统
技术领域
[0001] 本发明属于流媒体通讯技术领域，特别是涉及一种视频数据传输方法及系统。
背景技术
[0002] 服务器向浏览器等客户端提供流媒体服务的过程中，由于网络传输不稳定等原因可能会导致视频数据在传输过程中出现丢包，从而导致客户端无法解析出稳定流畅的画面。
[0003] 为了应对视频数据网络传输丢包问题，通常会采用传输控制协议（TCP，Transmission Control Protocol）在网络层传输视频数据，但是由于TCP协议在连通过程中需要三次握手和四次挥手才能完整完成一次通讯，这就导致传输响应速度较慢，同样会影响客户端的视频观看体验。
[0004] 在公开号为CN105430320A的专利中公开了一种基于UDP和TCP的音视频媒体数据传输方法，应用于VOIP、音视频会议业务，所述方法包括以下步骤：在终端或服务器发送RTP包之前，创建RTP/UDP通道，另外建立一个TCP连接；在正常传输时，使用RTP/UDP通道发送和接收RTP包；接收端发现有丢包时，生成NACK请求，通过TCP连接发送给发送端，请求丢包重传；发送端收到NACK请求后，解析NACK请求，将需要重传的RTP包，通过TCP连接，发送给接收端。但是上述方案通过TCP连接实现对RTP/UDP通道的监控和丢包重传，不仅失去了UDP协议响应速度快的优点，并且失去了TCP协议稳定可靠的优点。
发明内容
[0005] 本发明的目的在于提供一种视频数据传输方法及系统，通过对客户端视频播放状态的分析，对不同的数据传输信道传输的不同数据包进行分配，有效提高客户端接收视频数据的完整性和速率。
[0006] 为解决上述技术问题，本发明是通过以下技术方案实现的：
[0007] 本发明提供一种视频数据传输方法，用于在流媒体服务的服务器中执行，其包括：
[0008] 顺序获取视频中的关键帧和预测帧；
[0009] 获取所述关键帧和所述预测帧的编组顺序；
[0010] 根据所述关键帧和所述预测帧的编组顺序将所述关键帧和所述预测帧分别打包为关键数据包和预测数据包；
[0011] 根据所述关键帧和所述预测帧的编组顺序获取所述关键数据包和所述预测数据包的编组顺序；
[0012] 建立与客户端连通的双向连通信道和单向连通信道；
[0013] 经由所述双向连通信道和所述单向连通信道发送所述关键数据包和/或所述预测数据包；
[0014] 经由所述双向连通信道获取所述客户端的视频缓冲时长以及所述单向连通信道的丢包率；
[0015] 根据所述客户端的视频缓冲时长以及所述单向连通信道的丢包率调整所述关键数据包和所述预测数据包的发送信道。
[0016] 本发明还提供一种视频数据传输方法，用于在流媒体服务的客户端中执行，包括，[0017] 接收根据所述的视频数据传输方法生成的所述关键数据包和所述预测数据包；
[0018] 根据所述关键数据包和所述预测数据包进行视频解码，得到在所述客户端的已解码视频；
[0019] 根据所述客户端接收到的所述关键数据包和所述预测数据包的编组顺序获取所述单向连通信道的丢包率；
[0020] 获取所述客户端的已解码视频的播放进度；
[0021] 根据已解码视频以及所述客户端的已解码视频的播放进度获取所述客户端的视频缓冲时长；
[0022] 经由所述双向连通信道发送所述客户端的视频缓冲时长以及所述单向连通信道的丢包率。
[0023] 本发明还公开了一种视频数据传输系统，包括，
[0024] 服务器，用于顺序获取视频中的关键帧和预测帧；
[0025] 获取所述关键帧和所述预测帧的编组顺序；
[0026] 根据所述关键帧和所述预测帧的编组顺序将所述关键帧和所述预测帧分别打包为关键数据包和预测数据包；
[0027] 根据所述关键帧和所述预测帧的编组顺序获取所述关键数据包和所述预测数据包的编组顺序；
[0028] 建立与客户端连通的双向连通信道和单向连通信道；
[0029] 经由所述双向连通信道和所述单向连通信道发送所述关键数据包和/或所述预测数据包；
[0030] 经由所述双向连通信道获取所述客户端的视频缓冲时长以及所述单向连通信道的丢包率；
[0031] 根据所述客户端的视频缓冲时长以及所述关键数据包和所述单向连通信道的丢包率调整所述关键数据包和所述预测数据包的发送信道；
[0032] 还包括客户端，用于接收所述关键数据包和所述预测数据包；
[0033] 根据所述关键数据包和所述预测数据包进行视频解码，得到在所述客户端的已解码视频；
[0034] 根据所述客户端接收到的所述关键数据包和所述预测数据包的编组顺序获取所述单向连通信道的丢包率；
[0035] 获取所述客户端的已解码视频的播放进度；
[0036] 根据已解码视频以及所述客户端的已解码视频的播放进度获取所述客户端的视频缓冲时长；
[0037] 经由所述双向连通信道发送所述客户端的视频缓冲时长以及所述单向连通信道的丢包率。
[0038] 本发明通过将视频中的画面帧划分为关键帧和预测帧，再分别将关键帧和预测帧打包为网络层的关键数据包和预测数据包，最后通过调整关键数据包和预测数据包的发送信道的方式保障了客户端视频观看体验。
[0039] 当然，实施本发明的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
[0040] 为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0041] 图1为本发明所述一种视频数据传输方法的流程示意图一；
[0042] 图2为本发明所述一种视频数据传输系统的功能模块以及信息流向示意图；
[0043] 图3为本发明所述关键帧、预测帧以及双向预测帧于一实施例的结构示意图；
[0044] 图4为本发明所述双向连通信道连通的示意图；
[0045] 图5为本发明所述步骤S6的实施步骤示意图；
[0046] 图6为本发明所述步骤S65的实施步骤示意图；
[0047] 图7为本发明所述步骤S8的实施步骤示意图；
[0048] 图8为本发明所述步骤S81的实施步骤示意图；
[0049] 图9为本发明所述步骤S82的实施步骤示意图；
[0050] 图10为本发明所述步骤S85的实施步骤示意图；
[0051] 图11为本发明所述一种视频数据传输方法的流程示意图二。
[0052] 附图中，各标号所代表的部件列表如下：
[0053] 1‑服务器，2‑客户端。
具体实施方式
[0054] 下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。
[0055] 在服务器向客户端提供流媒体数据服务的过程中，需要先从服务器的数据库中调取视频数据资源，但是由于原生视频的体积过于巨大，通常在线视频网站等流媒体服务提供商会将视频压缩后进行存储，再将压缩后的数据流发送到客户端解码后播放。
[0056] 在视频数据流传输的过程中可以采用开放式系统互联通信参考模型（Open System Interconnection Reference Model，缩写为 OSI）进行分析。在服务器的视频推送进程将视频流打包为数据包进行发送的过程中在传输层进行传输，主流的传输协议是TCP协议和UDP协议。其中，TCP协议提供的是一种可靠的数据流服务。当传送受差错干扰的数据，或举出网络故障，或网络负荷太重而使网际基本传输系统不能正常工作时，就需要通过其他的协议来保证通信的可靠。UDP协议与TCP协议一样用于处理数据包，在OSI模型中，两者都位于传输层，处于IP协议的上一层。UDP协议有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的，但也正因为如此UDP协议具有较小的响应延迟，适合传输视频流。
[0057] 综合来说，依据TCP协议建立的双向连通信道具有高可靠性，依据UDP协议建立的单向连通信道具有低延迟性。为了在不可靠的网络环境下传输稳定可靠的视频画面，本发明提供以下方案。
[0058] 请参阅图1和2所示，本发明提供了一种视频数据传输系统，在传输之前需要从服务器的数据库中提取视频，并由服务器执行步骤S1根据视频的压缩编码方式提取其中的关键帧和预测帧。如图3所示，视频中的画面帧经过压缩之后形成多个图像组（GOP），在每个图像组内包括一个关键帧（I）和若干个预测帧（P），关键帧由视频中的原始画面帧经过静态压缩后得到，一般来说只会损失其中难以被人眼识别的细节。预测帧则不然，其主要是记录对应的原始画面帧与关键帧的区别，因此预测帧内的数据压缩比较高，但是预测帧的解码依赖于对应的关键帧。双向预测帧（B）则较为特殊，它也具有较高的压缩比，但其可以同时参考前后的关键帧和预测帧，具有较高的可恢复性。利用此特性能够在不可靠网络中传输可靠稳定的视频画面。接下来可以执行步骤S2获取关键帧和预测帧的编组顺序，以便于后续的顺序发送。接下来可以执行步骤S3根据关键帧和预测帧的编组顺序将关键帧和预测帧分别打包为关键数据包和预测数据包，需要说明的是，关键数据包和预测数据包中记载其对应的编组顺序。接下来可以执行步骤S4根据关键帧和预测帧的编组顺序获取关键数据包和预测数据包的编组顺序，在视频传输时按照编组顺序进行传输。
[0059] 接下来可以执行步骤S5建立与客户端连通的双向连通信道和单向连通信道，本方案中的双向连通信道可以是基于TCP协议建立的，单向连通信道可以是基于UDP协议建立的。接下来可以执行步骤S6经由双向连通信道和单向连通信道发送关键数据包和/或预测数据包。接下来可以执行步骤S7经由双向连通信道获取客户端的视频缓冲时长以及单向连通信道的丢包率，也就是利用TCP协调的双向连通性将客户端的信息回传到服务器。最后可以执行步骤S8根据客户端的视频缓冲时长以及单向连通信道的丢包率调整关键数据包和预测数据包的发送信道，通过调整关键数据包和预测数据包的发送信道的方式保持客户端接收数据包对应画面帧的稳定。
[0060] 请参阅如图4，具体展示出服务器与客户端在双向连通信道建立过程中复杂过程，每次握手（发送数据请求或应答）时，发送的数据为TCP报文，TCP段包含了源/目的地址，端口号，初始序号，滑动窗口大小，窗口扩大因子，最大报文段长度等。还有一些标志位。从图中，可以看出三次握手的基本步骤是：
[0061] 第一次握手：客户端向服务器端发送连接请求包SYN（syn=j），等待服务器回应。
[0062] 第二次握手：服务器端收到客户端连接请求包SYN（syn=j）后，将客户端的请求包SYN（syn=j）放入到自己的未连接队列，此时服务器需要发送两个包给客户端。
[0063] （1）向客户端发送确认自己收到其连接请求的确认包ACK（ack=j+1），向客户端表明已知道了其连接请求。
[0064] （2）向客户端发送连接询问请求包SYN（syn=k），询问客户端是否已经准备好建立连接，进行数据通信。即在第二次握手时服务器向客户端发送ACK（ack=j+1）和SYN（syn=k）包，此时服务器进入SYN_RECV状态，SYN_RECV状态指的是服务端被动打开后，接收到了客户端的SYN并且发送了ACK时的状态，在网络应用中具体指接收到连接请求，并发送连接请求后，等待对端应答时所置的状态。
[0065] 第三次握手：客户端收到服务器的ACK（ack=j+1）和SYN（syn=k）包后，知道了服务器同意建立连接，此时需要发送连接已建立的消息给服务器。向服务器发送连接建立的确认包ACK（ack=k+1），回应服务器的SYN（syn=k）告诉服务器，我们之间已经建立了连接，可以进行数据通信。
[0066] ACK（ack=k+1）包发送完毕，服务器收到后，此时服务器与客户端进入ESTABLISHED状态，开始进行数据传送，ESTABLISHED状态含义指的是TCP连接成功。
[0067] 接下来我们从客户端的角度讨论本技术方案，本方案的客户端指的是服务器‑客户端，即Client‑Server(C/S)结构中的客户端，可以是浏览器，也可以是移动端或桌面端的应用。客户端在和服务器建立双向连通信道和单向连通信道之后，首先可以执行步骤S9接收关键数据包和预测数据包，在接收之后进行缓存以便于后续解码。接下来可以执行步骤S10根据关键数据包和预测数据包进行视频解码，得到在客户端的已解码视频，对于未接收到的预测数据包对应的画面帧，不对其进行解码。接下来可以执行步骤S11根据客户端接收到的关键数据包和预测数据包的编组顺序获取单向连通信道的丢包率，丢包率是反应网络状态的重要参数，因此需要将其回传到服务器，以后与后续调整。接下来可以执行步骤S12获取客户端的已解码视频的播放进度，之后可以执行步骤S13根据已解码视频以及客户端的已解码视频的播放进度获取客户端的视频缓冲时长，视频缓冲时长不仅是反应网络状态的重要参数，同时也是影响用户观看视频体验的重要参数，因此需要将其回传到服务器。最后可以执行步骤S14经由双向连通信道发送客户端的视频缓冲时长以及单向连通信道的丢包率，以便后服务端调整关键数据包和预测数据包的连通信道。
[0068] 从数据包的视频信息密度而言，关键数据包中的关键数据帧能够影响整个图像组（GOP）的解码成像，而其中的预测数据包和双向预测数据包中的画面帧只会影响自己的解码成像，因此关键数据包的重要性显著大于预测数据包和双向预测数据包。同时由于数据包的数据内容部分容量相同或相似，因此每个预测数据包和双向预测数据包对应的画面帧的数量大于关键数据包。有鉴于此，使用双向连通信道传输关键数据包能够保证客户端的画面解码效果。使用单向连通信道传输预测数据包和双向预测数据包能够增加客户端视频画面的流畅度。
[0069] 请参阅图5所示，由于每个图像组（GOP）内只有一个关键数据帧，但是预测数据帧和双向预测数据帧的数量可能是多个，同时双向连通信道和单向连通信道的通讯速率各不相同，为了保证客户端的视频观看同步率，上述步骤S6在执行的过程中首先可以执行步骤S61按照关键数据包的编组顺序经由双向连通信道发送关键数据包。接下来可以执行步骤S62获取已发送关键数据包在视频中时间进度，接下来可以执行步骤S63按照预测数据包的编组顺序经由双向连通信道或单向连通信道发送预测数据包。接下来可以执行步骤S64获取已发送预测数据包在视频中时间进度，最后可以执行步骤S65控制已发送关键数据包和已发送预测数据包在视频中时间进度一致。通过时间控制的方式保持客户端接收的关键帧和预测帧同步，避免影响用户的视频观看体验。
[0070] 请参阅图6所示，由于同一个图像组（GOP）内的关键帧、预测帧以及双向预测帧需要同时解码才能完整播放，因此需要保证对应的数据包也同步完整传输到客户端，具体而言就是在执行步骤S65的过程中首先可以执行步骤S651根据关键帧和预测帧在视频中的时间顺序，将在时间顺序上相邻的两个关键帧之间的预测帧作为一个预测单元组。接下来可以执行步骤S652将预测单元组在时间顺序上的前一个关键帧作为预测单元组从属的关键帧，接下来可以执行步骤S653将关键帧打包为若干个关键数据包。接下来可以执行步骤S654将关键帧从属的预测单元组内每个预测帧打包为若干个预测数据包。接下来可以执行步骤S655将每个关键帧对应的关键数据包，以及关键帧从属的预测单元组内每个预测帧对应的预测数据包，分装至一个待发送分区内。接下来可以执行步骤S656按照每个待发送分区内关键帧在视频中的时间顺序将每个待发送分区进行排序，得到待发送分区的时间序列。最后可以执行步骤S657按照待发送分区的时间序列的先后顺序发送每个待发送分区内的关键数据包和预测数据包。
[0071] 请参阅图7所示，由于丢包率和视频缓冲时长对客户端的视频观看体验具有较大影响，也是体现用户观看体验的核心指标，因此可以据此对数据包的连通信道进行调整，具体到步骤S8的实施过程中，首先可以执行步骤S81获取双向连通信道和单向连通信道的数据包发送速率比值关于时间的对应关系作为信道发送速率比关于时间的对应关系。接下来可以执行步骤S82根据信道发送速率比关于时间的对应关系获取单向连通信道的丢包率关于信道发送速率比的对应关系以及客户端的视频缓冲时长关于信道发送速率比的对应关系。接下来可以执行步骤S83获取设定的丢包率容错范围，接下来可以执行步骤S84获取设定的视频缓冲时长范围。最后可以执行步骤S85根据单向连通信道的丢包率关于信道发送速率比的对应关系、客户端的视频缓冲时长关于信道发送速率比的对应关系、设定的丢包率容错范围以及设定的视频缓冲时长范围调整关键数据包和预测数据包的发送信道。需要说明的是，上述的设定的丢包率容错范围由技术人员调整设置，设定的视频缓冲时长范围通常由客户端的用户自行设置。
[0072] 请参阅图8所示，由于网络状态是客观因素，因此对客户端观看视频体验的主要调节方式是调整双向连通信道和单向连通信道的数据包发送速率比值，为了对其进行定量分析，上述的步骤S81在实施的过程中首先可以执行步骤S811获取双向连通信道发送的关键数据包和预测数据包的时刻。接下来可以执行步骤S812根据双向连通信道发送的关键数据包和预测数据包的时刻获取双向连通信道的数据包发送速率关于时间的对应关系。接下来可以执行步骤S813获取单向连通信道发送的预测数据包的时刻，接下来可以执行步骤S814根据单向连通信道发送的预测数据包的时刻获取单向连通信道的数据包发送速率关于时间的对应关系。最后可以执行步骤S815根据双向连通信道的数据包发送速率关于时间的对应关系以及单向连通信道的数据包发送速率关于时间的对应关系获取双向连通信道和单向连通信道的数据包发送速率比值关于时间的对应关系。通过建立关于时间的对应关系便于后续的准确定量分析，并且也能够根据时间趋势进行预测判断。
[0073] 请参阅图9所示，为了对单向连通信道的丢包率和客户端的视频缓冲时长进行定量分析，需要建立两者与信道发送速率比的对应关系，因此上述的步骤S82在执行的过程中首先可以执行步骤S821获取单向连通信道的丢包率关于时间的对应关系。接下来可以执行步骤S822根据信道发送速率比关于时间的对应关系以及单向连通信道的丢包率关于时间的对应关系，得到单向连通信道的丢包率关于信道发送速率比的对应关系。接下来可以执行步骤S823获取客户端的视频缓冲时长关于时间的对应关系。最后可以执行步骤S824根据信道发送速率比关于时间的对应关系以及客户端的视频缓冲时长关于时间的对应关系，得到客户端的视频缓冲时长关于信道发送速率比的对应关系，据此建立丢包率、视频缓冲时长与信道发送速率比的定量关系，以便于后续的分析和调整。
[0074] 请参阅图10所示，由于视频缓冲时长和丢包率都会影响客户端的视频观看体验，只要在设定的范围内都是可以的，在定量分析调整的过程中，首先可以执行步骤S851根据单向连通信道的丢包率关于信道发送速率比的对应关系以及设定的丢包率容错范围获取信道发送速率比的第一计算范围。接下来可以执行步骤S852根据客户端的视频缓冲时长关于信道发送速率比的对应关系以及设定的视频缓冲时长范围获取信道发送速率比的第二计算范围。接下来可以执行步骤S853截取单向连通信道的丢包率的第一计算范围和第二计算范围的交集作为信道发送速率比的规划范围。最后可以执行步骤S854根据信道发送速率比的规划范围调整关键数据包和预测数据包的发送信道。
[0075] 请参阅图11所示，不同的视频压缩编码方式使得视频内部的结构也有所不同，例如在H.261编码方式中包括关键帧和预测帧，但是在之后的MPEG‑1编码方式中引入的双向预测帧，在具有双向预测帧的状况下，首先可以执行步骤S15获取视频中的双向预测帧。接下来可以执行步骤S16获取双向预测帧的编组顺序，接下来可以执行步骤S17根据双向预测帧的编组顺序将双向预测帧打包为双向预测数据包。在步骤S15至S17的过程中保持与步骤S1至步骤S6相同的处理流程。接下来执行步骤S18根据双向预测帧的编组顺序获取双向预测数据包的编组顺序。但是在步骤S19的数据包发送流程上，由于双向预测包具有更高的画面帧信息密度，因此为了兼顾传输效率和客户端视频画面的完整度，可以将双向预测数据包同时在双向连通信道和单向连通信道上同时传输，具体而言就是沿着双向预测数据包的编组顺序，将双向预测数据包按照信道发送速率比经由双向连通信道和单向连通信道进行发送。当然对其它视频压缩编码方式中包含的压缩后画面帧，也可以采用相同的方式发送其对应的数据包，以此兼顾视频数据的传输效率和视频画面的完整性。
[0076] 综上所述，本方案在实施的过程中，结合视频数据的压缩方式，将客户端请求的数据源按照其压缩后的画面帧分别打包为关键数据包和预测数据包，并根据客户端的观看回传数据作为调整参数对数据包的传输连通信道进行调整，从而实现在保障客户端视频画面完整性的前提下提高视频传输播放的流畅性，以此提高了视频的观看体验。
[0077] 本发明所示实施例的上述描述（包括在说明书摘要中的内容）并非意在详尽列举或将本发明限制到本文所公开的精确形式。尽管在本文仅为说明的目的而描述了本发明的具体实施例和本发明的实例，但是正如本领域技术人员将认识和理解的，各种等效修改是可以在本发明的精神和范围内的。如所指出的，可以按照本发明实施例的上述描述来对本发明进行这些修改，并且这些修改将在本发明的精神和范围内。
[0078] 本文已经在总体上将系统和方法描述为有助于理解本发明的细节。此外，已经给出了各种具体细节以提供本发明实施例的总体理解。然而，相关领域的技术人员将会认识到，本发明的实施例可以在没有一个或多个具体细节的情况下进行实践，或者利用其它装置、系统、配件、方法、组件、材料、部分等进行实践。在其它情况下，并未特别示出或详细描述公知结构、材料和/或操作以避免对本发明实施例的各方面造成混淆。
[0079] 因而，尽管本发明在本文已参照其具体实施例进行描述，但是修改自由、各种改变和替换意在上述公开内，并且应当理解，在某些情况下，在未背离所提出发明的范围和精神的前提下，在没有对应使用其他特征的情况下将采用本发明的一些特征。因此，可以进行许多修改，以使特定环境或材料适应本发明的实质范围和精神。本发明并非意在限制到在下面权利要求书中使用的特定术语和/或作为设想用以执行本发明的最佳方式公开的具体实施例，但是本发明将包括落入所附权利要求书范围内的任何和所有实施例及等同物。因而，本发明的范围将只由所附的权利要求书进行确定。
