CN112738644B - 一种基于WebRTC的视频流传输方法和装置 - Google Patents

Abstract

本发明公开一种基于WebRTC的视频流传输方法和装置，包括：通过与网页即时通信WebRTC网关之间的第一会话描述协议SDP协商创建数据通道；浏览器获取视频流的订阅信息，若订阅信息指示订阅的视频流中存在编解码标准为H265的视频流，则浏览器通过数据通道接收流媒体服务器发送的编解码标准为H265的视频流；若订阅信息指示订阅的视频流中存在编解码标准为H264的视频流，则浏览器通过与WebRTC网关之间的第二SDP协商创建流通道；浏览器通过流通道接收流媒体服务器发送的编解码标准为H264的视频流，本发明使浏览器能够同时支持H265和H264视频流，同时降低了视频流传输的时延。

Description

一种基于WebRTC的视频流传输方法和装置

技术领域

本发明涉及流媒体传输技术，尤其涉及一种基于WebRTC的视频流传输方法和装置。

背景技术

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

但是，采用HLS技术的视频播放的实时性较差，视频画面延迟较大（约10秒），对于实时预览视频来说是难以接受的。而采用WebRTC的视频播放方案虽然延迟较低，但是不支持播放编解码标准为H265的视频流。

发明内容

本发明提供一种基于WebRTC的视频流的传输方法和装置，以至少解决现有技术中存在的以上技术问题。

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

所述浏览器初始化操作完成后，通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建数据通道；

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

若所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流，则所述浏览器通过所述数据通道接收所述流媒体服务器发送的所述编解码标准为H265的视频流；

若所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建流通道；

所述浏览器通过所述流通道接收所述流媒体服务器发送的所述编解码标准为H264的视频流。

其中，所述浏览器的初始化操作，包括：所述浏览器与所述WebRTC网关之间建立网络套接字WebSocket连接；

所述WebSocket连接建立成功时，所述初始化操作完成。

其中，所述通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建数据通道，包括：

所述浏览器接收所述WebRTC网关发送的第一SDP通知offer消息，所述第一SDPoffer消息中携带所述流媒体服务器的连接信息和数据通道的指示信息；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的；

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

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

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

所述浏览器接收所述WebRTC网关发送的第二SDP offer消息，所述第二SDP offer消息中携带编解码标准为H264的视频流的描述信息和流通道的指示信息；所述编解码标准为H264的视频流的描述信息为所述WebRTC网关从所述流媒体服务器获取的；

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

所述浏览器根据所述流通道的指示信息调用第二API创建流通道。

其中，所述编解码标准为H265的视频流中携带第一有效载荷payload，所述第一payload为特定payload；

所述编解码标准为H264的视频流中携带第二payload，所述第二payload由所述浏览器确定后，通过所述第二SDP 协商通知给所述WebRTC网关，并经由所述WebRTC网关通知给所述流媒体服务器。

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

初始化模块，用于进行初始化操作；

SDP模块，用于与WebRTC网关之间进行第一SDP协商，以创建数据通道；

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

数据监听模块，用于在所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流时，通过所述数据通道接收流媒体服务器发送的所述编解码标准为H265的视频流；

所述SDP模块，还用于在所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流时，与所述WebRTC网关之间进行第二SDP协商，以创建流通道；

所述数据监听模块，还用于通过所述流通道接收所述流媒体服务器发送的所述编解码标准为H264的视频流。

其中，所述进行初始化操作时，所述初始化模块，用于与所述WebRTC网关之间建立WebSocket连接，所述WebSocket连接建立成功时，所述初始化操作完成。

其中，所述与WebRTC网关之间进行第一SDP协商，以创建数据通道时：

所述SDP模块，用于接收所述WebRTC网关发送的第一SDP offer消息，所述第一SDPoffer消息中携带所述流媒体服务器的连接信息和数据通道的指示信息；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的；

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

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

其中，所述与所述WebRTC网关之间进行第二SDP协商，以创建流通道时：

