实现WebRTC的几个想法 | WebRTC编风网
0

实现WebRTC的几个想法

已有 737 人阅读此文 - - InfoQ - Nikolai Bezruk,译者:张卫滨

不借助第三方应用,快速且安全地在浏览器中传输视频——这有可能实现吗?根据你的需求,有不止一种方式能够将WebRTC添加到你的站点之中。

WebRTC(Web实时通信,Web Real-Time Communication)是一项开源技术,用来在Web浏览器中实现实时直接的多媒体通信功能。它能够在两个或更多的人之间建立端到端的连接,这对于传输媒体(音频和视频流)来说是非常合适的。这项技术已经在如下的浏览器中得到了支持:Google Chrome、Mozilla Firefox和 Opera。对于这些浏览器,我们不需要额外的插件。只需要打开一个Web浏览器页面并开启一个会话就可以了。对于使用Safari和IE的用户来说,没有原生的支持,但是我们可以添加特定的插件。

理念是非常简单的。首先,浏览器发送一个信号到WebRTC服务器,这个服务器是用户希望初始化调用的。在获取到服务器的连接之后,用户将其发送给他的同伴。浏览器弹出的窗口会提示用户访问Web摄像头和麦克风的权限。如果用户使用HTTPS协议的话,浏览器能够记住你所选择的选项(是否授予权限)。如果你使用HTTP协议的话,在每次尝试连接的时候,浏览器都会向你申请权限。

如果你是用户的话,这听起来非常简单。但是,作为开发人员,又该如何呢?在Web站点上如何实现它呢?如果你所需要的不仅仅是视频聊天,还要使用Web摄像头进行记录,并将录制的结果发送到Amazon S3存储中,这样第三方就有可能浏览这个录制结果,那又该怎样实现呢?对于一些场景来说,这种方式是非常棒的,比如收集某些商品和服务的视频回访,当某位讨论成员不在场的时候,为其记录视频信息,为工作的求职者进行面试,Web支持等等。

我们都知道,视频格式有很多种。它们中的大多数在某些方面都具有一定的优势。例如,我可以选择Flash格式(FLV、F4V)来记录视频,但是这项技术在Web中正在逐渐失势。多个浏览器都已经宣布将来不再支持Flash,这也是我选择使用WebRTC的另外一个原因。Flash使用H.264视频编码解码器,而WebRTC使用VP8。WebRTC标准中规定要支持H.264,但是它还没有得到广泛地应用。VP8是免费的(H.264并非如此),视频文件的质量和大小几乎是相同的。

我开始选择使用的是免费的JavaScript库,名为MediaStreamRecorder,它用于跨浏览器的音频/视频记录。这个库通常会与WebRTC实现相关。不过令人遗憾的是,在这个过程中,我遇到了很多技术难题。例如,每次记录完成时,浏览器会停止响应,并且会很多的延迟(lag)。

然后,我尝试使用WebRTC Experiments库。它使用了相同的技术,但是实现不同。记录完成时,它的延迟时间和浏览器行为都是正常的。

使用这个库的结论如下所示:

优点:

·不需要运行服务器,所有的负载都会落到浏览器端。

·录制过程的控制非常容易:只需点击pause键,就能开始新的录制和停止录制。

·没有延迟,因为所有的事情都是在Kurento中完成的(我稍后将会对其进行介绍)。

不足:

·Google Chrome会分别记录视频和音频,这样最终会有两个不同的文件:音频文件以及没有音频的视频文件。

·如果录制时间超过五分钟的话,浏览器会停止响应,用户的命令会被忽略掉。

·在录制停止时,将会耗费几秒钟的时间来解码视频和接收数据。

·它将会耗费一些时间将视频发送到仓库中。如果在文件传输的过程中,用户关闭了浏览器的tab标签,数据将会出现丢失。

我需要一个服务器来接收来自客户端的视频流并对其进行记录。对我来讲,一个较为合适的方案是使用Kurento Media Server,我在Amazon EC2上使用STUN/TURN服务器进行了搭建。我使用Kurento 实现了前端(不需要使用中间服务器)。Kurento(英语中“stream”这个词的世界语名称)是一个开源的框架,它提供了一个媒体服务器,这个服务器基于标准提供了任意媒体的处理功能。

最终,对于我来讲,无法接受这样的结果,但是如果上述的不足对你来讲不那么重要的话,那你可以使用这种方法。因为我的想法是尽可能实现最优的结果,因此我又开始寻找其他的解决方案。

