CN116170612A - 一种直播的实现方法、边缘节点、电子设备及存储介质 - Google Patents

Abstract

本申请实施例涉及直播技术领域，特别涉及一种直播的实现方法、边缘节点、电子设备及存储介质。直播的实现方法，应用于边缘节点，包括：接收中心节点发送的视频帧；从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存；在接收到客户端的内容请求后，基于RTC协议将缓存的所述视频帧发送给所述客户端，供所述客户端向用户呈现接收到的所述视频帧；在向所述客户端发送缓存的视频帧后，继续接收所述中心节点发送的视频帧并基于RTC协议将当前接收到的所述视频帧发送给所述客户端。使得在不影响用户体验的情况下，减小直播时延，以满足RTC的实时性要求。

Description

一种直播的实现方法、边缘节点、电子设备及存储介质

技术领域

本申请实施例涉及直播技术领域，特别涉及一种直播的实现方法、边缘节点、电子设备及存储介质。

背景技术

直播是指通过互联网实时传输演出的音频和视频内容。随着实时视频的流行，直播俨然已成为众多企业和市场战略的重要组成部分。直播可用于活动(赛事)直播、提供客户服务以及举行网络研讨会等一切内容。

直播通常涉及推流和拉流两个部分，其中，推流是指将包含直播内容的音视频流推送到服务器，拉流是指用户从服务器中拉取音视频流。

在实现拉流时，通常还会利用内容分发网络(Content Delivery Network，CDN)进行加速，以提高音视频流的传输效率，即目前常用的基于实时消息传输协议(Real TimeMessaging Protocol，RTMP)的直播、基于超文本传输协议的流媒体协议(Hyper TextTransfer Protocol-Flash Video，HTTP-FLV)的直播、基于超文本传输协议的自适应码率流媒体传输协议(Hyper Text Transfer Protocol Live Streaming，HLS)的直播等普通直播。

随着实时通信(Real time communication，RTC)的发展，为了进一步提高音视频流的传输效率，逐渐开始考虑将RTC应用于直播中，即基于RTC的直播。其中，基于RTC的直播通常是在RTC的基础上，在边缘节点上配置RTC相关协议，以使得边缘节点能够将接收到的中心节点发送的普通直播的音视频帧转换为RTC音视频帧，然后基于RTC协议将缓存的音视频帧发送给客户端。

然而，在实现基于RTC的直播时，如何在不影响用户体验的情况下满足RTC的实时性要求仍待解决。

发明内容

本申请实施例提供了一种直播的实现方法、边缘节点、电子设备及存储介质，有利于在不影响用户体验的情况下，减小直播时延，以满足RTC的实时性要求。

减小基于RTC的直播中客户端呈现直播内容的首屏时间。

根据本申请的一些实施例，本申请实施例一方面提供了一种直播的实现方法，应用于边缘节点，所述方法包括：接收中心节点发送的视频帧；从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存；在接收到客户端的内容请求后，基于RTC协议将缓存的所述视频帧发送给所述客户端，供所述客户端向用户呈现接收到的所述视频帧。

根据本申请的一些实施例，本申请实施例一方面还提供了边缘节点，包括：接收模块，用于接收中心节点发送的视频帧；缓存模块，用于从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存；发送模块，用于在接收到客户端的内容请求后，将缓存的所述视频帧发送给所述客户端，供所述客户端向用户呈现接收到的所述视频帧。

根据本申请的一些实施例，本申请实施例一方面还提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的直播的实现方法。

根据本申请的一些实施例，本申请实施例一方面还提供了一种计算机可读存储介质，存储有计算机程序，所述计算机程序被处理器执行时实现如上所述的直播的实现方法。

本申请实施例提供的技术方案至少具有以下优点：

在接收到中心节点发送的视频帧后，从类型为I帧的视频帧开始缓存视频，因此，起始视频帧为I帧。而I帧为可以独立解码的帧，也就是说，边缘节点基于RTC协议将缓存的视频帧发送给客户端后，起始视频帧能够直接被客户端解码播放，无需等待I帧来辅助起始视频帧的解码播放。进而在此之后，继续接受中心节点发送的视频帧并基于RTC协议将当前接收到的视频帧发送给客户端，即边接收中心节点发送的视频帧边向客户端发送视频帧，使得客户端能够基于在前发送给客户端的视频帧，对当前接收到的视频帧进行解码播放，实现对直播画面的实时播放，满足了RTC的实时性要求，且不会由于接收到的视频帧缺乏在前的类型为I帧的视频帧而出现无法解码、影响用户体验的问题。达到了在不影响用户体验的情况下，减小直播时延，以满足RTC的实时性要求。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是本申请一实施例中提供的边缘节点所在网络的结构示意图；

图2是本申请一实施例中提供的直播的实现方法的流程图；

