一种基于WebRTC的视频流传输方法、装置、存储介质和设备

摘要

本发明公开一种基于WebRTC的视频流传输方法、装置、存储介质和设备，包括：浏览器通过与网页即时通信WebRTC网关之间的第一会话描述协议SDP协商创建所述浏览器和所述流媒体服务器之间的会话，并建立第一流通道；所述浏览器获取视频流的订阅列表，若所述订阅列表指示订阅一条视频流，则所述浏览器通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流；若所述订阅列表指示订阅多条视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道；所述浏览器通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流，如此可以实现浏览器基于WebRTC的多流同时预览。

权利要求

1.一种基于WebRTC的视频流传输方法，其特征在于，该方法应用于流媒体系统，该流媒体系统包括：浏览器、网页即时通信WebRTC网关和流媒体服务器，所述方法包括：所述浏览器初始化操作完成后，通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建所述浏览器和所述流媒体服务器之间的会话，并建立第一流通道；

所述浏览器获取视频流的订阅列表，并通过所述WebRTC网关发送给所述流媒体服务器；

若所述订阅列表指示订阅一条视频流，则所述浏览器通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流；

若所述订阅列表指示订阅多条视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道；

所述浏览器通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流。

2.根据权利要求1所述基于WebRTC的视频流传输方法，其特征在于，所述通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建所述浏览器和所述流媒体服务器之间的会话，并建立第一流通道，包括：

所述浏览器接收所述WebRTC网关发送的第一SDP通知offer消息，所述第一SDP offer消息中携带所述流媒体服务器的连接信息和第一同步信源标识符SSRC；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的，所述第一SSRC由所述WebRTC网关确定；

所述浏览器根据所述第一SDP offer消息生成第一SDP应答answer消息发送给所述WebRTC网关，完成所述第一SDP协商；

所述浏览器根据所述连接信息与所述流媒体服务器之间建立会话，并且所述浏览器调用应用程序接口API创建第一流通道，所述会话建立完成时所述第一流通道创建成功。

3.根据权利要求2所述基于WebRTC的视频流传输方法，其特征在于，所述第一SDP answer消息中携带所述第一SSRC，在完成所述第一SDP协商之后，所述方法还包括：通过所述WebRTC网关将第一SDP协商结果发送给所述流媒体服务器，所述第一SDP协商结果包括所述第一SSRC，以使所述流媒体服务器通过所述第一流通道向所述浏览器发送所述一条视频流时，使用所述第一SSRC作为所述一条视频流的SSRC。

4.根据权利要求1所述基于WebRTC的视频流传输方法，其特征在于，所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道，包括：所述浏览器接收所述WebRTC网关发送的第二SDP offer消息；

所述浏览器根据所述第二SDP offer消息生成第二SDP answer消息发送给所述WebRTC网关，完成所述第二SDP协商；

所述浏览器根据所述第二SDP offer消息调用API创建基于所述会话的第二流通道。

5.根据权利要求1所述基于WebRTC的视频流传输方法，其特征在于，所述浏览器获取到视频流的订阅列表后，所述方法还包括：若所述订阅列表指示订阅多条视频流，则所述浏览器创建与每条视频流对应的播放通道，每条播放通道对应一个第二SSRC；

所述浏览器通过所述网关发送给所述流媒体服务器的订阅列表中包含每条视频流对应的第二SSRC，以使所述流媒体服务器通过所述第二流通道向所述浏览器发送所述多条视频流时，使用对应的第二SSRC作为视频流的SSRC。

6.根据权利要求1所述基于WebRTC的视频流传输方法，其特征在于，所述浏览器再次获取到视频流的订阅列表时，所述方法还包括：若本次订阅的视频流的数量大于上一次订阅的视频流的数量时，所述浏览器通过与所述WebRTC网关之间的第二SDP协商重新创建第二流通道；

若本次订阅的视频流的数量小于等于上一次订阅的视频流的数量时，所述浏览器通过已创建的流通道接收所述流媒体服务器发送的本次订阅的多条视频流，所述已创建的流通道为第一流通道或第二流通道。

7.根据权利要求1所述基于WebRTC的视频流传输方法，其特征在于，所述浏览器的初始化操作，包括：

所述浏览器和所述WebRTC网关之间建立网络套接字Websocket连接；

