直播链路处理方法、装置、计算设备及计算机存储介质

技术领域

本申请实施例涉及直播技术领域，具体涉及一种直播链路处理方法、装置、计算设备及计算机存储介质。

背景技术

在直播架构中，主播利用主播端对直播源流进行推流，转码系统可对直播源流进行直播转码得到不同清晰度的转码流，观众可利用观看端拉取直播源流或者转码流进行观看。流数据帧从主播端传输到观看端这过程中的延时可称为直播延时，直播延时的长短直接影响观众的观看体验，尤其是对于互动性较强的直播间，直播延时较长会导致直播间的直播内容出现延迟、不连贯等情况，影响直播互动。然而，在实际的直播场景中，很难合理地管理直播链路，经常会因为转码、上行节点跳转等情况而导致直播链路变长，进而导致直播延时变长，影响用户的直播体验。

发明内容

鉴于上述问题，本申请提出了一种直播链路处理方法、装置、计算设备及计算机存储介质，用于解决以下问题：现有的直播链路处理方式不够合理，导致直播延时较长，影响用户的直播体验。

根据本申请实施例的一个方面，提供了一种直播链路处理方法，包括：

接收观看端的直播流获取请求，直播流获取请求用于获取直播间的直播流；

检测直播间是否设置有预设延时标签；

若设置有预设延时标签，则为观看端分配源流拉取链路，以供观看端根据源流拉取链路获取直播流中的直播源流。

进一步地，该方法还包括：

接收主播端在目标直播分区中发送的开播请求，根据开播请求为主播端的直播间设置预设延时标签，并根据预设延时标签对直播间对应的转码任务进行管理。

进一步地，根据预设延时标签对直播间对应的转码任务进行管理进一步包括：

若直播间的源流码率和直播间的观看人数不符合第一预设转码策略，则不下发转码任务；

若直播间的源流码率和直播间的观看人数符合第一预设转码策略，则按照第一预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流。

进一步地，该方法还包括：

若未设置有预设延时标签，则根据直播间的源流码率和直播间的观看人数，为观看端分配源流拉取链路或者转码流拉取链路。

进一步地，根据直播间的源流码率和直播间的观看人数，为观看端分配源流拉取链路或者转码流拉取链路进一步包括：

若直播间的源流码率和直播间的观看人数不符合第二预设转码策略，则为观看端分配源流拉取链路；

若直播间的源流码率和直播间的观看人数符合第二预设转码策略，则按照第二预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流，并为观看端分配源流拉取链路或者转码流拉取链路。

进一步地，为观看端分配源流拉取链路或者转码流拉取链路进一步包括：

若直播间的源流码率和直播间的观看人数符合预设源流拉取条件，则为观看端分配源流拉取链路；

若直播间的源流码率和直播间的观看人数不符合预设源流拉取条件，则为观看端分配转码流拉取链路。

进一步地，源流拉取链路为通过下行内容分发网络从上行边缘节点拉取直播流中的直播源流的链路；

转码流拉取链路为通过下行内容分发网络从转码系统拉取直播流中的转码流的链路。

进一步地，该方法还包括：

若未设置有预设延时标签，则监测在直播过程中是否接收到观看端和/或主播端的目标互动请求；

若接收到目标互动请求，则为目标互动请求对应的直播间添加预设延时标签。

进一步地，目标互动请求包括：弹幕请求、视频连麦请求和/或语音连麦请求。

进一步地，该方法还包括：

接收观看端的清晰度调整请求，清晰度调整请求用于将直播流的清晰度调整为第一目标清晰度；

根据清晰度调整请求，为观看端分配第一目标清晰度对应的直播流的拉取链路。

进一步地，该方法还包括：

采集观看端在直播过程中产生的卡顿数据；

根据卡顿数据，为观看端分配第二目标清晰度对应的直播流的拉取链路；其中，第二目标清晰度低于观看端当前所拉取的直播流的清晰度。