图3是本申请一实施例中提供的包括清除第k个类型为I帧的视频帧之前缓存的视频帧步骤的直播的实现方法的流程图；

图4是本申请一实施例中提供的包括判断当前已缓存的视频帧的数量是否已达到预设值步骤的直播的实现方法的流程图；

图5是本申请一实施例中提供的包括缓存音频帧步骤的直播的实现方法的流程图；

图6是本申请一实施例中提供的直播的实现方法的交互流程图；

图7是本申请一实施例中提供的边缘节点的结构示意图；

图8是本申请一实施例中提供的电子设备的结构示意图。

具体实施方式

如背景技术所述，在实现基于RTC的直播时，在不影响用户体验的情况下满足RTC的实时性要求仍待解决。

经分析发现，出现上述问题的原因在于：为了使客户端拉流播放能够更加流畅，基于RTMP、HTT-FLV、HLS等的直播一般会在中心节点或者边缘节点缓存多个图像组(Group OfPicture，GOP)，这样，客户端来拉流时一次性发送多个GOP给客户端。而在实现基于RTC的直播时，若仍按照前述的普通直播方案缓存多个GOP，则会导致客户端的画面延迟时间过长，实时性差，无法满足RTC的高实时性要求。因此，为了满足RTC的实时性要求，边缘节点不能缓存多个GOP。但若是边缘节点接收到数据帧就发送的数据帧发送给客户端，又会出现客户端首屏时间过长的问题，这又会严重降低用户体验。

其中，进一步分析之后还发现，边缘节点接收到数据帧就发送的数据帧发送给客户端时出现首屏时间过程的原因在于：

客户端对直播的请求时机不定，因此，边缘节点接收到的来自中心节点的起始视频帧的类型可以是I帧、P帧和B帧中的任一种。而不论其接收到的视频帧中的起始音视频帧类型为I帧、P帧或B帧，边缘节点都会基于RTC协议将接收到的视频帧发送给客户端。

但是，如果起始音视频帧的类型是P帧或B帧，则会由于P帧和B帧无法被独立解码，出现需要等待在后的类型为I帧的音视频帧才能对视频帧进行解码播放的情况，也就是说，将会出现首屏时间很长的情形。

并且音视频帧中类型为B帧和P帧的概率明显大于类型为I帧的概率，因此，起始音视频帧的类型大概率为P帧或B帧。即直播实现时，很可能出现上述首屏时间长、用户体验低的情形。

此外，也无法对用户加入直播的时间进行限定，否则会严重影响用户体验。

为解决上述问题，本申请实施例提供了一种直播的实现方法，应用于边缘节点，该方法包括：接收中心节点发送的视频帧；从类型为I帧的视频帧开始，对接收到的视频帧进行缓存；在接收到客户端的内容请求后，将缓存的视频帧发送给客户端，供客户端向用户呈现接收到的视频帧；在向所述客户端发送缓存的视频帧后，继续接收所述中心节点发送的视频帧并基于RTC协议将当前接收到的所述视频帧发送给所述客户端。

本申请实施例提供的技术方案，在基于RTC的直播场景下，边缘节点在对视频帧进行缓存时，不再从中心节点发送的起始视频帧开始，而是从接收到的I帧开始，也就是说，I帧之前的P帧和B帧不会被缓存，因此，边缘节点缓存并基于RTC协议发送到客户端的起始视频帧为I帧，从而基于I帧可以被独立解码的特性，客户端能够直接解码播放起始视频帧，因此，在实现基于RTC的直播时，并不会出现客户端接收到的起始视频帧无法直接解码的问题，从而避免了由于起始视频帧无法解码而导致的客户端呈现直播内容的首屏时间过长的问题，不会影响用户体验。进而，在此之后，继续接收中心节点发送的视频帧并基于RTC协议将当前接收到的视频帧发送给客户端，即边缘节点边接收中心节点发送的视频帧边向客户端发送视频帧，就能够使得客户端能够基于在前接收的类型为I帧的视频帧对当前接收到的视频帧进行解码播放，实现直播画面的实时播放，满足RTC的实时性要求。实现在不影响用户体验的情况下，减小直播时延，满足了RTC的实时性要求。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。

以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本申请实施例一方面提供了一种直播的实现方法，应用于边缘节点，该边缘节点处于如图1所示的网络，该网络在边缘节点的基础上还包括中心节点和其他边缘节点，各边缘节点还对应至少一个客户端。在直播拉流的过程中，对音视频的请求由客户端发出，首先被边缘节点响应，若边缘节点未缓存音视频帧，则由边缘节点向中心节点请求；至于音视频流，其从中心节点出发，在对应的客户端具有直播需求的边缘节点处被缓存，最后被边缘节点推送到一个或多个客户端。其中，中心节点和部分边缘节点之间可以具有至少一个中间节点。

直播的实现方法的流程如图2所示，至少包括以下步骤：

