直播数据的处理方法、装置及电子设备与流程

专利2022-05-09  18


本申请涉及一种直播数据的处理方法、装置及电子设备,属于计算机技术领域。



背景技术:

目前的直播中,采用cdn(contentdeliverynetwork,内容分发网络)技术进行直播数据分发,直播端将视频数据发送到离播放端较近的cdn节点上进行缓存,然后,再由cdn节点向播放端进行直播数据发送。

在一些情况下,由于直播端网络抖动,例如wifi、4g信号被干扰,可能造成短时间网络阻塞,然后瞬间所有数据全部发送到cdn节点,而cdn节点需要向大量的播放端进行数据发送,很可能会造成网络拥塞,导致播放端出现卡顿。此外,对于访问量超大的直播端进行直播的情形,还会出现数据的尖峰,很可能会直接把cdn节点的处理能力打满,造成大范围的播放端的卡顿,这种情况,尤其在大量播放端同时涌入直播间的情形,为了实现秒开直播,cdn节点会发送大量的gop(groupofpictures,图像组)缓存数据,从而造成数据突发,很容易超过udp(userdatagramprotocol,用户数据报协议)链路的负载能力,造成大量丢包以及在秒开期间出现花屏及卡顿现象。



技术实现要素:

本发明实施例提供一种直播数据的处理方法、装置及电子设备,以应对数据突发,减少卡顿现象。

为了实现上述目的,本发明实施例提供了一种直播数据的处理方法,包括:

响应于播放端发送的直播播放请求,以第一平滑发送速度发送首个图像组的关键帧的图像数据;

以第二平滑发送速度发送所述首个图像组的关键帧以外的其他帧的图像数据,其中,所述第一平滑发送速度大于所述第二平滑发送速度。

本发明实施例还提供了一种直播数据的处理装置,包括:

第一平滑处理模块,用于响应于播放端发送的直播播放请求,以第一平滑发送速度发送首个图像组的关键帧的图像数据;

第二平滑处理模块,用于以第二平滑发送速度发送所述首个图像组的关键帧以外的其他帧的图像数据,其中,所述第一平滑发送速度大于所述第二平滑发送速度。

本发明实施例还提供了一种直播数据的处理方法,包括:

获取直播端的码率和/或请求直播数据的播放端的数量;

根据直播端的码率和/或请求直播数据的播放端的数量确定多个级别的平滑发送速度;

根据各个播放端对应的直播进程,动态配置所述多个级别的平滑发送速度来进行直播数据的发送。

本发明实施例还提供了一种电子设备,包括:

存储器,用于存储程序;

处理器,用于运行所述存储器中存储的所述程序,以执行前述的直播数据的处理方法。

本发明实施例直播数据的处理方法、装置及电子设备,根据不同的直播数据发送阶段执行相应的平滑发送处理策略,来减缓数据突发而造成丢包以及图像卡顿的问题,尤其是针对秒开直播阶段,对于关键帧采用较大的平滑发送速度进行发送,从而让播放端尽快获得关键帧并进行播放,然后再使用相对小一些的平滑发送速度发送首个gop数据中的其他帧的图像数据,从而能够有效减缓在直播开始阶段的数据尖峰,并且不影响在播放端快速呈现直播画面。

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

附图说明

图1为本发明实施例的直播数据的处理方法的应用场景示意图之一;

图2为本发明实施例的直播数据的处理方法的应用场景示意图之二;

图3为本发明实施例的cdn节点的结构示意图;

图4为本发明实施例的直播场景下的直播数据量变化的示意图;

图5为本发明实施例的直播场景下的直播数据平滑效果的示意图;

图6为本发明实施例的直播数据的处理方法的流程示意图;

图7为本发明实施例的直播数据的处理装置的结构示意图;

图8为本发明实施例的电子设备的结构示意图。

具体实施方式

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

下面通过一些具体实施例来进一步说明本发明的技术方案。

如图1和图2所示,其为本发明实施例的直播数据的处理方法的应用场景示意图。本发明实施例的网络直播采用cdn网络进行直播数据分发,直播数据会先被传输至cdn网络上的各个cdn节点上,然后再由cdn节点向播放端进行发送。在直播场景下,直播端向cdn网络发送直播数据的过程称为推流,播放端向cdn节点请求直播数据的过程称作拉流。播放端通过与直播服务平台的交互来获取拉流地址,播放端会从网络路径距离较近的cdn节点进行拉流,从而减少直播数据的延迟,整个cdn网络可以部署在较大范围的区域中,从而可以将直播端的直播数据快速高效地提供给众多的播放端。推流的处理可以采用两种方式,一种是直播端直接将直播数据发送至cdn网络,如图1所示,直播端通过与直播服务平台的交互,获取推流地址,然后根据推流地址向cdn网络发送直播播放数据,另一种方式为直播端将直播数据发送至直播服务平台,然后由直播服务平台向cdn网络进行推流。

