网页端WebRTC推流转换为RTMP/GB28181等其他直播流协议

WebRTC是一个在WEB浏览器端广泛应用的流媒体引擎,通过点对点的方式实现音视频数据的传输,以完成视频会议等功能。但是考虑到WebRTC主要是为有限人数情况下的点对点视频会议服务,在做其他直播应用的时候,或者接入现有流媒体网络的情况下,并不太适合,可以考虑将浏览器端的WebRTC流,转换为RTMP/GB28181等其他流媒体协议。经过一段时间的研究,已经成功实现了这一功能,这里我介绍一下转换原理。

WebRTC工作流程

WebRTC 协议主要由三部分组成:

  • 用户接口 (User Interface):提供了一组 API,使得开发者可以在浏览器和移动应用程序之间进行音视频通信;

  • 网络协议栈 (Network Protocol Stack):负责网络数据的传输和协议处理;

  • 音视频引擎 (Audio/Video Engine):负责音视频数据的处理和编解码。

在建立音视频通信之前,浏览器之间需要通过信令服务器进行一系列交互,以协商会话参数和通信方式。下面是 WebRTC 的信令交互过程:

  • 建立房间(Room):浏览器A和B都需要进入同一个房间,以便进行音视频通信。在进入房间之前,它们需要通过信令服务器进行认证和授权。

  • 交换SessionDescriptionProtocol(SDP):在进入房间之后,浏览器A和B都会生成SDP信息,用于协商音视频通信的参数和格式。它们会将自己的SDP信息通过信令服务器发送给对方。

  • 交换ICECandidate:为了穿透NAT和防火墙,WebRTC使用ICE协议来获取NAT类型和外部IP地址。在SDP协商过程中,浏览器A和B会交换彼此的ICECandidate信息,以便进行NAT穿透。

  • 建立PeerConnection:在完成SDP和ICE协商之后,浏览器A和B就可以建立PeerConnection,开始进行音视频传输。PeerConnection会在浏览器之间建立一条点对点的连接,并且支持多种传输方式,包括UDP、TCP和SCTP等。

当信令交互完成后,WebRTC双方建立起数据通道,就开始传输数据,WebRTC支持多种数据传输方式,包括实时传输协议(Real-time Transport Protocol,RTP)、用户数据报协议(User Datagram Protocol,UDP)、传输控制协议(Transmission Control Protocol,TCP)和数据通道协议 (Data Channel Protocol)等。

其中,RTP 是WebRTC 最常用的音视频传输协议,用于实时传输音视频数据。它基于 UDP 协议,并且提供了一些额外的功能,比如丢包恢复、流量控制和时钟同步等。WebRTC 还可以使用 RTCP 协议来进行质量控制和反馈,包括网络延迟、抖动和丢包等指标。

UDP 协议适合传输实时音视频数据,因为它具有低延迟和高吞吐量的特点。但是 UDP 协议也存在一些问题,比如丢包和乱序等,需要通过额外的机制来解决。WebRTC 使用了一些优化技术,比如前向纠错、重传和重构等,来提高音视频传输的质量和稳定性。

除了传输音视频数据,WebRTC 还支持数据通道协议,用于在浏览器之间传输任意数据。数据通道协议基于 SCTP 协议,并且支持可靠传输和流控制等功能。它可以用于传输文件、消息和游戏数据等,提供了一种全新的浏览器间通信方式。

协议转换方案

WebRTC的优点虽然很多,但是对直播等领域并不具有特别明显的优点,不过有一个最大的好处是可以在浏览器上进行摄像头采集、编码和推送。所以可以利用这一点,通过网页端获取到编码后的摄像头数据,再进一步接入到现有的其他直播协议或者工作流程中。

当了解清楚WebRTC的整个工作流程后,就可以设定协议转换方案:

  1. 首先需要构造一个通信协议,用于和浏览器之间进行信令的通信,并做好数据端口的监听,等待浏览器发送WebRTC报文和数据包。
  2. 浏览器页面调用WebRTC接口的时候,首先按照正常流程,创建RTCPeerConnection,之后创建本地offer,当收到浏览器回调后,提取offer中的sdp信息,上传给服务器
  3. 服务器当接收到浏览器发送的offer后,解析SDP包,然后生成本地SDP数据,在SDP中填写本地RTP端口和RTCP端口等相关媒体信息,返回给浏览器。
  4. 浏览器页面接收到SDP之后,调用WebRTC接口,创建answer,并设置浏览器WebRTC模块,如果SDP正确,那么历览器接下来给就会开始向服务器发送RTP报文,内含音频和视频编码数据,程序对此进行解析和提取,将相关数据,重新进行新协议(RTMP、RTSP、GB28181)等的封装。

遇到的问题和解决办法

  1. 需要注意的是,浏览器在和服务器通信的时候,还会发送STUN报文,需要处理好STUN报文的回包,否则会出现连接中断的问题。
  2. 必须处理RTCP报文,并做正常流程的RTCP交互。
  3. WebRTC编码的H.264数据只会发送一次关键帧,这个如果不做处理直接转换成其他协议的直播流,很可能会导致播放端连接后无法获取到关键帧从而无法解码。这个处理方式就是在需要关键帧的时候,向浏览器发送关键帧重传请求。当然也是通过RTCP发送。

以下是FIR(Full Intra Request)关键帧重传报文的格式。

合作请加WX:hbstream或企鹅:229375788。(转载请注明作者和出处)


posted on 2023-04-06 09:17  haibindev  阅读(438)  评论(0编辑  收藏  举报