所述SDP模块，用于接收所述WebRTC网关发送的第二SDP offer消息，所述第二SDPoffer消息中携带编解码标准为H264的视频流的描述信息和流通道的指示信息；所述编解码标准为H264的视频流的描述信息为所述WebRTC网关从所述流媒体服务器获取的；

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

所述SDP模块，还用于根据所述流通道的指示信息调用第二API创建流通道。

其中，所述编解码标准为H265的视频流中携带第一payload，所述第一payload为特定payload；

所述编解码标准为H264的视频流中携带第二payload，所述第二payload由所述浏览器确定后，通过所述第二SDP协商通知给所述WebRTC网关，并经由所述WebRTC网关通知给所述流媒体服务器。

在上述过程中，通过一次第一SDP协商为H265视频流创建专门的数据传输通道，使浏览器能够接收H265视频流进行播放；针对每次订阅的H264视频流，通过对应的第二SDP协商过程创建专门的流通道，使浏览器能够接收H264视频流进行播放，基于此，结合浏览器自身支持的多流播放方案，能够实现多流的播放。同时，数据通道和流通道均是基于同一个会话、且在浏览器和流媒体服务器之间创建，流媒体数据直接从流媒体服务器传输到浏览器，流媒体数据传输中转次数少，延迟非常低。

附图说明

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

图2示出了一实施例所示的基于WebRTC的视频流传输系统示意图；

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

图4示出了一实施例所示的基于WebRTC的视频流传输装置示意图。

具体实施方式

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

为了使浏览器同时支持编码标准为H264和H265的视频流的播放，且支持无插件、低时延地播放视频流，如图1所示，本公开示例提供了一种基于WebRTC的视频流传输方法，该方法可应用于一流媒体系统，基于WebRTC技术，该流媒体系统包括：浏览器、WebRTC网关和流媒体服务器，该方法包括：

步骤101，浏览器初始化操作完成后，通过与所述WebRTC网关之间的第一SDP（会话描述协议，Session Description Protocol）协商创建数据通道。

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

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

第一SDP协商的过程如下：

所述浏览器接收所述WebRTC网关发送的第一SDP offer（通知）消息，所述第一SDPoffer消息中携带所述流媒体服务器的连接信息和数据通道的指示信息；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的；

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

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

在第一SDP offer消息中：上述流媒体服务器的连接信息包括：内网外IP和内外网端口号，基于此，浏览器可与流媒体服务器建立会话；数据通道的指示信息可以通过SDPoffer消息中m行的描述来表示，例如m行的描述为Webrtc-datachannel时，表示数据通道，浏览器基于此可调用第一API创建该数据通道。此外，第一SDP offer消息中还可以携带数据通道使用的传输协议，在该示例中采用RTP（实时传输协议，Real-time TransportProtocol）。如此，在数据通道创建完成后，流媒体服务器可按照RTP通过该数据通道传输H265视频流，而浏览器可按照RTP对接收到的H265视频流进行解析。

步骤102，所述浏览器获取视频流的订阅信息，并通过所述WebRTC网关向所述流媒体服务器发送视频流的订阅信息。

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

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

步骤103，若所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流，则所述浏览器通过所述数据通道接收所述流媒体服务器发送的所述编解码标准为H265的视频流。

如果浏览器请求预览的视频流中包含了编解码标准为H265的视频流，那么浏览器可直接通过已经建立好的数据通道接收流媒体服务器发送的编解码标准为H265的视频流。

在一个示例中，数据通道使用RTP（实时传输协议，Real-time TransportProtocol），如此，流媒体服务器可按照RTP通过该数据通道传输H265视频流，而浏览器可按照RTP对接收到的H265视频流进行解析。在另一个示例中，浏览器和流媒体服务器之间可预先约定好H265视频流对应的payload（称为第一payload（有效载荷）），该第一payload为特定payload，例如，第一payload为100，那么流媒体服务器发送的H265视频流中携带的payload为100，相应的，浏览器接收到一个视频流时，解析出payload为100，则浏览器确定该条视频流为H265视频流。

