WebRTC下流媒体文件远程推送与即时播放研究

2017-11-02张宝明钮丹倩

软件导刊 2017年10期

张宝明++钮丹倩

摘要：WebRTC是推动互联网经济向前发展的重要技术，但存在应用模式不成熟，应用范围有限，与电子商务缺乏深度融合等问题。探讨了WebRTC的应用模式及其实现技术。分析了现行流媒体文件远程推送与即时播放方法的不足；通过增加排队系统和协调机制，设计了基于事件响应的处理模型，丰富了电子商务视频应用解决方案。

关键词：流媒体；远程推送；即时播放；电子商务

DOIDOI：10.11907/rjdk.171649

中图分类号：TP393

文献标识码：A文章编号：16727800（2017）010018203

0引言

WebRTC（Web RealTime Communication，网页实时通信）是第4代Web应用技术[1]，自2012年出现以来一直受到追捧。其核心要义在于集成音视和视频，绕过服务器，通过信令直接在浏览器和浏览器之间（peertopeer）建立信道，实现浏览器与浏览器之间的实时通信，以拓展Web应用，推动互联网经济向前发展[23]。

随着WebRTC技术不断成熟、功能逐渐完善，建立在其技术基础之上的视频会议、可视通信等应用也得以推广，在電子商务、网络社区中屡屡可见其身影。然而，受到技术条件的限制和监管政策的约束，与Web应用第2代技术Ajax和第3代技术WebSocket出现后，集中爆发的新模式如微博、维基、社交网络等应用相比，基于WebRTC技术的应用目前还仅局限于视频会议和可视通信，与电子商务和电子政务的深度融合尚未开始，应用范围较为有限，应用模式还不够清晰，缺少必要的创新。因此，探讨WebRTC技术下新的应用模式显得尤为重要。

本文探讨了WebRTC技术新的应用模式：流媒体文件的远程推送与即时播放，目的是在实时通信过程中，利用WebRTC技术向其它远程端浏览器（远程Peer）推送流媒体文件，并及时播放（一边推送一边播放，而不是等推送完再播放）。这样不但能减少远程客户端等待时间，改善用户体验，还能由此产生新的商业模式，实现诸如电子商务中的广告插播、音乐商店中的体验播放、教育网站上的明师名家视频教学等应用。

1WebRTC技术现状

对于WebRTC技术相关文献有一些探讨。如在W3C组织推荐的《W3C Working Draft for Audio API 1.0》[4]草案中，就提出了MediaStream概念，将本地播放的视频、音频流（即网页中用于播放视频和音频文件的

作为阶段性成果，目前在一些浏览器（如chrome、FireFox）中，已经可以通过AudioContext对象，运用createBufferSource（）方法，将本地

通常，WebRTC有3个重要的脚本接口：①MediaStream，用于通过摄像头及话筒获得视频、音频的同步流；②RTCPeerConnection，用于构建PeerPeer流媒体通道；③RTCDataChannel，用于构建数据通道。文献[6]提出利用RTCDataChannel接口实现视频文件的远程推送和播放，具体方法如下：①在本地Peer打开视频文件（WebM或MP4格式）；②通过FileReader将其数据以Uint8Array格式读到缓冲区buffer中；③将缓冲区buffer中的数据分割成若干个数据块（每个数据块不大于3 000字节），并通过RTCDataChannel信道传送给远程Peer端；④远程Peer端收到数据块后，立即写入（不等收到所有数据块）一个属于MediaSource的SourceBuffer对象中（即所谓的appendBuffer操作），并通过预先与

图1视频文件远程推送与播放模型

SourceBuffer关联多个对象，其写入操作较为复杂，需要进行一系列指令处理，存在一定的时间延迟，这在视频文件较小、发送速度较慢的情况下没有多大问题。但是，在数据发送量加大、接收速度加快的情况下，由于时间延迟的存在，致使前一个appendBuffer操作尚未完成，就需要立即响应后一个appendBuffer操作，导致通信失败。

2改进与实现

上述方法的缺陷在于：①在进行appendBuffer操作时，缺少任务排队系统，这样在接收速度高于写入速度时导致写入失败；②缺少事件处理协调机制，尤其当系统建构到Node.js环境时，由于Node.js具有事件驱动、非阻塞式I/O模型特征，协调机制的缺失会使接收、写入和播放操作在时序上产生冲突。为此，笔者在建设电子商务平台（https：//120.25.222.72）时，对远程Peer端流程进行了改造，加入了排队系统和协调机制，成功实现了视频文件的远程推送和播放，模型见图2。

图2改进的视频文件远程推送与播放模型

首先，在接收数据和申请写入数据模块中增加一个排队系统queue，在数据抵达事件发生后，先将数据放入queue队列排队，然后依据queue中是否存在唯一的数据块，决定是否发起 appendBuffer操作，实现将数据块写入SourceBuffer并及时播放。这样，就改变了以前只要收到数据就立即插入sourceBuffer而带来的速度不匹配问题。

其次，在onMessage、onUpdate和onLoad事件处理模块间加入了时序协调机制。为此，增加两个全局变量：isFirstChunkUpdating、receiveError，分別表示“queue中第1个数据块正在进行appendBuffer操作”、“appendBuffer操作过程中发生了错误”。

在接收数据之前，分别将初始值设置为： isFirstChunkUpdating =false和receiveError =false，然后通过以下流程进行协调：

等待数据通道传来数据，以触发onmessage事件。

onmessage事件的处理。过程代码如下：

（1）判断传来的数据是视频数据块或是结束标记。若是视频数据块，则转入（2）；若是结束标记，则转入（3）；

（2）是视频数据块，则：

if（receiveError）{

清空queue队列，丢弃所有已排队的数据块；

}else{

将数据块转换成Uint8Array格式；

进入queue队列，排队等待；

if（！isFirstChunkUpdating &&queue.length==1）{

设置isFirstChunkUpdating =true；