根据本申请实施例的另一方面，提供了一种直播链路处理装置，包括：

接收模块，适于接收观看端的直播流获取请求，直播流获取请求用于获取直播间的直播流；

检测模块，适于检测直播间是否设置有预设延时标签；

处理模块，适于若检测模块检测得到设置有预设延时标签，则为观看端分配源流拉取链路，以供观看端根据源流拉取链路获取直播流中的直播源流。

根据本申请实施例的又一方面，提供了一种计算设备，包括：处理器、存储器、通信接口和通信总线，处理器、存储器和通信接口通过通信总线完成相互间的通信；

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述直播链路处理方法对应的操作。

根据本申请实施例的再一方面，提供了一种计算机存储介质，存储介质中存储有至少一可执行指令，可执行指令使处理器执行如上述直播链路处理方法对应的操作。

根据本申请实施例提供的直播链路处理方法、装置、计算设备及计算机存储介质，通过目标直播分区便捷地对直播间进行标签设置，以实现对具有低延时需求的直播间的有效标识和识别；并且为设置有预设延时标签的直播间和未设置有预设延时标签的直播间提供了不同的直播链路分配方式，联动直播间清晰度调度，当观看端请求拉流时，通过检测直播流获取请求对应的直播间是否设置有预设延时标签来确定直播链路分配方式；针对设置有预设延时标签的直播间，为观看端分配源流拉取链路，使得观看端拉取直播源流，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时；另外，动态监测直播间情况，根据直播间的源流码率和直播间的观看人数，及时下发或停止转码任务，实现了对直播间对应的转码任务的动态管理，既有效控制了带宽消耗，又尽可能地缩短直播过程中主播端到观看端链路，有效降低了直播延时，进一步提升了主播和观众的直播体验。

上述说明仅是本申请实施例技术方案的概述，为了能够更清楚了解本申请实施例的技术手段，而可依照说明书的内容予以实施，并且为了让本申请实施例的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请实施例的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请实施例的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了直播全链路的示意图；

图2示出了根据本申请一个实施例的直播链路处理方法的流程示意图；

图3示出了根据本申请另一个实施例的直播链路处理方法的流程示意图；

图4示出了根据本申请一个实施例的直播链路处理装置的结构框图；

图5示出了根据本申请一个实施例的一种计算设备的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

直播全链路：是指从主播端到观看端完整的直播传输过程，在这个过程中涉及多个环节和技术组成部分，包括采集、编码、传输、分发和播放等环节。

直播流：是指实时传输音视频内容的数据流，具有实时性和互动性，能够被作为一个稳定的和连续的流通过网络传输给观众观看；且直播推流过程是一个长连接，除非主播主动断流，否则直播应一直是持续的。

直播转码：是指将直播流从一个编码格式转换为另一个编码格式，以便适应不同的网络条件或设备要求。

转码系统：用于对直播流对应的源流进行转码处理的功能系统。

CDN：内容分发网络(Content Delivery Network)，是一种用于加速和优化网络内容传输的技术架构，是构建在现有网络基础之上的智能虚拟网络；其依靠部署在各地的边缘服务器，具有内容复制与缓存、就近访问、负载均衡和动态内容加速等功能，能够提高加载速度、减轻源服务器的压力、提高稳定性等。

回源：在CDN领域中，如果下行内容分发网络(即下行CDN)没有观众请求的资源会请求上行边缘节点或转码系统而获得该资源并进行缓存的过程。

直播间：在直播服务中，每个主播有一个唯一的标识符，即直播间标识，例如房间号等，用户可以以直播间标识进入至该主播的直播观看页面。

清晰度：影像上各细部影纹及其边界的清晰程度。

码率：数据传输时单位时间内传送的数据位数。