在一个示例中，通过一个订阅请求可请求多条H265的视频流，每条H265视频流具有各自的SSRC（同步信源标识符），则浏览器通过SSRC对多条H265视频流进行区分。

步骤104，若所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建流通道。

如果浏览器请求预览的视频流中包含了编解码标准为H264的视频流，那么浏览器和WebRTC网关之间需要进行第二SDP协商，创建专门用于传输H264视频流的流通道。

第二SDP协商的过程包括：

所述浏览器接收所述WebRTC网关发送的第二SDP offer消息，所述第二SDP offer消息中携带编解码标准为H264的视频流的描述信息和流通道的指示信息；所述编解码标准为H264的视频流的描述信息为所述WebRTC网关从所述流媒体服务器获取的；

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

所述浏览器根据所述流通道的指示信息调用第二API创建流通道。需要指出的是，由于浏览器和流媒体服务器之间的会话已经在第一SDP协商时创建完成，因此，这里调用第二API创建流通道时，该流通道就已创建完成。

在第二SDP offer消息中：上述编解码标准为H264的视频流的描述信息中包括每条H264视频流的SSRC；流通道的指示信息可以通过SDP offer消息中m行的描述来表示，例如m行的描述为video时，表示流通道，浏览器基于此可调用第二API创建该流通道。此外，第二SDP offer消息中还可以携带流通道使用的传输协议，在该示例中采用RTP。如此，在流通道创建完成后，流媒体服务器可按照RTP通过该流通道传输H264视频流，而浏览器可按照RTP对接收到的H264视频流进行解析。

其中，编解码标准为H264的视频流的描述信息在所述第二SDP offer消息中的描述方式为所述浏览器支持的多流播放方案或单流播放方案指示的描述方式，所述浏览器支持的多视频流播放方式由所述WebRTC网关根据所述浏览器的描述信息确定。浏览器的描述信息在步骤101中WebSocket连接的建立过程中WebRTC网关即可获取到。

在一个示例中，流通道使用RTP，如此，流媒体服务器可按照RTP通过该数据通道传输H264视频流，而浏览器可按照RTP对接收到的H264视频流进行解析。在另一个示例中，在第二SDP协商时，浏览器可确定出H264视频流使用的payload（称为第二payload），该第二payload由所述浏览器确定后，通知给所述WebRTC网关，并经由所述WebRTC网关通知给所述流媒体服务器，假设第二payload为96，那么流媒体服务器发送的H264视频流中携带的payload为96，相应的，浏览器接收到一个视频流时，解析出payload为96，则浏览器确定该条视频流为H264视频流。

在一个示例中，通过一个订阅请求可请求多条H264的视频流，每条H264视频流具有各自的SSRC，则浏览器通过SSRC对多条H264视频流进行区分。

步骤105，所述浏览器通过所述流通道接收所述流媒体服务器发送的所述编解码标准为H264的视频流。

流通道创建完成后，浏览器可直接通过已经建立好的流通道接收流媒体服务器发送的编解码标准为H264的视频流。

在一个示例中，通过一个订阅请求可请求多条H264的视频流。

浏览器接收到H264视频流时，可通过自身支持的WebRTC解码模块进行解码，并播放。浏览器接收到H265的视频流时，浏览器可采用自身支持的WASM（Web Assembly，网页汇编代码）解码模块进行解码，然后，通过WebGL（Web Graphics Library，是一种3D绘图协议）和Canvas（Canvas（画布）是在HTML5中新增的标签用于在网页实时生成图像，并且可以操作图像内容）渲染出来，供用户预览。

