下拉式对等网络直播业务实现方法

摘要

本发明公开了一种下拉式对等网络直播业务实现方法，步骤包括：用户节点播放直播频道时获取具有播放频道内容的源节点，所述源节点包括局端源节点或者正在收看该频道的用户源节点，所述源节点定期向所述用户节点发送自身具备的数据块情况；所述用户节点在所述局端源节点的缓存内容中选择起始数据块作为自己的播放指针，在所述播放指针之后设置紧急窗口，所述紧急窗口内的数据块向所述局端源节点发起请求，所述紧急窗口外的数据块向所述用户源节点发起请求；当所述播放指针下的数据块播放完毕后，所述播放指针按照数据块进行移动，所述紧急窗口也随之移动，落入所述紧急窗口内的数据块向所述局端源节点发起请求。

权利要求

1.一种下拉式对等网络直播业务实现方法，步骤包括：

(1)用户节点播放直播频道时获取具有播放频道内容的源节点，所述源节点包括局端源节点或者正在收看该频道的用户源节点；所述局端源节点为具有播放频道内容的局端节点，所述用户源节点为具有播放频道内容的用户节点；所述源节点定期向所述用户节点发送自身具备的数据块情况；

(2)所述用户节点在所述局端源节点的缓存内容中选择起始数据块作为自己的播放指针，在所述播放指针之后设置紧急窗口，所述紧急窗口内的数据块向所述局端源节点发起请求，所述紧急窗口外的数据块向所述用户源节点发起请求；

(3)当所述播放指针下的数据块播放完毕后，所述播放指针按照数据块进行移动，所述紧急窗口也随之移动，落入所述紧急窗口内的数据块向所述局端源节点发起请求。

2.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(1)中，所述播放频道内容在所述局端节点和用户源节点中按块进行滚动缓存。

3.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(1)中，所述源节点包括一个局端源节点和至少一个用户源节点。

4.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(1)中，所述局端节点起码流补偿作用，当用户源节点不能及时提供直播数据时，由所述局端节点作为局端源节点进行补偿。

5.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(1)中，所述用户节点的播放进度参考所述局端源节点的码流进度。

6.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(2)中，确定所述数据块发起请求的源节点包括：(21)如果数据块落入紧急窗口，则把该数据块的源节点确定为局端源节点；否则，该数据块的源节点从用户源节点中选择；

(22)选择具有所求数据块的用户节点，形成集合A；

(23)从所述A中选择当前没有传输数据任务的用户节点，形成B；

(24)如果B非空，则从中选择一个用户节点作为所求数据块的用户源节点；如果B为空，则表明分配失败，等待下一次分配。

7.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(2)中，所述紧急窗口用于放置紧急数据块，所述紧急数据块为接近播放点的数据块，所述紧急数据块向局端源节点请求取得。

8.根据权利要求1所述的下拉式对等网络直播业务实现方法，其特征在于，步骤(3)中，紧急窗口外的数据块向所述用户源节点发起请求。

说明书

下拉式对等网络直播业务实现方法

技术领域

[0001] 本发明涉及一种对等网络(Peer To Peer Network，以下简称P2P)技术和宽带流媒体技术中的P2P直播业务，具体说，涉及一种下拉式对等网络直播业务实现方法。 背景技术

[0002] 随着互联网络和宽带接入网络的迅速发展，采用P2P技术已经能够成功地在互联网上规模开展视频直播业务。这种业务一方面丰富了互联网上的内容，吸引用户上网；另一方面这些业务又大量地消耗了网络资源，对电信运营商带来极为不利的影响。另一方面，电信运营商为了提高收益迫切需要在宽带网络上开展各种媒体业务的运营。这样就迫切需要建设一种可运营的P2P直播业务媒体网络。

[0003] 但目前互联网上的P2P直播媒体业务在体验质量上还存在以下问题： [0004] (1)码流过小、清晰度不够，导致画面尺寸过小、画面质量不高。 [0005] (2)播放不流畅，经常出现画面停顿和跳跃问题。

[0006] 这些问题导致了这种P2P直播难以开展运营，因此，可运营的P2P直播方案必须对现有的P2P技术进行改造，使之能够达到可运营的质量要求。

[0007] 导致这些问题的原因有：

[0008] (1)现有P2P直播完全依赖用户客户端资源，其中ADSL用户线路上行带宽限制了直播码流大小，从而只能播放低清晰度的直播节目；同时客户端处理负荷的不稳定、网络线路的抖动以及客户端的频繁上下线都会影响播放的流畅度。

[0009] (2)现有的P2P直播一般采用下推式实现方案，这样上游节点的变化会直接影响到下游节点播放，并要求下游节点频繁地根据多个上游节点的播放进度调整自己的播放进度，这样从技术方案上就决定了难以避免画面跳跃的问题。

发明内容

