CN109474684A

CN109474684A - 一种获取直播视频流的方法、装置、终端设备及存储介质

Info

Publication number: CN109474684A
Application number: CN201811363027.1A
Authority: CN
Inventors: 冯修杰
Original assignee: Guangzhou Huya Information Technology Co Ltd
Current assignee: Guangzhou Huya Information Technology Co Ltd
Priority date: 2018-11-14
Filing date: 2018-11-14
Publication date: 2019-03-15
Anticipated expiration: 2038-11-14
Also published as: CN109474684B

Abstract

本申请公开一种获取直播视频流的方法、装置、终端设备及存储介质，该方法包括：直播客户端进入直播间后，向所述直播间对应的P2P网络中的至少两个节点发送连接请求；与响应所述连接请求的至少两个节点建立连接，与已连接的节点分别协商订阅指定数据包；在协商成功后，被订阅的节点通过其他节点从服务器获取数据包时，将指定数据包推送给直播客户端，所述数据包由服务器将直播视频流切割得到，所述服务器将数据包按照包括第一标识的自定义格式封装，所述第一标识用于描述每个封装后的数据包的唯一性；直播客户端根据获取的数据包的第一标识拼装得到直播视频流。旨在解决传统的P2P技术无法适用于对延时容忍率极低的直播场景的问题。

Description

一种获取直播视频流的方法、装置、终端设备及存储介质

技术领域

本申请涉及互联网领域，尤其涉及P2P网络领域。

背景技术

Peer-to-peer(P2P)是一种分布式网络，P2P网络的参与者共享他们所拥有的一部分硬件资源(处理能力、存储能力、网络连接能力、打印机等)，这些共享资源需要由网络提供服务和内容，能被其它对等节点(peer)直接访问而无需经过中间实体。在此网络中的参与者既是资源(服务和内容)提供者，又是资源获取者。

直播可快速准确的传递现场信息，强烈的临场感让越来越多的人通过网站、电脑或手机来观看直播。实时的直播视频流通常由服务器分发给对应的直播客户端，以供用户观看。一般情况，会有几十万甚至上百万的用户实时观看同一路直播数据流，若利用P2P的方式将直播视频流进行分发，可以极大减轻服务器的压力，降低带宽成本，提高各直播客户端获取直播视频流的效率。但是，传统的P2P技术中，通过P2P网络中各对等节点之间拉取数据，需要对等节点之间进行多次请求及响应交互，会存在延时问题，因此，传统的P2P技术无法适用在对延时容忍率极低的直播场景。

发明内容

为了解决上述技术问题，本申请提供一种获取直播视频流的方法、装置、终端设备及存储介质。

在本申请的第一方面，提供一种获取直播视频流的方法，包括步骤：

直播客户端进入直播间后，向所述直播间对应的P2P网络中的至少两个节点发送连接请求；与响应所述连接请求的至少两个节点建立连接后，向已连接的节点分别协商订阅指定数据包；

在协商成功后，被订阅的节点在通过其他节点从服务器获取到数据包时，将所述直播客户端订阅的指定数据包推送给所述直播客户端，其中，所述数据包由服务器将所述直播间对应的直播视频流切割得到，所述服务器将数据包按照自定义的格式封装，所述自定义的格式中包括第一标识，所述第一标识用于描述每个封装后的数据包的唯一性；

所述直播客户端根据获取的数据包的第一标识拼装得到直播视频流。

在一些例子中，不同的数据包根据第一标识被分成多个组，被订阅的不同节点各自推送的指定数据包属于不同分组。

在一些例子中，所述第一标识包括预设位数的编号；其中，各数据包所属分组根据自身第一标识确定，包括：

以数据包的编号为被除数，分组的组数为除数进行求余，根据所述求余的余数确定数据包所属分组。

在一些例子中，所述分组的组数根据所述直播视频流的码率确定。

在一些例子中，所述P2P网络中，任一节点被主动连接的其他节点数不大于第一设定阈值，任一节点主动连接的其他节点数不大于第二设定阈值，且所述第一设定阈值大于第二设定阈值。

在一些例子中，所述方法还包括步骤：

记录针对指定数据包与自身已连接的节点数量；

若所述节点数量小于预设值，则再次向所述直播间对应的P2P网络中符合预设条件的节点发送连接请求。