需要指出的是，在步骤104中，当浏览器再次发起订阅请求时，如果当前的订阅请求中指示存在H264视频流，则浏览器和WebRTC网关之间即可重新进行第二SDP协商，或者，只有在本次订阅请求的H264视频流的数量多于上一次请求的数量时，浏览器和WebRTC网关之间才重新进行第二SDP协商，如果当前的订阅请求中指示不存在H264的视频流，则不会重新进行第二SDP协商。

在上述的示例中，通过一次第一SDP协商为H265视频流创建专门的数据传输通道，使浏览器能够接收H265视频流进行播放；针对每次订阅的H264视频流，通过对应的第二SDP协商过程创建专门的流通道，使浏览器能够接收H264视频流进行播放，在此基础上，结合浏览器自身支持的多流播放方案，能够实现多流的播放。同时，数据通道和流通道均是在浏览器和流媒体服务器之间创建，流媒体数据直接从流媒体服务器传输到浏览器，流媒体数据传输中转次数少，延迟非常低。

为了使本公开的方案更加清楚，如图2所示，本公开的另一个示例提供了一种基于WebRTC的视频流传输系统，包括：浏览器210、WebRTC网关220和流媒体服务器230，基于该系统实现的视频流的传输过程包括：

所述浏览器210，进行初始化操作，包括：所述浏览器210与所述WebRTC网关220建立WebSocket连接；所述WebSocket连接建立成功时，所述初始化操作完成。

所述WebRTC网关220，与所述浏览器210进行第一SDP协商，通过所述第一SDP协商将所述流媒体服务器230的连接信息提供给所述浏览器210，在一个示例中：所述初始化操作完成时，所述WebRTC网关220向所述流媒体服务器230请求所述连接信息；所述WebRTC网关220与所述浏览器210进行第一SDP协商，包括：所述WebRTC网关220向所述浏览器210发送第一SDP offer消息，所述第一SDP offer消息中携带所述连接信息和数据通道指示信息；

所述浏览器210，基于所述连接信息与所述流媒体服务器230之间建立会话，并根据数据通道指示信息创建数据通道：所述浏览器210生成第一SDP answer消息发送给所述WebRTC网关220，完成所述第一SDP协商，同时，所述浏览器210根据所述数据通道指示信息调用第一API以创建所述数据通道，在所述会话建立完成后，所述数据通道即创建完成。

所述浏览器210，通过所述WebRTC网关220向所述流媒体服务器230发送视频流的订阅信息。

所述流媒体服务器230，确定所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流时，通过所述数据通道向所述浏览器210发送所述编解码标准为H265的视频流。

所述流媒体服务器230，确定所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流时，向所述WebRTC网关220通知编解码标准为H264的视频流的描述信息。

所述WebRTC网关220与所述浏览器210进行第二SDP协商，包括：所述WebRTC网关220向所述浏览器210发送第二SDP offer消息，所述第二SDP offer消息中携带编解码标准为H264的视频流的描述信息和流通道指示信息。

其中，所述编解码标准为H264的视频流的描述信息在所述第二SDP offer消息中的描述方式为所述浏览器210支持的多流播放方案或单流播放方案指示的描述方式，所述浏览器210支持的多流播放方案或单流播放方案由所述WebRTC网关220根据所述浏览器210的描述信息确定。

所述浏览器210，生成第二SDP answer消息发送给所述WebRTC网关220，完成所述第二SDP协商，同时，所述浏览器210根据所述流通道指示信息调用第二API，以创建流通道。

所述流媒体服务器230，通过所述流通道向所述浏览器210发送所述编解码标准为H264的视频流。在一个示例中，所述第二SDP协商完成时，所述WebRTC网关220通知所述流媒体服务器230所述流通道建立完成；所述流媒体服务器230通过所述流通道向所述浏览器210发送所述编解码标准为H264的视频流。

在该系统中，还可以包括调度器，该调度器用于在浏览器210请求和WebRTC网关建立连接时，根据负载均衡策略为浏览器分配一个WebRTC网关220，浏览器210与该WebRTC网关220建立连接。调度器还可以用于在WebRTC网关220请求流媒体服务器的连接信息时（即WebRTC网关220代替浏览器请求连接流媒体服务），为浏览器分配一个可以提供流媒体服务的流媒体服务器230。如此，可使本方案适用于集群的场景中，负载均衡的使用提高了系统的整体性能。

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

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

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

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

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

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

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

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

