CN107483972B - 一种音视频的直播处理方法、存储介质和一种移动终端 - Google Patents

Abstract

本发明公开了一种音视频的直播处理方法，用于解决现有移动终端浏览器在音视频直播时延时较高的问题。本发明提供的方法包括：移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址；根据播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；向所述流媒体服务器发送目标连接请求；通过所述数据传输链路从所述流媒体服务器上获取第一数据包；对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；通过基于html5的浏览器对所述流媒体数据进行解码播放。本发明还提供存储介质和一种移动终端。

Description

一种音视频的直播处理方法、存储介质和一种移动终端

技术领域

本发明涉及数据传输技术领域，尤其涉及一种音视频的直播处理方法、存储介质和一种移动终端。

背景技术

随着移动终端业务的快速发展，以及高速移动网络的铺设，越来越多的用户通过移动终端来收看音视频的直播。

在移动终端接收音视频直播数据方面，目前在web端的普遍做法为采用RTMP协议或HLS协议作为音视频传输协议与流媒体服务器完成数据传输，利用移动终端的浏览器audio/video标签进行视频播放。但是，RTMP协议不适用于大部分移动终端的浏览器；HLS协议因切片文件机制容易导致延时过长，不适用于互动、直播等对时延要求较高的场景。

因此，寻找一种适用于移动终端上进行低延时的音视频直播的方法成为本领域技术人员亟需解决的问题。

发明内容

本发明实施例提供了一种音视频的直播处理方法、存储介质和一种移动终端，能够减少数据传输的时延，提高音视频直播的实时性。

第一方面，提供了一种音视频的直播处理方法，包括：

移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；

所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；

所述移动终端向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；

所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；

所述移动终端对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；

所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放。

第二方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述的音视频的直播处理方法的步骤。

第三方面，提供了一种移动终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如下步骤：

移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；

所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；

所述移动终端向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；

所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；

所述移动终端对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；

所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放。

从以上技术方案可以看出，本发明实施例具有以下优点：

本发明实施例中，首先，移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；然后，所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；接着，所述移动终端向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；再之，所述移动终端对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；最后，所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放。通过上述步骤，移动终端与流媒体服务器之间通过基于websocket协议的数据传输链路进行流媒体数据的传输，基于websocket协议对移动终端移动终端的高度支持，可持续完成流媒体数据的传输，再加上该移动终端上的浏览器基于html5标准建立，利用html5的新特征，可以减少数据传输的时延，提高音视频直播的实时性。

附图说明

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

图1为本发明实施例中一种音视频的直播处理方法一个实施例流程图；

图2为本发明实施例中一种音视频的直播处理方法中流媒体服务器获取流媒体数据的流程示意图；

图3为本发明实施例中流媒体服务器的原理示意图；

图4为本发明实施例中一种音视频的直播处理方法在一个应用场景下调整缓存空间的流程示意图；

图5为本发明实施例中移动终端、流媒体服务器和中心节点之间的数据传输示意图；

图6为本发明实施例中一种音视频的直播处理方法在一个应用场景下对RTMP流数据的解码播放过程的示意图；

图7为本发明实施例中一种音视频的直播处理装置一个实施例结构图；

图8为本发明一实施例提供的移动终端的示意图。

具体实施方式

本发明实施例提供了一种音视频的直播处理方法、存储介质和一种移动终端，用于解决现有移动终端浏览器在音视频直播时延时较高的问题。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本发明保护的范围。

请参阅图1，本发明实施例中一种音视频的直播处理方法一个实施例包括：

101、移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；

本实施例中，移动终端上的浏览器采用html5标准，从而可以支持移动终端上的浏览器进行多媒体的播放以及其它功能。该移动终端(客户端)通过与流媒体服务器进行数据传输，由流媒体服务器采用websocket协议提供流媒体数据的响应支持，从而移动终端可以持续获取到相应的流媒体数据并进行音视频的直播，减少数据传输的时延的同时提高音视频直播的实时性。

