作者:Pipe(原文链接)
翻译:刘通
原标题:Why we chose WebRTC over Media Recorder API for HTML5 Video Recording
通过这篇文章,我们将要分析一下我们为什么在从浏览器录制视频的时候,选择使用WebRTC而不是Media Recorder API的原因。下面将给出技术细节。
直到2016年第四季度,Safari已经成为了第一大浏览器,这让Flash的处境更加艰难,因为Safari默认必须要点击才能播放网页上的Flash内容。在2017年内Chrome也计划实施相似的计划。因为我们的电脑视频录制用户是建在Flash中的,所以我们快速的对HTML5进行了调查。
结果显示并没有太多的选择,只有
1.HTML Media Capture(HTML媒体捕捉)
2.Media Recorder API
3.WebRTC视频录制
HTML Media Capture
我们已经可以在手机端浏览器中使用HTML Media Capture来稳定的录制视频,但是因为不能够在电脑端浏览器上实现,所以HTML Media Capture不可能成为本文讨论问题的一个选项。
这就只剩下Media Recorder API和WebRTC这两个选择来代替Flash进行视频录制了。
Media Recorder API
我们之前就已经讨论过Media Recorder API,这个API在本地录制并且上传到网页服务器的时候工作状况良好。但是在支持的浏览器数量方面不足,只有Firefox和Chrome支持。但真正严峻的问题是,其他主要浏览器并不必须实施这项标准,所以以WebRTC来讲,我们可能只能给65%的互联网用户提供服务。
WebRTC
在进行视频录制时WebRTC也存在部分问题:
1. 因为是为P2P直播流而设计的,WebRTC在进行流传输的时候不会使用本地缓存è它只能携带与实时UDP上传带宽所允许等量的视频质量。
2. 我们发现,想要让企业受限网络中的设备与你的WebRTC端点相连接是比较困难的,TokBox的报告称他们无法解释着0.05%的失败率。
但是另一方面:
1. WebRTC的未来支持情况一片大好。Firefox,Chrome和Opera已经能够稳定地支持WebRTC,Microsoft也声明在Edge浏览器中支持WebRTC 1.0,最近苹果也在Safari 11中加入了WebRTC功能。
2. WebRTC还有另外一个重要的优势:因为它是以数据流方式工作的,所以它没有上传时间,并且在浏览器崩溃的情况中不会造成数据丢失。而就是这个优点让我们决定选用WebRTC。
对比
如果你想要在自己的网站加入视频录制功能,这里是对WebRTC和Media Recorder API的对比:
|
WebRTC |
Media Recorder API |
支持浏览器 |
Chrome、Firefox、Opera、Edge 15、Safari 11 |
Chrome 49+、Firefox 30+、Opera 36+ |
基础设备 |
复杂:信令服务器,TURN/STUN服务器,WebRTC终端 |
简单:用于上传的网页服务器 |
连接过程 |
复杂:连接过程可能在信令,发现或者P2P连接的时候发生失败 |
无 |
录制过程 |
以数据流的形式发送到WebRTC终端并且保存 |
本地录制+稍后上传 |
视频质量 |
受到上传带宽的限制 |
受到网络摄像头质量的限制 |
上传过程 |
无 |
有,由上传带宽决定 |
数据完整性 |
因为数据是实时推流的所以数据永远不会丢失 |
在浏览器,操作系统或者电脑崩溃的时候会造成录制的数据丢失 |
安全性 |
数据在传输过程中被加密。信令和发现阶段必须单独进行加密 |
在使用https的时候,数据在传输过程中加密 |
文件类型 |
webm |
webm |
视频codec |
规范强制:VP8,H.264 |
浏览器独立决定:VP8,VP9,H.264 |
音频codec |
规范强制:Opus 48kHz |
浏览器独立决定:Opus 48kHz,Vorbis 44kHz |