7、网关接收到流媒体服务器返回的连接成功响应后，发起和浏览器之间的第一SDP协商，第一SDP协商用于创建数据通道。

首先，网关生成第一SDP offer消息，网关将该第一SDP offer消息通过WebSocket连接发送给浏览器。其中，第一SDP offer消息至少包括：流媒体服务器的连接信息、数据通道使用的协议为RTP，m行的描述为Webrtc-datachannel。通过该m行的描述Webrtc-datachannel浏览器即可判断出需要建立数据通道。

8、浏览器接收到第一SDP offer消息后，浏览器解析第一SDP offer消息，然后：

浏览器生成第一SDP answer消息，发送给网关，以完成第一SDP协商；

同时，浏览器通过解析第一SDP offer消息，确定m行的描述为Webrtc-datachannel时，浏览器即可判断出需要建立数据通道，那么浏览器可调用专门的用于创建数据通道的第一API（即开启对数据通道的监听），在浏览器和流媒体服务器之间的会话还未建立成功时不能传输数据，虽然开启了监听，实质上数据通道还未成功建立。

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

浏览器和流媒体服务器的会话建立后，浏览器和流媒体服务器之间的数据通道就创建完成了，可以随时通过该数据通道传输H265视频流。

10、浏览器获取到用户的订阅列表后，通过WebSocket连接发送订阅列表给网关；该订阅列表中包括一个或多个视频源（视频会议客户端），假设该订阅列表包括A、B、C三个视频源，每个视频源对应一条视频流。

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

12、流媒体服务器根据订阅列表，获取视频源的视频流，并确定每个视频流的编码标准。

13、对于编码标准为H265的视频流，流媒体服务器直接将H265的视频流通过数据通道发送给浏览器。在传输H265的视频流时，浏览器和流媒体服务器使用事先约定好的特定payload，浏览器根据视频流中的特定payload能够识别出该视频流是H265视频流。其中，通过该数据通道可以发送多条H265的视频流，由于数据通道采用了RTP协议，那么通过数据通道传输到浏览器的视频数据的RTP头中携带了视频流的SSRC，浏览器根据这些SSRC能够区分出多条H265视频流，并分别进行解码。浏览器可使用WASM解码方式对于H265的视频流进行解码并播放，如此实现了无插件播放H265的视频流。

14、对于编码标准为H264的视频流，流媒体服务器将H264的视频流的描述信息通过订阅成功消息发送给网关。需要指出的是，步骤13和14的执行无明确的先后关系，可以同时进行。

15、网关接收到订阅成功消息后，发起与浏览器的第二SDP协商，用于创建流通道，流通道用于传输H264视频流。首先，网关创建SDP offer消息（即上述的第二SDP offer消息），至少包括：编解码标准为H264的视频流的描述信息、m行的描述为video字段。通过video字段浏览器即可判断需要建立流通道。

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

若仅存在一条H264视频流，则第二SDP offer消息中该条H264视频流的描述方式采用planA规定的描述方式。

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

16、浏览器接收到第二SDP offer消息后，生成第二SDP answer消息（携带H264视频流使用的payload），发送给网关完成第二SDP协商；

同时，浏览器解析出m行的描述为vedio字段时，确定需要创建流通道，调用第二API创建流通道。

由于浏览器和流媒体服务器之间的会话在步骤9时已经创建完成，因此，浏览器调用API创建流通道时，该流通道即创建完成。

17、第二SDP协商完成之后，网关将第二SDP协商的结果通知流媒体服务器，至少包括传输H264视频流使用的payload。

18、流媒体服务器接收到流通道创建成功的消息后，即可直接通过流通道向浏览器发送H264的视频流。

