看网上文章后随手写的, 只做为简单笔记, 还没时间真正研究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服务器应该不支持, 需要自己写服务器做处理).
浏览器底层直接支持,可以使用js直接调用, 也就是说浏览器就可以当做客户端, 不过想做的更好的话最好还是自己做原生客户端.
jitterbuffer功能, 音频信号的各种处理优化, 音视频同步, 视频码率动态调整.
几种方式
1. 全部p2p, 客户端互连. 客户端压力大.
2. 服务器收所有客户音视频进行混音和视频合并, 服务器cpu压力大, 因为需要解码编码, 而且音视频质量肯定下降, 另外延时变长.
3. 服务器中转数据, 客户端只发一路给服务器, 从服务器接收多个流, 类似目前流行的直播, 服务器流量压力大.
从这儿可以看出如果做多人音视频聊天, 诸如N对百人甚至万人的直播, 还是得采用现在流行的直播技术, 比如RTMP 或者像以前公司一样自己做私有协议.
先进行relay, 保证用户第一时间连通提升用户体验, 然后背后进行stun打洞, 当成功打洞后再切换到p2p.
有人测试说doubango使用了webrtc的音频库,但是效果比webrtc的效果好, 好像没开源所以不知道原因. (这个说法太古老了应该)
使用h264好像不支持fec,这样在丢包率高网络不稳定的情况下花屏卡顿现象比vp8厉严重。
正常情况下h264的画面质量强于vp8,而且h264在移动端有硬编码的优势。
这个简单的学习过程最大的收获是让自己有了新的点子(保密,哈哈).