为了便于理解本申请，下面先对直播全链路进行介绍，图1示出了直播全链路的示意图，如图1所示，主播利用主播端将直播源流推流到上行边缘节点，转码系统从上行边缘节点拉取一部分码率较高、观看人数较多的直播源流，并对其进行编解码后输出多个清晰度的转码流供下行CDN回源拉流。直播源流也可直接由下行CDN进行拉流。观众通过观看端从CDN回源直播源流或转码流进行拉流观看。整个过程形成了直播全链路。

在直播场景中，对直播源流进行转码是为了适应观众不同的网络条件或设备要求，降低带宽消耗，提高观众的直播体验，但转码流是由转码系统从上行边缘节点中拉取，进行编解码后重新输出的，再由下行CDN进行回源拉流，这个过程会比源流拉取链路更长，导致直播延时更长，很容易影响观众的观看体验。然而在现有技术中，直播间的转码链路的开启和增加不够合理，会为具有低延时需求的直播间即互动性较强的直播间开启转码链路，为观看端分配转码流拉取链路，导致直播过程中主播端到观看端链路增加，使得观众在直播间观看转码流时延时较高，影响观众和主播之间的实时互动，影响直播体验。

图2示出了根据本申请一个实施例的直播链路处理方法的流程示意图，如图2所示，该方法包括如下步骤：

步骤S201，接收观看端的直播流获取请求。

当观众想要观看某直播间的直播时，可通过观看端进入该直播间，那么观看端向服务端发送针对该直播间的直播流获取请求，直播流获取请求用于获取直播间的直播流，服务端接收该直播流获取请求。其中，按照是否经过转码，将直播流进一步分为直播源流和转码流。直播源流是指主播端向上行边缘节点所发送的数据流，转码流是指由转码系统对直播源流进行转码处理所得到的不同清晰度的数据流。转码流的清晰度不同于直播源流的清晰度，通常情况下，转码流的清晰度低于直播源流的清晰度。例如，直播源流的清晰度为蓝光，通过对直播源流进行转码可得到一个或多个转码流，转码流的清晰度可包括流畅、标清、高清、超清等。

步骤S202，检测直播间是否设置有预设延时标签；若是，则执行步骤S203；若否，则执行步骤S204。

为了保证具有低延时需求的直播间能够获得较低直播延时，在本申请实施例中，直播平台中可以设置目标直播分区，目标直播分区具体可为低延时直播分区，用于表示在该分区内开播的直播间均具有低延时需求，在实际的直播场景中，目标直播分区可包括直播连麦分区、直播PK分区、语聊房分区等。可通过为目标直播分区的直播间设置预设延时标签，利用预设延时标签来标识对应的直播间具有低延时需求，以实现对具有低延时需求的直播间的有效识别。具体地，当主播通过主播端在目标直播分区中进行开播时，为该主播端的直播间设置预设延时标签。本领域技术人员可根据实际需要确定预设延时标签的标签内容，此处不做限定。

在本申请实施例中，为设置有预设延时标签的直播间和未设置有预设延时标签的直播间提供了不同的直播链路分配方式。在服务端接收到观看端的直播流获取请求之后，检测直播流获取请求对应的直播间是否设置有预设延时标签。若经检测得到该直播间设置有预设延时标签，说明该直播间具有低延时需求，则执行步骤S203；若经检测得到该直播间未设置有预设延时标签，则执行步骤S204。

步骤S203，为观看端分配源流拉取链路，以供观看端根据源流拉取链路获取直播流中的直播源流。

若经步骤S202检测得到设置有预设延时标签，说明该直播间具有低延时需求，则为观看端分配源流拉取链路，其中，源流拉取链路为通过下行内容分发网络从上行边缘节点拉取直播流中的直播源流的链路。通过这种处理方式，使得观看端能够根据源流拉取链路通过下行内容分发网络直接从上行边缘节点获取直播流中的直播源流，而不是从转码系统拉取转码流，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时。

步骤S204，根据直播间的源流码率和直播间的观看人数，为观看端分配源流拉取链路或者转码流拉取链路。

