音视频拉取方法、装置、存储介质及计算机设备

技术领域

本申请涉及网络直播领域，具体涉及一种音视频拉取方法、装置、存储介质及计算机设备。

背景技术

随着直播行业的不断发展，在直播过程中进行互动的需求逐渐增加。在直播间的互动场景中，观众端拉流的视频，是需要先在服务器侧将各主播端的互动视频流进行混画和混音，经过解码和重新编码后输出新的视频流。然后观众端再通过播放器拉流经过混画和混音后的视频流，实现直播互动场景下的音视频的播放。

影响网络直播观看体验的主要因素包括首屏时间、延时、音画同步、流畅性四个方面。同时现在的网络直播越来越强调主播和观众之间的互动交流，而时延是影响互动的最重要的因素。

在观众端的播放器一般采用HTTP-FLV或者RTMP协议从CDN拉流，主播端到观众端(以下简称端到端)一般会有2～5秒的延时，有些赛事直播为了流畅性可能选择用HLS协议从CDN拉流，端到端延时可能达到5～10秒。这些协议均基于TCP来传输数据，在公网传输上时延很难进一步做优化。

发明内容

本申请实施例提供一种音视频拉取方法、装置、存储介质及计算机设备，用于减少直播音视频播放时的时延，优化用户体验感。

为解决上述的技术问题，本申请实施例提供以下技术方案：

一种音视频拉取方法，该方法应用于第一终端，该第一终端中包含第一实时通讯接口，该音视频拉取方法包括：

接收低延时播放指令；

响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯；

基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。

一种音视频拉取装置，该音视频拉取装置应用于第一终端，该第一终端中包含第一实时通讯接口，该音视频装置包括：

第一接收单元，用于接收低延时播放指令；

第一订阅单元，用于响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯；

拉取单元，用于基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。

在一些实施例中，该第一订阅单元，包括：

解析子单元，基于所述第一实时通讯接口，对所述低延时播放指令进行解析，得到待拉取的音视频流信息，所述视频流信息包括目标传输头和传输地址；

订阅子单元，用于将所述音视频流信息相应的目标传输头发送至所述媒体服务器，订阅与所述传输地址对应的目标音视频流。

在一些实施例中，该拉取单元，包括：

协议子单元，用于通过在所述第一实时通讯接口采用所述用户数据报协议，并根据所述音视频流名称中与所述用户数据报协议对应的传输头传输所述目标音视频流，以确定目标音视频流的协议传输策略；

网络子单元，用于基于预设的网络优化策略，对传输网络进行调整，确定第一实时通讯接口下行的网络传输策略；

执行子单元，用于基于所述协议传输策略和网络传输策略，从所述媒体服务器中主动拉取所述目标音视频流，并播放所述目标音视频流。

在一些实施例中，该网络子单元，还用于：

基于真实宽带探测算法实时监测当前的传输网络的网络质量；

采集所述网络质量的网络数据，并对所述网络数据的数据特征进行分析，确定当前的传输网络对应的网络模型；

在所述网络模型的网络质量未达到预设标准时，根据预设的发送端控制算法，对所述网络模型进行调整，确定目标音视频拉取的网络传输策略。

在一些实施例中，该音视频拉取装置，还用于：

根据所述网络传输策略，生成对应存储大小的缓存区域；

在所述缓存区域中预缓存的音视频流缓存数据；

播放所述音视频流缓存数据，直到获取所述预设的播放帧，停止播放所述音视频流缓存数据并播放所述目标音视频流。

在一些实施例中，该音视频拉取装置，还用于：

基于已播放的音视频流缓存数据，计算对应的回调速度；

根据所述回调速度，对所述音视频流缓存数据进行追帧，以消耗所述音视频流缓存数据并播放所述目标音视频流。

在一些实施例中，该音视频拉取装置，还用于：

通过网络时间协议，计算目标音视频流中音频和视频对应的播放时延；

当所述网络时间协议出现异常时，在所述目标音视频流中音频和视频对应的播放时延中分别添加对应的抖动缓冲，计算目标音视频流中音频和视频对应的目标播放时延；

根据所述目标音视频流中音频和视频对应的目标播放时延，对所述目标音视频流中的音频和视频进行音画同步。

一种音视频拉取装置，该音视频装置应用于服务器，该服务器通过第二实时通讯接口与第二终端进行数据传输，该音视频装置包括：

第二接收单元，用于通过所述第二实时通讯接口的第二预设传输策略，接收第二终端上传的上行音视频流，所述第二实时通讯接口采用用户数据报协议实现通讯；

第二订阅单元，用于接收第一终端请求订阅目标音视频流的订阅指令，所述订阅指令为第一终端调用第一实时通讯接口，订阅待拉取的目标音视频流的操作生成的，所述订阅指令包括第一订阅指令和第二订阅指令；

第二传输单元，用于响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端。

在一些实施例中，该第二接收单元，用于：

通过在所述第二实时通讯接口采用用户数据报协议，并根据与所述用户数据报协议对应的传输头传输所述上行音视频流，以确定上行音视频流的协议传输策略；

基于预设的网络优化策略，对上行音视频流上行的传输网络进行调整，确定第二实时通讯接口的网络传输策略；

基于所述第二通讯接口的协议传输策略和网络传输策略，被动接收所述第二终端的上行音视频流。

在一些实施例中，该第二传输单元，还用于：

当所述上行音视频流为单人直播音视频流时，响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端；

当所述上行音视频流为多人直播互动音视频流时，将所述上行音视频流转发至混画转码服务器，以使得所述混画转码服务器对所述上行音视频流进行直播音视频流混合处理，并接收处理后的上行音视频流；