所述Websocket连接建立完成时，所述浏览器的初始化操作完成。

8.一种基于WebRTC的视频流传输装置，其特征在于，该装置应用于浏览器，该装置包括：

初始化模块，用于执行所述浏览器的初始化操作；

SDP模块，用于在所述初始化操作完成后，通过与WebRTC网关之间的第一SDP协商创建所述浏览器和流媒体服务器之间的会话，并建立第一流通道；

订阅模块，用于获取视频流的订阅列表，并通过所述WebRTC网关发送给所述流媒体服务器；

数据监听模块，用于在所述订阅列表指示订阅一条视频流时，通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流；

所述SDP模块，还用于在所述订阅列表指示订阅多条视频流时，通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道；

所述数据监听模块，还用于通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1‑7任一项所述的基于WebRTC的视频流传输方法。

10.一种电子设备，其特征在于，包括：处理器、用于存储所述处理器可执行指令的存储器；

所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现权利要求1‑7任一项所述的基于WebRTC的视频流传输方法。

说明书

一种基于WebRTC的视频流传输方法、装置、存储介质和设备

技术领域

[0001] 本发明涉及流媒体传输技术，尤其涉及一种基于WebRTC的视频流传输方法、装置、存储介质和设备。

背景技术

[0002] 目前，通过浏览器无插件观看视频的需求越来越多，现有主流的无插件视频播放方法一般采用HLS（HTTP Live Streaming，基于HTTP的自适应码率流媒体传输协议）技术或
WebRTC（Web Real‑Time Communication，网页即时通信）技术。

[0003] 但是，采用HLS技术的视频播放的实时性较差，视频画面延迟较大（约10秒），对于实时预览视频来说是难以接受的。而采用WebRTC的视频播放方案虽然延迟较低，但是对于
同时播放多条视频流并没有给出解决方案。

发明内容

[0004] 本公开提供一种基于WebRTC的视频流的传输方法、装置、存储介质和设备，以至少解决现有技术中存在的以上技术问题。

[0005] 本发明第一方面提供一种基于WebRTC的视频流传输方法，该方法应用于流媒体系统，该流媒体系统包括：浏览器、网页即时通信WebRTC网关和流媒体服务器，所述方法包括：

[0006] 所述浏览器初始化操作完成后，通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建所述浏览器和所述流媒体服务器之间的会话，并建立第一流通道；

[0007] 所述浏览器获取视频流的订阅列表，并通过所述WebRTC网关发送给所述流媒体服务器；

[0008] 若所述订阅列表指示订阅一条视频流，则所述浏览器通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流；

[0009] 若所述订阅列表指示订阅多条视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道；

[0010] 所述浏览器通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流。

[0011] 其中，所述通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建所述浏览器和所述流媒体服务器之间的会话，并建立第一流通道，包括：

[0012] 所述浏览器接收所述WebRTC网关发送的第一SDP通知offer消息，所述第一SDP offer消息中携带所述流媒体服务器的连接信息和第一同步信源标识符SSRC；所述流媒体
服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的，所述第一SSRC由所述
WebRTC网关确定；

[0013] 所述浏览器根据所述第一SDP offer消息生成第一SDP应答answer消息发送给所述WebRTC网关，完成所述第一SDP协商；

[0014] 所述浏览器根据所述连接信息与所述流媒体服务器之间建立会话，并且所述浏览器调用应用程序接口API创建第一流通道，所述会话建立完成时所述第一流通道创建成功。

[0015] 其中，所述第一SDP answer消息中携带所述第一SSRC，在完成所述第一SDP协商之后，所述方法还包括：

[0016] 通过所述WebRTC网关将第一SDP协商结果发送给所述流媒体服务器，所述第一SDP协商结果包括所述第一SSRC，以使所述流媒体服务器通过所述第一流通道向所述浏览器发
送所述一条视频流时，使用所述第一SSRC作为所述一条视频流的SSRC。

[0017] 其中，所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道，包括：

[0018] 所述浏览器接收所述WebRTC网关发送的第二SDP offer消息；

[0019] 所述浏览器根据所述第二SDP offer消息生成第二SDP answer消息发送给所述WebRTC网关，完成所述第二SDP协商；