考虑到可能存在具有低延时需求的主播而未在目标直播分区进行开播的情况，本申请实施例针对未检测到预设延时标签的情况，充分结合直播间的源流码率和直播间的观看人数，来确定为观看端分配源流拉取链路还是分配转码流拉取链路，动态调度流拉取链路，以尽可能地减少直播过程中主播端到观看端链路，优化直播延时。

根据本申请实施例提供的直播链路处理方法，利用预设延时标签来标识对应的直播间具有低延时需求，以实现对具有低延时需求的直播间的有效标识和识别；并且为设置有预设延时标签的直播间和未设置有预设延时标签的直播间提供了不同的直播链路分配方式，当观看端请求拉流时，通过检测直播流获取请求对应的直播间是否设置有预设延时标签来确定直播链路分配方式，针对设置有预设延时标签的直播间，为观看端分配源流拉取链路，使得观看端拉取直播源流，而不是从转码系统拉取转码流，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时，有效地提升了用户的直播体验。

图3示出了根据本申请另一个实施例的直播链路处理方法的流程示意图，如图3所示，该方法包括如下步骤：

步骤S301，接收主播端在目标直播分区中发送的开播请求，根据开播请求为主播端的直播间设置预设延时标签，并根据预设延时标签对直播间对应的转码任务进行管理。

其中，可在直播平台中可以设置目标直播分区，目标直播分区是指低延时直播分区，可包括直播连麦分区、直播PK分区、语聊房分区等。当主播认为自己直播间的直播内容具有低延时需求时，主播可通过主播端在目标直播分区中进行开播。具体地，主播通过主播端在目标直播分区中发送开播请求，服务端接收该开播请求，根据开播请求为主播端的直播间设置预设延时标签，以标识该直播间具有低延时需求。在完成对直播间的预设延时标签的设置后，可自动向转码系统同步直播间的预设延时标签，以便转码系统对具有预设延时标签的直播间对应的转码任务和转码链路进行动态管理。

针对设置有预设延时标签的直播间，实时监测直播间的源流码率和直播间的观看人数，可根据直播间的源流码率和直播间的观看人数来实现对直播间对应的转码任务的动态管理。具体地，可针对设置有预设延时标签的直播间，预先设置第一预设转码策略，第一预设转码策略中记录有针对设置有预设延时标签的直播间进行逐级开启转码链路时对应的直播间的源流码率所需满足的范围以及直播间的观看人数所需满足的范围。表1示出了一种第一预设转码策略。

表1第一预设转码策略

具体地，若直播间的源流码率和直播间的观看人数不符合第一预设转码策略，则不下发转码任务，若该直播间存在已有的转码任务和转码链路，则可对已有转码任务进行停止处理，并去除转码链路；若直播间的源流码率和直播间的观看人数符合第一预设转码策略，则按照第一预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流。其中，一条转码链路对应于转码一种清晰度的转码流，按照第一预设转码策略，根据直播间的源流码率和直播间的观看人数的增多，进行逐级开启多个转码链路，从而增加多个清晰度的转码流，以便根据观看端的清晰度调整请求进行清晰度调整或者在出现直播播放卡顿时自动降低清晰度。

步骤S302，接收观看端的直播流获取请求。

当观众想要观看某直播间的直播时，可通过观看端进入该直播间，那么观看端向服务端发送针对该直播间的直播流获取请求，服务端接收该直播流获取请求。其中，直播流获取请求包含有观看端标识、直播间标识、请求时间等信息。

步骤S303，检测直播间是否设置有预设延时标签；若是，则执行步骤S304；若否，则执行步骤S305。

在本申请实施例中，为设置有预设延时标签的直播间和未设置有预设延时标签的直播间提供了不同的直播链路分配方式。在服务端接收到观看端的直播流获取请求之后，检测直播流获取请求对应的直播间是否设置有预设延时标签。若经检测得到该直播间设置有预设延时标签，说明该直播间具有低延时需求，则执行步骤S304；若经检测得到该直播间未设置有预设延时标签，则执行步骤S305。