在一些例子中，所述直播客户端与已连接的节点间基于不可靠协议传输数据包；

所述直播客户端进入直播间后，还包括步骤：

所述直播客户端与服务器建立连接，在检测到数据包丢失后，向所述服务器请求传输所述丢失的数据包，所述直播客户端与所述服务器间基于可靠协议传输数据包。

在本申请的第二方面，提供一种获取直播视频流的装置，包括：

获取模块，用于在直播客户端进入直播间后，向所述直播间对应的P2P网络中的至少两个节点发送连接请求；与响应所述连接请求的至少两个节点建立连接后，向已连接的节点分别协商订阅指定数据包；

拼装模块，用于所述直播客户端根据获取的数据包的第一标识拼装得到直播视频流。

在本申请的第三方面，提供一种终端设备，包括：

处理器；以及

存储器，所述存储器被配置成存储计算机程序，所述计算机程序被配置成被所述处理器执行如前述第一方面任意一项方法所述的操作。

在本申请的第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行如前述第一方面任意一项方法所述的操作。

本申请实施例首先确定新加入P2P网络的直播客户端的订阅关系，并且从至少两个不同的节点订阅不同的指定数据包，被订阅在通过其他节点从服务器获取到数据包时，将所述直播客户端订阅的指定数据包发送给所述直播客户端，其中，所述数据包由服务器将所述直播间对应的直播视频流切割得到，所述服务器将数据包按照自定义的格式封装，所述自定义的格式中包括第一标识，所述第一标识用于描述每个封装后的数据包的唯一性；所述直播客户端根据获取的数据包的第一标识拼装得到直播视频流。以避免现有P2P技术中各节点通过拉流的方式，带来的请求及响应信息交互过多产生的延时以及对网络带宽的占用，保证直播客户端播放直播视频流的实时性，并且由于各直播客户端可以从不同的节点获取不同的指定数据包，并根据获取的数据包的第一标识拼装得到直播视频流，可以进一步提高各直播客户端获取直播视频流的效率，尤其适用于直播场景。

附图说明

图1为本申请实施例示例性示出的一种直播场景示意图；

图2为本申请实施例示例性示出的一获取直播视频流的方法的部分流程；

图3为本申请实施例示例性示出的一获取直播视频流的方法的部分流程；

图4a-图4c为本申请实施例中三种不同的服务器架构下搭建的网络；

图5为本申请实施例示例性示出的一P2P网络示意图；

图6为现有的P2P网络示意图；

图7a为本申请实施例示例性示出的一P2P网络示意图；

图7b为本申请实施例示例性示出的一P2P网络示意图；

图8为本申请实施例示例性示出的获取直播视频流的装置的示意图；

图9为本申请实施例示例性示出的一终端设备的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

参照图1，为本申请实施例示例性示出的一基于P2P网络的直播场景示意图，第一观众客户端、第二观众客户端、第三观众客户端及主播客户端分别被安装在终端设备110、120、130及140上，主播客户端可以通过屏幕捕捉，以及配合调用摄像头录制视频、拍摄照片等其他方式制作直播视频流，直播视频流包括一帧帧图像帧及音频数据，然后通过网络将制作的直播视频流发送给服务端100。服务端100用于提供直播的后台服务，例如保存各主播客户端与观众客户端的对应关系，P2P网络的管理，将直播视频流切割成若干数据包，将数据包按照自定义的格式封装，并进行封装后的数据包的分发等，当第一观众客户端、第二观众客户端及第三客户端与主播客户端在同一直播间内，服务端100可以通知第一观众客户端、第二观众客户端及第三观众客户端建立P2P网络，P2P网络中的第一观众客户端、第二观众客户端及第三观众客户端相互之间可以交互数据包，以减轻服务器的压力，提高各直播客户端获取直播视频流的效率。P2P网络中的直播客户端也被称为节点。

本申请实施例所述的是指众多用户聚合在一起的社交网络平台、即时通讯平台等，用户通过登录客户端的方式进入直播间，用户在直播间内以成员的身份存在，同一个直播间内包含有多种身份的成员，比如观众、主播等。用户可任意加入或退出直播间。对于具有一定权限的用户，其可添加或删除直播间成员，也可新建或解散直播间，这类具有权限的用户的身份为主播。在直播间内，任意多个成员可进行聊天、通话、视频或推送电子赠品等交互。