[0020] 所述浏览器根据所述第二SDP offer消息调用API创建基于所述会话的第二流通道。

[0021] 其中，所述浏览器获取到视频流的订阅列表后，所述方法还包括：

[0022] 若所述订阅列表指示订阅多条视频流，则所述浏览器创建与每条视频流对应的播放通道，每条播放通道对应一个第二SSRC；

[0023] 所述浏览器通过所述网关发送给所述流媒体服务器的订阅列表中包含每条视频流对应的第二SSRC，以使所述流媒体服务器通过所述第二流通道向所述浏览器发送所述多
条视频流时，为每条视频流确定一个对应的第二SSRC，使用第二SSRC作为视频流的SSRC。

[0024] 其中，所述浏览器再次获取到视频流的订阅列表时，所述方法还包括：

[0025] 若本次订阅的视频流的数量大于上一次订阅的视频流的数量时，所述浏览器通过与所述WebRTC网关之间的第二SDP协商重新创建第二流通道；

[0026] 若本次订阅的视频流的数量小于等于上一次订阅的视频流的数量时，所述浏览器通过已创建的流通道接收所述流媒体服务器发送的本次订阅的多条视频流；

[0027] 所述已创建的流通道为第一流通道或第二流通道。

[0028] 其中，所述浏览器的初始化操作，包括：

[0029] 所述浏览器和所述WebRTC网关之间建立网络套接字WebSocket连接；

[0030] 所述WebSocket连接建立完成时，所述浏览器的初始化操作完成。

[0031] 本发明另一方面提供了一种基于WebRTC的视频流传输装置，该装置应用于浏览器，该装置包括：

[0032] 初始化模块，用于执行所述浏览器的初始化操作；

[0033] SDP模块，用于在所述初始化操作完成后，通过与WebRTC网关之间的第一SDP协商创建所述浏览器和流媒体服务器之间的会话，并建立第一流通道；

[0034] 订阅模块，用于获取视频流的订阅列表，并通过所述WebRTC网关发送给所述流媒体服务器；

[0035] 数据监听模块，用于在所述订阅列表指示订阅一条视频流时，通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流；

[0036] 所述SDP模块，还用于在所述订阅列表指示订阅多条视频流时，通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道；

[0037] 所述数据监听模块，还用于通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流。

[0038] 本发明再一方面提供了一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于执行所述的基于WebRTC的视频流传输方法。

[0039] 本发明还一方面提供了一种电子设备，包括：

[0040] 处理器、用于存储所述处理器可执行指令的存储器；

[0041] 所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现所述的基于WebRTC的视频流传输方法。

[0042] 通过一次第一SDP协商创建了浏览器和流媒体服务器之间的会话连接以及第一流通道，若订阅的是单流时，那么直接通过第一流通道传输，节省了SDP协商的时间，降低了流
传输过程中的时延；若订阅的是多流，那么需要通过第二SDP协商创建第二流通道，第二流
通道基于已经创建的会话建立，该会话连接一直维持，省去了每次订阅时浏览器和流媒体
服务器之间会话建立的过程，降低了流传输过程中的时延，同时，基于浏览器和流媒体服务
器之间SSRC的协商机制，可保证浏览器从一条流通道准确识别并接收多条流，实现了多流
同时播放。另外，第一流通道和第二流通道均是在浏览器和流媒体服务器之间创建，无需中
转，进一步降低了视频流传输的时延。

附图说明

[0043] 图1示出了一实施例所示的基于WebRTC的视频流传输方法流程图；

[0044] 图2示出了一实施例所示的基于WebRTC的视频流传输装置示意图；

[0045] 图3示出了一实施例所示的基于WebRTC的视频流传输过程示意图。

具体实施方式

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

[0047] 为了使浏览器基于WebRTC技术支持低延时的多流播放，如图1所示，本公开示例提供了一种基于WebRTC的视频流的传输方法，该方法可应用于流媒体系统，基于WebRTC技术，
该流媒体系统包括：浏览器、WebRTC网关和流媒体服务器，该方法包括：

[0048] 步骤101，浏览器初始化操作完成后，通过与WebRTC网关之间的第一SDP（会话描述协议，Session Description Protocol）协商创建所述浏览器和所述流媒体服务器之间的
会话，并建立第一流通道。