随着互联网直播体量的增大,同时参与直播的用户经常在超大数量级,对于访问量超大的直播端,甚至会在千万甚至上亿的用户同时参与直播。在网络抖动或者大量用户瞬间涌入直播间的情况下,经常导致较大的网络数据尖峰,从而造成大量丢包,体现到播放端上,会出现花屏或者卡顿的现象,非常影响用户参与直播的体验。这种问题在直播秒开的场景下更为严重,一些访问量超大的直播端,在开播时候或者搞活动的时候,往往出现大量用户同时加入直播间,由于同时请求直播数据的用户量非常大,会出现非常大的数据突发,以至于超过udp链路的缓存承受能力,造成大量丢包,在播放端造成较大的开播延迟或者花屏等现象。

本发明实施例的直播数据的处理方法正是针对上述问题提出的,通过根据不同的直播数据发送阶段执行相应的平滑发送处理策略,来减缓数据突发而造成的各种问题。如图3所示,其为本发明实施例的cdn节点的结构示意图,本发明的直播数据的处理方法可以应用在各个cdn节点上,图3所示的场景为直播端将直播数据推流到cdn节点上,然后由cdn节点向播放端发送。

在本发明实施例中,直播数据可以包括视频数据和音频数据两部分,其中,视频数据可以采用gop(groupofpictures,图像群组)的形式进行编码,在直播端,图像编码器将多张图像进行编码后,生成一组一组的gop数据,在播放端,图像解码器对一组一组的gop数据解码重建出视频图像。gop是一组连续的图像,由一张i帧(也称为关键帧)和数张b/p帧组成,是视频图像编码器和解码器存取和处理的基本单位,这样的i帧和数张b/p帧的排列方式会不断重复,直到直播视频的结束。其中,i帧是内部编码帧,i帧是一个完整的图像,而p帧和b帧记录的是相对于i帧的变化数据,p帧是前向预测帧(前向参考帧),b帧是双向内插帧(双向参考帧),p帧和b帧都依赖于i帧进行解码,在gop格式中,i帧处于gop数据的第一帧。音频数据独立于视频数据进行编码和解码,并通过时间戳方式与视频的各帧图像数据进行对齐,在数据传输方式上,一般采用音视频交织的方式进行数据传输。

如图3所示,直播数据在推流至cdn节点后,其中,视频数据和音频数据分别被放入gop数据缓存和音频数据缓存。然后,根据预设的直播数据处理策略,对不同阶段的直播数据进行分级的平滑处理,平滑处理逻辑主要通过秒开处理模块和直播数据处理模块以及平滑处理模块来协同完成。这里所说的平滑发送处理是指对缓存的视频数据和音频数据按照配置的平滑发送速率进行发送,将突发数据量进行平缓发送,从而避免网络拥塞,平滑过程中,会根据数据内容的优先级进行有区别的速度配置,从而让直播数据以更加合理的速度分配向播放端进行发送。在本发明实施例中,平滑处理策略可以分为三级:

1)秒开首帧

如前面所提到的i帧处于gop数据的第一帧,是一个完整的图像,后面的p帧和b帧需要依赖于i帧来进行解码,因此,i帧的数据量相对于同组的gop数据中的p帧和b帧要大很多。此外,对于视频直播中,视频流gop数据的i帧更具有特殊意义,这个i帧是整个视频图像序列的起始帧,一般称作idr帧,其除了具有一般i帧的作用外,还是视频图像序列开始的标志,idr帧之后的所有帧都不能引用任何idr帧之前的帧的内容。需要说明的是,在本发明实施例中,首个图像组是指在播放端请求加入直播后,即播放端向cdn节点发送直播数据请求后,cdn节点向播放端发送的第一组gop数据,上述的秒开首帧以及下面的秒开gop缓存,都是针对该第一组gop数据的处理策略。

对于视频直播场景,直播秒开是评价用户体验的重要指标,因此,在平滑发送策略的配置上,会让播放端尽快获得首个i帧,从而能够在播放端上迅速呈现直播画面,并且为后续的p帧和b帧的解码做好准备,让起播阶段更加顺畅。因此,在配置平滑发送速度时,对于首个i帧配置速度最高的第一平滑发送速度。