响应于所述订阅指令，从处理后的上行音视频流中确定对应的目标视频流，并将所述目标音视频流返回至所述第一终端。

一种计算机存储介质，所述存储介质存储有多条指令，所述指令适于处理器进行加载，以执行上述音视频拉取方法中的步骤。

一种计算机设备，包括存储器、处理器以及存储在所述存储器中并可以在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述提供的音视频拉取方法中的步骤。

一种计算机程序产品或计算机程序，所述计算机程序产品或计算机程序包括计算机指令，所述计算机指令存储在存储介质中。计算机设备的处理器从存储介质读取所述计算机指令，处理器执行所述计算机指令，使得所述计算机设备执行上述提供的音视频拉取方法中的步骤。

本申请实施例接收低延时播放指令；响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯；基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。以此，通过实时通讯接口与终端的结合，基于私有RTC协议进行数据传输，降低了直播音视频播放的时延。另外，基于实时通讯接口的传输策略调整，从媒体服务器获取音视频流，减少了直播音视频流进行数据传输的步骤，提高了目标音视频流的拉取效率和播放效果，进而减少了音视频流播放时的时延，优化用户直播观看体验。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的直播系统的架构示意图；

图2是本申请实施例提供的音视频拉取方法的流程示意图；

图3是本申请实施例提供的音视频拉取方法的场景示意图；

图4是本申请实施例提供的音视频拉取方法的时序流程示意图；

图5是本申请实施例提供的音视频拉取方法的另一流程示意图；

图5a是本申请实施例提供的音视频拉取方法的另一场景示意图；

图6是本申请实施例提供的音视频拉取装置的结构示意图；

图7是本申请实施例提供的音视频拉取装置的另一结构示意图；

图8是本申请实施例提供的计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供一种音视频拉取方法、装置、存储介质及计算机设备。

以下首先对本申请技术方案中的直播系统的架构进行说明，请参阅图1，图1为本申请实施例所提供的直播系统的架构示意图，在该直播系统中可以包括：客户端A、媒体服务器B以及混画转码服务器C。其中，客户端A与媒体服务器B之间可以通过通信网络连接；媒体服务器B与混画转码服务器C之间可以通过通信网络连接。该通信网络，包括无线网络以及有线网络，其中无线网络包括无线广域网、无线局域网、无线城域网、以及无线个人网中的一种或多种的组合。网络中包括路由器、网关等等网络实体，图中并未示意出。

该直播系统可以包括音视频拉取装置，该音视频拉取装置具体可以集成在平板电脑、手机、笔记本电脑、台式电脑等具备储存单元并安装有微处理器而具有运算能力的终端中。该终端可以安装客户端A，其中，客户端A可以包括主播客户端和观众客户端，主播客户端和观众客户端的数量都不做相应的限制。需要说明的是，主播客户端通过RTC的上行模块上传直播的音视频数据或应用技术成像得到的虚拟成像场景画面；观众客户端通过RTC的下行模块拉取并播放音视频流或应用技术成像得到的虚拟成像场景画面。该客户端A的观众客户端可以用于接收低延时播放指令；响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯；基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。

该直播系统还可以包括媒体服务器B，该媒体服务器B中可以包括若干数量的媒体服务器，存储有主播客户端进行直播的音视频数据。当媒体服务器B接收到主播客户端上行的音视频数据时，媒体服务器B可以检测该音视频数据是否在音视频流的互动场景下，若主播客户端上行的音视频流数据不在互动场景下，则响应于客户端A的观众客户端的订阅指令，将音视频数据发送至客户端A的观众客户端进行播放；若主播客户端上行的音视频数据在互动场景下，则将该音视频数据发送至混画转码服务器C进行混画混音操作，并缓存记录混画混音后的互动音视频数据。该媒体服务器B在本实施例的直播系统扮演着数据转发的角色，可以用于通过所述第二实时通讯接口的第二预设传输策略，接收第二终端上传的上行音视频流，所述第二实时通讯接口采用用户数据报协议实现通讯；接收第一终端请求订阅目标音视频流的订阅指令，所述订阅指令为第一终端调用第一实时通讯接口，订阅待拉取的目标音视频流的操作生成的；响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端。

该直播系统还可以包括混画转码服务器C，该混画转码服务器C可以对互动场景下从主播客户端上传的音视频流进行混画混音，当接收到媒体服务器B的音视频流数据为互动场景下的多人音视频数据时，将多人音视频数据发送至混画转码服务器C，通过混画转码服务器C对多人的音视频数据进行混画混音转码。

需要说明的是，图1所示的直播系统的架构示意图仅仅是一个示例，本申请实施例描述的直播系统以及架构是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着直播系统的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

以下分别进行详细说明。

在本实施例中，将从音视频拉取装置的角度进行描述，该音视频拉取装置具体可以集成在终端的客户端中。

请参阅图2，图2是本申请实施例提供的音视频拉取方法的流程示意图。该音视频拉取方法应用于直播系统的第一终端，在该第一终端中包含第一实时通讯接口，该音视频拉取方法包括：

在步骤S101中，接收低延时播放指令。

其中，第一终端可以是直播系统的观众客户端，观众客户端可以通过第一实时通讯接口拉取目标音视频流，并在观众客户端的播放器上播放该目标音视频流。具体地，第一实时通讯接口可以是RTC(Real Time Communication，实时通讯)的下行模块，观众客户端通过该RTC的下行模块与服务器进行数据传输。