[0049] 首先，浏览器需要进行初始化操作，主要包括：浏览器和WebRTC网关之间建立连接。该连接建立完成时，浏览器的初始化操作完成。在一个示例中，浏览器和WebRTC网关之
间创建的连接为Websocket（网络套接字）连接，基于Websocket连接，WebRTC网关可以主动
向浏览器推送消息，浏览器也可以主动向WebRTC网关发送消息。

[0050] 基于该Websocket连接，浏览器和WebRTC网关进行第一SDP协商。在该示例中，通过第一SDP协商可进行第一流通道的创建，第一流通道的创建可用于一条视频流的传输。

[0051] 第一SDP协商的过程如下：

[0052] 所述浏览器接收所述WebRTC网关发送的第一SDP offer消息，所述第一SDP offer消息中携带所述流媒体服务器的连接信息和第一SSRC（同步信源标识符）；所述流媒体服务
器的连接信息为所述WebRTC网关从所述流媒体服务器获取的，所述第一SSRC由所述WebRTC
网关确定；

[0053] 所述浏览器根据所述第一SDP offer消息生成第一SDP应答answer消息发送给所述WebRTC网关，完成所述第一SDP协商；

[0054] 所述浏览器根据所述连接信息与所述流媒体服务器之间建立会话，并且所述浏览器调用API（应用程序接口，Application Programming Interface）创建第一流通道，所述
会话建立完成时所述第一流通道创建成功。

[0055] 在第一SDP offer消息中：上述流媒体服务器的连接信息包括：内网外IP和内外网端口号，基于此，浏览器可与流媒体服务器建立会话。第一SSRC由WebRTC网关确定后，配置
在第一SDP offer消息中与浏览器进行第一SDP协商。

[0056] 步骤102，所述浏览器获取视频流的订阅列表，并通过所述WebRTC网关发送给所述流媒体服务器。

[0057] 第一流通道创建完成之后，浏览器可随时向流媒体服务器发送视频流的订阅请求，订阅请求中携带订阅列表，可指示出浏览器所需预览的视频流的标识信息，例如，在一
个视频会议中，一共有A、B、C三个参会者，那么视频流的标识信息可为参会者的身份标识A、
B、C；每个参会者具有一个视频会议客户端，那么，视频流的标识信息也可为各个视频会议
客户端的标识。

[0058] 一个订阅列表中可指示多条视频流，在一个视频会议中，一个参会者（视频会议客户端）对应一条视频流，那么，一个参会者（视频会议客户端）为产生一条视频流的视频源。

[0059] 步骤103，若所述订阅列表指示订阅一条视频流，则所述浏览器通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流。

[0060] 在步骤101中，浏览器生成的第一SDP answer消息中携带所述第一SSRC，相应的，在第一SDP协商之后，浏览器可通过WebRTC网关将第一SDP协商结果发送给所述流媒体服务
器，第一SDP协商结果包括所述第一SSRC，如此，流媒体服务器在接收到订阅列表之后，可直
接通过第一流通道向浏览器发送该条视频流，使用该第一SSRC作为该条视频流的SSRC。

[0061] 需要指出的是，在创建了第一路通道后，如果随即订阅了单流，那么可以直接复用创建好的第一流通道，可降低时延，另外，第一流通道在流媒体服务器和浏览器之间直接创
建，没有中转，进一步降低了时延。

[0062] 步骤104，若所述订阅列表指示订阅多条视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道。

[0063] 第二SDP协商的过程包括：

[0064] 所述浏览器接收所述WebRTC网关发送的第二SDP offer消息；

[0065] 所述浏览器根据所述第二SDP offer消息生成第二SDP answer消息发送给所述WebRTC网关，完成所述第二SDP协商；

[0066] 所述浏览器根据所述第二SDP offer消息调用API创建第二流通道。

[0067] 需要指出的是，由于浏览器和流媒体服务器之间的会话已经在第一SDP协商时创建完成，因此，这里调用API创建第二流通道时，该第二流通道就已创建完成。第二流通道创
建完成后，第一流通道随即释放。

[0068] 其中，视频流的描述信息在所述第二SDP offer消息中的描述方式为所述浏览器支持的多流播放方案或单流播放方案指示的描述方式，所述浏览器支持的多视频流播放方
式由所述WebRTC网关根据所述浏览器的描述信息确定。浏览器的描述信息在初始化操作的
Websocket连接的建立过程中WebRTC网关即可获取到。