本申请实施例所述的“主播客户端”“观众客户端”可以指安装在终端设备上的软件，在某些情况下，所述直播客户端与观众客户端集成在一个软件上，当用户的身份为主播时，该客户端可以被称为主播客户端，当用户的身份是观众时，该客户端被称为观众客户端。本申请说明书中的直播客户端是对主播客户端和观众客户端的统称。

直播中实时的直播视频流通常由服务器分发给对应的直播客户端，以供用户观看。一般情况，会有几十万甚至上百万的用户实时观看同一路直播数据流，若利用P2P的方式将直播视频流进行分发，可以极大减轻服务器的压力，提高各直播客户端获取直播视频流的效率。但是，传统的P2P技术中，通过P2P网络中各对等节点之间拉取数据，需要对等节点之间进行多次请求及响应交互，会存在延时问题，因此，传统的P2P技术无法适用在对延时容忍率极低的直播场景。

为了解决上述技术问题，本申请实施例提供一种获取直播视频流的方法、装置、终端设备及存储介质。参照图2，为本申请实施例示例性示出的一种获取直播视频流的方法的流程图，所述方法包括步骤：

某个直播间中已具有一定数据量的观众客户端，这些已进入直播间的观众客户端建立P2P网络后，S210：若有新的直播客户端进入直播间后，向所述直播间对应的P2P网络中的至少两个节点发送连接请求；

上述新的直播客户端S220：与响应所述连接请求的至少两个节点建立连接后，与已连接的节点分别协商订阅指定数据包；

S230：在协商成功后，被订阅的节点在通过其他节点从服务器获取到数据包时，将所述直播客户端订阅的指定数据包推送给所述直播客户端；

本申请实施例所述的数据包由服务器将所述直播间对应的直播视频流切割成得到，所述服务器将数据包按照自定义的格式封装，所述自定义的格式中包括第一标识，所述第一标识用于描述每个封装后的数据包的唯一性。需要说明的是，在数据包封装阶段，为了使切割后的数据包能够被对客户端接收后有序拼装以及客户端之间形成对等节点后能够交互数据包，服务器可以为每个数据包编号，作为描述每个数据包唯一标识的字段，所述唯一标识为第一标识，某些例子中，可以自定义数据包的格式来实现此目的，自定义的格式中可以规定特定字段作为此唯一标识。在一些例子中，本申请提出的第一标识可以是同一直播视频流中用于区分其他数据包的唯一标识。当然，并不排除其他方式来实现此目的。

S240：所述直播客户端根据获取的数据包的第一标识拼装得到直播视频流。

在一个具体的例子中，参照图3，为申请实施例实例性示出的一获取直播视频流的方法的流程图，所述方法包括步骤：

S201：主播客户端将采集的直播视频流发送给服务器。

S202：服务器将接收到的直播视频流切割成若干数据包，并将每个数据包按照自定义的格式封装，所述自定义的格式中包括第一标识，第一标识用于描述每个数据包唯一性。

本步骤中，可以将直播视频流切割成若干类指定数据包，并根据数据包的第一标识将数据包分为两类，分别是第一类指定数据包以及第二指定数据包。

S203：与所述直播客户端在同一直播间的观众客户端建立P2P网络，服务器将所述封装的数据包分发给P2P网络中订阅服务器的节点。

S211：若有新的直播客户端a进入直播间后，从服务器获取节点列表。

一些例子中，服务器会将P2P网络中一定数据量的节点的地址信息(例如IP地址等)以节点列表的形式发送给直播客户端a。可以理解，上述一定数量的节点可以根据直播客户端a的所在终端设备的位置信息(例如所在区域)确定，例如挑选一定数量距离直播客户端a较近的节点。

在一些例子中，本步骤新的直播客户端a进入直播间后，该直播客户端a向服务器注册，注册后才从服务器获取节点列表。

S212：直播客户端a根据所述节点列表，向所述直播间对应的P2P网络中的至少两个符合预设条件的节点发送连接请求。

在一些例子中，所述预设条件的节点指的是节点列表中的全部节点，直播客户端a，可以向节点列表中的部分或全部节点发送连接请求。