在现有技术中，观众端播放器采用如RTMP、HTTP-FLV、HLS协议拉流，这些底层基于TCP的传输的拉流协议，时延都比较高，进而影响了观众观看直播的体验感。

为解决上述问题，本申请实施例通过在观众客户端的直播界面上添加一个低延时播放的触发组件，在当前直播间正在播放的音视频数据存在时延问题时，用户可以通过触发该低延时播放组件，生成低延时播放指令，该低延时播放指令用于调整当前直播间的直播音视频流的传输策略，降低当前直播间的直播音视频流产生的时延，具体过程请继续参阅如下步骤。

为了更好地理解本申请，可以参照图3，图3为本申请实施例提供的场景示意图。在当前直播间正在播放的音视频数据存在时延问题时，用户可以通过点击“低延时”的触发组件3001，在触发该“低延时”的触发组件3001后，将当前直播间的直播音视频流切换为低延时的直播音视频流。

在步骤S102中，响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯。

本申请实施例中所涉及到的响应于，用于表示所执行的操作所依赖的条件或者状态，当满足所依赖的条件或状态时，所执行的一个或多个操作可以是实时的，也可以具有设定的延迟；在没有特别说明的情况下，所执行的多个操作不存在执行先后顺序的限制。

需要说明的是，在该第一终端中包含第一实时通讯接口，第一终端通过第一实时通讯接口实现与服务器的音视频流数据传输。其中，第一实时通讯接口可以是RTC的下行模块，该RTC下行模块采用UDP(User Datagram Protocol，用户数据报协议)实现音视频流的数据传输。

在相关技术中，观众客户端拉取直播音视频流一般是采用RTMP(Real TimeMessaging Protocol，实时传输协议)从公网上的CDN(Content Delivery Network，内容分发网络)拉取直播音视频流进行播放。上述直播音视频流实现数据传输的实时传输协议还可以是HTTP-FLV(HTTP-FLash Video，直播协议)和HLS(HTTP Live Streaming，流媒体协议)等。在上述协议在数据传输过程中，均基于TCP(Transmission Control Protocol，传输控制协议)实现数据传输。具体地，通过传输控制协议从内容分发网络的共网上拉取直播音视频流，一方面，在公网上进行数据传输难以减少时延；另一方面，端对端的数据传输方式加大数据传输两端的负载和算法压力，导致观众端音视频拉流的过程出现严重的时延，影响观众进行直播观看的体验效果。

为了解决上述问题，本申请实施例通过在观众客户端与服务器之间的传输网络中加入RTC的下行模块，需要说明的是，RTC的下行模块采用UDP实现音视频流的数据传输，该用户数据协议报是一种无需建立连接就可以发送封装的IP数据包的数据传输方法，是一种无连接的传输层协议。通过RTC的下行模块的用户数据报协议进行直播音视频流数据的下行传输时，通过在RTC的下行模块载入数据传输算法，实现音视频流数据端对端的传输，因此，观众客户端只需要通过RTC的下行模块从服务器拉取直播音视频流，提升了音视频流拉取的效率，减小了音视频流数据传输过程中下行模块的时延，优化了观众端进行直播观看的用户体验。

在一些实施方式中，调用所述第一实时通讯接口订阅对应的目标音视频流，包括：

(1)基于所述第一实时通讯接口，对所述低延时播放指令进行解析，得到待拉取的音视频流信息，所述视频流信息包括目标传输头和传输地址；

(2)将所述音视频流信息相应的目标传输头发送至所述媒体服务器，订阅与所述传输地址对应的目标音视频流。

需要说明的是，在响应于观众客户端的直播界面中的低延时播放指令时，通过观众客户端的第一实时通讯接口(RTC下行模块)对低延时播放指令进行解析，得到待拉取的音视频流的音视频流信息，其中，音视频流信息包括音视频流的传输地址和目标传输头。该目标传输头是基于第一实时通讯接口采用UDP进行传输预设的传输头，比如yits，该目标传输头用于保障在第一终端和媒体服务器基于用户数据报传输协议进行音视频流数据传输过程中的数据稳定性和安全性。相应地，通过第一实时通讯接口对该低延时播放指令进行数据解析后，可以得到相对应的由目标传输头和音视频流的传输地址构成相应的低延时播放指令，该低延时播放指令可以是统一资源定位符(Universal Resource Locator，URL)。具体地，该低延时播放指令可以包括：单人直播场景中对应的低延时播放指令以及多人连麦直播场景下对应的低延时播放指令。

以此，在接收到与当前应用场景相对应的低延时播放指令后，将该低延时播放指令发送至媒体服务器，从该媒体服务器拉取与低延时播放指令中对应的音视频流，返回至观众客户端的播放器进行播放。具体地，当低延时播放指令对应的音视频流为单人直播场景下的直播音视频流时，则将该音视频流作为目标音视频流从媒体服务器发送至第一终端(观众客户端)进行播放。当低延时播放指令对应的音视频流为多人连麦互动场景下的多个音视频流，则将该多个音视频流发送至混画转码服务器，对该多个音视频流进行混画混音转码，得到目标音视频流，并将该目标音视频流通过RTC的下行模块传输至第一终端(观众客户端)播放，具体过程请继续参阅如下步骤。

在一些实施方式中，第一预设传输策略关联第一实时通讯接口，第一预设传输策略包括协议传输策略和网络传输策略，基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放，包括：

(1)通过在所述第一实时通讯接口采用所述用户数据报协议，并根据所述音视频流名称中与所述用户数据报协议对应的传输头传输所述目标音视频流，以确定目标音视频流的协议传输策略；