步骤201，接收中心节点发送的视频帧。

本实施例不对视频帧的格式、视频帧的接收方式等进行限定，可以是任何一种格式的视频帧，可以是一次接收一个视频帧，也可以是一次接收多个视频帧等。

需要说明的是，边缘节点对应有至少一个客户端，在其对应多个客户端时，多个客户端中的至少两个客户端的用户可能具有观看同一直播的需求，具有观看同一直播需求的用户通过客户端观看直播的时机可能相同，也可能不同。也就是说，边缘节点接收的视频帧可能是中心节点根据边缘节点首次请求某个直播内容的视频帧而返回的视频帧，边缘节点接收的视频帧还可能是中心节点根据边缘节点首次请求某个直播内容的视频帧返回的视频帧之后，继续向边缘节点发送的视频帧。本实施例对此并不进行限制。

还需要说明的是，中心节点向边缘节点发送视频帧可以是基于RTMP的直播方案所实现的，其采用的协议可以是传输控制协议(TCP，Transmission Control Protocol)。其中，基于RTMP的直播方案其还可以包含RTMP协议以及与RTMP协议相关的多个变种，如RTMPS、RTMPE等。中心节点向边缘节点发送视频帧还可以是基于HTTP-FLV的直播方案所实现的，其采用的是HTTP协议。当然，中心节点向边缘节点发送视频帧还可以是基于HLS的直播方案等所实现的，此处就不再一一赘述了。

步骤202，从类型为I帧的视频帧开始，对接收到的视频帧进行缓存。

视频帧具有三种类型：I帧、P帧和B帧。其中，I帧为内部编码帧，可以被独立解码；P帧为前向参考帧，无法独立解码；P帧为双向参考帧，也无法独立解码。

本实施例中，从I帧开始缓存，因此，缓存的第一个视频帧即为I帧，从而客户端接收视频帧后，待解码播放的第一个视频帧也为I帧，即起始视频帧为I帧，其中，起始视频帧为客户端接收到的视频帧中，时间戳所对应的时刻最早的视频帧。而I帧可以独立解码，也就是说，起始视频帧能够被独立解码，能够很快地展示给用户。尤其是与P帧和B帧相比，无需参考其他视频帧解码，解码播放效率更高，减小直播的首屏时间，提高了用户体验。

在一些实施例中，从类型为I帧的视频帧开始，对接收到的视频帧进行缓存，可以通过如下方式实现：对当前接收到的视频帧的类型是否为I帧进行检测；在检测到当前接收到的视频帧的类型是I帧的情况下，对当前接收到的视频帧进行缓存并对当前接收到的视频帧之后接收到的视频帧进行缓存；在检测到当前接收到的视频帧的类型不是I帧的情况下，丢弃当前接收到的视频帧并对接收到的下一视频帧的类型是否为I帧进行检测。

这样，在接收类型为I帧的视频帧之前，每接收到一个视频帧，就通过检测决策该视频帧是丢弃还是缓存，能够及时对不需要的视频帧进行丢弃，减少接收视频帧对存储空间的占用。

在一些实施例中，从类型为I帧的视频帧开始，对接收到的视频帧进行缓存，还可以通过如下方式实现：对当前接收到的视频帧的类型是否为I帧进行检测；在检测到当前接收到的视频帧的类型是I帧的情况下，对当前接收到的视频帧、对已接收到的视频帧中时间戳在当前接收到的视频帧之后的视频帧进行缓存并对时间戳在当前接收到的视频帧之前的已接收视频帧进行丢弃，然后继续接收视频帧并对继续接收到的视频帧进行缓存；在检测到当前接收到的视频帧的类型不是I帧的情况下，暂存当前接收到的视频帧并对接收到的下一视频帧的类型是否为I帧进行确认。例如，在依次接收到视频帧A、B、C、D，假设受到网络抖动等情况的影响，视频帧D的类型I帧，但视频帧C的时间戳晚于视频帧D，那么基于当前实施例的方案，在缓存类型为I帧的视频帧D的时候，由于视频帧C的时间戳晚于视频帧D，因此，也会对视频帧C进行缓存，而不是丢弃视频帧C。后续继续接收视频帧E等，继续对接收到的视频帧进行缓存。

也就是说，直到接收到类型为I帧的视频帧后，再根据该类型为I帧的视频帧的时间戳决策是否丢弃当前已接收的各视频帧，这样，即使出现网络抖动等会导致中心节点的视频帧发送顺序和边缘节点的视频帧接收顺序不一致的情况，也能够使得时间戳在类型为I帧的视频帧之后且边缘节点接收时机在类型为I帧的视频帧之前的视频帧能够被缓存，减少时间戳在类型为I帧的视频帧之后的视频帧的遗失，即减少了有效视频帧的遗失。其中，时间戳在类型为I帧的视频帧之前的视频帧，由于无法解码而属于无效视频帧。