对于上述步骤101，用户可以在移动终端的浏览器展示的页面上，点击某个音频或视频的直播触发事件，例如某个视频直播的链接地址，从而即可在移动终端生成相应的直播链接请求(即上述输入的直播指令)，移动终端可以根据该直播链接请求向业务后台申请对应的websocket协议的播放地址。可以理解的是，该业务后台可以部署在本地服务器上或者远程服务器上，该业务后台预先维护了多路可能用到的websocket协议的播放地址，这些播放地址的地址格式为“ws://+ip地址”，若为安全方式的Websocket协议，则地址格式可以为“wss：//+ip地址”。其中，这些播放地址中的ip地址指向一个流媒体服务器，该流媒体服务器的地址即为该ip地址。

进一步地，为了避免过多的连接请求均集中在一台服务器上，导致服务器压力过大的问题，本实施例中的流媒体服务器可以部署在一个CDN(内容分发网络)网络中，由CDN网络将不同连接请求分发至不同的服务器上，在缓解和优化各个服务器的整体服务压力的同时提高了各个服务器的服务质量。为此，所述播放地址所指向的流媒体服务器通过以下步骤确定：CDN网络的调度中心根据所述移动终端与所述CDN网络上各个节点服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服务器作为所述流媒体服务器。

可以理解的是，一个CDN网络上可以部署有多个节点服务器，这些节点服务器也称为边缘节点(即，CDN网络中离客户端访问最近的服务节点)，由CDN网络的调度中心进行统一的调度管理。当某个移动终端需要与CDN网络上的节点服务器通信时(可以有业务后台告知，或者直接由调度中心担当上述的业务后台)，CDN网络可以根据该移动终端与各个节点服务器之间的网络连接情况，采用就近原则和服务器的负载情况，比如哪个节点服务器与移动终端在网络线路上距离更近、和/或哪个节点服务器当前的服务压力较小等，从而从各个节点服务器中确定出其中一个节点服务器作为给所述移动终端提供服务的流媒体服务器。

102、所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；

在移动终端获取到所述播放地址之后，该移动终端可以根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路。具体地，移动终端可以向流媒体服务器发送接入请求，流媒体服务器可以通过预设在所述流媒体服务器上的websocket服务程序完成与所述移动终端之间的数据传输链路的建立。其中，所述websocket服务程序预先部署在所述CDN网络上，并通过所述CDN网络的内部服务更新渠道以二进制文件形式自动同步到所述各个节点服务器上。可以理解的是，websocket服务程序以二进制文件的形式被执行，可以大大减少websocket服务程序在CDN网络的各个节点服务器上部署扩展的代价和成本，提高服务程序的部署、更新效率。

103、所述移动终端向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；

移动终端在获取到输入的直播指令之后，该移动终端可以向该流媒体服务器发送目标连接请求。其中，该目标连接请求中可以包括连接对象的信息，这里说的连接对象指的是该目标连接请求需要请求连接并获取流媒体数据的对象的地址或者唯一标识，流媒体服务器可以依据连接对象从服务器本地或者网络中寻找到相应的音视频数据。

可以理解的是，这里的连接对象即为上述直播指令所指向的对象，也即用户希望通过移动终端观看音视频直播的内容所对应的某个直播音频、直播视频或者某个网络直播间的地址等等。

需要说明的是，上述步骤101、102和103之间不区分先后执行顺序，且上述步骤101和103可以同时执行。可以理解的是，该移动终端可以直接发送目标连接请求至业务后台，从而业务后台向移动终端反馈播放地址，并且业务后台可以同时将该目标连接请求交给该流媒体服务器，相当于该移动终端间接地发送该目标连接请求至流媒体服务器。对于移动终端来说，其只需执行一个动作即可实现上述的步骤101和103。另一方面，上述步骤102也可以在步骤103之后执行，由上述内容可知，若目标连接请求是由业务后台交给该流媒体服务器的，则该移动终端无需等待步骤102执行完毕，建立好数据传输链路后再发送目标连接请求至流媒体服务器。该流媒体服务器可以在步骤102之前接收到目标连接请求并做好相应的流媒体数据的获取和传输准备。