[0069] 在一个示例中，所述浏览器获取到视频流的订阅列表后：

[0070] 若所述订阅列表指示订阅多条视频流，则所述浏览器创建与每条视频流对应的播放通道，并为每条播放通道分配一个对应的第二SSRC，相应的，所述浏览器通过所述网关发
送给所述流媒体服务器的订阅列表中包含每条视频流对应的第二SSRC，以使所述流媒体服
务器通过所述第二流通道向所述浏览器发送所述多条视频流时，使用对应的第二SSRC作为
视频流的SSRC。

[0071] 步骤105，所述浏览器通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流。

[0072] 第二流通道创建完成后，浏览器可直接通过已经建立好的第二流通道接收流媒体服务器发送的多条视频流。

[0073] 浏览器可解析出每条流的第二SSRC，基于第二SSRC可确定出是哪一条视频流，并将每条流通过对应的播放通道进行播放。

[0074] 该第二流通道在浏览器和流媒体服务器之间直接创建，不需要中转，降低了数据传输的时延，第二SSRC的协商机制可保证浏览器基于一条通道的数据传输准确识别出每条
流，实现了多流同时播放。

[0075] 在一个示例中，第一SSRC和多个第二SSRC中的一个第二SSRC相同。

[0076] 在一个示例中：

[0077] 如果浏览器再次获取到视频流的订阅列表时：

[0078] 若本次订阅的视频流的数量大于上次订阅的视频流的数量时，所述浏览器通过与所述WebRTC网关之间的第二SDP协商重新创建第二流通道；

[0079] 若本次订阅的视频流的数量小于等于上次订阅的视频流的数量时，所述浏览器通过已创建的流通道接收所述流媒体服务器发送的本次订阅的多条视频流。这里，已创建的
流通道为第一流通道或第二流通道，流通道的复用节省了重新SDP协商的过程，降低了时
延。

[0080] 为了实现上述方法，本公开一示例提供了一种基于WebRTC的视频流传输装置，该装置应用于浏览器，该装置包括：

[0081] 初始化模块10，用于执行所述浏览器的初始化操作；

[0082] SDP模块20，用于在所述初始化操作完成后，通过与所述WebRTC网关之间的第一SDP协商创建所述浏览器和所述流媒体服务器之间的会话，并建立第一流通道；

[0083] 订阅模块30，用于获取视频流的订阅列表，并通过所述WebRTC网关发送给所述流媒体服务器；

[0084] 数据监听模块40，用于在所述订阅列表指示订阅一条视频流时，通过所述第一流通道接收所述流媒体服务器发送的所述一条视频流；

[0085] 所述SDP模块20，还用于在所述订阅列表指示订阅多条视频流时，通过与所述WebRTC网关之间的第二SDP协商创建基于所述会话的第二流通道；

[0086] 所述数据监听模块40，还用于通过所述第二流通道接收所述流媒体服务器发送的所述多条视频流。

[0087] 在一个示例中，所述通过与所述WebRTC网关之间的第一SDP协商建立所述会话和第一流通道时：

[0088] SDP模块20，用于接收所述WebRTC网关发送的第一SDP通知offer消息，所述第一SDP offer消息中携带所述流媒体服务器的连接信息和第一SSRC；所述流媒体服务器的连
接信息为所述WebRTC网关从所述流媒体服务器获取的，所述第一SSRC由所述WebRTC网关确
定；

[0089] SDP模块20，还用于根据所述第一SDP offer消息生成第一SDP应答answer消息发送给所述WebRTC网关，完成所述第一SDP协商；

[0090] SDP模块20，还用于根据所述连接信息与所述流媒体服务器之间建立会话，并且调用API创建第一流通道，所述会话建立完成后所述第一流通道创建成功。

[0091] 在一个示例中，所述第一SDP answer消息中携带所述第一SSRC，在所述完成所述第一SDP协商之后：

[0092] SDP模块20，还用于通过所述WebRTC网关将第一SDP协商结果发送给所述流媒体服务器，所述第一SDP协商结果包括所述第一SSRC，以使所述流媒体服务器通过所述第一流通
道向所述浏览器发送所述一条视频流时，使用所述第一SSRC作为所述一条视频流的SSRC。