在传输H264的视频流时，浏览器和流媒体服务器使用通过第二SDP协商过程协商好的payload，浏览器根据视频流中的payload能够识别出该视频流是H264视频流。

通过该流通道可以发送多条H264的视频流，流通道使用RTP协议，那么通过流通道传输到浏览器的视频数据的RTP头中携带了视频流的SSRC，基于SSRC浏览器可识别出多条H264的视频流，并使用WebRTC解码方式进行解码并播放，实现了无插件播放H264视频流。

需要指出的是，当浏览器再次发起订阅请求时：

如果本次订阅了H265的视频流，则流媒体服务器直接通过已建立的数据通道发送该H265的视频流；

如果本次未订阅H264的视频流，则网关不发起再次第二SDP协商；

如果本次订阅了H264的视频流，则网关即可再次发起第二SDP协商，或者，在确定本次订阅的H264的视频流数量多于上一次订阅的H264的视频流数量时，网关再发起第二SDP协商。

为了实现上述的视频流传输方法，本公开一示例还提供了一种基于WebRTC的视频流传输装置，该装置应用于图2所示的浏览器210中，如图4所示，该装置包括：

初始化模块41，用于进行初始化操作；

SDP模块42，用于与WebRTC网关之间进行第一SDP协商，以创建数据通道；

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

数据监听模块44，用于在所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流时，通过所述数据通道接收流媒体服务器发送的所述编解码标准为H265的视频流；

所述SDP模块42，还用于在所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流时，与所述WebRTC网关之间进行第二SDP协商，以创建流通道；

所述数据监听模块44，还用于通过所述流通道接收所述流媒体服务器发送的所述编解码标准为H264的视频流。

在一个示例中，所述进行初始化操作时，所述初始化模块41，用于与所述WebRTC网关之间建立WebSocket连接，所述WebSocket连接建立成功时，所述初始化操作完成。

在一个示例中，所述与WebRTC网关之间进行第一SDP协商，以创建数据通道时：

所述SDP模块42，用于接收所述WebRTC网关发送的第一SDP offer消息，所述第一SDP offer消息中携带所述流媒体服务器的连接信息和数据通道的指示信息；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的；

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

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

在一个示例中，所述与所述WebRTC网关之间进行第二SDP协商，以创建流通道时：

所述SDP模块42，用于接收所述WebRTC网关发送的第二SDP offer消息，所述第二SDP offer消息中携带编解码标准为H264的视频流的描述信息和流通道的指示信息；所述编解码标准为H264的视频流的描述信息为所述WebRTC网关从所述流媒体服务器获取的；

所述SDP模块42，还用于根据所述第二SDP offer消息生成第二SDP answer消息发送给所述WebRTC网关，完成所述第二SDP协商；

所述SDP模块42，还用于根据所述流通道的指示信息调用第二API创建流通道。

在一个示例中，所述编解码标准为H265的视频流中携带第一payload，所述第一payload为特定payload；

所述编解码标准为H264的视频流中携带第二payload，所述第二payload由所述浏览器确定后，通过所述第二SDP协商通知给所述WebRTC网关，并经由所述WebRTC网关通知给所述流媒体服务器。

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

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

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

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

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

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

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

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

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

Claims (10)

1.一种基于WebRTC的视频流传输方法，其特征在于，该方法应用于一流媒体系统，该流媒体系统包括：浏览器、网页即时通信WebRTC网关和流媒体服务器，该方法包括：

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

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

若所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流，则所述浏览器通过所述数据通道接收所述流媒体服务器发送的所述编解码标准为H265的视频流；

若所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流，则所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建所述浏览器与所述流媒体服务器之间的流通道；

所述浏览器通过所述流通道接收所述流媒体服务器发送的所述编解码标准为H264的视频流。

2.根据权利要求1所述的基于WebRTC的视频流传输方法，其特征在于，