特别地，在一个应用场景下，若该业务后台就是上述CDN网络的调度中心，则移动终端可以直接发送目标连接请求给调度中心，调度中心为该移动终端分配对应的流媒体服务器，并且将该目标连接请求发送给流媒体服务器。流媒体服务器接收到该目标连接请求之后，与该移动终端建立上述的数据传输链路。

104、所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；

本实施例中，在移动终端向所述流媒体服务器发送目标连接请求之后，流媒体服务器根据该目标连接请求执行下列步骤来获取相应的流媒体数据，如图2所示：

201、流媒体服务器接收来自移动终端的目标连接请求；

202、所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理器，所述目标事件处理器采用websocket协议与所述移动终端进行数据传输；

203、所述流媒体服务器查询是否已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，若是，则执行步骤204，若否，则执行步骤205；

204、所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体数据复用至所述目标事件处理器，以便于所述目标事件处理器将复用得到的流媒体数据发送给所述移动终端；所述第一连接请求是指所述其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接请求；

205、所述流媒体服务器创建一个与所述目标连接请求对应的新的缓冲队列；

206、所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的流媒体数据；

207、所述流媒体服务器将提取得到的流媒体数据通过所述新的缓冲队列分发至所述目标事件处理器，以便于所述目标事件处理器将提取得到的流媒体数据发送给所述移动终端。