[0010] 本发明所解决的技术问题是提供一种下拉式对等网络直播业务实现方法，充分利用了用户节点资源，同时又能避免用户节点服务能力的波动。

[0011] 技术方案如下：

[0012] 一种下拉式对等网络直播业务实现方法，步骤包括：

[0013] (1)用户节点播放直播频道时获取具有播放频道内容的源节点，所述源节点包括局端源节点或者正在收看该频道的用户源节点；所述局端源节点为具有播放频道内容的局端节点，所述用户源节点为具有播放频道内容的用户节点；所述源节点定期向所述用户节点发送自身具备的数据块情况；

[0014] (2)所述用户节点在所述局端源节点的缓存内容中选择起始数据块作为自己的播放指针，在所述播放指针之后设置紧急窗口，所述紧急窗口内的数据块向所述局端源节点发起请求，所述紧急窗口外的数据块向所述用户源节点发起请求；

[0015] (3)当所述播放指针下的数据块播放完毕后，所述播放指针按照数据块进行移动，所述紧急窗口也随之移动，落入所述紧急窗口内的数据块向所述局端源节点发起请求。 [0016] 进一步，步骤(1)中，所述播放频道内容在所述局端节点和用户源节点中按块进行滚动缓存。

[0017] 进一步，步骤(1)中，所述源节点包括一个局端源节点和至少一个用户源节点。 [0018] 进一步，步骤(1)中，所述局端节点起码流补偿作用，当用户源节点不能及时提供直播数据时，由所述局端节点作为局端源节点进行补偿。

[0019] 进一步，步骤(1)中，所述用户节点的播放进度参考所述局端源节点的码流进度。 [0020] 进一步，步骤(2)中，确定所述数据块发起请求的源节点包括： [0021] (21)如果数据块落入紧急窗口，则把该数据块的源节点确定为局端源节点；否则，该数据块的源节点从用户源节点中选择；

[0022] (22)选择具有所求数据块的用户节点，形成集合A；

[0023] (23)从所述A中选择当前没有传输数据任务的用户节点，形成B； [0024] (24)如果B非空，则从中选择一个用户节点作为所求数据块的用户源节点；如果B为空，则表明分配失败，等待下一次分配。

[0025] 进一步，步骤(2)中，所述紧急窗口用于放置紧急数据块，所述紧急数据块为接近播放点的数据块，所述紧急数据块向局端源节点请求取得。

[0026] 进一步，步骤(3)中，紧急窗口外的数据块向所述用户源节点发起请求。 [0027] 本发明技术方案既充分利用了用户节点资源，同时又能避免用户节点服务能力的波动，适合于运营商运营高码流且平滑播放的直播业务。另外，因为数据的请求完全由接收端的播放进程驱动，这样各用户节点的播放进度就不会相互影响，保证了播放的流畅性。 [0028] 附图说明

[0029] 图1是伙伴节点关系图；

[0030] 图2a是伙伴节点的资源情况和请求分配过程中，用户节点1新接入频道时的请求情况示意图；

[0031] 图2b是伙伴节点的资源情况和请求分配过程中，在时刻1的请求情况示意图； [0032] 图2c是伙伴节点的资源情况和请求分配过程中，在时刻2的请求情况示意图。 [0033] 具体实施方式

[0034] 在P2P媒体网络中，媒体存储的单位为分段，传输单位为分块，点播和下载时按媒体分段定位源节点，直播时按频道定位源节点。整个网络按照物理区域划分成许多分区，分区内的每个用户节点归属一个媒体网关管理，这个媒体网关称为归属媒体网关。同时，每个媒体分段或直播频道都归属一个内容管理器进行管理。

[0035] 媒体加载时，分段的媒体数据文件被加载到初始发布区的局端节点上，把媒体描述文件加载到需要提供该媒体服务的分区媒体网络的业务网关上，并发布该媒体可以对所在分区的用户进行服务，分段的媒体数据加载完成后在初始发布区的媒体网关上进行登记和管理。

[0036] 用户选择播放一个频道和播放某个媒体分段时，先向业务网关取得媒体描述数据，然后向归属媒体网关请求足够数量的源节点(包括局端节点和用户节点)。如果本分区有足够的具备服务能力的源节点，则归属媒体网关返回源节点列表，用户节点向这些源节点发起连接并请求数据；如果本分区没有足够的具备服务能力的源节点，则需要向该媒体分段或直播频道归属的内容管理器请求返回分区媒体网关列表，用户节点依次向这些媒体网关请求源节点，直到满足为止。

[0037] 用户节点与这些源节点建立连接取得直播数据并解码播放，同时用户节点上报媒体网关自己具备的某个直播频道的内容。这种媒体网关加内容管理器的两级查询结构既保证了本地源优先，减少跨分区流量，同时也保证了网络的可扩展性。

