CN103118277A - 一种视频加速方法 - Google Patents

Abstract

本发明公开了一种视频加速方法，该方法加速器拦截合作方播放器向合作方源服务器发出的URL视频播放请求，使得该加速器成为了一个视频资源传输的中转站，进而通过该中转站向URL分析服务器发出URL视频播放请求，从而为所请求的视频文件建立身份标示，进而根据在身份标识在种子服务器上查询种子列表，如果存在相应的种子，则以P2P的方式在各个客户端之间交互下载数据，从而摆脱了单一地从源服务器下载数据的缺陷。由此可知，本发明所提供的视频加速方法在通过自身播放器播放合作方视频资源时，能够使得视频播放摆脱源服务器带宽的限制，加快媒体数据的传输速度，减少播放缓冲时长，从而能够显著提高用户的播放体验。

Description

一种视频加速方法

技术领域

本发明涉及网络视频播放技术领域，特别涉及一种视频加速方法。

背景技术

乐视、优酷、土豆和爱奇艺等视频网站播放视频时，使用传统的C/S方式下载媒体数据后播放，其基本过程为：

1、在网页中嵌入自己的播放器，以及播放相应视频的清单；

2、用户点击某视频，告知播放器需要播放的视频信息；

3、播放器向源服务器建立连接；

4、服务器向播放器返回视频数据；

5、播放器获取到源服务器的数据解码后播放。

此外，除上述在视频网站上直接点击观看视频的方式，还存在有另一种模式，亦即视频合作播放模式。该种模式涉及到两方：播放方和合作方。播放方为拥有客户端播放器的一方，亦即本发明所说的自身播放器，比如本公司所拥有的暴风影音播放器，当然，也可以为其他的播放器，比如迅雷看看和pplive等，本发明对此不作限制。合作方为拥有视频资源的一方，比如优酷、土豆、爱奇艺和乐视等。优酷、土豆、爱奇艺和乐视等网站的页面上内嵌有播放器（亦即合作方播放器），当在上述客户端播放器（自身播放器）的视频清单上点击合作方的视频时，合作方的视频播放器便显示到自身播放器中，通过该合作方的视频播放器向合作方的源服务器请求数据，亦即执行上述步骤3至5，从而实现播放。

然而，上述两种传统的视频播放方法，均存在如下问题：

第一，源服务器带宽不足时，播放体验不能保证。播放器流畅播放的前提是：从播放器下载媒体数据的速度大于播放该视频的码率，当源服务器带宽吃紧时播放体验会变差，出现缓冲、卡断现象。

第二，带宽成本较高。为了满足用户的体验，需要与源服务器提供大于用户数*视频码率的带宽来保障用户体验。

第三，其它软件对播放器下载速度具有影响。如果用户机器上安装用迅雷或者BT软件时，这些软件的上传或者下载数据的行为都会占用用户本地的网络带宽，使播放器的下载速度受到影响。

第四，用户播放过后的视频再次播放时仍需要重新下载。看过的视频需要重新观看时，播放器需要重新与源服务器建立连接，下载数据后播放。

本发明是针对在自身播放器上播放合作方视频资源而设计。

有鉴于此，涉及到在自身播放器上播放合作方视频资源，如何对现有技术的视频播放方法进行改进，从而使得视频播放摆脱源服务器带宽限制，加快媒体数据的传输速度，减少播放缓冲时长，提高了用户的播放体验。

发明内容

本发明要解决的技术问题为提供一种视频加速方法，该视频加速方法在通过自身播放器播放合作方视频资源时，能够使得视频播放摆脱源服务器带宽的限制，加快媒体数据的传输速度，减少播放缓冲时长，从而能够显著提高用户的播放体验。

为解决上述技术问题，本发明提供一种视频加速方法，用于加速下载播放合作方的视频文件，包括如下步骤：

S11：加速器拦截内嵌在自身播放器中的合作方播放器向合作方的源服务器发送的视频URL请求，并使得该URL请求转向自己；

S12：加速器将该URL请求原样转发给所述源服务器；

S13：源服务器向加速器返回对应的流媒体数据；

S14：加速器将该流媒体数据返回给合作方播放器；并，加速器将URL请求发送给URL分析服务器；