(2)基于预设的网络优化策略，对传输网络进行调整，确定第一实时通讯接口下行的网络传输策略；

(3)基于所述协议传输策略和网络传输策略，从所述媒体服务器中主动拉取所述目标音视频流，并播放所述目标音视频流。

需要说明的是，本申请实施方式通过第一实时通讯接口对音视频流进行数据传输，第一实时通讯接口(RTC的下行模块)对音视频流数据进行传输的传输方法关联第一预设传输策略，其中，第一预设传输策略可以包括协议传输策略和网络传输策略。

具体地，协议传输策略是指在不同的传输要求下，进行音视频流数据传输的过程中所具体采取的数据传输协议；网络传输策略是指在不同网络情况下，进行音视频流数据传输的过程中根据预设的QoS(Quality of Service，服务质量)策略对网络进行优化所具体采取的网络传输策略，而服务质量策略QoS可以包括网络传输的带宽、数据传送的时延、数据的丢包率。可以理解的是，不同的传输要求可以是音视频流数据的传输格式、传输端口和决策应用层等标准性要求等；不同的网络情况可以是在音视频流传输过程中，各端的网络状况、网络链路参数等传输质量情况等。

在本实施例中，一方面，通过在第一实时通讯接口中采用UDP的数据传输协议实现音视频流的数据传输，确定与第一实时通讯接口相关联的第一预设传输策略进行音视频流数据传输的协议传输策略，在本实施例中，通过应用预设的传输头保障在第一终端和媒体服务器基于用户数据报传输协议进行音视频流数据传输过程中的数据稳定性和安全性，比如，在第一实时通讯接口采用UDP进行传输的过程中使用预设的传输头进行音视频流数据的传输。

另一方面，通过在音视频流的网络传输过程中采用ARQ(AutomaticRetransmission reQuest，自动重传请求)、带宽探测等多种服务质量策略，对在各种复杂网络中的传输网络进行适应性调整，生成传输音视频流的网络传输策略。

在一些实施方式中，基于预设的优化策略，对所述目标音视频流拉取的传输网络进行调整，确定第一实时通讯接口的网络传输策略，具体包括：

1、基于真实宽带探测算法实时监测当前的传输网络的网络质量；

2、采集所述网络质量的网络数据，并对所述网络数据的数据特征进行分析，确定当前的传输网络对应的网络模型；

3、在所述网络模型的网络质量未达到预设标准时，根据预设的拥塞控制算法，对所述网络模型进行调整，确定目标音视频拉取的网络传输策略。

需要说明的是，由于第一实时通讯接口通过RTC的下行模块进行数据传输，而RTC的下行模块采用UDP的数据传输协议，因此，该UDP的数据传输协议在数据传输时会造成数据安全性和可靠性低的问题。

以此，本申请实施例基于预设的优化策略，对用户数据报协议的传输网络进行调整，以确定第一实时通讯接口(RTC的下行模块)在采用用户数据报协议进行数据传输的同时，保证音视频流的数据安全性和数据可靠性。其中，预设的优化策略可以是可靠传输策略，拥塞控制策略和真实宽带探测策略。

具体地，可靠传输策略可以是在针对弱网情况下的自动重传策略，并且，在音视频流传输过程中，对传输网络的网络数据进行采集，对网络数据的数据特征进行分析后，得到当前传输网络对应的网络模型，根据该网络模型对当前传输网络进行调整。拥塞控制策略可以是融合发行端拥塞算法和执行端拥塞算法的拥塞控制策略，例如，在检测到网络环境较差的接收端时，通过在服务器上调度发行端控制的拥塞控制算法，比如拥塞控制算法(Google Congest Control，GCC)和拥塞控制算法(Bottleneck Bandwidth and Round-trip propagation time，BBR)类的发行端控制算法，在服务器运行拥塞算法以实现两端之间的音视频流数据传输，通过在数据传输过程中灵活调用上述拥塞控制算法实现双端的数据传输，减少音视频流传输过程中的时延。真实宽带探测策略基于上述拥塞控制策略，在音视频流的传输网络上增加了真实带宽探测的策略，通过合理地控制发端数据的发送来探测出链路的真实带宽，提升传输网络上网络质量对应数据特征的精确性。

示例性地，通过在接收端写入GCC，使得计算逻辑集中在接收端，以此来减轻发送端的算法压力，在本实施例中，通过将计算逻辑编译依赖至第一终端(观众客户端)，减轻了媒体服务器的计算逻辑压力。进一步地，当网络环境的状况变差时，通过发送端的拥塞控制算发BBR对网络状况差的第一终端进行拥塞算法调整，实现音视频流在各种网络环境下的数据传输，且在一定程度上降低了音视频流数据的传输时延。

在步骤S103中，基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。

需要说明的是，该第一实时通讯接口是RTC的下行模块，观众客户端与服务器进行数据传输可以通过第一实时通讯接口(RTC的下行模块)实现数据传输，因此，观众客户端与服务器(第一实时通讯接口)在进行数据传输时基于用户数据报协议UDP。

需要说明的是，用户数据报协议UDP是一种无连接的传输层协议，基于用户数据报协议进行数据传输时，进行传输的音视频流数据包不包括分组、组装和排序，因此，在通过用户数据报协议进行数据传输时，音视频流的控制选项少，加快各端之间的传输速度，音视频流的拉取延迟小、效率高，时延小。然而，通过用户数据报协议进行数据传输的音视频流不包括可靠性保证、顺序保证和流量控制字段，因此，基于用户数据报协议的第一实时通讯接口(RTC的下行模块)在减少时延时会导致音视频流丢包、乱序和传输可靠性低的问题。

