看网上文章后随手写的, 只做为简单笔记, 还没时间真正研究WebRTC, 说实话一直觉得WebRTC太臃肿, 要不是现在要成为标准那代码除了jitterbuffer、fec、qos和音频信号处理外真心懒得看.
WebRTC流媒体通信基于RTP和RTCP. RTP用于流媒体数据传输,RTCP负责可靠传输、流量控制和拥塞控制等服务质量保证.
WebRTC支持p2p, 其实只是单点对单点, 客户端节点并没有像BT, emule之类被当做中转服务器中转数据.
ice服务包含stun和turn, turn服务器包含stun功能..
stun是用来给客户端做获取NAT ip/port的服务.
客户端a, b都连接stun, stun 获得双方的公网ip/port, 然后给双方发消息告知对方的ip/port, 让双方互相通信从而测试出双方的NAT类型.
a和b如果能通过NAT通信的话也就是打洞成功, 以后的音视频流直接p2p.
如果不能直连, 此时则需要用到turn服务, turn服务提供relay功能, 让双方通过服务器中转进行音视频聊天.
chrome内置支持webrtc, 可以使用js调用webrtc API. 目前的safari好像也支持,不过API可能有点不一样.
现在不知道relay是怎么中转数据的, 是否支持上传者一份数据直接转发给多个连接者(一般turn服务器应该不支持, 需要自己写服务器做处理).
webrtc的优势:
浏览器底层直接支持,可以使用js直接调用, 也就是说浏览器就可以当做客户端, 不过想做的更好的话最好还是自己做原生客户端.
jitterbuffer功能, 音频信号的各种处理优化, 音视频同步, 视频码率动态调整.
多人聊天:
几种方式
- 全部p2p, 客户端互连. 客户端压力大.
- 服务器收所有客户音视频进行混音和视频合并, 服务器cpu压力大, 因为需要解码编码, 而且音视频质量肯定下降, 另外延时变长.
- 服务器中转数据, 客户端只发一路给服务器, 从服务器接收多个流, 类似目前流行的直播, 服务器流量压力大.
从这儿可以看出如果做多人音视频聊天, 诸如N对百人甚至万人的直播, 还是得采用现在流行的直播技术, 比如RTMP 或者像以前公司一样自己做私有协议.
STUN和Relay的优化:
先进行relay, 保证用户第一时间连通提升用户体验, 然后背后进行stun打洞, 当成功打洞后再切换到p2p.
doubango
有人测试说doubango使用了webrtc的音频库,但是效果比webrtc的效果好, 好像没开源所以不知道原因. (这个说法太古老了应该)
h264和vp8
使用h264好像不支持fec，这样在丢包率高网络不稳定的情况下花屏卡顿现象比vp8厉严重。
正常情况下h264的画面质量强于vp8，而且h264在移动端有硬编码的优势。
需要做的事情
- 房间服务器
客户端要先进入房间才可以知道对方，才能发起音视频通讯。
开源apprtc，基于gae python实现，应该只是个demo并不实用。 - 信令服务器
跟楼上房间服务器一起管理控制客户端进行连接。
上面所说的apprtc包含一个collider信令服务器，golang实现。 - turn服务器
coturn用golang写的开源服务器，golang我喜欢，可以直接拿来改改。
coturn是用c写的，其实我还是想找个golang写的，因为go用来写Relay功能更方便。
不过看了一眼coturn的README.MD感觉还是挺强大的，而且这个大概也是使用最广泛的turn开源服务器，先用着不够用了再改，反正c语言简单修改起来方便。
收获
这个简单的学习过程最大的收获是让自己有了新的点子(保密,哈哈).
网友评论