S15：URL分析服务器根据URL请求中的文件路径生成所请求视频文件的身份标示，并将该身份标示返回给加速器；

S16：加速器根据该身份标示向种子服务器查询，如果存在相应种子，则以P2P方式下载数据，然后组织数据推送给合作方播放器。

优选地，在步骤S13中，源服务器还向加速器返回流媒体数据的文件段长度，该文件段长度等于文件头长度、与数据请求点与结束点的差值之和。

优选地，在步骤S13与步骤S14之间还包括如下步骤：

Sa：加速器以range的方式向源服务器请求数据，从而获得所请求视频文件的文件总长度。

优选地，在步骤S14中，加速器还将所述文件总长度发送给URL分析服务器；

在步骤15中，URL分析服务器还将所收集到的各个客户端发送来的涉及到同一视频文件的文件总长度的数据参数发送给加速器。

优选地，在步骤S15与步骤S16之间还包括如下步骤：

Sb：加速器判断所收到的文件总长度的数据参数是否满足预订条件，如果是，则往下执行步骤S16；如果否，则流程结束，不进行加速操作。

优选地，所述预设条件为：文件总长度的数据参数的数量达到预定数量，并且各个数据参数中，相同值数据参数的数量与总数据参数的数量的比值达到预定比例。

优选地，在步骤S16中，加速器按照如下策略组织数据，以便向播放器推送：

如果完整文件头长度、与数据请求点与结束点的差值之和，等于所述文件段长度，则加速器拼完整个文件头后，将该完整文件头及相应的数据文件向合作方播放器推送；

如果完整文件头长度、与数据请求点与结束点的差值之和，不等于所述文件段长度，则从完整文件头中摘出部分文件头，使得部分文件头，与数据请求点与结束点的差值之和，等于所述文件段长度，则将该部分文件头及相应的数据文件向合作方播放器推送。

优选地，步骤S16包括如下分步骤：

S161：加速器根据该身份标示向种子服务器查询种子列表；

S162：种子服务器将种子列表发送给加速器；

S163：加速器根据该种子列表通过P2P连接方式下载数据，并写入缓冲文件；

S164：加速器综合通过上述P2P方式下载的数据、以及通过由源服务器通过加速器转回的数据，并推送给播放器。

优选地，加速器通过如下方式拦截所述视频URL请求：

在客户端软件播放器启动时，通过API Hook修改WinINet的函数地址入口，指向加速器的Stub函数，以便用户点击合作方的视频时，合作方的播放器发出的视频URL通过Stub函数转发到了加速器上。

以下论述本发明的技术效果：

在本发明中，通过加速器拦截合作方播放器向合作方源服务器发出的URL视频播放请求，使得该加速器成为了一个视频资源传输的中转站，进而通过该中转站向URL分析服务器发出URL视频播放请求，从而为所请求的视频文件建立身份标示，进而根据在身份标识在种子服务器上查询种子列表，如果存在相应的种子，则以P2P的方式在各个客户端之间交互下载数据，从而摆脱了单一地从源服务器下载数据的缺陷。亦即利用各个客户端富裕上传的能力，在多个用户观看同一个视频的时候，相互提供数据而不完全从服务器下载。同时，观看过的视频会在本地硬盘缓存保留一段时间，用于给其它用户提供上传。

由此可知，本发明所提供的视频加速方法在通过自身播放器播放合作方视频资源时，能够使得视频播放摆脱源服务器带宽的限制，加快媒体数据的传输速度，减少播放缓冲时长，从而能够显著提高用户的播放体验。

附图说明

图1为本发明一种实施例中视频加速方法的逻辑框图；

图2为对图1的实施例进行改进后的逻辑框图；

图3为本发明图1和图2实施例中视频加速方法的原理图；

图4为本发明图1和图2实施例中视频加速方法的具体步骤流程图；

图5为本发明图1和图2实施例中视频加速方法的URL拦截示意图。

具体实施方式

本发明的核心为提供一种视频加速方法，该视频加速方法在通过自身播放器播放合作方视频资源时，能够使得视频播放摆脱源服务器带宽的限制，加快媒体数据的传输速度，减少播放缓冲时长，从而能够显著提高用户的播放体验。