一些例子中，直播客户端a向分别向订阅有指定数据包的节点中符合预设条件的节点发送连接请求，例如，将直播视频流切割成2类指定数据包，直播客户端a向订阅有第一类指定数据包的节点中符合预设条件的节点发送连接请求，以及向订阅有第二类指定数据包的节点中符合预设条件的节点发送连接请求。

S220：与响应所述连接请求的至少两个节点建立连接后，直播客户端a向已连接的节点分别协商订阅指定数据包。

依然以将直播视频流切割成2类指定数据包为例，假设直播客户端a与3个订阅了第一类指定数据包的节点建立连接，分别是节点1、2和3；直播客户端a与3个订阅了第二类指定数据包的节点建立连接，分别是节点4、5和6，那么可以是：直播客户端a从节点1、2和3中至少挑选一个协商订阅第一类指定数据包；直播客户端b从节点4、5和6中至少挑选一个协商订阅第二类指定数据包。当然，上述订阅过程可以是相互的，例如直播客户端a从节点a订阅第一类指定数据包，节点a可以从直播客户端a订阅第二类指定数据包。

在一些例子中，与响应所述连接请求的至少两个节点建立连接后，还可以与已连接的节点周期性交互信令消息，以使了解两个节点间的网络状况，以便在网络状况不佳时，更换连接对象，所述信令信息可以包括：丢包率、延时、网速和/或上行带宽。

S230：在协商成功后，被订阅的节点在通过其他节点从服务器获取到数据包时，将所述直播客户端订阅的指定数据包推送给所述直播客户端。

本步骤中，每个节点获取数据包后，会将指定数据包即刻推送给订阅自身的节点，以使订阅自身的节点能快速接收到指定数据包。

S240：所述直播客户端a根据获取的数据包的第一标识拼装得到直播视频流。

本申请实施例首先确定新加入P2P网络的直播客户端的订阅关系，并且从至少两个不同的节点订阅不同的指定数据包，被订阅在通过其他节点从服务器获取到数据包时，将所述直播客户端订阅的指定数据包发送给所述直播客户端，以避免采用现有P2P技术中各节点通过拉流的方式，带来的请求及响应信息交互过多产生的延时以及对网络带宽的占用，保证直播客户端播放直播视频流的实时性，并且由于各直播客户端可以从不同的节点获取不同的指定数据包，并根据获取的数据包的第一标识拼装得到直播视频流，可以进一步提高各直播客户端获取直播视频流的效率，尤其适用于直播场景。

进一步，图2和图3所述的方法不同于传统的P2P模式，首先将直播视频流切割成数据包而不是文件块，文件块的大小可能在上百KB，而相对于文件块来说，数据包的可切割粒度更小，可以作为更小的传输单元在网络中传输，例如在考虑切割后的数据包的大小时，可以结合互联网网络层的传输特性来设计，使得数据包的大小与P2P网络中各连接通道的传输带宽匹配。举例来说，各对等节点之间建立的通道可以是UDP通道，每个数据包的大小可以是1KB左右，小于MTU(互联网网络层最大传输单元)，这样，每个数据包可以由1个IP包传输，不需要出现基于IP包拆包，因此比切割文件的方式效率更高，从而使得具有更广泛的适用场景。

本申请实施例提出的服务器可以由多种实体承担，这取决于设计者对不同网络设备的角色划分。例如，图4a、图4b、图4c是三种不同场景下的网络架构，可以看出，不同业务模式下，由于业务或设备管理的需求不同，可以由不同类型的服务器设备承担上述服务器的功能。图4a中，第一服务器承担收集直播视频流的角色，第二服务器承担切割数据包的角色，第三服务器作为向对等节点分发数据包的角色。图4b中，第一服务器集成了收集直播视频流和切割数据包的功能，第二服务器作为分发数据包的服务器。图4c中，服务器将收集直播视频流、切割数据包、分发数据包的功能集于一体。需要指出，除了图4a、图4b及图4c所列举的示例以外，并不排除有其他形式的网络架构或服务器功能。

为了进一步提高P2P网络中数据传输的效率，在一些例子中，不同的数据包根据第一标识被分成多个组，被订阅的不同节点各自推送的指定数据包属于不同分组。