[0093] 所述通过与所述WebRTC网关之间的第二SDP协商创建第二流通道时：

[0094] SDP模块20，用于接收所述WebRTC网关发送的第二SDP offer消息；还用于根据所述第二SDP offer消息生成第二SDP answer消息发送给所述WebRTC网关，完成所述第二SDP
协商；

[0095] SDP模块20，还用于根据所述第二SDP offer消息，调用所述API创建第二流通道。

[0096] 在一个示例中，浏览器还可包括配置模块（图2中未示出），则

[0097] 获取到视频流的订阅列表后：

[0098] 若所述订阅列表指示订阅多条视频流，则配置模块，用于创建与每条视频流对应的播放通道，并为每条播放通道分配一个对应的第二SSRC；

[0099] 相应的，订阅模块30通过所述网关发送给所述流媒体服务器的订阅列表中包含每条视频流对应的第二SSRC，以使所述流媒体服务器通过所述第二流通道向所述浏览器发送
所述多条视频流时，使用对应的第二SSRC作为视频流的SSRC。

[0100] 在一个示例中，所述订阅模块30再次获取到视频流的订阅列表时，若本次订阅的视频流的数量大于上次订阅的视频流的数量时，所述SDP模块20通过与所述WebRTC网关之
间的第二SDP协商重新创建第二流通道；若本次订阅的视频流的数量小于等于上次订阅的
视频流的数量时，所述数据监听模块40通过已创建的流通道接收所述流媒体服务器发送的
本次订阅的多条视频流。

[0101] 下面通过一个示例详细说明本公开的视频流传输过程，如图3所示，包括：

[0102] 301、用户登录浏览器，浏览器执行初始化操作，首先，浏览器访问web服务器，从web服务器获取到可以预览的视频列表，例如该视频列表中包含了视频会议的全部参会者；
同时，浏览器向网关发送websocket连接请求，用于请求和网关建立websocket连接，该连接
请求是一个http请求。

[0103] 302、调度器接收到websocket连接请求后，根据负载均衡策略为浏览器分配一个网关，然后，调度器将该websocket连接请求发送给该网关，由于使用的Websocket连接是个
长连接，因此浏览器和该网关之间就可以始终保持负载。

[0104] 303、网关接收到websocket连接请求后，直接向浏览器回复websocket连接响应，至此，浏览器和网关之间的websocket连接建立成功。网关还可以从websocket连接请求中
解析出浏览器的描述信息（例如浏览器的版本信息）。

[0105] 至此，浏览器的初始化操作完成。

[0106] 304、网关和浏览器建立连接成功后，网关发送流媒体服务连接请求。

[0107] 305、调度器接收到流媒体服务连接请求后，根据负载均衡策略为浏览器分配一个流媒体服务器，并将该流媒体服务连接请求发送给该流媒体服务器。

[0108] 306、流媒体服务器接收到流媒体服务连接请求后，向网关返回连接成功响应，该响应中携带流媒体服务器的连接信息：包括内网IP、内网端口号，外网IP和外网端口号，其
中，内外网端口号可以是同一个。

[0109] 307、网关接收到流媒体服务器返回的连接成功响应后，发起和浏览器之间的第一SDP协商，以创建第一流通道。

[0110] 首先，网关创建第一SDP offer消息，在该第一SDP offer消息中至少携带了流媒体服务器的连接信息以及第一SSRC，网关将该第一SDP offer消息通过websocket连接发送
给浏览器。第一SSRC由网关确定。

[0111] 308、浏览器接收到第一SDP offer消息后：

[0112] 浏览器生成第一SDP answer消息（携带第一SSRC）发送给网关，完成第一SDP协商。

[0113] 同时，浏览器可调用API创建第一流通道，这里，第一流通道用于传输单条H264视频流，在该第一流通道上传输的单条H264视频流均使用所述第一SSRC。

[0114] 309、第一次SDP协商完成后，网关将第一SDP协商结果通知给流媒体服务器，其中携带了上述第一SSRC，使流媒体服务器在发送单条H264视频流时使用该第一SSRC。