步骤S304，为观看端分配源流拉取链路，以供观看端根据源流拉取链路获取直播流中的直播源流。

在检测得到设置有预设延时标签的情况下，为观看端分配源流拉取链路。其中，源流拉取链路为通过下行内容分发网络从上行边缘节点拉取直播流中的直播源流的链路。观看端根据源流拉取链路，通过下行内容分发网络直接从上行边缘节点获取直播流中的直播源流，而不是从转码系统拉取转码流，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时。

本申请实施例联动直播间清晰度调度，当观众进入直播间时服务端优先为观看端分配源流拉取链路，如果出现直播播放卡顿时可自动降低清晰度，从而保证了网速较好的观众可以继续低延时互动，并保证了网速较差的观众能够正常观看直播，而且还有助于降低观众到CDN请求的带宽，降低带宽的消耗，节约边缘计算带宽成本。

步骤S305，判断直播间的源流码率和直播间的观看人数是否符合第二预设转码策略；若是，则执行步骤S306；若否，则执行步骤S307。

考虑到主播开播具有随机性，可能存在具有低延时需求的主播而其未在目标直播分区进行开播的情况，本申请实施例采用动态调控机制管理转码系统的转码任务，实现对具有低延时需求的直播间的查漏补缺。针对未设置有预设延时标签的直播间，实时监测直播间的源流码率和直播间的观看人数，可根据直播间的源流码率和直播间的观看人数来实现对直播间对应的转码任务的动态管理与动态调控。具体地，可针对未设置有预设延时标签的直播间，预先设置第二预设转码策略，第二预设转码策略中记录有针对未设置有预设延时标签的直播间进行逐级开启转码链路时对应的直播间的源流码率所需满足的范围以及直播间的观看人数所需满足的范围。通过判断直播间的源流码率和直播间的观看人数是否符合第二预设转码策略来确定如何为观看端分配流拉取链路。

可选地，第二预设转码策略的具体策略内容不同于第一预设转码策略的具体策略内容，从而针对未设置有预设延时标签的直播间和设置有预设延时标签的直播间，采用不同的转码策略对转码任务进行动态管理与动态调控。

步骤S306，按照第二预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流，并为观看端分配源流拉取链路或者转码流拉取链路。

若经步骤S305判断得到符合第二预设转码策略，说明需要对该直播间进行转码处理，按照第二预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流。

为了尽可能地减少直播过程中主播端到观看端链路，降低直播延时，在确定需要转码处理的情况下，还需进一步根据预先设置的预设源流拉取条件，通过对直播间的源流码率和直播间的观看人数进行判断来确定为观看端分配源流拉取链路还是分配转码流拉取链路，实现动态调度流拉取链路。其中，预设源流拉取条件中记录有针对未设置有预设延时标签的直播间在符合第二预设转码策略的情况下直播间的源流码率和观看人数需要满足什么范围时才能为观看端分配源流拉取链路。

具体地，若直播间的源流码率和直播间的观看人数符合预设源流拉取条件，则为观看端分配源流拉取链路；若直播间的源流码率和直播间的观看人数不符合预设源流拉取条件，则为观看端分配转码流拉取链路。转码流拉取链路为通过下行内容分发网络从转码系统拉取直播流中的转码流的链路。

步骤S307，为观看端分配源流拉取链路。

若经步骤S305判断得到不符合第二预设转码策略，说明无需对该直播间进行转码处理，则为观看端分配源流拉取链路，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时。