当然，在一些实施例中，还可以是对当前接收到的视频帧的类型是否为I帧进行检测；在检测到当前接收到的视频帧的类型是I帧的情况下，对当前接收到的视频帧和时间戳在当前接收到的视频帧之后的视频帧进行缓存并对时间戳在当前接收到的视频帧之前的已接收视频帧进行丢弃；在检测到当前接收到的视频帧的类型不是I帧的情况下，暂存当前接收到的视频帧并对接收到的下一视频帧的类型是否为I帧进行检测。即在上一实施例的基础上，不再对接收类型为I帧的视频帧之后接收的数据帧全部进行缓存，而是根据时间戳确定是丢弃还是缓存，使得时间戳在类型为I帧的视频帧之后的视频帧均能够被缓存，且时间戳在类型为I帧的视频帧均前的视频帧均能够被丢弃，在减少有效视频帧遗失的同时，还通过减少无效视频帧的缓存而提高存储空间的利用率。

如步骤201的说明，边缘节点接收的视频帧可能是中心节点根据边缘节点首次请求某个直播内容的视频帧而返回的视频帧，边缘节点接收的视频帧还可能是中心节点根据边缘节点首次请求某个直播内容的视频帧已返回的视频帧之后，继续向边缘节点发送的视频帧。

需要说明的是，在上述第二种情况下，中心节点发送的视频帧为边缘节点对应的至少一个客户端已请求过某个直播内容且正在播放直播内容后，另一(些)客户端也请求该直播内容后中心节点返回给边缘节点的视频帧，此时，需要边缘节点发送视频帧的客户端有两类，包括正在播放直播的客户端和等待播放直播的客户端。

对于正在播放直播的客户端而言，其不断接收视频帧，即使边缘节点当前缓存的起始视频帧为P帧或B帧，由于在之前已向边缘节点发送过I帧，因此，P帧或B帧解码时可以参考已接收到的I帧，而无需等待接收下一I帧。也就是说，需要发送给正在播放直播的客户端的视频帧，在边缘节点处的缓存方式可以是边缘节点接收到一个视频帧就缓存一个视频帧，这样，发送给正在播放直播的客户端的视频帧将会更全面，无视频帧丢弃，呈现给用户的是信息无损的直播内容。

对于等待播放直播的客户端而言，其解码播放需要从I帧开始，因此，等待播放直播的客户端所接收到的视频帧需要从I帧开始，也就是说，这些视频帧在边缘节点处是从接收到的类型为I帧的视频帧开始被缓存。

而类型为I帧的视频帧之前的视频帧延迟较长且无法被解码，因此，不缓存或者丢弃类型为I帧的视频帧之前的视频帧，还具有避免接收到的视频帧无法解码的优点，且还有利于减少直播画面的时延。

由此可见，在中心节点发送的视频帧为边缘节点对应的至少一个客户端已请求过某个直播内容且正在播放直播内容，另一(些)客户端也请求该直播内容后中心节点返回给边缘节点的视频帧的情况下，边缘节点可以分别为正在播放直播的客户端和等待播放直播的客户端提供不同的视频帧缓存方式，以提供更好的用户体验。

可以理解的是，边缘节点向客户端发送缓存的视频帧要等待客户端准备好接收边缘节点的视频帧的时机到来，但是该时机不定，因此，在发送给等待播放直播的客户端前，边缘节点缓存的视频帧的数量不定。此时，还可以通过对边缘节点缓存的视频帧的数量进行限定，使得边缘节点缓存的视频帧总是最新的一些视频帧，这样，边缘节点发送给等待播放直播的客户端的视频帧总是最新的一些视频帧，有利于减少等待播放直播的客户端解码播放的画面的时延，提高了用户体验。

在一些实施例中，如图3所示，从类型为I帧的视频帧开始，对接收到的视频帧进行缓存，还可以通过如下方式实现：在接收到第k个类型为I帧的视频帧后，对第k个类型为I帧的视频帧之前缓存的视频帧进行清除，并从第k个类型为I帧的视频帧开始对接收到的视频帧进行缓存。此时，k为正整数。

在一些例子中，k不大于N1，N1为客户端向边缘节点请求直播内容后到直播结束前，直播内容所包含的I帧数量。也就是说，边缘节点持续等待向客户端发送视频帧的时机到来，直到直播结束，一直为客户端缓存视频帧，使得向客户端发送视频帧的时机的到来预留尽量长的时间，而无需客户端再次向边缘节点发起请求，提高了用户体验。

在一些例子中，k不大于N2，N2为预设数值。也就是说，若是边缘节点在接收到N2个类型为I帧的视频帧之后，向客户端发送视频帧的时机仍然未到来，可以不再缓存数据，从而能够将边缘节点的资源用于实现其他任务，节约了资源，提高了其他任务带给用户的体验。

