改造的janus视频网关

janus视频网关

从选型决定使用janus作为框架来开发视频会议系统已经有一长段时间了，也很想总结一下janus整个框架和videoroom插件。
janus是依webrtc设计的服务端视频网关，所以在协议层支持sdp协议（会话协议描述），pc（点对点传输）等功能，整个框架是使用c语言实现的。
sdp：重要的信息是媒体的编解码信息和传输使用的端口。
pc：peerconnection，依据sdp描述的端口信息，进行打孔，流传输。
为了开发多人视频会议，我们使用了janus的videoroom插件，该插件特点是sfu，一个peer多路流（planb），是个轻量级的网关。

我们的改变

但在实际开发中，尤其未来要商用的话，必须需要对其做一定的修改，我总结了以下几点：

1. 一个peer一路流：目前我们使用的版本videoroom插件支持的是sdp
   planb，也就是一个PeerConnection对应多路媒体流。实际上视频会议都是不固定的，音频，视频，桌面共享都是需要单独进进行处理时尤其是移动端，长时间发布视频，消耗手机的电量， 所以我们决定使用sdp plana，也就是一个PeerConnection对应一路媒体流，这样能够应付复杂的场景。同时会占用更多的机器资源，比如端口

2. 音频混流：janus videoroom插件是sfu机制的，只转发流，没有对流做任何的处理，虽然这样大大降低了业务的复杂度和机器的性能，对大型会议有重要的意义。但在实际会议中，如果出现讨论型会议，大家都打开麦，这样会大大提升下行带宽。所以我们借鉴了audio_bridge插件，将混流引入了视频会议插件中。

3. 桌面共享：在现代视频会议中，互联网的普及，桌面共享已经比不可少了，所以我们将webrtc中的deskcapture引入其中，并采用了simulcast，不同分辨率的多路流，供不同类型的客户端使用，主要是pc端和移动端，同时为了降低下行带宽，我们一个会议，只允许一路桌面共享

4. 负载均衡：相信随着业务量的增大和在运营商的带宽瓶颈，能够最大限度的使用运营商带宽，我们需要将各个发布者的流量均衡的分配在公有云不同的机器上，实现1+1>2的效果

5. 未来我们将实现引流功能，如将小程序发布的rtmp流引入到janus，同时将janus发布的流转发至rtmp服务器

6. 混屏，如果视频会议与直播行业相连，我们会进行考虑，待续。

后续

后续我希望将服务器流的负载均衡的方案和引流方案与各位分享和交流