在直播过程中，对于直播间的源流码率和直播间的观看人数的监测可实时或定时进行，一旦监测到不符合第二预设转码策略，则对直播间已有的转码任务和转码链路进行动态管理，具体地，对已有转码任务进行停止处理，并去除转码链路，将观看端的流拉取链路调整为源流拉取链路，使观众观看直播源流，从而有效地缩短主播端到观看端链路，有效降低直播延时，极大提高主播和观众的互动性，提升直播体验。

可选地，本申请实施例还可针对未设置有预设延时标签的直播间，通过监测在直播过程中观看端和/或主播端的请求行为的方式来识别该直播间是否存在高互动性的行为，以确定直播间是否存在低延时需求，从而由服务端为直播间补加预设延时标签。那么该方法还包括：若未设置有预设延时标签，则监测在直播过程中是否接收到观看端和/或主播端的目标互动请求；若接收到目标互动请求，则为目标互动请求对应的直播间添加预设延时标签。目标互动请求是指高互动性的行为的请求，具体地，目标互动请求可包括：弹幕请求、视频连麦请求和/或语音连麦请求。

在实际的直播场景中，观众可通过观看端主动调整清晰度。那么该方法还包括：接收观看端的清晰度调整请求，清晰度调整请求用于将直播流的清晰度调整为第一目标清晰度；根据清晰度调整请求，为观看端分配第一目标清晰度对应的直播流的拉取链路。

另外，在出现直播播放卡顿时还可自动降低清晰度。那么该方法还包括：采集观看端在直播过程中产生的卡顿数据；根据卡顿数据，为观看端分配第二目标清晰度对应的直播流的拉取链路；其中，第二目标清晰度低于观看端当前所拉取的直播流的清晰度。

根据本申请实施例提供的直播链路处理方法，通过目标直播分区便捷地对直播间进行标签设置，以实现对具有低延时需求的直播间的有效标识和识别；并且为设置有预设延时标签的直播间和未设置有预设延时标签的直播间提供了不同的直播链路分配方式，联动直播间清晰度调度，当观看端请求拉流时，通过检测直播流获取请求对应的直播间是否设置有预设延时标签来确定直播链路分配方式，针对设置有预设延时标签的直播间，为观看端分配源流拉取链路，使得观看端拉取直播源流，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时；另外，动态监测直播间情况，根据直播间的源流码率和直播间的观看人数，及时下发或停止转码任务，实现了对直播间对应的转码任务的动态管理，既有效控制了带宽消耗，又尽可能地缩短直播过程中主播端到观看端链路，有效降低了直播延时，进一步提升了主播和观众的直播体验。

图4示出了根据本申请一个实施例的直播链路处理装置的结构框图，如图4所示，该装置包括：接收模块410、检测模块420以及处理模块430。

接收模块410适于：接收观看端的直播流获取请求，直播流获取请求用于获取直播间的直播流。

检测模块420适于：检测直播间是否设置有预设延时标签。

处理模块430适于：若检测模块420检测得到设置有预设延时标签，则为观看端分配源流拉取链路，以供观看端根据源流拉取链路获取直播流中的直播源流。

可选地，接收模块410进一步适于：接收主播端在目标直播分区中发送的开播请求；处理模块430进一步适于：根据开播请求为主播端的直播间设置预设延时标签，并根据预设延时标签对直播间对应的转码任务进行管理。

可选地，处理模块430进一步适于：若直播间的源流码率和直播间的观看人数不符合第一预设转码策略，则不下发转码任务；若直播间的源流码率和直播间的观看人数符合第一预设转码策略，则按照第一预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流。

可选地，处理模块430进一步适于：若未设置有预设延时标签，则根据直播间的源流码率和直播间的观看人数，为观看端分配源流拉取链路或者转码流拉取链路。

可选地，处理模块430进一步适于：若直播间的源流码率和直播间的观看人数不符合第二预设转码策略，则为观看端分配源流拉取链路；若直播间的源流码率和直播间的观看人数符合第二预设转码策略，则按照第二预设转码策略下发转码任务，由转码系统根据转码任务开启对应清晰度的转码链路对直播间的直播源流进行转码处理得到直播流中的转码流，并为观看端分配源流拉取链路或者转码流拉取链路。