在一些例子中，k不大于N3，N3为客户端向边缘节点请求直播内容后到其他请求同样直播内容的客户端结束观看前，直播内容所包括的类型为I帧的视频帧的数量。也就是说，在边缘节点为其他请求同样直播内容的客户端缓存视频帧的情况下，可以基于接收到的视频帧为客户端缓存视频帧，充分利用了资源。

也就是说，每接收到一个类型为I帧的视频帧，就对其之前缓存的视频帧进行清除，因此，边缘节点缓存的只有当前最新的一个图像组(Group of picture，GOP)中的视频，发送给客户端的也就是当前最新的一个图像组(Group of picture，GOP)中的视频。

当然，在其他实施例中还可以是将在接收到第k个类型为I帧的视频帧后，对第k-1个类型为I帧的视频帧之前缓存的视频帧进行清除，并从第k个类型为I帧的视频帧开始对接收到的视频帧进行缓存。即，边缘节点缓存的是当前最新的两个图像组GOP中的视频。此时，k为大于1的整数。此处就不再一一赘述了。

这样，以GOP为单位对边缘节点缓存的视频帧的数量进行限定，相邻两个GOP的视频帧之间相接，使得边缘节点至少缓存至少一个GOP中的至少一个视频帧，保证了向客户端发送视频帧的时机在任一时刻到来，边缘节点中均缓存有至少一个视频帧能够发送给客户端，无需客户端等待，有利于减少首屏时间。

在一些实施例中，从类型为I帧的视频帧开始，对接收到的视频帧进行缓存，还可以通过如下方式实现：对第一个类型为I帧的视频帧进行缓存；检测当前已缓存的视频帧数量是否已达到预设值；在当前已缓存的视频帧数量已达到预设值的情况下，对当前已缓存的视频帧进行清除，并在接收到从下一个类型为I帧的视频帧开始，对接收到的视频帧进行缓存；在当前已缓存的视频帧数量未达到所述预设值的情况下，对当前接收到的视频帧进行缓存。

为便于本领域技术人员更好地理解上述实施例，以下将结合图4进行举例说明。如图4所示，从类型为I帧的视频帧开始，对接收到的视频帧进行缓存，还可以包括以下步骤：

步骤2021，在接收到第i个类型为I帧的视频帧后，对接收到的第i个类型为I帧的视频帧进行缓存，i为正整数。

需要说明的是，此处i的取值范围与前述的参数取值大致相同，此处就不再一一赘述了。

步骤2022，接收中心节点发送的下一视频帧。

步骤2023，检测当前已缓存的视频帧数量是否已达到预设值；若是，执行步骤2024，若否，执行步骤2025。

本实施例中，预设值为根据需求设置的可缓存视频帧的最大数量。

步骤2024，对当前已缓存的视频帧进行清除并继续接收中心节点发送的视频帧。

在一些例子中，预设值可以小于一个GOP所包含的视频帧的数量，由于是从类型为I帧的视频帧开始进行缓存，即从GOP的第一个视频帧开始进行缓存，因此，在已缓存的视频帧的数量达到预设值的情况下对当前已缓存的视频帧进行清除，意味着，边缘节点对每个图像组只缓存前预设值数量的视频帧，进一步减少缓存的视频帧的数量，节约了存储空间。

步骤2025，对当前接收到的视频帧进行缓存。

相应地，在步骤2024和步骤2025之后，应该分别包括：

步骤2026，检测当前是否接收到客户端发送的内容请求。

步骤2027，检测当前是否接收到客户端发送的内容请求。

其中，若是接收到客户端发送的内容请求，则执行步骤203，否则，应当继续接收和/或缓存视频帧。具体参见图4，此处就不再一一赘述了。

也就是说，以视频帧的单位对边缘节点缓存的视频帧的数量进行限定，减少缓存的视频帧对存储空间占用。同时数量为预设值的视频帧相对于预设数量的GOP包含的视频帧而言，数量更加固定，因此，缓存队列的长度等配置更加固定，减少自主设置的内容，有利于减少错误发生。

当然，以上仅为具体的举例说明，在其他实施例中，可以根据其他需求对缓存的具体方式进行限定，满足缓存以及发送给客户端的起始视频帧为I帧即可。

步骤203，在接收到客户端的内容请求后，基于RTC协议将缓存的视频帧发送给客户端，供客户端向用户呈现接收到的视频帧。

本实施例中，客户端的内容请求用于表征边缘节点向客户端发送视频帧的时机到来。当边缘节点接收到客户端发送的内容请求后，边缘节点若确定向客户端发送缓存的视频帧的时机已到，将会触发边缘节点向客户端发送缓存的视频帧的动作。

需要说明的是，根据不同的需求，其内容请求可以为不同的信息。