为了使本领域的技术人员更好地理解本发明的技术方案，下面结合附图和具体实施例对本发明作进一步的详细说明。

请参考图1和图2，图1为本发明一种实施例中视频加速方法的逻辑框图；图2为对图1的实施例进行改进后的逻辑框图。

如图1所示，在一种实施例中，本发明所提供的视频加速方法，用于加速下载播放合作方的视频文件，包括如下步骤：

S11：加速器拦截内嵌在自身播放器中的合作方播放器向合作方的源服务器发送的视频URL请求，并使得该URL请求转向自己；

S12：加速器将该URL请求原样转发给所述源服务器；

S13：源服务器向加速器返回对应的流媒体数据；

S14：加速器将该流媒体数据返回给合作方播放器；并，加速器将URL请求发送给URL分析服务器；

S15：URL分析服务器根据URL请求中的文件路径生成所请求视频文件的身份标示，并将该身份标示返回给加速器；

S16：加速器根据该身份标示向种子服务器查询，如果存在相应种子，则以P2P方式下载数据，然后组织数据推送给合作方播放器。

在本发明中，通过加速器拦截合作方播放器向合作方源服务器发出的URL视频播放请求，使得该加速器成为了一个视频资源传输的中转站，进而通过该中转站向URL分析服务器发出URL视频播放请求，从而为所请求的视频文件建立身份标示，进而根据在身份标识在种子服务器上查询种子列表，如果存在相应的种子，则以P2P的方式在各个客户端之间交互下载数据，从而摆脱了单一地从源服务器下载数据的缺陷。亦即利用各个客户端富裕上传的能力，在多个用户观看同一个视频的时候，相互提供数据而不完全从服务器下载。同时，观看过的视频会在本地硬盘缓存保留一段时间，用于给其它用户提供上传。

如图2所示，在本发明中，在步骤S13中，源服务器还向加速器返回流媒体数据的文件段长度，该文件段长度等于文件头长度、与数据请求点与结束点的差值之和。比如：

合作方播放器发出的带有start（请求点）和stop（结束点）参数的URL请求为：

http://data/135248948399.flv?start=1005.72&stop=1439.16

此时，源服务器回应为：

HTTP/1.1200OK

Content-Type:video/x-flv

Content-Length:13441703，该13441703即为上述文件段长度。

进一步地，在步骤S13与步骤S14之间还包括如下步骤：

Sa：加速器以range的方式向源服务器请求数据，从而获得所请求视频文件的文件总长度。比如：

客户端播放器以range的方式发出的URL请求为：

http://data/1339926968.flv?range=0-1024

此时，源服务器回应为：

HTTP/1.1200ok

Content-Type:video/x-flv

Content-Length:1025

Content-Range:bytes0-1024/184500963，该184500963即为上述文件总长度。

此外，如图2所示，在步骤S14中，加速器还将所述文件总长度发送给URL分析服务器；在步骤15中，URL分析服务器还将所收集到的各个客户端发送来的涉及到同一视频文件的文件总长度的数据参数发送给加速器。

同时，如图2所示，在步骤S15与步骤S16之间还包括如下步骤：

Sb：加速器判断所收到的文件总长度的数据参数是否满足预订条件，如果是，则往下执行步骤S16；如果否，则流程结束，不进行加速操作。

具体地，预设条件可以为：文件总长度的数据参数的数量达到预定数量，并且各个数据参数中，相同值数据参数的数量与总数据参数的数量的比值达到预定比例。当然，还可以为其他内容的预设条件，该预设条件只要能够使得客户端之间准确进行P2P的上传和下载，本发明对此不作限制。

进一步地，在步骤S16中，加速器按照如下策略组织数据，以便向播放器推送：

如果完整文件头长度、与数据请求点与结束点的差值之和，等于所述文件段长度，则加速器拼完整个文件头后，将该完整文件头及相应的数据文件向合作方播放器推送；比如，

如果源服务器返回的文件头长度5，并且已知数据请求点与结束点的差值20，如果源服务器返回的上述文件段长度为25，则有5+20=25，则完整文件头长度、与数据请求点与结束点的差值之和，等于所述文件段长度，则器拼完整个文件头后，将该完整文件头及相应的数据文件向合作方播放器推送。