具体的，一些例子中，所述第一标识可以是预定位数的编号，可以用各数据包的编号对分组数进行求余，根据求余的余数确定各数据包的分组。例如：一直播视频流被切割成了编号为1-20的数据包，分组数为5，用各数据包的编号对5进行求余，例如编号为1，1/5的余数是1，余数为1的都属于第一组，所以编号为1的数据包属于第一组，以此类推，可以确定各数据包的分组情况，每组分组的数据包组成一路子流，例如余数为0的数据包属于0号子流，余数为1的数据包属于1号子流，以此类推。在一些例子中，所述分组数可以根据直播视频流的码率或分辨率或承担分发数据包任务的服务器的数量确定，可以有效利用每个节点的上行带宽，保证资源最有效的利用。本申请实施例不限定具体求余的策略。将数据包分组后，服务器可以基于分组将数据包分发给P2P网络中的节点，例如，可以由多个服务器分别将不同组的数据包发送给P2P网络中从服务器获取资源数据的节点，以提高数据传输效率，及增加节点播放直播视频流的起播速度。当然，在一些例子中，将数据包分组后，本实施例中所述的“指定数据包”可以是某个分组对应的数据包，即可以是每个节点从不同的节点获取不同分组的数据包，以进一步提高P2P网络中数据传输效率；例如，直播视频流分成若干组，如2组，这两个组分别是0号子流及1号子流，用每个数据包的编号除以2，根据余数确定分组，即编号为偶数的数据包属于0号子流，编号为奇数的数据包属于1号子流，参照图5，如左图，节点1从服务器订阅0号子流，节点2和节点3从节点1订阅0号子流，节点4和5从节点2订阅0号子流，节点6从节点3订阅0号子流，首先服务器将0号子流推送给节点1，节点1获取0号子流后，主动将0号子流推送给节点2和节点3，然后节点2获取0号子流后，主动将0号子流推送给节点4和节点5；如图5右图，对于1号子流，订阅关系为：节点6从服务器订阅，节点4和节点5从节点6订阅，节点1、2及3从节点5订阅，服务器将1号子流推送给节点6，节点6获取1号子流后，将1号子流主动推送给从节点6订阅1号子流的节点4和节点5，节点5接收到1号子流后，主动将1号子流推送给节点1、2及3。

在实际应用中，若在建立P2P网络时沿用现有的P2P技术，P2P网络易出现饱和现象，使得新加入P2P网络的节点无法从其他节点获得指定数据包。例如，参照图6，节点1、2及3两两互为指定数据包提供者及指定数据包获取者，如每个节点最多作为两个节点的指定数据包提供者，那么在有新的节点进入时，节点1、2及3无法给新进入的节点提供指定数据包。为了解决上述问题，本申请实施还可以对建立P2P网络阶段进行改进，在一些例子中，规定所述P2P网络中，任一节点被主动连接的其他节点数不大于第一设定阈值，任一节点主动连接的其他节点数不大于第二设定阈值，且所述第一设定阈值大于第二设定阈值。例如参照图7a，为本申请实施例示出的P2P网络示意图，例如第一设定阈值为3，第二设定阈值为2，节点1主动与2个节点建立连接，被3个节点主动连接，那么节点1被主动连接的其他节点数为3，等于第一设定阈值，节点1主动连接的其他节点数为2，等于第二设定阈值，此时，节点1无法主动连接其他节点，也无法被其他节点成功地主动连接；节点2主动连接1个节点，被2个节点主动连接，那么节点2被主动连接的其他节点数为2，小于第一设定阈值，节点2主动连接的其他节点数为1，小于第二设定阈值，此时，节点2还可以主动连接为2-1＝1个节点，节点2还允许被3-2＝1个其他节点主动连接。