在一些实施例中，内容请求为网络地址转换会话穿越应用程序(SessionTraversal Utilities for Network Address Translation，STUN)请求，以在客户端与边缘节点之间建立STUN数据通道，从而边缘节点可以通过建立好的STUN数据通道将视频帧发送给客户端。即边缘节点接收到STUN数据包，并在接收到STUN数据包后，将根据STUN数据包触发基于RTC协议将缓存的视频帧发送给客户端的动作，以基于RTC协议将缓存的视频帧发送给所述客户端。此时，边缘节点和客户端之间采用私有SDK(Software Development Kit，软件开发工具包)非加密方式进行视频帧传输。从而通过减少加密处理时间，减少接收到内容请求后的响应时间，有利于进一步减少首屏时间。

在一些实施例中，内容请求还可以为数据报安全传输协议(Datagram TransportLevel Security，DTLS)握手请求，以在边缘节点和客户端之间进行DTLS握手。即边缘节点接收所述客户端发送的DTLS握手请求；根据DTLS握手请求，与客户端进行DTLS握手。从而在完成DTLS握手后，对缓存的视频帧进行加密；然后再基于RTC协议将加密后的视频帧发送给客户端。这样，后续边缘节点向客户端发送视频帧时采用加密传输的方式，提高了视频帧的传输安全性。其中，在进行DTLS握手前，边缘节点和客户端还通过STUN数据包建立了STUN数据传输通道，以提供视频帧的传输通道。

也就是说，在接收到STUN请求后，边缘节点还需要等待接收DTLS握手请求，才会向客户端发送缓存的视频帧。

当然，上述仅为对内容请求的具体举例，在其他实施例中，还可以将其他的请求定义为内容请求，此处就不再一一赘述了。

而关于视频帧的发送，在一些实施例中，可以是基于RTC协议将缓存的视频帧一次性发送给客户端，这样客户端在接收到视频帧后能够持续进行解码播放，而不会在两个视频帧解码播放之间出现空闲时刻，影响用户体验。

需要说明的是，边缘节点上配置有协议转换功能，以支持基于RTC协议将缓存的视频帧发送给客户端的功能，使得在发送视频帧之前，边缘节点将从中心节点接收到的基于RTMP协议传输的音视频流转换为RTC流发送给用户的客户端，从而基于RTC协议与客户端进行视频数据传输，并进一步提高音视频流的传输效率。

具体地，转换为RTC流的实现方式如下：边缘节点对缓存队列取出的视频帧逐帧进行实时传输协议(Real-time Transport Protocol，RTP)分片后，再发送给客户端，从而将视频帧采用时延更小的RTC方式发送到客户端，此处就不再一一赘述了。

还需要说明的是，边缘节点向客户端基于RTC机制发送视频帧，与前述中心节点向边缘节点发送视频帧不同。并且由于RTC的传输效率更高，使得视频帧的传输效率得到提高。由此可见，基于RTC的直播方案有利于进一步降低直播的时延，提高用户体验。

步骤204，在向客户端发送缓存的视频帧后，继续接收中心节点发送的视频帧并基于RTC协议将当前接收到的视频帧发送给客户端。

也就是说，边缘节点在向客户端初次发送过视频帧之后，将会采用边接收中心节点发送的视频帧边向客户端发送视频帧的方式进行视频帧传输，从而能够在客户端实现直播画面的实时播放，满足了RTC的实时性要求，且保证了客户端能够基于在前接受的视频帧对后续的视频帧进行解码播放，不会影响用户体验。

可以理解的是，直播内容通常不仅包括视频帧，还包括音频帧，从而在视觉和听觉上为用户提供直播服务。

在一些实施例中，由于视频帧相对于音频帧包含的信息更多，且用户对画面的响应比对声音的响应更快、更强烈，因此，边缘节点首次向客户端发送直播内容前，可以优先对视频帧进行缓存和发送，使得边缘节点有限的带宽能够被充分用于向客户端发送视频帧，有利于利用有限的资源为用户提供相对更优的体验。尤其是在视频帧包含的信息量较大、对带宽占用较大，而边缘节点的可用带宽有限的情况下，同时发送视频帧和音频帧容易造成卡顿，优先发送视频帧则减少了视频帧播放的卡顿。

当然，在一些实施例中，还可以对视频帧和音频帧都进行缓存，而是否同时向用户发送视频帧还可以是根据发送前的边缘节点的带宽资源情况、缓存的视频帧和/或音频帧预计所占用的带宽大小进行确定。

基于此，在一些实施例中，如图5所示，直播的实现方法还包括以下内容：

接收中心节点发送的视频帧的同时，还接收中心节点发送的音频帧。

从类型为I帧的视频帧开始，对接收到的视频帧进行缓存的同时，还从类型为I帧的视频帧对应的音频帧开始对接收到的音频帧进行缓存。

基于RTC协议将缓存的视频帧发送给所述客户端的同时，还基于RTC协议将缓存的音频帧发送给客户端。