以此，本实施例通过在第一实时通讯接口中加入第一预设传输策略，将第一预设传输策略关联第一实时通讯接口，在RTC的下行模块对音视频流进行数据传输时，对用户数据报协议的传输网络进行优化，以实现在降低音视频流传输时延问题的基础上，保证音视频流的数据稳定性和可靠性。

为了更好地理解本申请，可以参照图4，图4为本申请实施例提供的时序流程示意图。需要说明的是，在本实施例中，播放器与RTC的下行模块是结合起来的，但为了更好地体现RTC的下行模块执行的步骤，将播放器与RTC的下行模块进行分别说明。具体地，通过观众客户端的播放器输入低延时播放指令对应的统一资源定位符(Universal ResourceLocator，URL)，播放器将该统一资源定位符发送给RTC的下行模块，RTC的下行模块对该统一资源定位符进行解析确定待拉取的流名称，根据该流名称向媒体服务器进行目标音视频流的订阅，若流名称是单人直播场景下的请求名称，则直接将流名称对应的音视频流返回至RTC的下行模块；若流名称是多人连麦场景下对应的多音视频流名称，则将流音视频流名称对应的多音视频流发送至混画转码服务器进行混音混画，并将混画混音好的目标音视频流返回至媒体服务器，再从该媒体服务器将该混画混音的目标音视频流发送至RTC的下行模块。RTC的下行模块接收服务器下发的目标音视频流，并将该目标音视频流返回给观众客户端的播放器进行解码渲染并播放。

本实施例通过将第一终端与第一实时通讯接口(观众客户端与RTC的下行模块)结合，减轻了服务器在音视频流数据拉取过程中的负担，解决了服务器在音视频流数据拉取过程中的卡顿问题，降低了直播音视频播放的时延。另外，基于第一实时通讯接口的用户数据报协议对直播音视频流进行数据传输，直播音视频流数据直接在第一终端和服务器进行数据传输，而无需从公网上进行音视频流拉取，减少了直播音视频流进行数据传输的步骤，解决了直播音视频流数据过大造成的音视频流播放延迟大、效率低的问题，降低了直播音视频流的时延。

在一些其他的实施方式中，在所述播放所述目标音视频流之前，所述方法还包括：

根据所述网络传输策略，生成对应存储大小的缓存区域；

在所述缓存区域中预缓存的音视频流缓存数据；

播放所述音视频流缓存数据，直到获取所述预设的播放帧，停止播放所述音视频流缓存数据并播放所述目标音视频流。

需要说明的是，为了应对在直播音视频流传输过程中网络环境的物理波动，通过抖动缓冲技术在RTC的下行模块中设置预设存储大小的缓存区域，用于存放拉取目标音视频流和播放目标音视频流之间的音视频流缓存数据，其中，该音视频流缓存数据可以是直播音视频流中的一些关键帧，比如IDR帧。以此，通过在观众客户端的播放器设置一个固定缓存区，在保证目标音视频流拉取过程中的低时延的情况下，减少了播放目标音视频流的首屏时间。

需要说明的是，IDR帧是指视频的首帧，在本实施例中，不管是主播通过主播客户端上行的视频还是在混画转码服务器中输出的视频，视频的首帧都为IDR帧，在播放器对视频进行解码时，只有当视频的首帧为IDR帧时，播放器才能对视频流进行解码并播放。

在一些其他的实施方式中，所述停止播放所述音视频流缓存数据并播放所述目标音视频流，包括：

基于已播放的音视频流缓存数据，计算对应的回调速度；

根据所述回调速度，对所述音视频流缓存数据进行追帧，以消耗所述音视频流缓存数据并播放所述目标音视频流。

需要说明的是，由于在上述减少目标音视频流播放的首屏时间的方案中，在RTC的下行模块中设置预设存储大小的缓存区域存放音视频流缓存数据，然而该音视频流缓存数据在完成目标音视频流的加载后，服务器会先下发快速接入数据，会导致目标音视频流的播放卡顿，以此，当在播放上述缓存区域中的视频流缓存数据时，基于UDP接收到第一终端进行播放的目标音视频流数据触发对视频流缓存数据的丢帧逻辑，具体地，通过在RTC下行模块控制快播追帧，加快回调给播放器音视频帧的速度，对非关键帧的视频流和时间戳相近的音频流进行删减，其中，删减音视频流的丢帧逻辑的优先集可以是：丢B帧、丢P帧、丢I帧。以此，在考虑到音视频流数据的解码依赖性的前提下，让播放器尽快解码和播放，提高了目标音视频流播放的流畅性将降低了目标音视频流的时延。

在一些其他的实施方式中，在所述播放所述目标音视频流之后，所述方法还包括：

通过网络时间协议，计算目标音视频流中音频和视频对应的播放时延；

当所述网络时间协议出现异常时，在所述目标音视频流中音频和视频对应的播放时延中分别添加对应的抖动缓冲，计算目标音视频流中音频和视频对应的目标播放时延；

根据所述目标音视频流中音频和视频对应的目标播放时延，对所述目标音视频流中的音频和视频进行音画同步。

需要说明的是，在本申请技术方案中为了保证目标音视频流中音频与视频对应的时间戳的稳定性，在RTC的下行模块使用的是终端操作系统的时钟源作为音频与视频进行同步的时间戳。进一步地，在RTC的下行模块基于NTP(Network Time Protocol，网络时间协议)服务，计算目标音视频流中音频和视频对应的播放时延。其中，目标音视频流中音频和视频对应的播放时延是一种绝对的时延。