有时候,我们所需要的记录文件并不仅仅只有一个。如果我们基于某些原因,需要将流划分为多个部分,例如应用只能接收三分钟或五分钟的视频记录(以避免出现过载的情况),那该怎么做呢?我思考过如何将一个小时的记录划分为12个五分钟的记录,每一个都保存为一个单独的文件。我尝试的做法是每次都停止录制,断开与服务器的连接并重新开始录制(再次连接到服务器)。使用Kurento无法正常运行,这是因为我每次重新连接服务器的时候,会丢掉几秒钟的记录(连接不是瞬时完成的)。

于是,我决定采用一个连接,使用Web摄像头进行无停止的录制。稍后,我要将记录进行分割并将其发送到Amazon S3上,这个过程中,我决定使用node-fluent-ffmpeg库。为了完成该功能,我搭建了一个新的服务器,但是这里还有一个难题。Kurento会将文件保存为webm格式,在Google Chrome上无法正确地播放(Mozilla Firefox不会有这个问题):视频流播放地比音频流更快。修正这个问题的最佳方式是讲文件重编码为mp4,这样就能解决这个问题了。

15

最终,所有的事情都能正常运行了。我使用WebRTC技术构建了完整的流程,在当前的任务下解决了所有的问题。当然,实现并不是100%完美的,我们同时可以看到它的优势和不足:

优点:

·视频和音频位于同一个文件中,没有将其分为两个单独的文件。

·视频是以实时的模式录制的,不会丢失视频文件。如果在客户端一侧实现录制的话,用户在退出我们的服务之前,必须要等待文件上传到仓库之中。

不足:

·连接到Kurento Media Server需要耗费一些时间。

·网络传输。客户端的带宽要足够快。

·实现起来比较困难,这不仅涉及到资源还涉及到时间。我必须要搭建Kurento Media Server、coturn以及Node.js,其中Node.js会用来将视频转换为另外一种格式,将其拆分为多个部分,并将其发送到S3中。

WebRTC技术是很新的,所以在安全性上会有一些问题。它所使用的加密构建在TLS协议之上。我们会发现安全漏洞,但是这可能并不是WebRTC技术的问题,而是信号传输所使用的浏览器本身的问题。WebRTC的主要问题在于它很容易和快速地暴露真实的用户IP地址,它并没有使用代理、VPN、Tor或流行的插件如Ghostery进行保护。为了使用WebRTC组织视频或音频会话,两台电脑必须发送IP地址给对方(不仅包括公网IP,还包括私有IP)。我们可以在JavaScript中使用简单的脚本来请求地址,在个人数据保护方面,这是一个巨大的问题,这个问题只能通过禁用WebRTC来解决。

这里有很大的提升空间,首先就是浏览器的良好支持。

你也可以看到,这里并没有完美的答案。这项技术有好处也有坏处,有优势也有不足,但是WebRTC正在迅速地流行起来。使用WebRTC的统计数据是令人兴奋的。有47%的商业组织计划在未来的12个月中使用该技术,或者已经使用了该技术。90%的受访者相信WebRTC有潜力提升客服中心的服务水平。超过720家公司正在以某种实行使用WebRTC。

我们可以预期WebRTC将会影响通信市场,有多种方式来使用该项技术。例如,假设在线商店会有一个“客户支持”的链接,我们可以点击这个链接并与客服进行视频聊天、询问问题并得到建议。这都是在浏览器中实现的,不需要额外的应用或插件。这能够在很大程度上提升客户服务的质量,因而有利于增加利润。这意味着致力于成为市场领导者的公司会迅速使用这项技术,其余的公司将会随之跟进。

现实中使用传统电话呼叫的很多领域正在被快速的链接点击或Web通信器的消息所取代。相对于打电话,通过在站点上点击链接,会更加容易地打出租车、订餐等等。这是可以使用WebRTC技术的一个领域。它起初与通用的视频聊天(如Skype)和电话呼叫进行竞争。谁知道呢,也许在未来的几年内,WebRTC将会改变我们的日常习惯。

 

3
相关文章!
  • 1486631713(1) WebRTC视频采集模块和数据流水线建立
    - 阅 1,254

    本文在深入分析WebRTC视频采集、SDP协商和VideoEngine源代码的基础上,重点研究其视频采集模块的实现,视频数据流水线的建立,和视频数据从采集到待编码的流向。

  • 0-1 WebRTC的模块处理机制
    - 阅 1,179

    本文在深入分析WebRTC源代码基础上,学习研究其模块处理机制的实现细节,从另一个角度理解WebRTC的技术原理。

  • 0 Web 前端实时化
    - 阅 693

    实时作为 H5 的核心思想之一,意味着便捷的交互体验、高效的网络传输、快速的交流和更多的机遇,但由于 Web 对于实时天然缺乏支持,传统的 Web 技术并不适合实时化场景。

  • 0 webrtc中的网络反馈与控制
    - 阅 2,714

    本文主要介绍WebRTC中网络反馈与控制的方法和策略。