所述浏览器的初始化操作，包括：所述浏览器与所述WebRTC网关之间建立网络套接字WebSocket连接；

所述WebSocket连接建立成功时，所述初始化操作完成。

3.根据权利要求1所述的基于WebRTC的视频流传输方法，其特征在于，所述通过与所述WebRTC网关之间的第一会话描述协议SDP协商创建数据通道，包括：

所述浏览器接收所述WebRTC网关发送的第一SDP通知offer消息，所述第一SDP offer消息中携带所述流媒体服务器的连接信息和数据通道的指示信息；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的；

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

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

4.根据权利要求3所述的基于WebRTC的视频流传输方法，其特征在于，所述浏览器通过与所述WebRTC网关之间的第二SDP协商创建流通道，包括：

所述浏览器接收所述WebRTC网关发送的第二SDP offer消息，所述第二SDP offer消息中携带编解码标准为H264的视频流的描述信息和流通道的指示信息；所述编解码标准为H264的视频流的描述信息为所述WebRTC网关从所述流媒体服务器获取的；

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

所述浏览器根据所述流通道的指示信息调用第二API创建流通道。

5.根据权利要求1所述的基于WebRTC的视频流传输方法，其特征在于，

所述编解码标准为H265的视频流中携带第一有效载荷payload，所述第一payload为特定payload；

所述编解码标准为H264的视频流中携带第二payload，所述第二payload由所述浏览器确定后，通过所述第二SDP 协商通知给所述WebRTC网关，并经由所述WebRTC网关通知给所述流媒体服务器。

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

初始化模块，用于进行初始化操作；

SDP模块，用于与WebRTC网关之间进行第一SDP协商，以创建所述浏览器与所述流媒体服务器之间的数据通道；

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

数据监听模块，用于在所述订阅信息指示订阅的视频流中存在编解码标准为H265的视频流时，通过所述数据通道接收流媒体服务器发送的所述编解码标准为H265的视频流；

所述SDP模块，还用于在所述订阅信息指示订阅的视频流中存在编解码标准为H264的视频流时，与所述WebRTC网关之间进行第二SDP协商，以创建所述浏览器与所述流媒体服务器之间的流通道；

所述数据监听模块，还用于通过所述流通道接收所述流媒体服务器发送的所述编解码标准为H264的视频流。

7.根据权利要求6所述的基于WebRTC的视频流传输装置，其特征在于，所述进行初始化操作时，所述初始化模块，用于与所述WebRTC网关之间建立WebSocket连接，所述WebSocket连接建立成功时，所述初始化操作完成。

8.根据权利要求6所述的基于WebRTC的视频流传输装置，其特征在于，

所述与WebRTC网关之间进行第一SDP协商，以创建数据通道时：

所述SDP模块，用于接收所述WebRTC网关发送的第一SDP offer消息，所述第一SDPoffer消息中携带所述流媒体服务器的连接信息和数据通道的指示信息；所述流媒体服务器的连接信息为所述WebRTC网关从所述流媒体服务器获取的；

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

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

9.根据权利要求8所述的基于WebRTC的视频流传输装置，其特征在于，所述与所述WebRTC网关之间进行第二SDP协商，以创建流通道时：

所述SDP模块，用于接收所述WebRTC网关发送的第二SDP offer消息，所述第二SDPoffer消息中携带编解码标准为H264的视频流的描述信息和流通道的指示信息；所述编解码标准为H264的视频流的描述信息为所述WebRTC网关从所述流媒体服务器获取的；

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

所述SDP模块，还用于根据所述流通道的指示信息调用第二API创建流通道。

10.根据权利要求6所述的基于WebRTC的视频流传输装置，其特征在于，

所述编解码标准为H265的视频流中携带第一payload，所述第一payload为特定payload；

所述编解码标准为H264的视频流中携带第二payload，所述第二payload由所述浏览器确定后，通过所述第二SDP协商通知给所述WebRTC网关，并经由所述WebRTC网关通知给所述流媒体服务器。

Images