2)秒开gop缓存

在首个i帧发送完毕后,使用相对比较大的第二平滑发送速度发送第一组gop数据中剩余的p帧和b帧。由于p帧和b帧相对于i帧来说,数据量较小,在小于第一平滑发送速度的情况下,仍然能够让播放端持续获得图像帧,从而让用户在快速打开视频直播画面后,能够紧接着看到连续的画面。与此同时,与第一组gop数据对应的音频数据可以和视频数据以交织的方式进行发送。

3)常规直播数据发送

前述的1)和2)完成了秒开直播阶段的处理,在秒开完成后,对于后面常规的直播数据,即第一组gop数据之后直播数据,可以采用小于上述第二平滑发送速度的第三平滑发送速度进行视频数据的发送,从而让后整个直播过程中的直播数据传输在时间维度上进行平缓处理,避免数据尖峰,提高直播过程中的流畅性。

由于在播放端一侧已经获得了至少一组的gop数据,其中包含了完整图像的i帧和多个p帧和b帧,基于这些图像帧,即使在直播过程中,存在一些gop数据的延迟,基于已经接收到的gop数据,在短时间内仍然可以渲染出视频画面,从而不会出现黑屏或者严重卡顿的现象。

此外,由于在每组gop数据中,i帧是必然存在的,而i帧相对于b帧和p帧而言,其数据量会很大,也就是说,在首个i帧之后,在常规直播数据的发送过程中,仍然会出现i帧而导致的数据冲击,只不过,在此之前已经接收到i帧,即使当前的i帧出现卡顿,基于之前的接收到的i帧以及p帧和b帧对应的图像,仍然可以维持直播画面显示。但是在带宽不足的情况下,由于大的i帧冲击可能会导致音频数据的滞后,因此,可以在遇到传输i帧时,先发送对应的音频数据,然后再传送该i帧的数据,从而在播放端能够让用户听到连续的声音,从而不会影响直播进程。

如图4所示,其为本发明实施例的直播场景下的直播数据量变化的示意图,其中,横轴表示时间维度,纵轴表示直播数据量,从图中可以看出,在每隔一定时间会出现较高的数据尖峰,数据尖峰出对应着i帧的数据发送。再入图5所示,其为本发明实施例的直播场景下的直播数据平滑效果的示意图,图5(a)为未使用本发明实施例的平滑发送处理的直播数据的波动情况,图5(b)为使用了本发明实施例的平滑发送处理的直播数据的波动情况,在图5(a)中,在刚开播时,出现了较大的数据尖峰,这是由于大量的用户进入直播间,各个用户对应的播放端几乎同时请求直播数据,为了实现秒开,cdn节点需要向大量的播放端发送直播数据,从而造成了第一个数据尖峰,如图中的0.5到2秒时间段中,在这个数据尖峰时间段,由于网络拥塞还可能会造成大量丢包而触发重传,进一步加剧了数据尖峰。当过了需要秒开直播的阶段,播放端接收的直播数据流相对稳定,但仍然会在部分时间出现数据尖峰,例如传送i帧的时候,但是由于过了需要秒开直播的阶段,数据尖峰相对平缓。在图5(b)中,应用了本发明实施例的平滑发送处理后,将秒开直播阶段的大的数据尖峰被平滑到了0.5到5秒的时间段中,数据峰值明显下降,并且从图5(b)中可以看出,在平滑后的数据中,在0.5秒附近会有高于后面平滑阶段的小尖峰,这个部分对应于前面介绍的秒开首帧的策略,即第一平滑发送速度将首个i帧发送出去,由于这个处理仅仅是针对首个i帧的,因此,没有造成如图5(a)那么大的数据尖峰,因此,不会出现大量丢包。另外,在针对后续的数据尖峰的处理中,可以看出,通过本发明实施例的平滑发送处理,也明显地弱化或者去除了数据尖峰,从而获得更加顺畅的直播体验。

