我所了解的webRTC是怎样的一种技术

通过浏览器对视频进行快速、安全的传输不用借助任何第三方平台应用可以实现吗

根据你的需求&＃xff0c;不止一种方式可以在你的网站里添加WebRTC

WebRTC&＃xff08;Web Real-Time Communication&＃xff09;是一项开源技术用于实现通过浏览器进行实时的多媒体通信。

它通过点对点链接2个或多个终端&＃xff0c;这种传输方式对于媒体流&＃xff08;音频、视频&＃xff09;来说是完美的。这项技术已经被以下浏览器支持&＃xff1a;Google Chrome, Mozilla Firefox and Opera。你不需要安装其他插件&＃xff0c;直接打开浏览器就可以进行通话。Safari和IE不能原生支持&＃xff0c;但可以通过一些特殊插件支持。

实现思路很简单。首先浏览器向WebRTC Server发起一个请求表示该用户想发起一个对话。从服务端获取一个链接后&＃xff0c;浏览器发送这个链接给他的同伴。接受到链接的浏览器会弹出一个窗口向用户申请获取网络摄像头和麦克风的权限。

如果你使用的是HTTPS协议&＃xff0c;浏览器会帮你记住你的接受或拒绝的动作&＃xff0c;如果是HTTP协议&＃xff0c;每次链接浏览器都会发起权限请求。

这个过程对于用户来说很简单。但对于开发者呢&＃xff0c;如何集成WebRTC到你的网站中&＃xff1f;或者你不止想做一个视频聊天&＃xff0c;还想录制摄像头拍摄的内容并存到Amazon S3存储以方便第三方去观看这个录像。这对一些收集商品或服务评论很有帮助。一场谈话当有成员缺席的时候可以录制视频信息&＃xff0c;寻找工作的面试也可以远程进行&＃xff0c;方便地进行网络服务支持等。

众所周知视频有很多文件格式&＃xff0c;大多数格式都有自己独特的优势。我可以选择Flash FLV去录制视频&＃xff0c;举个例子&＃xff0c;但这项技术正在脱离主流。浏览器厂商们都宣布未来不支持Flash技术&＃xff0c;这也是我为什么选择WebRTC的原因。

Flash使用H.264视频编码&＃xff0c;而WebRTC使用VP8。WebRTC标准也支持H.264&＃xff0c;但现在还没有普及实现。VP8是免费的&＃xff08;H.265不是&＃xff09;&＃xff0c;二者视频文件的质量、大小都差不多一样。

最初我选择一个叫做MediaStreamRecorder的Javascript库&＃xff0c;做跨浏览器的音频、视频录制。这个库经常和WebRTC一起使用。

但不幸的是&＃xff0c;使用过程中我碰到了很多技术困难。比如&＃xff0c;每次录制结束后&＃xff0c;浏览器会停止响应&＃xff0c;同时还与很多次的延迟。

我就转而使用了WebRTC Experiments库。它使用了相同的技术&＃xff0c;但是用了比较难的实现方式。录制结束后的延迟浏览表现的还算令人满意。

- 使用这个库的结论 -

优点&＃xff1a;

不需要启动服务器&＃xff0c;所有工作的都由浏览器完成。

非常容易进行录制操作&＃xff0c;仅仅需要几个按钮暂停、开始录制、停止。

没有延迟&＃xff0c;因为所有的都由Kurento&＃xff08;接下来我会详细的介绍它&＃xff09;完成。

不足&＃xff1a;

Google Chrome录制视频、音频是分开的&＃xff0c;这也是为什么结束后会有2个单         独的文件&＃xff0c;音频文件和不包含音频的视频文件。

如果录制时间超过5分钟&＃xff0c;浏览器会假死&＃xff0c;对用户指令无反应。

录制结束后会花费几秒时间去解码和接受数据流。

把视频传到仓库中会花费很长时间&＃xff0c;如果在文件传输过程中用户关闭浏览器标签&＃xff0c;会造成数据丢失。

我需要一个服务器用来保存客户端传过来的视频流。一个选择就是用Kurento媒体服务器&＃xff0c;通过STUN / TURN服务器在Amazon EC2中获得。

前端实现使用Kurento开发库&＃xff08;不用中间件服务器&＃xff09;。Kurento&＃xff08;在世界语中对应英语的stream&＃xff09;开源框架提供的媒体服务器&＃xff0c;是基于任意处理媒体能力的标准。

最后的结论对我来说不可被接受&＃xff0c;但对你来说如果不足之处不是绝对严重的话&＃xff0c;可以使用上面提到的方法。既然初衷是为了寻求最好的结果&＃xff0c;我就开始寻找另外的解决方案。