当网络时间协议的服务出现异常时，通过在上述计算得到的目标音视频流中音频和视频对应的播放时延中分别添加音频或者视频的抖动缓冲，分别确定音频和视频的总延时，根据该音频和视频的总延时进行音视频同步。当上述计算音频和视频的播放延时，对观众客户端的播放器对目标音视频流进行解码、渲染的耗时同时进行考虑，保证了音频和视频的总延时的准确性，并进一步的提升了对目标音视频流进行音画同步的精确度，优化了用户进行波波观看的体验感。

请参阅图5，图5为本发申请实施例提供的音视频拉取方法的另一流程示意图。具体而言，该方法还应用于直播系统的服务器，该服务器通过第二实时通讯接口与第二终端进行数据传输，该音视频拉取方法还包括：

在步骤201中，通过所述第二实时通讯接口的第二预设传输策略，接收第二终端上传的上行音视频流，所述第二实时通讯接口采用用户数据报协议实现通讯。

需要说明的是，第二实时通讯接口可以是RTC的上行模块，服务器通过该RTC的上行模块与第二终端进行数据传输，其中，第二终端可以是主播客户端，用于上行直播间的直播音视频流；第二实时通讯接口通过采用UDP的数据传输协议实现直播音视频流数据传输。

以此，主播客户端通过RTC的上行模块将直播音视频流发送到服务器进行后续操作，而无需将直播音视频流发送到内容分发网络上，提升了音视频流拉取的效率，减轻了数据传输过程中两端的负载，因此，减少了音视频流数据传输过程中上行模块的时延，优化了后续拉取直播音视频流进行观看的用户体验。

在一些实施例中，该第二预设传输策略关联第二实时通讯接口，该第二预设传输策略包括协议传输策略和网络传输策略，通过所述第二实时通讯接口的第二预设传输策略，接收第二终端上传的上行音视频流，所述第二实时通讯接口采用用户数据报协议实现通讯，包括：

(1)通过在所述第二实时通讯接口采用用户数据报协议，并根据与所述用户数据报协议对应的传输头传输所述上行音视频流，以确定上行音视频流的协议传输策略；

(2)基于预设的网络优化策略，对上行音视频流上行的传输网络进行调整，确定第二实时通讯接口的网络传输策略；

(3)基于所述第二通讯接口的协议传输策略和网络传输策略，被动接收所述第二终端的上行音视频流。

需要说明的是，本申请实施方式通过第二实时通讯接口的第二预设传输策略对音视频流进行数据传输，其中，第二实时通讯接口(RTC的下行模块)对音视频流数据进行传输的传输方法关联第二预设传输策略。具体地，第二预设传输策略与第一预设传输策略的原理步骤相同，可以包括协议传输策略和网络传输策略，确定在不同的传输要求下，进行音视频流数据传输的过程中所具体采取的数据传输协议以及确定在不同网络情况下，进行音视频流数据传输的过程中所具体采取的网络传输策略的方式一致，在此不再赘述。

在步骤202中，接收第一终端请求订阅目标音视频流的订阅指令；

所述订阅指令为第一终端调用第一实时通讯接口，订阅待拉取的目标音视频流的操作生成的。

需要说明的是，根据从第一终端接收到请求订阅预设音视频流数据的订阅指令，从媒体服务器拉取到对应的直播音视频流。在确定与订阅指令对应的直播音视频流后，通过第一实时通讯接口实现媒体服务器与第一终端之间的音视频流数据传输。其中，第一实时通讯接口可以是RTC的下行模块，该RTC下行模块采用UDP实现音视频流的数据传输。

可知地，服务器通过第二实时通讯接口，并基于第二预设传输策略将目标音视频流发送给观众客户端，其中，第二实时通讯接口与本申请方案中第一终端中的第一实时通讯接口的工作原理一致，具体参阅本申请说明书在步骤S102和步骤S103中的描述，在此不再赘述。

在步骤203中，响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端。

需要说明的是，随着直播行业的不断发展，连麦互动在直播场景下的应用越来越普遍，在连麦互动的直播场景下，随着互动场景中的参与人数增加，进行处理和数据传输的音视频流增多，导致直播音视频拉的传输过程出现严重的时延问题。

为了解决上述技术问题，服务器通过第二实时通讯接口(RTC的上行模块)接收若干数量的通过主播客户端上行的直播音视频流，再通过第二实时通讯接口将该若干数量的直播音视频流发送给媒体服务器，而媒体服务器在接收到该若干数量的直播音视频流后，将这些待交互的若干数量的直播音视频流在混画转码服务器上进行混画混音的音视频流转码，得到在音视频流的互动场景下的已交互的目标音视频流。

以此，本申请方案通过减少将若干数量的直播音视频流发送至公网上进行数据传输的步骤，直接通过媒体服务器连接混画转码服务器，在混画转码服务器上对若干数量的直播音视频流进行混画转码，输出混画后的视频流，减轻了客户端的计算负担，在多人连麦互动的场景下，观众端观只需要订阅混画和混音后的一路视频流，就可以观看多人主播连麦的画面，提升了多人连麦互动场景下的直播效率和用户体验。

需要说明的是，本申请技术方案在对若干数量的直播音视频流进行混画混音的音视频流转码的过程中，混画转码服务器采用抖动缓存技术将若干数量的直播音视频流混合成一条音视频流。其中，抖动缓存技术用于提高混音混画后的已交互的目标音视频流的流畅性。