以上介绍针对直播过程的分阶段的平滑发送策略,在确定了某个阶段所使用的平滑发送速度后,可以通过调用基于udp协议的数据包发送接口函数来执行数据发送,并通过控制调用数据包发送接口函数的时间间隔和每次发送的数据量来实现平滑速度的控制。在本发明实施例中,可以采用udp多包发送机制来批量发送udp数据包,从而减少调用接口函数的次数,以节省cpu的占用率。具体地,可以调用sendmmsg函数来进行多udp包的批量发送。具体地,udp多包发送函数可以以预设的时间间隔进行调用,对于每次调用udp多包发送函数所发送的数据量,可以根据预设的时间间隔和当前采用的平滑发送速率而确定。例如,可以将时间间隔设定为10ms,如果当前设定的平滑发送速度为8000kbps(每秒发送的字节数,每个字节为8位),则可以计算出发送的数据量为(8000k/8)×(10/1000)=10kb。通过每隔10ms调用一次sendmmsg函数,每次调用发送的数据量为10kb,就可以实现8000kbps的平滑发送速度,需要说明的是,调用一次sendmmsg函数所发送的数据量,可以视为是瞬间发出的或者在间隔时间中平滑发出的,这部分数据量的具体发送速度是由系统控制,不再本发明实施例的平滑控制策略的范围中。因此,在本发明实施例中,调用数据包发送接口函数的时间间隔,决定了平滑控制的控制粒度,时间间隔设定的越短,对于平滑速度的控制粒度会越细,具体的时间间隔设定可以综合cpu使用效率和希望实现的平滑控制粒度而确定。

另外,对于平滑发送速度的选择,需要兼顾平滑和播放体验,尤其是在秒开阶段,如果第一平滑发送速度过大,则在秒开期间起不到平滑的作用,如果过小会导致数据发送速度太慢,影响播放体验。因此,在本发明实施例中,可以根据直播端的码率和根据直播播放数据反馈,来选择最适合的平滑发送速度,从而实现平滑和播放体验的兼顾。直播端的码率是指编码器每秒编码的数据大小,单位是kbps,比如800kbps代表编码器每秒产生800kb的数据,直播端的码率可以由主播进行选择,由于直播项目一般是基于直播服务平台和cdn网络而进行的,因此,直播端的用户(一般为主播)所选择的码率一方面取决于自身的硬件设置,另一方面也取决于直播服务平台为其提供的直播服务等级,直播端用户选择的码率越高,相应的带宽费用可能也会越高,直播端的码率属于在开始直播前的预设值,一般来说,直播端的码率越高,所需要的平滑发送速度也就越大。上述的直播播放数据反馈是指一种事后反馈机制,即在以某个平滑发送速度执行平滑处理后,从播放端获得反馈数据,来评估当前设定的平滑发送速度是否合理,例如,以秒开阶段为例,在以当前的第一平滑发送速度和第二平滑发送速度完成对首个i帧以及第一组gop数据中的剩余帧的数据发送后,从而大量的播放端可以获得实际的秒开直播画面以及后续几帧画面的流畅程度的数据反馈,从而根据这些信息来优化第一平滑发送速度和第二平滑发送速度,从而使得后续再进入该直播间的播放端能够获得更加良好的秒开直播的用户体验。

此外,由于关键帧包含了完整的图像画面并且在播放端不需要进行解码处理,因此,在播放端可以从接收到的图像组数据中仅选择关键帧进行播放,在而且即使在cdn一侧,也可以只向播放端发送关键帧,这样处理,一方面,能够大量减少播放端对b帧或者p帧等非关键帧的解码处理,从而加快视频呈现速度,另一方面,也减少了向播放端传输的视频数据量,虽然这样的处理会损失一定的画面质量以及连续性,但是在应对突然出现数据突发时,不会因为b帧或者p帧传输的延迟,而导致播放画面呈现不及时或者图像卡顿等现象。另外,在上述的技术方案中,可以在播放端记录播放日志,用于记录播放过程中的接收视频数据接收、解码的处理情况,其中,可以包括数据突发、丢包的异常情况,使用该播放日志可以用于直播过程中数据处理的回放、测试等,以进一步优化平滑处理策略,提高直播效果。本发明实施例的直播数据的处理方法,通过根据不同的直播数据发送阶段执行相应的平滑发送处理策略,来减缓数据突发而造成丢包以及图像卡顿的问题,尤其是针对秒开直播阶段,对于i帧采用较大的平滑发送速度进行发送,从而让播放端尽快获得i帧并进行播放,然后再使用相对小一些的平滑发送速度发送首个gop数据中的其他帧的图像数据,从而能够有效减缓在直播开始阶段的数据尖峰,并且不影响在播放端快速呈现直播画面。

实施例一

如图6所示,其为本发明实施例的直播数据的处理方法的流程示意图,该方法可以应用于进行直播数据发送的cdn节点上,该方法可以包括:

s101:响应于播放端发送的直播播放请求,以第一平滑发送速度发送首个图像组(gop)的i帧的图像数据。