在向客户端发送缓存的视频帧和音频帧后，继续接收中心节点发送的视频帧和音频帧，并基于RTC协议将当前接收到的音频帧和视频帧发送给客户端。

在一些情况下，音频帧和视频帧之间可以根据时间戳对应，如时间戳相同或时间戳相差最小的音频帧和视频帧对应。

也就是说，音频帧和视频帧从对应的一帧开始进行缓存，有利于保证缓存以及基于RTC协议发送给客户端的音频帧和视频帧之间的同步，从而提高用户体验。

当然，音频帧还可以根据实际情况确定是否进行缓存并基于RTC协议发送给客户端。

在一些实施例中，在同时接收到的音频帧和视频帧后，直播的实现方法还包括：根据视频帧的码率确定是否缓存音频帧。相应地，在确定缓存音频帧的情况下，才在从类型为I帧的视频帧开始，对接收到的视频帧进行缓存的同时，还从I帧对应的音频帧开始对接收到的音频帧进行缓存。在确定不缓存音频帧的情况下，无需缓存音频帧，也就不会向客户端发送音频帧。

在一些实施例中，还可以根据音频帧和视频帧的总码率确定是否缓存音频帧，或者，根据边缘节点的空闲带宽确定是否缓存音频帧，或者，根据边缘节点的空闲带宽和视频帧的码率确定是否缓存音频帧等。

当然，以上对是否缓存音频的判断、不对音频帧进行缓存的相关说明仅针对某个客户端将要首屏打开某个直播的情况而言，在首屏之后，为了给用户提高更好的体验，无需判断是否缓存视频帧，而是在缓存视频帧的同时缓存音频帧，并会同时基于RTC协议向客户端发送视频帧和音频帧，此处就不再一一赘述了。

需要说明的是，音频帧既可以是在对视频帧进行缓存后，查找与缓存的视频帧对应的音频帧进行缓存；也可以是每缓存了第一个视频帧后，对对应的音频帧进行缓存，并以此为开始，继续缓存后续接收到的音频帧，而不需参考视频帧的缓存。其中，在边缘节点对音频帧的缓存不需参考对视频帧的缓存的情况下，音频帧的缓存是独立的，其实现过程与前述视频帧的缓存过程大致相同，其区别主要在于一个缓存的是音频帧，一个缓存的是视频帧，其余内容此处就不再一一赘述了。

为了便于本领域技术人员更好的理解上述实施例所述的直播的实现方法，以下将以某个边缘节点对应的所有客户端中首次请求某个直播内容的场景进行举例说明。如图6所示，直播的实现方法包括：

步骤601，客户端向边缘节点发送会话描述协议(Session DescriptionProtocol，SDP)请求，SDP请求用于指示客户端的直播拉流需求。

步骤602，边缘节点对SDP请求进行解析，以判断本节点是否支持客户端所请求的音视频编码格式。

步骤603，在本节点支持客户端所请求的音视频编码格式的情况下，向中心节点发送拉流请求。

步骤604，中心节点向边缘节点返回拉流请求的拉流响应，拉流请求包括视频帧和音频帧。

步骤605，边缘节点根据视频帧的码率确定对音频帧进行缓存的情况下，从第一个类型为I帧的视频帧开始缓存接收到的视频帧和第一个类型为I帧的视频帧对应的音频帧开始缓存接收到的音频帧。

步骤606，客户端向边缘节点发送STUN请求。

步骤607，边缘节点向客户端发送STUN请求的响应。

步骤608，边缘节点对缓存的音视频帧逐帧进行RTP分片。

步骤609，边缘节点基于RTC协议向客户端发送分片后的音视频帧，供客户端解码播放音视频帧并呈现给用户。

其中，步骤609之后，还包括：边缘节点边接收中心节点发送的音视频帧，边对当前接收到的音视频帧进行RTP分片并发送给客户端(图6中未示出)，此处就不再一一赘述了。

上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

本申请实施例另一方面还提供了一种边缘节点，如图7所示，包括：

接收模块701，用于接收中心节点发送的视频帧。

缓存模块702，用于从类型为I帧的视频帧开始，对接收到的视频帧进行缓存。

发送模块703，用于在接收到客户端的内容请求后，基于RTC协议将缓存的视频帧发送给客户端，供客户端向用户呈现接收到的视频帧。

转发模块704，在向客户端发送缓存的视频帧后，继续接收中心节点发送的视频帧并基于RTC协议将当前接收到的视频帧发送给客户端。

不难发现，本实施例为与方法实施例相对应的节点实施例，本实施例可与方法实施例互相配合实施。方法实施例中提到的相关技术细节在本实施例中依然有效，为了减少重复，这里不再赘述。相应地，本实施例中提到的相关技术细节也可应用在方法实施例中。