至此，不同于传统的P2P网络的组建方法，本申请实施例提出的P2P网络中，任一节点被主动连接的其他节点数不大于第一设定阈值，任一节点主动连接的其他节点数不大于第二设定阈值，且所述第一设定阈值大于第二设定阈值。也就是说，本申请实施例中使每个节点的允许被主动连接的节点数(第一设定阈值)大于允许主动连接其他节点数(第二设定阈值)，使得按照本申请实施例的方法，无论整个P2P网络如何组建，一定存在被其他节点主动连接的机会，以致通过本申请实施例组建的P2P网络不可能发生饱和，最终使得新加入的节点能够更容易接入P2P网络中。例如，参照图7b，以P2P网络中有3个节点为例，分别是节点1、节点2和节点3，该P2P网络中，第一设定阈值是2，第二设定阈值为1，即每个节点允许主动连接的其他节点数为1，允许被主动连接的其他节点数为2。若节点1主动连接节点2，那么节点1达到第二设定阈值，节点1无法主动连接其他节点，但是可以被1个节点主动连接；此时，节点3可以主动连接节点1或者节点2，由于节点3主动连接节点1或者节点2的情况相似，为了不重复描述，图7b中以节点3主动连接节点1为例作为示意，此时，节点1和3均达到第二设定阈值，均无法主动连接其他节点，但均可以被1个节点主动连接，此时的P2P网络中，节点2可以主动连接1个其他节点，由于节点1和2已经建立连接，所以，节点2向节点3主动发送连接请求，到此时节点1-3完成P2P网络的建立，该P2P网络中，没有任何节点可以主动向其他节点发送连接请求，而3个节点均可被其他节点主动连接。当节点4进入该P2P网络时，由于该P2P网络中的节点1-3均无法主动连接其他节点，所以，由新入该P2P网络的节点4向节点1-3中任一节点发送连接请求(例如图7b所示的节点4主动连接节点2)，以建立新的P2P网络。从图7b的例子可以看出，通过本申请实施例的方法，并且无论节点1-3间的连接关系如何，整个P2P网络中存在3个允许被其他节点主动连接的机会，网络不会发生饱和；并且节点4加入后的新的P2P网络中，节点1和节点3均可以允许被1个节点主动连接，节点4则被允许被2个节点主动连接，新的P2P网络也存在4个允许被其他节点主动连接的机会，也不会出现饱和。在实际应用中，节点在播放直播视频流时可能会出现短暂的延时或卡顿问题，申请人发现由于直播与传统的P2P技术应用的场景具有很大差别，传统的P2P技术主要应用在共享视频或音频资料的场景(例如视频点播等网站的视频指定数据包下载)，相比与上述场景，直播存在每时每刻均可能有大量的用户进出直播间的特点，使得基于直播的P2P网络时刻动态变化，并且变化频率极快，但这会造成播放直播视频流时出现短暂的延时或卡顿问题。为了解决上述直播中的问题，在一些例子中，本申请实施例提出的获取直播视频流的方法还可以包括步骤：记录与自身针对指定数据包已连接的节点数量；若所述节点数量小于预设值，则再次向所述直播间对应的P2P网络中符合预设条件的节点发送连接请求。依然以将直播视频流切割成2类指定数据包为例，假设直播客户端a与3个订阅了第一类指定数据包的节点建立连接，分别是节点1、2和3；直播客户端a与3个订阅了第二类指定数据包的节点建立连接，分别是节点4、5和6；那么直播客户端a记录与自身关于第一类指定数据包已连接的第一节点数量为3，与自身关于第二类指定数据包已连接的第二节点数量也为3，假设第一节点数量对应的第一预设值为4，此时第一节点数量少于第一预设值，那么再次向所述直播间对应的P2P网络中符合预设条件的节点发送连接请求；若第二节点数量对应的第二预设值为3，此时第二节点数量等于第二预设值，那么无需额外操作。

上述实施例通过保证本端成功连接的节点数量不少于预设值，使得本端获取直播视频流的节点退出直播间，或是网络故障时，本端可以快速从其他成功连接的节点获取直播视频流，以保证本端用户观看时延时和卡顿较少，极好地适应直播场景。

本申请还可以通过给节点分类的方式实现上述实施例的效果。在一个具体的例子中，P2P网络中的每个节点可以维护或记录不同类型的节点，节点的类型包括：候选节点、活跃节点、传输节点、淘汰节点或/和僵死节点。其中，

候选节点，指从服务器获取的节点列表中的节点，但尚未建立连接。

活跃节点，指从候选节点中取出，并与本节点已建立连接并保持连接状态的节点。本节点与活跃节点之间会周期性的交互信令信息，包括：丢包率、延时、网速和/或上行带宽等。

传输节点，指的是所述候选节点中可以用于获取指定数据包的节点。

淘汰节点，指的是活跃节点中质量较差，而被本节点主动放弃的节点。

僵死节点，可以分为两种，其中一种是候选节点中请求连接，但未连接成功的节点；另一种是传输节点中，无法传输数据的节点，此种情况可能是死机或断网造成的。