i帧处于图像组的第一帧,是一个完整的图像,后面的p帧和b帧需要依赖于i帧来进行解码,而首个i帧是整个视频图像序列的起始帧,只要获得了首个i帧,才能显示直播画面,因此,在平滑发送策略的配置上,会让播放端尽快获得首个i帧,从而能够在播放端上迅速呈现直播画面,并且为后续的p帧和b帧的解码做好准备,让起播阶段更加顺畅。因此,在配置平滑发送速度时,对于首个i帧配置速度最高的第一平滑发送速度,该第一平滑发送速度可以配置为在不发生丢包的情况下的最大发送速度。

s102:以第二平滑发送速度发送所述首个图像组的i帧以外的其他帧的图像数据,其中,第一平滑发送速度大于第二平滑发送速度。

在首个i帧发送完毕后,可以使用相对比较大的第二平滑发送速度发送第一组图像组的数据中剩余的p帧和b帧。由于p帧和b帧相对于帧来说,数据量较小,在小于第一平滑发送速度的情况下,仍然能够让播放端持续获得图像帧,从而让用户在快速打开视频直播画面后,能够紧接着看到连续的画面,从而兼顾了数据发送的平滑性和秒开阶段的画面连续性。

上述的步骤s101和步骤s102完成了针对第一个图像组的平滑发送处理,由于在直播场景下,数据突发最为严重的时间段就是大量播放端同时进入直播间而请求直播数据的初始阶段,在这个阶段希望为用户提供快速进入直播画面的秒开体验,因此,配置的较高的平滑发送速度。而过了秒开阶段后,对于后续图像组的数据,由于数据突发现象相对减弱,可以根据网络情况采用不同的发送速度进行发送,例如根据拥塞控制策略确定的发送速度,发送后续图像组中的视频帧的图像数据。或者,也可以采用如下步骤s103的处理进行发送。

s103:以第三平滑发送速度发送后续图像组的视频帧的图像数据,所述第三平滑发送速度小于所述第二平滑发送速度。在经过秒开直播阶段后,播放端对于快速播放后续的直播图像的迫切程度降低了,这是因为在播放端一侧已经获得了至少一组的图像组的数据,其中包含了完整图像的i帧和多个p帧和b帧,基于这些图像帧,即使在直播过程中,存在一些图像组的数据的延迟,基于已经接收到的图像组的数据,在短时间内仍然可以渲染出视频画面,从而不会出现黑屏或者严重卡顿的现象。因此,在秒开完成后,对于后面常规的直播数据,即第一组图像组的数据之后直播数据,可以采用小于上述第二平滑发送速度的第三平滑发送速度进行视频数据的发送,从而让后整个直播过程中的直播数据传输在时间维度上进行平缓处理,避免数据尖峰,提高直播过程中的流畅性。

此外,对于后续图像组,由于每个图像组中必然有i帧存在,在带宽不足的情况下,仍然会出现i帧而导致的数据冲击。由于大的i帧冲击可能会导致音频数据的滞后,对此,可以采用如下方式进行处理,在对于后续的图像组平滑发送处理,优先发送该图像组中的图像数据对应的音频数据,然后再发送图像数据。而在秒开阶段,可以采用默认的音视频交织的方式发送图像组数据和音频数据,也可以优先发送图像组的视频数据,然后再发送对应的音频数据,从而尽可能满足快速秒开直播画面的需求。

作为另外一种可实施方式,对应首个图像组之后的视频数据,也可以两个级别的速度进行平滑发送。具体地,以第四平滑发送速度发送后续图像组中的i帧的图像数据,以第五平滑发送速度发送后续图像组中的i帧以外的其他帧的图像数据,其中,所述第四平滑发送速度小于所述第二平滑发送速度,所述第五平滑发送速度小于所述第四平滑发送速度。

进一步地,上述各个阶段的平滑发送速度可以根据直播端的码率和/或根据直播播放数据反馈来确定。其中,直播端的码率是指编码器每秒编码的数据大小,直播端的码率可以由直播端设定,可以视为预设值,直播端的码率越高,所需要的平滑发送速度也就越大。上述的直播播放数据反馈是指一种事后反馈机制,即在以某个平滑发送速度执行平滑处理后,从播放端获得反馈数据,来评估当前设定的平滑发送速度是否合理,以秒开阶段为例,在以当前的第一平滑发送速度和第二平滑发送速度完成对首个i帧以及第一组gop数据中的剩余帧的数据发送后,从大量的播放端可以获得实际的秒开直播画面以及后续几帧画面的流畅程度的数据反馈,从而根据这些信息来优化第一平滑发送速度和第二平滑发送速度,使得后续再进入该直播间的播放端能够获得更加良好的秒开直播的用户体验。