对于上述步骤202，在该流媒体服务器中，通过各个事件处理器来分别与各个不同的连接请求进行数据传输。具体地，该流媒体服务器可以预先利用go语言的官方维护的标准包go.net中的websocket包来创建各个Handler，即各个事件处理器。这些事件处理器可以主要针对HTTP请求。其中，该流媒体服务器可以将采用特定规则设置的ws地址(例如ws://…/ws/stream_name,该地址代表一路流，stream_name代表任意流名称)分别绑定这些Handler，一个ws地址绑定一个Handler。

当该流媒体服务器接收到该目标连接请求之后，该目标连接请求可以触发流媒体服务器上的一个空闲的handler，触发的这个handler随即与该目标连接请求建立对应关系，并且该handler作为目标事件处理器采用websocket协议与所述移动终端进行数据传输。

对于步骤203，基于快速获取流媒体数据方面的考虑，若流媒体服务器上已存在某个连接请求的连接对象与该目标连接请求的连接对象相同，则表示该目标连接请求需要获取的流媒体数据已被另一个连接请求提前获取到，而另一个连接请求获取的这些流媒体数据目前正缓存在该流媒体服务器上。因此，该流媒体服务器无需另外再为目标连接请求重新获取相同的流媒体数据，直接将另一个连接请求获取的流媒体数据重复利用，提供给该移动终端即可。反之，若流媒体服务器查询后发现并不存在某个连接请求的连接对象与所述目标连接请求的连接对象相同，则可以执行步骤205。

进一步地，如图3所示，所述流媒体服务器可以预先建立流媒体连接池，所述流媒体连接池用于存储和管理当前各路连接请求的流管理对象，流管理对象记录有与其对应的连接请求的连接对象的信息。其中，上述步骤203可以具体为：所述流媒体服务器查询所述流媒体连接池的各个流管理对象中是否已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同。

若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则在步骤205之前，所述流媒体服务器还可以将所述目标连接请求对应的流管理对象注册进所述流媒体连接池。

参阅图3，该流媒体服务器上的流媒体连接池可以通过go语言的map对象创建，存储当前连接的StreamManager信息，即流管理对象。每个连接请求对应的StreamManager成功建立之后，流媒体连接池可以为该StreamManager分配一个池内连接对象Conn，该池内连接对象Conn用于标识该StreamManager对应的目标连接请求。另外，该StreamManager还可以记录有对应的连接请求的连接对象的信息，这里的连接对象可以根据stream_name进行区分。因此，若流媒体服务器查找到当前流媒体连接池中两个StreamManager记录的stream_name相同，则可以认为这两个StreamManager对应的连接请求具有相同的连接对象，也即代表这两个连接请求之间的流媒体数据可以复用。对于这里所说的复用，由于前一个连接请求通常已建立有对应的缓冲队列，因此后一个连接请求直接可以与前一个连接请求共用一个已有的缓冲队列即可。

反之，若不存在两个连接请求具有相同的连接对象时，表明当前的目标连接请求无法利用一个已有的缓冲队列，因此，需要将该目标连接请求对应的StreamManager注册进所述流媒体连接池，以便于后续建立该目标连接请求对应的缓冲队列。

对于上述步骤204，可以理解的是，当存在可以复用的第一连接请求时，将该第一连接请求对应缓冲队列中的流媒体数据交给目标事件处理器，从而目标事件处理器将这些流媒体数据发送给移动终端，实现了流媒体数据的快速获取；由于采用了数据复用的方式，该流媒体服务器可以更加高效地为该移动终端提供流媒体数据的支持服务。需要说明的是，由于移动终端与流媒体服务器之间采用websocket协议数据传输链路，因此，目标事件处理器在发送这些流媒体数据之前，需要采用websocket协议对这些流媒体数据进行数据封装后得到第一数据包，然后将第一数据包通过数据传输链路发送给所述移动终端。

对于步骤205，可以理解的是，当不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同时，则流媒体服务器需要为该目标连接请求提供一个新的缓冲队列，以便于为该目标连接请求获取流媒体数据。

其中，进一步地，所述流媒体服务器可以预先建立缓冲区，所述缓冲区用于存放各路连接请求对应的缓冲队列。并且，为了提高缓冲区的利用率以及保证流媒体服务器提供流媒体数据服务的质量、效率，所述流媒体服务器可以根据当前的流媒体数据获取速度调整所述缓冲区的大小；其中，当前的流媒体数据获取速度越快，则调整后的所述缓冲区越小；当前的流媒体数据获取速度越慢，则调整后的所述缓冲区越大。

需要说明的是，由于各个连接请求之间存在缓冲队列复用的情况，因此流媒体服务器在创建新的缓冲队列时，可以只为在流媒体连接池中注册的StreamManager创建对应的缓冲队列。可以理解的是，若目标连接请求可以复用其它连接请求的缓冲队列，则该目标连接请求对应的StreamManager无需注册进流媒体连接池；反之，若目标连接请求没有可以复用的其它连接请求的缓冲队列，则该目标连接请求对应的StreamManager注册进该流媒体连接池，因此，流媒体服务器为流媒体连接池中注册的StreamManager创建对应的缓冲队列，也即相当于流媒体服务器为无法采用数据复用方式获取到流媒体数据的连接请求创建对应的缓冲队列。

对于步骤206，可以理解的是，目标连接请求的连接对象的信息可以是某个音视频数据的存储地址或者唯一标识等，流媒体服务器可以根据这个连接对象的信息从服务器本地或者网络中寻找到相应的音视频数据。

特别地，若该连接对象存放于其它节点服务器上，如图3所示，该流媒体服务器可以通过StreamManager获取对应的缓冲队列，然后通过该缓冲队列与连接对象所在的节点服务器建立RTMP连接，从而可以从该节点服务器上取流至缓冲队列中。其中，取流得到的流媒体数据可以以RTMP数据包的格式缓存在流媒体服务器上对应的缓冲队列。

如图3所示，为了便于管理各个缓冲队列与CDN网络中的其它节点服务器或网络中的其它服务器之间的RTMP连接，该流媒体服务器可以预先建立一个RTMP连接池，该RTMP连接池用于管理这些RTM连接。另外，还可以结合RTMP和websocket流服务在程序上统一设计，或者提供共享内存进行跨进程访问，从而可以实现RTMP连接的缓冲数据从节点服务器上现有的RTMP连接池中获取，达到最大限度地复用流媒体服务器上的流媒体数据，对此本实施例不作具体限定。

对于步骤207，需要说明的是，由于移动终端与流媒体服务器之间采用websocket协议数据传输链路，因此，目标事件处理器在发送这些流媒体数据之前，需要采用websocket协议对这些流媒体数据进行数据封装后得到第一数据包，然后将第一数据包通过数据传输链路发送给所述移动终端。

进一步地，在流媒体服务器预先建立有流媒体连接池、缓冲区和/或RTMP连接池的基础上，该流媒体服务器还可以设置有统计数据收集进程Data collector和流媒体监控进程monitor。流媒体服务器可以通过Go预言建立Monitor，并通过RPC(remote procedurecall远程过程调用)机制注册远程过程调用，将连接统计数据(RTMP连接数、各个缓冲队列大小、网络连接情况、客户端请求IP、异常次数、CPU使用率等)作为参数传递给Monitor进行统计，Monitor负责收集参数信息并根据这些参数信息判断是否需要向CDN网络的调度中心发起报警信号；另外，其还可以定时通过CDN内部信令通道(例如：HTTP或TCP连接)，按照CDN内部数据传输协议，提交该流媒体服务器的Websocket流连接状态至调度中心。

当流媒体数据获取不正常或者是某个节点服务器出现访问故障时，Monitor可以按照故障的严重程度及时上报至调度中心。另外，当websocket服务程序崩溃时，该Monitor还可以收集相关的系统信息，并对websocket服务程序尝试进行重启操作，以保证websocket服务程序的高可用性。

可以理解的是，CDN网络的调度中心根据Monitor的反馈信息可以对各个节点服务器当前的服务压力进行及时的调整，从而尽可能地提高CDN网络中各个节点服务器的服务质量，尤其是缓解在特殊时段(比如网络繁忙时段)各个节点服务器的服务压力。

上述步骤201～207主要从流媒体服务器一端描述该流媒体服务器在接收到目标连接请求之后的处理过程，在本实施例中，流媒体服务器的处理步骤并不限于上述步骤201～207，应当理解的是，上述步骤201～207描述的内容不是对本实施例中流媒体服务器的工作步骤作出的限定。

进一步地，为了提高移动终端接收第一数据包的接收能力，保证数据传输链路的传输速率不受接收端(移动终端)的影响，该移动终端可以预先设定一定大小的缓存空间用于缓存接收到的第一数据包。如图4所示，所述音视频的直播处理方法还包括：

401、所述移动终端将获取到的第一数据包缓存在预设的缓存空间中；

402、所述移动终端实时统计当前各个数据传输链路的传输速率和所述缓存空间的状态；

403、所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存空间的大小；其中，当前的传输速率越大，则调整后的所述缓存空间越小；当前的传输速率越小，则调整后的所述缓存空间越大。

对于上述步骤401～403，移动终端还可以对缓冲第一数据包中的各个环节进行状态统计，比如卡顿率、传输速率、抖动等，然后根据状态统计的结果进行丢数据帧或者加速解码、渲染等追赶操作，以动态调整缓存第一数据包的可用缓存空间。

可以理解的是，移动终端在动态调整缓冲空间的大小时，一般来说，若当前的传输速率较大，则表明网络状态较好，此时缓存空间可以适当地调小；反之，若当前的传输速率较小，则表明网络状态较差，此时为了保证直播的实时性，缓存空间应当适度调大。

105、所述移动终端对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；

106、所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放。

对于上述步骤105和106，可以理解的是，第一数据包采用websocket协议进行数据封装，移动终端在获取到第一数据包之后，也需要采用websocket协议对其进行解封装，得到第一数据包中的流媒体数据，这些流媒体数据可以为频数据和/或视频数据。在得到流媒体数据之后，移动终端可以通过基于html5的浏览器对所述流媒体数据进行解码播放。

进一步地，对于上述步骤105和106，这些流媒体数据可以具体为RTMP流数据。所述流媒体服务器为CDN网络的各个节点服务器中的一个节点服务器；所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的流媒体数据具体为：所述流媒体服务器根据所述目标连接请求的连接对象的信息从所述CDN网络的中心节点拉取相应的RTMP流数据。其中，在所述流媒体服务器将所述第一数据包发送给所述移动终端之前，所述流媒体服务器对拉取到的所述RTMP流数据采用websocket协议进行数据封装，得到所述第一数据包，移动终端接收并解封装该第一数据包之后，可以得到第一数据包中的RTMP流数据。因此，所述移动终端需要通过基于html5的浏览器根据RTMP协议对所述RTMP流数据进行解码播放。

如图5所示，该流媒体服务器为CDN网络中的一个边缘节点服务器，获取流媒体数据时，该流媒体服务器先从CDN网络的中心节点拉取相应的流媒体数据，这个拉取的通信过程采用RTMP协议；拉取得到流媒体数据之后，将这些流媒体数据使用websocket协议封装成第一数据包，然后发送第一数据包给移动终端，这个发送的通信过程则采用websocket协议。移动终端(即客户端)获取到这些第一数据包之后，对这些第一数据包进行解包、解码输出，即可实现音视频的直播。

对于上述步骤106，如图6所示，当该流媒体数据为RTMP流数据时，移动终端可以在websocket服务端接收到来自流媒体服务器的第一数据包之后，通过websocket客户端在Websocket的onMessage回调中接收所述第一数据包解包后的RTMP流数据，并放入待解复用队列。然后，移动终端根据RTMP协议的定义，首先接收到音视频元数据帧，移动终端解析出元数据信息，进行相应的音视频解码参数配置。其次接收音视频的普通数据帧，移动终端区分音视频数据类型，解封装后得到媒体编码数据分别放入对应媒体类型的解码队列中。

接着，移动终端启动媒体解码worker线程，每路流均可以根据相应媒体类型建立解码线程。对于视频数据，移动终端可以采用H.264解码库Boardway.js，新建Decoder对象进行配置及解码。而对于音频数据，移动终端则调用AudioContext的decodeAudioData进行解码，将解码后的数据放入输出队列。其中，视频数据通过渲染线程，从输出队列中取出解码后的YUV视频帧，调用WebGL(JavaScript和OpenGL ES 2.0结合的绘图标准)绘制到Canvas上。对于音频数据，移动终端将解码数组通过AudioContext连接到AudioSourceNode进行播放，另外，还需在渲染及播放之前进行音视频同步判断进行反馈调节。

在音视频同步过程中，移动终端可以采用音视频同步策略算法进行音视频数据帧判断，以音频时间为基准，在保证音频数据顺序播放的基础上，根据结果进行判断是否追赶或者丢弃某些解码后的视频帧，从而确保了音频和视频在时间上的同步输出。

另外，移动终端通过浏览器输出这些音视频时，还可以实现多画面和混音控制。其中，多画面控制可通过两种方式实现，一种为创建一个单独的canvas，多路流的画面根据viewport来限定绘制范围；另一种则分别创建canvas，便于单独控制显示位置，在建立canvas之后获取WebGL的上下文，设置渲染纹理进行画面绘制。在音频方面，移动终端可以通过AudioContext创建多个AudioBufferSource，将对应流的解码数据连接到对应的AudioBufferSource，即可实现混音输出，也便于单独控制某路流的声音参数。

本实施例提供的一种音视频的直播处理方法，与现有的RTMP流媒体技术相比，RTMP流数据在浏览器PC端主要通过Flash播放器来进行解复用及解码，而移动端由于系统平台的原因，没有相应的播放器支持，如需支持RTMP流数据的直接传输则要处理浏览器长连接及兼容性等问题；与现有的HLS流媒体技术相比，其流数据实际为分块切片文件，使用m3u8描述文件更新切片文件链接地址，播放器通过预先下载相应的切片文件实现连续播放的效果，但是由于文件切片的机制容易导致播放的实时性不强，延时通常达到10s以上，极大地影响了音视频直播的实时性。

而在本实施例提供的音视频的直播处理方法基于Websocket协议可实现传输全双工通信，可自定义传输数据格式，传输可提高安全性，同时目前市面上移动终端的主流浏览器均对Websocket协议有较好支持，只需经过一次http请求即可持续进行音视频数据传输，避免同步延迟，实时效果佳。另外，对第一数据包进行解封装后，本方法对视频数据采用H.264解码后再利用Canvas进行绘制，可支持多个画面绘制；对音频数据则可以直接送给AudioContext进行AAC解码播放，可支持多路播放，充分利用了移动终端的硬件加速能力，进一步提高音视频直播的实时性。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

上面主要描述了一种音视频的直播处理方法，下面将对一种音视频的直播处理装置进行详细描述。

图7示出了本发明实施例中一种音视频的直播处理装置一个实施例结构图。

本实施例中，一种音视频的直播处理装置包括：

播放地址获取模块701，用于根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；

传输链路建立模块702，用于根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；

请求发送模块703，用于向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；

数据包获取模块704，用于通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；

数据包解封装模块705，用于对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；

解码播放模块706，用于通过基于html5的浏览器对所述流媒体数据进行解码播放。

进一步地，所述播放地址所指向的流媒体服务器通过以下步骤确定：

CDN网络的调度中心根据所述移动终端与所述CDN网络上各个节点服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服务器作为所述流媒体服务器。

进一步地，在所述请求发送模块向所述流媒体服务器发送目标连接请求之后，所述流媒体服务器执行如下步骤：

流媒体服务器接收来自移动终端的目标连接请求；

所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理器，所述目标事件处理器采用websocket协议与所述移动终端进行数据传输；

所述流媒体服务器查询是否已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同；

若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体数据复用至所述目标事件处理器，以便于所述目标事件处理器将复用得到的流媒体数据发送给所述移动终端；所述第一连接请求是指所述其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接请求；

若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓冲队列，根据所述目标连接请求的连接对象的信息提取相应的流媒体数据，并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述目标事件处理器，以便于所述目标事件处理器将提取得到的流媒体数据发送给所述移动终端。

进一步地，所述流媒体服务器可以为CDN网络的各个节点服务器中的一个节点服务器；

所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的流媒体数据具体可以为：所述流媒体服务器根据所述目标连接请求的连接对象的信息从所述CDN网络的中心节点拉取相应的RTMP流数据；

在所述流媒体服务器将所述第一数据包发送给所述移动终端之前，所述流媒体服务器对拉取到的所述RTMP流数据采用websocket协议进行数据封装，得到所述第一数据包；

所述解码播放模块具体用于：所述移动终端通过基于html5的浏览器根据RTMP协议对所述RTMP流数据进行解码播放。

进一步地，所述音视频的直播处理装置还可以包括：

缓存模块，用于将获取到的第一数据包缓存在预设的缓存空间中；

状态统计模块，用于实时统计当前各个数据传输链路的传输速率和所述缓存空间的状态；

缓存空间调整模块，用于根据所述传输速率和所述缓存空间的状态调整所述缓存空间的大小；其中，当前的传输速率越大，则调整后的所述缓存空间越小；当前的传输速率越小，则调整后的所述缓存空间越大。

图8是本发明一实施例提供的移动终端的示意图。如图8所示，该实施例的移动终端8包括：处理器80、存储器81以及存储在所述存储器81中并可在所述处理器80上运行的计算机程序82，例如执行音视频的直播处理方法的程序。所述处理器80执行所述计算机程序82时实现上述各个音视频的直播处理方法实施例中的步骤，例如图1所示的步骤101至106。或者，所述处理器80执行所述计算机程序82时实现上述各装置实施例中各模块/单元的功能，例如图7所示模块701至706的功能。

示例性的，所述计算机程序82可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器81中，并由所述处理器80执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序82在所述移动终端8中的执行过程。

所述移动终端8可以是手机、平板电脑等计算设备。所述移动终端可包括，但不仅限于，处理器80、存储器81。本领域技术人员可以理解，图8仅仅是移动终端8的示例，并不构成对移动终端8的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述移动终端还可以包括输入输出设备、网络接入设备、总线等。

所述处理器80可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器81可以是所述移动终端8的内部存储单元，例如移动终端8的硬盘或内存。所述存储器81也可以是所述移动终端8的外部存储设备，例如所述移动终端8上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器81还可以既包括所述移动终端8的内部存储单元也包括外部存储设备。所述存储器81用于存储所述计算机程序以及所述移动终端所需的其他程序和数据。所述存储器81还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各实施例的模块、单元和/或方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (8)

1.一种音视频的直播处理方法，其特征在于，包括：

移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；

所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；

所述移动终端向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；

所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；

所述移动终端对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；

所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放；

在所述移动终端向所述流媒体服务器发送目标连接请求之后，还包括：

流媒体服务器接收来自移动终端的目标连接请求；

所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理器，所述目标事件处理器采用websocket协议与所述移动终端进行数据传输；

所述流媒体服务器查询是否已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同；

若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体数据复用至所述目标事件处理器，以便于所述目标事件处理器将复用得到的流媒体数据发送给所述移动终端；所述第一连接请求是指所述其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接请求；

若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓冲队列，根据所述目标连接请求的连接对象的信息提取相应的流媒体数据，并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述目标事件处理器，以便于所述目标事件处理器将提取得到的流媒体数据发送给所述移动终端。

2.根据权利要求1所述的音视频的直播处理方法，其特征在于，所述播放地址所指向的流媒体服务器通过以下步骤确定：

CDN网络的调度中心根据所述移动终端与所述CDN网络上各个节点服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服务器作为所述流媒体服务器。

3.根据权利要求1所述的音视频的直播处理方法，其特征在于，所述流媒体服务器为CDN网络的各个节点服务器中的一个节点服务器；

所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的流媒体数据具体为：所述流媒体服务器根据所述目标连接请求的连接对象的信息从所述CDN网络的中心节点拉取相应的RTMP流数据；

在所述流媒体服务器将所述第一数据包发送给所述移动终端之前，所述流媒体服务器对拉取到的所述RTMP流数据采用websocket协议进行数据封装，得到所述第一数据包；

所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放具体为：所述移动终端通过基于html5的浏览器根据RTMP协议对所述RTMP流数据进行解码播放。

4.根据权利要求1至3中任一项所述的音视频的直播处理方法，其特征在于，所述音视频的直播处理方法还包括：

所述移动终端将获取到的第一数据包缓存在预设的缓存空间中；

所述移动终端实时统计当前各个数据传输链路的传输速率和所述缓存空间的状态；

所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存空间的大小；其中，当前的传输速率越大，则调整后的所述缓存空间越小；当前的传输速率越小，则调整后的所述缓存空间越大。

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

6.一种移动终端，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如下步骤：

移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址，所述播放地址由所述业务后台维护并指向一个流媒体服务器；

所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；

所述移动终端向所述流媒体服务器发送目标连接请求，所述目标连接请求包括连接对象的信息；

所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包；所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据，并采用websocket协议对提取到的流媒体数据进行数据封装得到；

所述移动终端对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；

所述移动终端通过基于html5的浏览器对所述流媒体数据进行解码播放；

在所述移动终端向所述流媒体服务器发送目标连接请求之后，还包括：

流媒体服务器接收来自移动终端的移动终端的目标连接请求；

所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理器，所述目标事件处理器采用websocket协议与所述移动终端的移动终端进行数据传输；

所述流媒体服务器查询是否已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同；

若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体数据复用至所述目标事件处理器，以便于所述目标事件处理器将复用得到的流媒体数据发送给所述移动终端；所述第一连接请求是指所述其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接请求；

若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同，则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓冲队列，根据所述目标连接请求的连接对象的信息提取相应的流媒体数据，并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述目标事件处理器，以便于所述目标事件处理器将提取得到的流媒体数据发送给所述移动终端。

7.根据权利要求6所述的移动终端，其特征在于，所述播放地址所指向的流媒体服务器通过以下步骤确定：

CDN网络的调度中心根据所述移动终端与所述CDN网络上各个节点服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服务器作为所述流媒体服务器。

8.根据权利要求6至7中任一项所述的移动终端，其特征在于，所述处理器执行所述计算机程序时还包括：

所述移动终端将获取到的第一数据包缓存在预设的缓存空间中；

所述移动终端实时统计当前各个数据传输链路的传输速率和所述缓存空间的状态；

所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存空间的大小；其中，当前的传输速率越大，则调整后的所述缓存空间越小；当前的传输速率越小，则调整后的所述缓存空间越大。