当然，若数据包根据编号被分组，在一些例子中，P2P网络中传输节点可以包括订阅节点，例如，节点1从节点2获取1号子流，节点2是节点1对应与1号子流的订阅节点，节点1从节点3获取0号子流，节点3是节点1对应与0号子流的订阅节点。

每个节点均可以维护一个队列，用于记录针对某指定数据包的活跃节点，当存在淘汰节点和僵死节点时，将活跃节点中的淘汰节点和僵死节点剔除，并且当该节点发现可用节点的数量少于预设值时，向服务器再次请求节点列表，向节点列表中的候选节点发送连接请求，以使每个节点对应的可用节点的数量不少于预设值。可以理解，上述每类节点均可以用一队列进行维护。

在一些例子中，本申请实施例所述的P2P网络中，节点与及节点之间可以通过不可靠协议传输数据包，例如UDP协议，以进一步提高数据传输效率。当然为了在丢包时，能快速以及及时重传数据包，一些例子中，节点与服务器之间可以通过可靠协议传输数据包，例如基于TCP协议的HTTP协议，并且P2P网络中的各节点与服务器保持连接状态，若出现丢包，节点可以向服务器请求重传丢失的数据包。

请参见图8，为本申请实施例示例性示出的一种获取直播视频流装置800，包括：

处理模块810，用于直播客户端进入直播间后，向所述直播间对应的P2P网络中的至少两个节点发送连接请求；与响应所述连接请求的至少两个节点建立连接后，向已连接的节点分别协商订阅指定数据包；在协商成功后，被订阅的节点在通过其他节点从服务器获取到数据包时，将所述直播客户端订阅的指定数据包推送给所述直播客户端，其中，所述数据包由服务器将所述直播间对应的直播视频流切割得到，所述服务器将数据包按照自定义的格式封装，所述自定义的格式中包括第一标识，所述第一标识用于描述每个封装后的数据包的唯一性；

拼装模块820，用于所述直播客户端根据获取的数据包的第一标识拼装得到直播视频流。

图8中获取直播视频流的传输装置的实施例可以应用在终端设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器终端设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图9所示，为本申请获取直播视频流的装置所在客户端终端设备的一种硬件结构图，除了图9所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的客户端设备通常根据该设备的实际功能，还可以包括其他硬件，对此不再赘述。处理器被用于执行：

上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

在本申请实施例中，计算机可读存储介质可以是多种形式，比如，在不同的例子中，所述机器可读存储介质可以是：RAM(Radom Access Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。特殊的，所述的计算机可读介质还可以是纸张或者其他合适的能够打印程序的介质。使用这些介质，这些程序可以被通过电学的方式获取到(例如，光学扫描)、可以被以合适的方式编译、解释和处理，然后可以被存储到计算机介质中。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims

1.一种获取直播视频流的方法，其特征在于，包括步骤：

直播客户端进入直播间后，向所述直播间对应的P2P网络中的至少两个节点发送连接请求；与响应所述连接请求的至少两个节点建立连接后，与已连接的节点分别协商订阅指定数据包；

2.根据权利要求1所述的方法，其特征在于，不同的数据包根据第一标识被分成多个组，被订阅的不同节点各自推送的指定数据包属于不同分组。

3.根据权利要求2所述的方法，其特征在于，所述第一标识包括预设位数的编号；其中，各数据包所属分组根据自身第一标识确定，包括：

4.根据权利要求2所述的方法，其特征在于，所述分组的组数根据所述直播视频流的码率确定。

5.根据权利要求1所述的方法，其特征在于，所述P2P网络中，任一节点被主动连接的其他节点数不大于第一设定阈值，任一节点主动连接的其他节点数不大于第二设定阈值，且所述第一设定阈值大于第二设定阈值。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括步骤：

记录针对指定数据包与自身已连接的节点数量；

7.根据权利要求1所述的方法，其特征在于，所述直播客户端与已连接的节点间基于不可靠协议传输数据包；

所述直播客户端进入直播间后，还包括步骤：

8.一种获取直播视频流的装置，其特征在于，包括：

9.一种终端设备，其特征在于，包括：

处理器；以及

存储器，所述存储器被配置成存储计算机程序，所述计算机程序被配置成被所述处理器执行如权利要求1至7任意一项方法所述的操作。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行如权利要求1至7任意一项方法所述的操作。