在一些实施例中，述响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，将所述目标音视频流返回至所述第一终端，包括：

(1)当所述上行音视频流为单人直播音视频流时，响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端；

(2)当所述上行音视频流为多人直播互动音视频流时，将所述上行音视频流转发至混画转码服务器，以使得所述混画转码服务器对所述上行音视频流进行直播音视频流混合处理，并接收处理后的上行音视频流；

(3)响应于所述订阅指令，从处理后的上行音视频流中确定对应的目标视频流，并将所述目标音视频流返回至所述第一终端。

需要说明的是，当用户进入主播的直播间，媒体服务器从主播客户端接收到的上行音视频为单人直播场景下的直播音视频流时，则响应与用户在该直播间的订阅指令，将对应的音视频流上行至前端媒体服务器，并在上行音视频流中确定对应的目标音视频流，并将该目标音视频流从媒体服务器发送至第一终端(观众客户端)进行播放。

在另一些实施例中，单人直播场景下的直播音视频流也可以上行至媒体服务器，而媒体服务器将该单人直播场景下的直播音视频流输入混画转码服务器，提升直播音视频流的在第一终端播放的画面平滑度。

进一步地，当用户进入主播的直播间，媒体服务器从主播客户端接收到的上行音视频为多人连麦互动场景下对应的多个音视频数据流时，将对应的多个音视频流发送至混画转码服务器，通过该混画转码服务器对该多个音视频流进行混画混音转码，并在混画混音转码对应处理后的上行音视频流中确定对应的目标音视频流，其中，该目标音视频流未下行至第一终端进行播放的直播音视频流。

以上，目标音视频流下行至第一终端进行播放的步骤请参照具体参阅本申请说明书在步骤S102和步骤S103中的描述，在此不再赘述。

为了更好地理解本申请技术方案，请继续参照附图5a，图5a为本实施例提供的多人直播互动的场景示意图。通过在观众客户端点击多人连麦场景下的“低延时”的触发组件5001，第一终端接收到用户的低延时播放指令。基于该低延时指令将各对应的主播客户端的上行音视频上传至媒体服务器，通过RTC上行模块在第二实时通讯接口的第二传输策略从主播客户端将直播音视频流上传至媒体服务器。再多人连麦的互动场景下，该媒体服务器将若干数量的直播音视频流发送到混画转码服务器中进行音视频流混画转码，得到多人连麦互动场景下的目标音视频流，将该多人连麦场景下的目标音视频流返回至媒体服务器，并通过RTC下行模块基于第一实时通讯接口的第一传输策略将该多人连麦场景下的混画音视频流5002下行至第一终端进行播放。

以此，本申请方案针对多人连麦互动场景下的直播音视频流，独立于媒体服务器单独创建混画转码服务器对互动场景中的直播音视频流进行混画混音，减轻了媒体服务器的算法压力和负载。另外，本申请实施方案中的混画转码服务器采用抖动缓存技术对直播音视频流进行混合，提升了多人连麦互动场景下的直播间播放画面的平滑度，提升了连麦和非连麦直播间的兼容性以及多人连麦互动场景下的直播间切换的流畅性。

请参阅图6，图6为本申请实施例提供的音视频拉取装置的结构示意图，该音视频拉取装置应用于第一终端，该第一终端中包含第一实时通讯接口，其中该音视频拉取装置可以包括：第一接收单元301、第一订阅单元302以及拉取单元303等。

第一接收单元301，用于接收低延时播放指令；

第一订阅单元302，用于响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯；

拉取单元303，用于基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。

在一些实施例中，该第一订阅单元302，包括：

解析子单元，基于所述第一实时通讯接口，对所述低延时播放指令进行解析，得到待拉取的音视频流信息，所述视频流信息包括目标传输头和传输地址；

订阅子单元，用于将所述音视频流信息相应的目标传输头发送至所述媒体服务器，订阅与所述传输地址对应的目标音视频流；

传输子单元，用于将所述订阅指令发送至所述媒体服务器，以订阅与所述音视频流名称对应的目标音视频流。

在一些实施例中，该拉取单元303，包括：

协议子单元，用于通过在所述第一实时通讯接口采用所述用户数据报协议，并根据所述音视频流名称中与所述用户数据报协议对应的传输头传输所述目标音视频流，以确定目标音视频流的协议传输策略；

网络子单元，用于基基于预设的网络优化策略，对传输网络进行调整，确定第一实时通讯接口下行的网络传输策略；

执行子单元，用于基于所述协议传输策略和网络传输策略，从所述媒体服务器中主动拉取所述目标音视频流，并播放所述目标音视频流。

在一些实施例中，该网络子单元，还用于：

基于真实宽带探测算法实时监测当前的传输网络的网络质量；

采集所述网络质量的网络数据，并对所述网络数据的数据特征进行分析，确定当前的传输网络对应的网络模型；

在所述网络模型的网络质量未达到预设标准时，根据预设的发送端控制算法，对所述网络模型进行调整，确定目标音视频拉取的网络传输策略。

在一些实施例中，该音视频拉取装置，还用于：

根据所述网络传输策略，生成对应存储大小的缓存区域；

在所述缓存区域中预缓存的音视频流缓存数据；

播放所述音视频流缓存数据，直到获取所述预设的播放帧，停止播放所述音视频流缓存数据并播放所述目标音视频流。

在一些实施例中，该音视频拉取装置，还用于：

基于已播放的音视频流缓存数据，计算对应的回调速度；

根据所述回调速度，对所述音视频流缓存数据进行追帧，以消耗所述音视频流缓存数据并播放所述目标音视频流。