值得一提的是，本实施例中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本申请的创新部分，本实施例中并没有将与解决本申请所提出的技术问题关系不太密切的单元引入，但这并不表明本实施例中不存在其它的单元。

本申请实施例另一方面还提供了一种电子设备，如图8所示，包括：至少一个处理器801；以及，与至少一个处理器801通信连接的存储器802；其中，存储器802存储有可被至少一个处理器801执行的指令，指令被至少一个处理器801执行，以使至少一个处理器801能够执行上述任一方法实施例所描述的方法。

其中，存储器802和处理器801采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器801和存储器802的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器801处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传输给处理器801。

处理器801负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器802可以被用于存储处理器801在执行操作时所使用的数据。

本申请实施方式另一方面还提供了一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (11)

1.一种直播的实现方法，其特征在于，应用于边缘节点，所述方法包括：

接收中心节点发送的视频帧；

从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存；

在接收到客户端的内容请求后，基于RTC协议将缓存的所述视频帧发送给所述客户端，供所述客户端向用户呈现接收到的所述视频帧；

在向所述客户端发送缓存的视频帧后，继续接收所述中心节点发送的视频帧并基于RTC协议将当前接收到的所述视频帧发送给所述客户端。

2.根据权利要求1所述的直播的实现方法，其特征在于，所述从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存，包括：

在接收到第k个类型为I帧的所述视频帧后，对第k个类型为I帧的所述视频帧之前缓存的所述视频帧进行清除，并从第k个类型为I帧的所述视频帧开始对接收到的所述视频帧进行缓存。

3.根据权利要求1或2所述的直播的实现方法，其特征在于，所述从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存，包括：

对第一个类型为I帧的所述视频帧进行缓存；

检测当前已缓存的所述视频帧数量是否已达到预设值；

在当前已缓存的所述视频帧数量已达到所述预设值的情况下，对当前已缓存的所述视频帧进行清除，并在接收到从下一个类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存；

在当前已缓存的所述视频帧数量未达到所述预设值的情况下，对当前接收到的所述视频帧进行缓存。

4.根据权利要求1或2所述的直播的实现方法，其特征在于，所述接收中心节点发送的视频帧的同时，所述方法还包括：

接收所述中心节点发送的音频帧；

所述从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存的同时，所述方法还包括：

从类型为I帧的视频帧对应的所述音频帧开始对接收到的所述音频帧进行缓存；

所述基于RTC协议将缓存的所述视频帧发送给所述客户端的同时，所述方法还包括：

基于RTC协议将缓存的所述音频帧发送给所述客户端。

5.根据权利要求4所述的直播的实现方法，其特征在于，所述从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存之前，所述方法还包括：

根据所述视频帧的码率确定是否缓存所述音频帧；

所述从I帧对应的所述音频帧开始对接收到的所述音频帧进行缓存，包括：

在确定缓存所述音频帧的情况下，从类型为I帧对应的所述音频帧开始对接收到的所述音频帧进行缓存。

6.根据权利要求1或2所述的直播的实现方法，其特征在于，所述基于RTC协议将缓存的所述视频帧发送给所述客户端之前，所述方法还包括：

接收所述客户端发送的DTLS握手请求；

根据所述DTLS握手请求，与所述客户端进行DTLS握手；

所述将缓存的所述视频帧发送给所述客户端，包括：

在完成DTLS握手后，对缓存的所述视频帧进行加密；

基于RTC协议将加密后的所述视频帧发送给所述客户端。

7.根据权利要求1或2所述的直播的实现方法，其特征在于，所述基于RTC协议将缓存的所述视频帧发送给所述客户端之前，所述方法还包括：

接收所述客户端发送的STUN数据包；

所述基于RTC协议将缓存的所述视频帧发送给所述客户端，包括：

根据所述STUN数据包触发基于RTC协议将缓存的所述视频帧发送给所述客户端的动作，以基于RTC协议将缓存的所述视频帧发送给所述客户端。

8.根据权利要求1或2所述的直播的实现方法，其特征在于，所述基于RTC协议将缓存的所述视频帧发送给所述客户端之前，所述方法还包括：

基于RTC协议将缓存的所述视频帧一次性发送给所述客户端。

9.一种边缘节点，其特征在于，包括：

接收模块，用于接收中心节点发送的视频帧；

缓存模块，用于从类型为I帧的所述视频帧开始，对接收到的所述视频帧进行缓存；

发送模块，用于在接收到客户端的内容请求后，基于RTC协议将缓存的所述视频帧发送给所述客户端，供所述客户端向用户呈现接收到的所述视频帧；

转发模块，用于在向所述客户端发送缓存的视频帧后，继续接收所述中心节点发送的视频帧并基于RTC协议将当前接收到的所述视频帧发送给所述客户端。

10.一种电子设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至8中任一项所述的直播的实现方法。

11.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至8中任一项所述的直播的实现方法。

Images