如果完整文件头长度、与数据请求点与结束点的差值之和，不等于所述文件段长度，则从完整文件头中摘出部分文件头，使得部分文件头，与数据请求点与结束点的差值之和，等于所述文件段长度，则将该部分文件头及相应的数据文件向合作方播放器推送。比如：

如果源服务器返回的文件头长度5，并且已知数据请求点与结束点的差值20，如果源服务器返回的上述文件段长度为21，此时5+20≠21，因而此时需要对文件头进行拆分，在文件头各部分中，找到两个0.5部分，将这两个0.5进行拼接，则拼完部分文件头1，使得1+20=21，则此时将该部分文件头及相应的数据文件向合作方播放器推送。

此外，步骤S16包括如下分步骤：

S161：加速器根据该身份标示向种子服务器查询种子列表；

S162：种子服务器将种子列表发送给加速器；

S163：加速器根据该种子列表通过P2P连接方式下载数据，并写入缓冲文件；

S164：加速器综合通过上述P2P方式下载的数据、以及通过由源服务器通过加速器转回的数据，并推送给播放器。

请参考图3和图4，图3为本发明图1和图2实施例中视频加速方法的原理图；图4为本发明图1和图2实施例中视频加速方法的具体步骤流程图。

如图3所示，在发明的视频加速方法中，加速器拦截URL请求，使其导向自己，由该加速器向源服务器下载文件头和数据；加速器向URL分析服务器提交URL请求，从而返回GCID（亦即身份标示）及映射关系；加速器向种子服务器提交GCID，从而返回Peer列表，下载完成，上报种子；加速器向peers下载和上传数据。

如图4所示，本发明的具体逻辑流程如下所述：

1．播放器的带有start点和stop点的视频URL请求被拦截，转向加速器。

2．加速器把URL请求原样转发到源服务器上。

3．源服务器返回对应的流媒体数据，并返回文件段长度和文件头的长度。

同时，以Range的方式（Range[0,1024)）向源服务器请求数据，以获取该视频的文件大小，亦即前文所述的文件总长度。

4．加速器把源服务器返回的流媒体数据原样返回给播放器。

5．在获得文件的文件总长度后，连同视频URL发送到URL分析服务器。

6．URL分析服务器根据文件路径生成GCID（亦即身份标示），同时读取该文件所属网站请求点的单位（秒、字节，比如：乐视是字节，土豆是秒，该配置项是研发人员调研分析的结果，配置项可随时调整）。

7．URL分析服务器返回GCID，请求点的单位，完整的文件总长度。（这里的文件总长是上述以range方式或的150或500）

1)如果服务器返回的文件总长为0（亦即不满足预设条件），则流程结束，不进行加速操作。客户端使用用户请求的带有start和stop的完整文件URL进行连接，然后以range方式然后上报给URL分析服务器（此次流程结束）。

2)7.2如果服务器返回回的文件总长不为0（亦即满足预设条件），继续以下流程。

8．根据GCID向种子服务器查询Peer。

9．得到Peer列表。

10．从Peer下载映射文件。

11．从Peer得到数据写入缓存文件。

12．源服务器支持Range参数，则按区域从源服务器下载数据。源服务器返回的数据写入缓存文件。

13．综合不同的来源的数据，按顺序返回播放器。

14．下载完成，上报种子服务器。

需要说明的是，源服务器上的单个视频文件（大小为600M）有时是整体存储的，即整体的文件总长度为600M，此时，当用户在播放器进行拖动播放时，则拖动点到125M处，则start点为125M，此时URL中是不带有stop点，此时意味着文件播放至结尾；如果不带有start点，则意味着从头播放。

此外，单个视频文件（大小为600M）有时会分成3部分存储，此时第一部分为：0-200；第二部分为：201-400，第三部分为401-600；在该种情况下，文件总长度为各部分的长度，亦即为200M；当用户拖动点到125M处，此时start点为125，则stop点为200，当用户拖动点到325M处，此时start点为325，则stop点为400。

此外，文件头中具有Meta信息，包含有文件偏移和时间偏移的对应关系，start点和stop点的单位可以为时间，也可以为字节，当为时间时，通过上述Meta信息转化为字节。

在本发明中，还可以对加速器如何拦截URL进行具体设计，比如，请参考图5，图5为本发明图1和图2实施例中视频加速方法的URL拦截示意图。