可选地，处理模块430进一步适于：若直播间的源流码率和直播间的观看人数符合预设源流拉取条件，则为观看端分配源流拉取链路；若直播间的源流码率和直播间的观看人数不符合预设源流拉取条件，则为观看端分配转码流拉取链路。

可选地，源流拉取链路为通过下行内容分发网络从上行边缘节点拉取直播流中的直播源流的链路；转码流拉取链路为通过下行内容分发网络从转码系统拉取直播流中的转码流的链路。

可选地，处理模块430进一步适于：若未设置有预设延时标签，则监测在直播过程中是否接收到观看端和/或主播端的目标互动请求；若接收到目标互动请求，则为目标互动请求对应的直播间添加预设延时标签。

可选地，目标互动请求包括：弹幕请求、视频连麦请求和/或语音连麦请求。

可选地，接收模块410进一步适于：接收观看端的清晰度调整请求，清晰度调整请求用于将直播流的清晰度调整为第一目标清晰度；处理模块430进一步适于：根据清晰度调整请求，为观看端分配第一目标清晰度对应的直播流的拉取链路。

可选地，处理模块430进一步适于：采集观看端在直播过程中产生的卡顿数据；根据卡顿数据，为观看端分配第二目标清晰度对应的直播流的拉取链路；其中，第二目标清晰度低于观看端当前所拉取的直播流的清晰度。

以上各模块的描述参照方法实施例中对应的描述，在此不再赘述。

根据本申请实施例提供的直播链路处理装置，通过目标直播分区便捷地对直播间进行标签设置，以实现对具有低延时需求的直播间的有效标识和识别；并且为设置有预设延时标签的直播间和未设置有预设延时标签的直播间提供了不同的直播链路分配方式，联动直播间清晰度调度，当观看端请求拉流时，通过检测直播流获取请求对应的直播间是否设置有预设延时标签来确定直播链路分配方式，针对设置有预设延时标签的直播间，为观看端分配源流拉取链路，使得观看端拉取直播源流，有效地确保了直播过程中主播端到观看端链路较短，降低了直播延时；另外，动态监测直播间情况，根据直播间的源流码率和直播间的观看人数，及时下发或停止转码任务，实现了对直播间对应的转码任务的动态管理，既有效控制了带宽消耗，又尽可能地缩短直播过程中主播端到观看端链路，有效降低了直播延时，进一步提升了主播和观众的直播体验。

本申请实施例还提供了一种非易失性计算机存储介质，计算机存储介质存储有至少一可执行指令，可执行指令可执行上述任意方法实施例中的直播链路处理方法。

图5示出了根据本申请一个实施例的一种计算设备的结构示意图，本申请实施例的具体实施例并不对计算设备的具体实现做限定。

如图5所示，该计算设备可以包括：处理器(processor)502、通信接口(Communications Interface)504、存储器(memory)506、以及通信总线508。

其中：

处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。

通信接口504，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器502，用于执行程序510，具体可以执行上述直播链路处理方法实施例中的相关步骤。

具体地，程序510可以包括程序代码，该程序代码包括计算机操作指令。

处理器502可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。计算设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器506，用于存放程序510。存储器506可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序510具体可以用于使得处理器502执行上述任意方法实施例中的直播链路处理方法。程序510中各步骤的具体实现可以参见上述直播链路处理实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本申请实施例也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本申请实施例的内容，并且上面对特定语言所做的描述是为了披露本申请实施例的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本申请实施例的示例性实施例的描述中，本申请实施例的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本申请实施例要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请实施例的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请实施例的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本申请实施例的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本申请实施例中的一些或者全部部件的一些或者全部功能。本申请实施例还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本申请实施例的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本申请实施例进行说明而不是对本申请实施例进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本申请实施例可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。