[0115] 310、浏览器从第一SDP offer消息中解析出流媒体服务器的连接信息时，即可发起和流媒体服务器之间的会话建立，如果浏览器和流媒体服务器均处在内网中，则浏览器
能够基于流媒体服务器的内网IP和内网端口号和流媒体服务器之间建立会话连接；如果浏
览器在外网中，则浏览器能够基于流媒体服务器的外网IP和外网端口号和流媒体服务器之
间建立会话连接。

[0116] 该会话创建完成后，第一流通道也随之建立完成。

[0117] 然后，浏览器获取首次的订阅列表，如果首次订阅的是单流，则执行311；如果首次订阅的是多流，则执行315：

[0118] 311、浏览器获取到用户的首次订阅列表后，通过websocket连接发送订阅列表给网关。该订阅列表中指示了一个视频源、即视频会议客户端。

[0119] 312、网关接收到该订阅列表之后，发送给流媒体服务器。流媒体服务器确定本次订阅的是单流，那么流媒体服务器在发送单流时，使用第一SSRC作为该流的SSRC。

[0120] 313、流媒体服务器根据订阅列表，获取视频源的视频流，并向网关发送订阅成功的消息。

[0121] 314、流媒体服务器在向网关发送订阅成功消息的同时，可通过已经创建好的第一流通道发送该条视频流（使用第一SSRC）给浏览器。

[0122] 315、浏览器获取到用户的首次订阅列表后，通过websocket连接发送订阅列表给网关。该订阅列表中指示了多个视频源、即视频会议客户端。

[0123] 浏览器获取到订阅列表之后，为本次订阅的每条视频流创建对应的播放通道，每条播放通道具有一个SSRC、记为第二SSRC。

[0124] 相应的，浏览器发送给网关的订阅列表中除了订阅的视频流的信息，还携带本次订阅的视频流和第二SSRC的映射关系。

[0125] 316、网关接收到该订阅列表之后，发送给流媒体服务器。

[0126] 317、流媒体服务器根据订阅列表，获取视频源的视频流，并向网关发送订阅成功的消息。由于订阅列表中包含视频流和第二SSRC的映射关系，则流媒体服务器根据该映射
关系可确定出每条视频流的SSRC。

[0127] 318、由于订阅列表指示了多条视频流，那么，网关接收到订阅成功的消息后，发起与浏览器的第二SDP协商，重新创建流通道，这里记为第二流通道。需要指出的是，第二流通
道创建成功时，第一流通道关闭。

[0128] 网关生成第二SDP offer消息，发送给浏览器。第二SDP offer消息中携带多条视频流的描述信息，由于订阅过程中即步骤316中流媒体服务器已经通过订阅列表获取了每
条视频流的第二SSRC，因此，此处的视频流的描述信息中携带的是视频流的第二SSRC。

[0129] 第二SDP offer消息中多条视频流的描述方式取决于浏览器支持的多流播放方案，例如planB和Unified Plan，如果浏览器支持planB，则第二SDP offer消息中多条H264
视频流的描述信息采用planB规定的描述方式，如果浏览器支持Unified Plan，则SDP 
offer消息中多条视频流的描述信息采用Unified Plan规定的描述方式。

[0130] 其中，网关在步骤3中已经获取到了浏览器的描述信息，例如，浏览器的版本信息，网关通过版本信息可以确定浏览器支持的多流播放方案，从而网关在构建第二SDP offer
消息时，采用合适的描述方式携带H264视频流的描述信息。

[0131] 319、浏览器接收到第二SDP offer消息后，生成第二SDP answer消息，发送给网关，完成第二SDP协商。

[0132] 同时，浏览器调用API创建第二流通道（创建第一流通道调用的API与创建第二流通道调用的API是同一个API）。

[0133] 由于浏览器和流媒体服务器之间的会话在步骤310时已经创建完成，因此，浏览器调用API创建第二流通道时，该第二流通道即创建完成。第二流通道创建完成时，第一流通
道即被释放。

[0134] 320、第二SDP协商完成之后，网关通知流媒体服务器第二SDP协商成功。

[0135] 321、第二SDP协商成功后，流媒体服务器即可直接通过第二流通道向浏览器发送本次订阅的多条视频流。