在一些实施例中，该音视频拉取装置，还用于：

通过网络时间协议，计算目标音视频流中音频和视频对应的播放时延；

当所述网络时间协议出现异常时，在所述目标音视频流中音频和视频对应的播放时延中分别添加对应的抖动缓冲，计算目标音视频流中音频和视频对应的目标播放时延；

根据所述目标音视频流中音频和视频对应的目标播放时延，对所述目标音视频流中的音频和视频进行音画同步。

请参阅图7，图7为本申请实施例提供的音视频拉取装置的结构示意图，该音视频拉取装置应用于第一终端，该第一终端中包含第一实时通讯接口，其中该音视频拉取装置可以包括：第二接收单元401、第二订阅单元402以及第二传输单元403等。

一种音视频拉取装置，该音视频装置应用于服务器，该服务器通过第二实时通讯接口与第二终端进行数据传输，该音视频装置包括：

第二接收单元，用于通过所述第二实时通讯接口的第二预设传输策略，接收第二终端上传的上行音视频流，所述第二实时通讯接口采用用户数据报协议实现通讯；

第二订阅单元，用于接收第一终端请求订阅目标音视频流的订阅指令，所述订阅指令为第一终端调用第一实时通讯接口，订阅待拉取的目标音视频流的操作生成的；

第二传输单元，用于响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端。

在一些实施例中，该第二接收单元，用于：

通过在所述第二实时通讯接口采用用户数据报协议，并根据与所述用户数据报协议对应的传输头传输所述上行音视频流，以确定上行音视频流的协议传输策略；

基于预设的网络优化策略，对上行音视频流上行的传输网络进行调整，确定第二实时通讯接口的网络传输策略；

基于所述第二通讯接口的协议传输策略和网络传输策略，被动接收所述第二终端的上行音视频流。

在一些实施例中，该第二传输单元，还用于：

当所述上行音视频流为单人直播音视频流时，响应于所述订阅指令，从所述上行音视频流中确定对应的目标音视频流，并将所述目标音视频流返回至所述第一终端；

当所述上行音视频流为多人直播互动音视频流时，将所述上行音视频流转发至混画转码服务器，以使得所述混画转码服务器对所述上行音视频流进行直播音视频流混合处理，并接收处理后的上行音视频流；

响应于所述订阅指令，从处理后的上行音视频流中确定对应的目标视频流，并将所述目标音视频流返回至所述第一终端。

本申请实施例还提供一种计算机设备，该计算机设备可以为终端，如图8所示，其示出了本发明实施例所涉及的计算机设备的结构示意图，具体来讲：

该计算机设备可以包括一个或者一个以上处理核心的处理器401、一个或一个以上计算机可读存储介质的存储器402、电源403和输入单元404等部件。本领域技术人员可以理解，图5中示出的计算机设备结构并不构成对计算机设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。其中：

处理器401是该计算机设备的控制中心，利用各种接口和线路连接整个计算机设备的各个部分，通过运行或执行存储在存储器402内的软件程序和/或模块，以及调用存储在存储器402内的数据，执行计算机设备的各种功能和处理数据，从而对计算机设备进行整体监控。可选的，处理器401可包括一个或多个处理核心；优选的，处理器401可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器401中。

存储器402可用于存储软件程序以及模块，处理器401通过运行存储在存储器402的软件程序以及模块，从而执行各种功能应用以及数据处理。存储器402可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据计算机设备的使用所创建的数据等。此外，存储器402可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。相应地，存储器402还可以包括存储器控制器，以提供处理器401对存储器402的访问。

计算机设备还包括给各个部件供电的电源403，优选的，电源403可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。电源403还可以包括一个或一个以上的直流或交流电源、再充电系统、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。

该计算机设备还可包括输入单元404，该输入单元404可用于接收输入的数字或字符信息，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。

尽管未示出，计算机设备还可以包括显示单元等，在此不再赘述。具体在本实施例中，计算机设备中的处理器401会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器402中，并由处理器401来运行存储在存储器402中的应用程序，从而实现各种功能，如下：

接收低延时播放指令；

响应于所述低延时播放指令，调用所述第一实时通讯接口订阅对应的目标音视频流，其中，所述第一实时通讯接口采用用户数据报协议实现通讯；

基于所述第一实时通讯接口的第一预设传输策略，从媒体服务器拉取所述目标音视频流播放。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见上文针对音视频拉取方法的详细描述，此处不再赘述。

本领域普通技术人员可以理解，上述实施例的各种方法中的全部或部分步骤可以通过指令来完成，或通过指令控制相关的硬件来完成，该指令可以存储于一计算机可读存储介质中，并由处理器进行加载和执行。

为此，本申请实施例提供一种计算机存储介质，其中存储有多条指令，该指令能够被处理器进行加载，以执行本申请实施例所提供的任一种音视频拉取方法中的步骤。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述实施例提供的各种可选实现方式中提供的方法。

以上各个操作的具体实施可参见前面的实施例，在此不再赘述。

其中，该计算机存储介质可以包括：只读存储器(Read Only Memory，ROM)、随机存取记忆体(Random Access Memory，RAM)、磁盘或光盘等。

由于该计算机存储介质中所存储的指令，可以执行本申请实施例所提供的任一种音视频拉取方法中的步骤，因此，可以实现本申请实施例所提供的任一种音视频拉取方法所能实现的有益效果，详见前面的实施例，在此不再赘述。

以上对本申请实施例所提供的一种音视频拉取方法、装置、存储介质及计算机设备进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。