如图5所示，在客户端软件播放器启动时，通过API Hook修改WinINet的函数地址入口，指向加速器的Stub函数，以便用户点击合作方的视频时，合作方的播放器发出的视频URL通过Stub函数转发到了加速器上。

此外，需要说明的是，本发明的视频加速方法不仅仅用于播放器客户端播放器和网页视频网站之间，其实由于网页视频网站的网页上也内嵌有播放器，因而也可以用于网页视频网站之间，比如，优酷和乐视之间，可以在优酷上的播放器上加速下载乐视的视频文件。

以上对本发明所提供的一种视频加速方法进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (9)

1.一种视频加速方法，用于加速下载播放合作方的视频文件，其特征在于，包括如下步骤：

S11：加速器拦截内嵌在自身播放器中的合作方播放器向合作方的源服务器发送的视频URL请求，并使得该URL请求转向自己；

S12：加速器将该URL请求原样转发给所述源服务器；

S13：源服务器向加速器返回对应的流媒体数据；

S14：加速器将该流媒体数据返回给合作方播放器；并，加速器将URL请求发送给URL分析服务器；

S15：URL分析服务器根据URL请求中的文件路径生成所请求视频文件的身份标示，并将该身份标示返回给加速器；

S16：加速器根据该身份标示向种子服务器查询，如果存在相应种子，则以P2P方式下载数据，然后组织数据推送给合作方播放器。

2.如权利要求1所述的一种视频加速方法，其特征在于，在步骤S13中，源服务器还向加速器返回流媒体数据的文件段长度，该文件段长度等于文件头长度、与数据请求点与结束点的差值之和。

3.如权利要求2所述的一种视频加速方法，其特征在于，在步骤S13与步骤S14之间还包括如下步骤：

Sa：加速器以range的方式向源服务器请求数据，从而获得所请求视频文件的文件总长度。

4.如权利要求3所述的一种视频加速方法，其特征在于，

在步骤S14中，加速器还将所述文件总长度发送给URL分析服务器；

在步骤15中，URL分析服务器还将所收集到的各个客户端发送来的涉及到同一视频文件的文件总长度的数据参数发送给加速器。

5.如权利要求4所述的一种视频加速方法，其特征在于，在步骤S15与步骤S16之间还包括如下步骤：

Sb：加速器判断所收到的文件总长度的数据参数是否满足预订条件，如果是，则往下执行步骤S16；如果否，则流程结束，不进行加速操作。

6.如权利要求5所述的一种视频加速方法，其特征在于，所述预设条件为：文件总长度的数据参数的数量达到预定数量，并且各个数据参数中，相同值数据参数的数量与总数据参数的数量的比值达到预定比例。

7.如权利要求3-6任一项所述的一种视频加速方法，其特征在于，在步骤S16中，加速器按照如下策略组织数据，以便向播放器推送：

如果完整文件头长度、与数据请求点与结束点的差值之和，等于所述文件段长度，则加速器拼完整个文件头后，将该完整文件头及相应的数据文件向合作方播放器推送；

如果完整文件头长度、与数据请求点与结束点的差值之和，不等于所述文件段长度，则从完整文件头中摘出部分文件头，使得部分文件头，与数据请求点与结束点的差值之和，等于所述文件段长度，则将该部分文件头及相应的数据文件向合作方播放器推送。

8.如权利要求1-6任一项所述的一种视频加速方法，其特征在于，步骤S16包括如下分步骤：

S161：加速器根据该身份标示向种子服务器查询种子列表；

S162：种子服务器将种子列表发送给加速器；

S163：加速器根据该种子列表通过P2P连接方式下载数据，并写入缓冲文件；

S164：加速器综合通过上述P2P方式下载的数据、以及通过由源服务器通过加速器转回的数据，并推送给播放器。

9.如权利要求1-6任一项所述的一种视频加速方法，其特征在于，加速器通过如下方式拦截所述视频URL请求：

在客户端软件播放器启动时，通过API Hook修改WinINet的函数地址入口，指向加速器的Stub函数，以便用户点击合作方的视频时，合作方的播放器发出的视频URL通过Stub函数转发到了加速器上。

Images