此外,在确定了某个阶段所使用的平滑发送速度后,可以通过调用基于udp协议的数据包发送接口函数来执行数据发送。在本发明实施例中,可以采用udp多包发送机制来批量发送udp数据包,从而减少调用接口函数的次数,以节省cpu的占用率。具体地,可以调用sendmmsg函数来进行多udp包的批量发送。

进一步地,udp多包发送函数可以以预设的时间间隔进行调用,对于每次调用udp多包发送函数所发送的数据量,即udp数据包的个数,可以根据预设的时间间隔和当前采用的平滑发送速率而确定。

本发明实施例的直播数据的处理方法,通过根据不同的直播数据发送阶段执行相应的平滑发送处理策略,来减缓数据突发而造成丢包以及图像卡顿的现象,为播放端的用户提供更加流畅的直播体验。

实施例二

如图7所示,其为本发明实施例的直播数据的处理装置的结构示意图,该装置可以应用于进行直播数据发送的cdn节点上,具体地,该装置包括:

第一平滑处理模块11,用于响应于播放端发送的直播播放请求,以第一平滑发送速度发送首个图像组的i帧的图像数据。

i帧处于图像组的第一帧,是一个完整的图像,后面的p帧和b帧需要依赖于i帧来进行解码,而首个i帧是整个视频图像序列的起始帧,只要获得了首个i帧,才能显示直播画面,因此,在平滑发送策略的配置上,会让播放端尽快获得首个i帧,从而能够在播放端上迅速呈现直播画面,并且为后续的p帧和b帧的解码做好准备,让起播阶段更加顺畅。因此,在配置平滑发送速度时,对于首个i帧配置速度最高的第一平滑发送速度,该第一平滑发送速度可以配置为在不发生丢包的情况下的最大发送速度。

第二平滑处理模块12,用于以第二平滑发送速度发送所述首个图像组的i帧以外的其他帧的图像数据,其中,所述第一平滑发送速度大于所述第二平滑发送速度。

在首个i帧发送完毕后,可以使用相对比较大的第二平滑发送速度发送第一组图像组的数据中剩余的p帧和b帧。由于p帧和b帧相对于i帧来说,数据量较小,在小于第一平滑发送速度的情况下,仍然能够让播放端持续获得图像帧,从而让用户在快速打开视频直播画面后,能够紧接着看到连续的画面,从而兼顾了数据发送的平滑性和秒开阶段的画面连续性。

上述的模块完成了针对第一个图像组的平滑发送处理,由于在直播场景下,数据突发最为严重的时间段就是大量播放端同时进入直播间而请求直播数据的初始阶段,在这个阶段希望为用户提供快速进入直播画面的秒开体验,因此,配置的较高的平滑发送速度。而过了秒开阶段后,对于后续图像组的数据,由于数据突发现象相对减弱,可以根据网络情况采用不同的发送速度进行发送,例如根据拥塞控制策略确定的发送速度,发送后续图像组中的视频帧的图像数据。或者,也可以采用如下的模块进行发送。

第三平滑处理模块13,以第三平滑发送速度发送后续图像组的视频帧的图像数据,所述第三平滑发送速度小于所述第二平滑发送速度。

在经过秒开直播阶段后,播放端对于快速播放后续的直播图像的迫切程度降低了,这是因为在播放端一侧已经获得了至少一组的图像组的数据,其中包含了完整图像的i帧和多个p帧和b帧,基于这些图像帧,即使在直播过程中,存在一些图像组的数据的延迟,基于已经接收到的图像组的数据,在短时间内仍然可以渲染出视频画面,从而不会出现黑屏或者严重卡顿的现象。因此,在秒开完成后,对于后面常规的直播数据,即第一组图像组的数据之后直播数据,可以采用小于上述第二平滑发送速度的第三平滑发送速度进行视频数据的发送,从而让后整个直播过程中的直播数据传输在时间维度上进行平缓处理,避免数据尖峰,提高直播过程中的流畅性。

此外,对于后续图像组,由于每个图像组中必然有i帧存在,在带宽不足的情况下,仍然会出现i帧而导致的数据冲击。由于大的i帧冲击可能会导致音频数据的滞后,对此,可以采用如下方式进行处理,在对于后续的图像组平滑发送处理,优先发送该图像组中的图像数据对应的音频数据,然后再发送图像数据。而在秒开阶段,可以采用默认的音视频交织的方式发送图像组数据和音频数据,也可以优先发送图像组的视频数据,然后再发送对应的音频数据,从而尽可能满足快速秒开直播画面的需求。