[0136] 相应的，浏览器接收到多条视频流时，通过第二SSRC进行区分，并将每条视频流根据第二SSRC发送到对应的播放通道上。

[0137] 需要指出的是，当浏览器再次获取到订阅列表：

[0138] 若本次订阅的视频流数量大于上一次订阅的视频流数量，那么重新执行步骤315‑321：即浏览器获取到订阅列表后，重新为本次订阅的每条视频流创建相应的播放通道，即
建立视频流和第二SSRC的映射关系，并将该映射关系通过网关提供给流媒体服务器。相应
的，网关接收到订阅成功的消息后，重新执行第二SDP协商，协商完成后，通过重新创建的第
二流通道发送本次订阅的视频流。

[0139] 若本次订阅的视频流数量小于等于上一次请求的视频流数量，那么浏览器首先创建本次订阅的视频流和第二SSRC的映射关系，并将该映射关系通过网关提供给流媒体服务
器。网关收到订阅成功的消息后，不发起第二SDP协商，直接复用上一次创建的流通道，这里
有两种情形：上一次创建的流通道如果是第一流通道，那么说明自第一流通道创建完成之
后，截止到本次订阅之前的每次订阅都是单流，本次订阅的还是单流，该条视频流通过第一
流通道进行传输（使用第一SSRC）；如果上一次创建的流通道是第二流通道，那么本次订阅
的视频流数量少于或等于上一次订阅的视频流数量（少于上一次数量的情形也可能为一
条），本次订阅的视频流通过上次订阅创建的第二流通道进行传输（浏览器在建立视频流和
第二SSRC的映射关系时，可将上一次的多个第二SSRC分配给本次订阅的视频流）。

[0140] 在上述的视频流传输过程中，通过一次第一SDP协商创建了浏览器和流媒体服务器之间的会话连接以及第一流通道，若首次订阅的是单流时，那么直接通过第一流通道传
输，节省了SDP协商的时间，降低了流传输过程中的时延；若首次订阅的是多流，那么需要通
过第二SDP协商创建第二流通道，第二流通道基于已经创建的会话建立，该会话连接一直维
持，省去了每次订阅时浏览器和流媒体服务器之间会话建立的过程，降低了流传输过程中
的时延，同时，基于浏览器和流媒体服务器之间SSRC的协商机制，可保证浏览器从一条流通
道准确识别并接收多条流，实现了多流同时播放。另外，第一流通道和第二流通道均是在浏
览器和流媒体服务器之间创建，无需中转，进一步降低了视频流传输的时延。

[0141] 本公开示例还提供一种计算机可读存储介质，所述存储介质存储有计算机程序，所述计算机程序用于上述的基于WebRTC的视频流传输方法。

[0142] 本公开示例还提供一种电子设备，包括：

[0143] 处理器、用于存储所述处理器可执行指令的存储器；

[0144] 所述处理器，用于从所述存储器中读取所述可执行指令，并执行所述指令以实现上述基于WebRTC的视频流传输方法。

[0145] 除了上述方法和系统以外，本申请的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述
“示例性方法”部分中描述的根据本申请各种实施例的方法中的步骤。

[0146] 所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如
Java、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程
序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软
件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备
或服务器上执行。

[0147] 此外，本申请的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书上述“示例性方
法”部分中描述的根据本申请各种实施例的方法中的步骤。

[0148] 所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电
磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的
例子（非穷举的列表）包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储
器（RAM）、只读存储器（ROM）、可擦式可编程只读存储器（EPROM或闪存）、光纤、便携式紧凑盘
只读存储器（CD‑ROM）、光存储器件、磁存储器件、或者上述的任意合适的组合。

[0149] 以上结合具体实施例描述了本申请的基本原理，但是，需要指出的是，在本申请中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本申请的
各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作
用，而非限制，上述细节并不限制本申请为必须采用上述具体的细节来实现。

[0150] 本申请中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到
的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具
有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇
“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使
用的词汇“诸如”指词组“如但不限于”，且可与其互换使用。

[0151] 还需要指出的是，在本申请的装置、设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本申请的等效方案。

[0152] 提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本申请。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义
的一般原理可以应用于其他方面而不脱离本申请的范围。因此，本申请不意图被限制到在
此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

[0153] 为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技
术人员将认识到其某些变型、修改、改变、添加和子组合。