有的时候只是录制一个文件是不够的。如果你想分割视频流为多个&＃xff0c;举个例子&＃xff0c;你的应用只能保存多个3-5分钟的录制文件。我想如何把一个1小时的视频保存成12个5分钟的视频&＃xff0c;每一个都是以单独文件来保存。我尝试通过多次停止录制然后继续的方式&＃xff0c;中断链接服务器然后重新开始一个新的录制。但是这样Kurento不好用&＃xff0c;因为每次重新链接都会丢失好几秒的数据&＃xff08;链接不是连续的&＃xff09;。

结果&＃xff0c;我决定用一种保持一个链接&＃xff0c;不停止录制的方式。随后把得到的分开的录制文件都传送到Amazon S3。我决定使用node-fluent-ffmpeg这个库。

为了使用这个库&＃xff0c;我搭建了一个服务器&＃xff0c;但又遇到了其他的困难。Kurento以webcam格式保存文件&＃xff0c;这些文件在Google Chrome里播放不正确&＃xff08;FireFox就没有这个问题&＃xff09;&＃xff1a;

视频流播放速度比音频流快。解决这个问题的最好的方式是重新编码成Mp4格式

▼

最后&＃xff0c;所有的问题都解决了。我构建了基于WebRTC技术的所有流程&＃xff0c;根据每一项任务做了适当的调整。当然&＃xff0c;整个解决方案不是100%完美。

- 从中可以发现其两面性 -

优点&＃xff1a;

视频、音频是一个文件&＃xff0c;不是独立的两个文件。

视频是实时录制的&＃xff0c;不存在丢失的情况。采用在客户端进行录制的方式&＃xff0c;你必须在用户离开服务前把录制好的文件上传到存储空间。

不足&＃xff1a;

链接Kurento媒体服务器需要花费较长时间。

阻塞问题。客户端的宽带需要足够大。

这种方案花费更多的资源和时间。必须搭建Kurento媒体服务器&＃xff0c;coturn&＃xff0c;node.js进行视频格式转换&＃xff0c;分割成多个文件并传到S3。

WebRTC是新的技术&＃xff0c;所以有一些安全方面的问题。它在TLS协议的最顶层进行加密。你会发现存在安全漏洞&＃xff0c;但这个不是WebRTC技术的问题&＃xff0c;而是基于的浏览器本身传输所带来的问题。主要的问题是WebRTC很容易泄露真是的IP信息&＃xff0c;不管是用代理、VPN、Tor或者一些有名的插件比如Ghostery。

两台基于WebRTC通信的机器必须向对方发送自己的IP地址&＃xff08;不仅是公有地址&＃xff0c;也要私有地址&＃xff09;。你可以通过一小段Javascript代码即可获取这个地址&＃xff0c;这对个人信息隐私是个很大的问题&＃xff0c;而解决这个问题WebRTC就失去了它的灵活之处。就浏览器支持方面还有很大的提升空间。

正如你所知&＃xff0c;不总是会有童话里那种美好结局。这个技术有它的优点和缺点&＃xff0c;但这不妨碍WebRTC快速的流行起来。到目前为止使用WebRTC的统计数据是令人印象深刻的&＃xff0c;47%的企业已经、或计划在未来的12个月中使用这项技术。90%的企业相信WebRTC具有提高链接中心服务的潜力。超过720个公司在不同领域中使用了WebRTC技术。

我们可以预感WebRTC将影响通信交流的市场。WebRTC可以用到很多地方。举个例子&＃xff0c;设想下一个在线商店的客服中心提供一个在线视频的咨询服务&＃xff0c;你可以在线问你的问题&＃xff0c;得到建议。直接通过浏览器而不用任何其他软件或插件。

这个可以很好提高客户服务质量&＃xff0c;提高了盈利。这就意味着要想成为市场领先者的公司会很快的使用到这些技术&＃xff0c;其他公司也会跟随。

在生活的方方面面中有很多场景&＃xff0c;传统telephone正在被更快捷的web消息替代。打的、叫外卖在网上点击下链接比打个telephone容易得多。这些场景WebRTC都可以应用得上。

WebRTC开始与普通的视频聊天工具&＃xff08;比如Skype&＃xff09;和telephone竞争。也许接下来几年内&＃xff0c;WebRTC会改变我们每天的生活习惯&＃xff0c;谁知道呢&＃xff1f;

作者&＃xff1a;Nikolai Bezruk

Qualium Systems的Javascript开发者。该公司为创业公司、数字广告公司提供web&＃xff0c;mobile的应用。Nikolai是一个Team Leader和软件架构师&＃xff0c;从事web全栈开发。他也培训公司内部职员。

原文路径&＃xff1a;

译文&＃xff1a;点击

原文&＃xff1a;点击