[0038] 下面参照附图，对本发明的优选实施例作详细描述。

[0039] 参照图1所示，伙伴节点包括一个局端节点和多个用户节点(包括用户节点1、用户节点2、用户节点3)，局端节点直接从直播源取得数据并滚动缓存，每个用户节点可以从局端节点和其他用户节点取得数据。

[0040] 首先用户节点从归属分区的业务网关取得媒体描述数据，然后根据描述数据按分段向媒体网关取得该分段的若干源节点，这些源节点包括局端节点和用户节点。然后用户节点与这些源节点建立连接，进行媒体数据传输，并解码播放。在数据传输过程中，数据尽量利用用户源节点的服务能力，减轻局端源节点的负荷。

[0041] 局端节点主要用于解决用户源节点的服务能力波动问题，起码流补偿作 用，即当多个用户源节点不能及时提供直播数据时，由局端节点作为局端源节点进行补偿，这样一方面可以平滑用户节点服务能力的波动，保证接收客户端流畅播放，另一方面接收客户端的播放进度可以直接参考局端节点的码流进度，避免了播放进度的频繁调整。 [0042] 该方法包括以下步骤：

[0043] 1、局端节点引入直播流并按块进行滚动缓存。

[0044] 2、用户节点播放直播频道时，通过媒体网关取得具有播放频道内容的源节点，源节点包括局端源节点和正在收看该频道的用户源节点。

[0045] 用户节点得到源节点后，分别与这些源节点建立连接，并向源节点请求数据块。局端源节点为具有播放频道内容的局端节点，用户源节点为具有播放频道内容的用户节点，源节点定期向所述用户节点发送自身具备的数据块情况。

[0046] 3、用户节点根据局端源节点的缓存内容随机选择一个起始媒体块作为播放指针。 [0047] 4、用户节点在播放指针之后设置一个紧急窗口，紧急窗口内的数据块向局端源节点请求，紧急窗口外的数据块向用户源节点请求。

[0048] 当某个数据块离播放点很近时，需要快速取得，这种数据块称为紧急数据块，这种紧急数据块保存在紧急窗口下。紧急数据块需要向局端源节点请求，离播放点较远的数据块则向用户源节点请求取得。

[0049] 每个数据块的源节点按照以下方法分配：

[0050] (1)如果用户节点的数据块落入紧急窗口，则把该数据块的源节点确定为局端源节点；否则，该数据块的源节点从多个用户源节点中选择。

[0051] (2)选择那些具备所求数据块的用户节点，形成集合A。

[0052] (3)从A中选择那些当前没有向用户节点传输数据任务的其他用户节点，形成B。 [0053] (4)如果B非空，则随机从其中选择一个用户节点做源节点；如果B为空，则表明分配失败，等待下一次分配。

[0054] 5、用户节点每播放一个数据块，播放指针按照数据块前移一块，紧急窗口也随之前移一块，同时在用户节点中增加了一个待请求数据块。

[0055] 参照图2所示，对伙伴节点的资源情况和请求分配过程作详细描述，图2包括图2a、图2b和图2c。

[0056] 如图2a所示，用户节点1刚接入直播频道，起始播放块为N+1，落入紧急窗口的数据块N+1、N+2、N+3向局端节点请求，此时刻的局端节点是用户节点1的局端源节点。紧急窗口后面的数据块N+4和N+5分别向用户节点2和3请求数据块。用户节点2的数据块N+5因为不落在其紧急窗口中，所以向用户节点3请求数据块。用户节点3的数据块N+4由于落入其紧急窗口，因此向局端节点请求，此时刻的局端节点作用户节点3的局端源节点。用户节点1的数据块N+6和用户节点3的数据块N+6由于不在紧急窗口内，而且其他用户节点(在此为用户节点2和用户节点3)也都没有该数据块，因此暂时未分配源节点。 [0057] 如图2b所示，过了一个时间周期，到达时刻1，此时各用户节点(包括用户节点1、用户节点2、用户节点3)的播放指针和紧急窗口都往前移了一块，而且都新产生一个待请求的数据块。局端节点缓存内容也滚动往前一块，老化了数据块N，进入了新的数据块N+8。 [0058] 用户节点2向用户节点3请求的数据块N+5还在传输中，因此其待请求数据块N+6虽然用户节点3也有，但暂时不请求，用户节点1的数据块N+6则向用户节点3请求。 [0059] 如图2c所示，再过一个时间周期到时刻2，用户节点1向用户节点3请求数据块N+7，用户节点2则向用户节点1请求数据块N+6。

[0060] 从上可知，用户节点之间可以相互传输数据，后接入的用户节点可以为先接入的用户节点提供服务。每个用户节点都独立地进行数据请求，相互不会影响彼此的播放进程，从而确保了播放的流畅性。同时，由于局端节点和紧急窗口机制的引入，也保证了播放质量。