作为另外一种可实施方式,对应首个图像组之后的视频数据,也可以两个级别的速度进行平滑发送。具体地,以第四平滑发送速度发送后续图像组中的i帧的图像数据,以第五平滑发送速度发送后续图像组中的i帧以外的其他帧的图像数据,其中,所述第四平滑发送速度小于所述第二平滑发送速度,所述第五平滑发送速度小于所述第四平滑发送速度。

进一步地,上述装置还可以包括平滑发送速度确定模块14,用于根据直播端的码率和/或直播播放数据反馈,确定与所述直播端对应的平滑发送速度。其中,直播端的码率是指编码器每秒编码的数据大小,直播端的码率可以由直播端设定,可以视为预设值,直播端的码率越高,所需要的平滑发送速度也就越大。上述的直播播放数据反馈是指一种事后反馈机制,即在以某个平滑发送速度执行平滑处理后,从播放端获得反馈数据,来评估当前设定的平滑发送速度是否合理。

此外,在确定了某个阶段所使用的平滑发送速度后,可以通过调用基于udp协议的数据包发送接口函数来执行数据发送。在本发明实施例中,可以采用udp多包发送机制来批量发送udp数据包,从而减少调用接口函数的次数,以节省cpu的占用率。具体地,可以调用sendmmsg函数来进行多udp包的批量发送。进一步地,udp多包发送函数可以以预设的时间间隔进行调用,对于每次调用udp多包发送函数所发送的数据量,即udp数据包的个数,可以根据预设的时间间隔和当前采用的平滑发送速率而确定。

本发明实施例的直播数据的处理装置,通过根据不同的直播数据发送阶段执行相应的平滑发送处理策略,来减缓数据突发而造成丢包以及图像卡顿的现象,为播放端的用户提供更加流畅的直播体验。

实施例三

本发明实施例提供了一种直播数据的处理方法,可以应用于进行直播数据发送的cdn节点上,具体地,该方法包括:

s201:获取直播端的码率和/或请求直播数据的播放端的数量。这里所说的直播端的码率是指直播端配置的编码器每秒编码的数据大小,在直播端的硬件和软件配置的处理能力范围内,码率可以由直播端的用户设定,在基于直播服务平台而进行的直播中,码率也可以由直播服务平台根据直播用户的等级或者选择的服务等级来进行设定。直播端的码率直接决定了直播过程中直播数据的传输量,直播端的码率越高,所需要的平滑发送速度也就越大。另外,这里所述请求直播数据的播放端包括了刚加入直播而请求直播数据的播放端,也包括已经发送过直播数据请求而目前正处于直播中的播放端。对于某个直播端的直播,请求直播数据的播放端的数量越多,那么cdn网络需要向播放端传输的数据量也越大,因此,也就更加容易形成数据突发的情况。直播端的码率可以从直播服务平台对直播端的配置数据中获取,也可以在直播端开播的时候,从直播端直接获取。

s202:根据直播端的码率和/或请求直播数据的播放端的数量确定多个级别的平滑发送速度。如前面介绍的,直播端的码率和播放端的数量会对直播传输数据量由较大影响,通过获取到这两个数据能够有效地估计出数据突发的情况,从而确定合理的平滑发送速度。需要说明的是,直播端的码率以及播放端的数量可以是动态变化的,cdn节点可以定期获取直播端的码率以及统计请求直播数据的播放端的数量,从而来动态确定平滑发送速度。这里所说的多个级别的平滑发送速度可以根据实际的平滑发送策略而定,例如可以设定为三个级别或者四个级别,以对应直播进程不同阶段。而平滑发送速度的具体设定值可以根据经验值设定,也可以根据播放端的直播播放数据反馈而动态调整。

s203:根据各个播放端对应的直播进程,动态配置所述多个级别的平滑发送速度来进行直播数据的发送。如前面实施例所介绍的,本发明实施例可以采用对不同阶段的直播数据进行分级的平滑处理,作为示例,可以采用如下两种平滑发送策略:1)分为三个级别的平滑发送速度:依次递减的第一平滑发送速度、第二平滑发送速度以及第三平滑发送速度。相应地,该步骤s203可以包括:

响应于播放端发送的直播播放请求,以第一平滑发送速度发送首个图像组的关键帧的图像数据,然后,以第二平滑发送速度发送所述首个图像组的关键帧以外的其他帧的图像数据,最后,以第三平滑发送速度发送后续图像组的视频帧的图像数据。在该策略中,将首个图像组的图像数据分为了首个关键帧和首个关键帧以外的其他帧来进行分级发送,对于首个图像组之后的图像组,作为常规视频数据以相对较低的平滑速度进行发送。

2)分为四个级别的平滑发送速度:依次递减的第一平滑发送速度、第二平滑发送速度、第四平滑发送速度以及第五平滑速度。相应地,该步骤s203可以包括:

响应于播放端发送的直播播放请求,以第一平滑发送速度发送首个图像组的关键帧的图像数据,然后,以第二平滑发送速度发送所述首个图像组的关键帧以外的其他帧的图像数据。之后,以第四平滑发送速度发送后续图像组中的关键帧的图像数据,以第五平滑发送速度发送后续图像组中的关键帧以外的其他帧的图像数据。在该策略中,将首个图像组的图像数据分为了首个关键帧和首个关键帧以外的其他帧来进行分级发送,对于首个图像组之后的图像组,仍然划分为两个级别,并用相对较小的第四平滑发送速度以及第五平滑速度来发送。

以上介绍针对图像数据的发送策略,而对于音频数据,也可以根据直播的不同阶段,而采用不同的策略,具体地,可以包括:在发送所述首个图像组的图像数据过程中,可以以音视频交错的方式,发送图像数据和对应的音频数据,另外,在发送所述后续图像组的图像数据过程中,可以先发送对应的音频数据,再发送图像数据,这样的方式能够在直播过程中,保证播放端能够先听到声音,尽量保证声音的不延迟,从而播放端的用户能够及时获取到直播内容信息。

需要说明的是,上述的策略针对各个播放端的直播进程而分别进行的,从而能够让每个播放端能获得平滑处理的效果,使得直播效果更加流畅。

本发明实施例的直播数据的处理方法,根据不同直播阶段实行分级的平滑处理策略,并且根据直播端的码率以及播放端的数量来确定合理的平滑发送速度,从而能够有效减缓数据突发而造成丢包以及图像卡顿的问题,提高直播质量。

实施例四

前面实施例描述了直播数据的处理方法的流程处理及装置结构,上述的方法和装置的功能可借助一种电子设备实现完成,如图8所示,其为本发明实施例的电子设备的结构示意图,具体包括:存储器110和处理器120。

存储器110,用于存储程序。

除上述程序之外,存储器110还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令,联系人数据,电话簿数据,消息,图片,视频等。

存储器110可以由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(sram),电可擦除可编程只读存储器(eeprom),可擦除可编程只读存储器(eprom),可编程只读存储器(prom),只读存储器(rom),磁存储器,快闪存储器,磁盘或光盘。

处理器120,耦合至存储器110,用于执行存储器110中的程序,以执行前述实施例中所描述的直播数据的处理方法的操作步骤。

此外,处理器120也可以包括前述实施例所描述的各种模块以执行直播数据的处理,并且存储器110可以例如用于存储这些模块执行操作所需要的数据和/或所输出的数据。

对于上述处理过程具体说明、技术原理详细说明以及技术效果详细分析在前面实施例中进行了详细描述,在此不再赘述。

进一步,如图所示,电子设备还可以包括:通信组件130、电源组件140、音频组件150、显示器160等其它组件。图中仅示意性给出部分组件,并不意味着电子设备只包括图中所示组件。

通信组件130被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络,如wifi,2g、3g、4g/lte、5g等移动通信网络,或它们的组合。在一个示例性实施例中,通信组件130经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中,通信组件130还包括近场通信(nfc)模块,以促进短程通信。例如,在nfc模块可基于射频识别(rfid)技术,红外数据协会(irda)技术,超宽带(uwb)技术,蓝牙(bt)技术和其他技术来实现。

电源组件140,为电子设备的各种组件提供电力。电源组件140可以包括电源管理系统,一个或多个电源,及其他与为电子设备生成、管理和分配电力相关联的组件。

音频组件150被配置为输出和/或输入音频信号。例如,音频组件150包括一个麦克风(mic),当电子设备处于操作模式,如呼叫模式、记录模式和语音识别模式时,麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器110或经由通信组件130发送。在一些实施例中,音频组件150还包括一个扬声器,用于输出音频信号。

显示器160包括屏幕,其屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板,屏幕可以被实现为触摸屏,以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界,而且还检测与触摸或滑动操作相关的持续时间和压力。

本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

转载请注明原文地址:https://doc.8miu.com/read-149997.html

最新回复(0)