HTML5视频监控技术预研

安防类项目中通常都有视频监控方面的需求。视频监控客户端主要是Native应用的形式，在Web端需要利用NPAPI、ActiveX之类的插件技术实现。

但是，IE式微，Chrome也放弃了NPAPI，另一方面，监控设备硬件厂商的视频输出格式则逐渐标准化。这让基于开放、标准化接口的Web视频监控成为可能。

本文讨论以HTML5及其衍生技术为基础的B/S架构实时视频监控解决方案。主要包括两方面的内容：

1. 视频编码、流媒体基础知识，以及相关的库、框架的介绍
2. 介绍可以用于视频监控的HTML5特性，例如媒体标签、MSE、WebRTC，以及相关的库、框架

本文仅仅简介若干种备选的解决方案，本站其它文章进行了更加深入的探讨：

1. H.264学习笔记
2. 实时通信协议族
3. 基于Kurento搭建WebRTC服务器
4. 基于Broadway的HTML5视频监控

音频、视频的编码（Codec，压缩）算法有很多，不同浏览器对音视频的编码算法的支持有差异。H264这样的监控设备常用的视频编码格式，主流浏览器都有某种程度的支持。

常见的音频编码算法包括： MP3, Vorbis, AAC；常见的视频编码算法包括： H.264, HEVC, VP8, VP9。

编码后的音频、视频通常被封装在一个比特流容器格式（container）中，这些格式中常见的有： MP4, FLV, WebM,  ASF, ISMA等。

视频解码工作通常由浏览器本身负责，配合video实现视频播放。

现代浏览器的JS引擎性能较好，因此出现了纯粹由JS实现的解码器JSMpeg，它能够解码视频格式MPEG1、音频格式MP2。支持通过Ajax加载静态视频文件，支持低延迟（小于50ms）的流式播放（通过WebSocket）。JSMpeg包括以下组件：

1. MPEG-TS分流器（demuxer）。muxer负责把视频、音频、字幕打包成一种容器格式，demuxer则作相反的工作
2. MPEG1视频解码器
3. MP2音频解码器
4. WebGL渲染器、Canvas2D渲染器
5. WebAudio音频输出组件

JSMpeg的优势在于兼容性好，几乎所有现代浏览器都能运行JSMpeg。

JSMpeg不能使用硬件加速。在iPhone 5S这样的设备上，JSMpeg能够处理720p@30fps视频。

比起现代解码器，MPEG1压缩率较低，因而需要更大的带宽。720p的视频大概占用250KB/s的带宽。

下面我们尝试利用ffmpeg编码本地摄像头视频，并通过JSMpeg播放。

创建一个NPM项目，安装依赖：

JSMpeg提供了一个中继器，能够把基于HTTP的MPEG-TS流转换后通过WebSocket发送给客户端。此脚本需要到Github下载。 下面的命令启动一个中继器：

下面的命令捕获本地摄像头（Linux），并编码为MPEG1格式，然后发送到中继器：

上述命令执行后，中继器控制台上打印：

客户端代码：

Broadway是一个基于JavaScript的H.264解码器，其源码来自于Android的H.264解码器，利用Emscripten转译成了JavaScript，之后利用Google的Closure编译器优化，并针对WebGL进一步优化。

注意：Broadway仅仅支持Baseline这个H.264 Profile。

h264-live-player是基于Broadway实现的播放器，允许通过WebSocket来传输NAL单元（原始H.264帧），并在画布上渲染。我们运行一下它的示例应用：

因为我的机器是Linux，所以修改h264-live-player/lib/ffmpeg.js， 把ffpmeg的参数改为：

然后运行 node server-ffmpeg，打开http://127.0.0.1:8080/，可以看到自己摄像头传来的H.264码流，效果还不错。

老牌的编解码库，支持很多的音频、视频格式的编解码，支持多种容器格式，支持多种流协议。关于ffpmeg的详细介绍参见Linux命令知识集锦。

ffpmeg除了提供开发套件之外，还有一个同名的命令行工具，直接使用它就可以完成很多编解码、流转换的工作。

类似的库是libav，ffpmeg和它的功能非常相似，特性更多一些。

官网自称是最好的H.264编码器。特性包括：

1. 提供一流的性能、压缩比。特别是性能方面，可以在普通PC上并行编码4路或者更多的1080P流
2. 提供最好的视频质量，具有最高级的心理视觉优化
3. 支持多种不同应用程序所需要的特性，例如电视广播、蓝光低延迟视频应用、Web视频

有了上面介绍的HTML5标签、合理编码的视频格式，就可以实现简单的监控录像回放了。但是，要进行实时监控画面预览则没有这么简单，必须依赖流媒体技术实现。

所谓多媒体（Multimedia）是指多种内容形式 —— 文本、音频、视频、图片、动画等的组合。

所谓流媒体，就是指源源不断的由提供者产生，并持续的被终端用户接收、展示的多媒体，就像水流一样。现实世界中的媒体，有些天生就是流式的，例如电视、广播，另外一些则不是，例如书籍、CD。

流媒体技术（从传递媒体角度来看）可以作为文件下载的替代品。

流媒体技术关注的是如何传递媒体，而不是如何编码媒体，具体的实现就是各种流媒体协议。封装后的媒体比特流（容器格式）由流媒体服务器递送到流媒体客户端。流媒体协议可能对底层容器格式、编码格式有要求，也可能没有任何要求。

直播流（Live streaming）和静态文件播放的关键差异：

1. 点播的目标文件通常位于服务器上，具有一定的播放时长、文件大小。浏览器可以使用渐进式下载，一边下载一边播放
2. 直播不存在播放起点、终点。它表现为一种流的形式，源源不断的从视频采集源通过服务器，传递到客户端
3. 直播流通常是自适应的（adaptive），其码率随着客户端可用带宽的变化，可能变大、变小，以尽可能消除延迟

流媒体技术不但可以用于监控画面预览，也可以改善录像播放的用户体验，比起简单的静态文件回放，流式回放具有以下优势：

1. 延迟相对较低，播放能够尽快开始
2. 自适应流可以避免卡顿

主流的用于承载视频流的流媒体协议包括：

协议	说明
HLS	HTTP实时流（HTTP Live Streaming），由苹果开发，基于HTTP协议 HLS的工作原理是，把整个流划分成一个个较小的文件，客户端在建立流媒体会话后，基于HTTP协议下载流片段并播放。客户端可以从多个服务器（源）下载流。 在建立会话时，客户端需要下载extended M3U (m3u8) 播放列表文件，其中包含了MPEG-2 TS（Transport Stream）容器格式的视频的列表。在播放完列表中的文件后，需要再次下载m3u8，如此循环 此协议在移动平台上支持较好，目前的Android、iOS版本都支持 此协议的重要缺点是高延迟（5s以上通常），要做到低延迟会导致频繁的缓冲（下载新片段）并对服务器造成压力，不适合视频监控 播放HLS流的HTML代码片段： XHTML 1 <video src="http://movie.m3u8" height="329" width="480"></video>
RTMP	实时消息协议（Real Time Messaging Protocol），由Macromedia（Adobe）开发。此协议实时性很好，需要Flash插件才能在客户端使用，但是Adobe已经打算在不久的将来放弃对Flash的支持了 有一个开源项目HTML5 FLV Player，它支持在没有Flash插件的情况下，播放Flash的视频格式FLV。此项目依赖于MSE，支持以下特性： 支持H.264 + AAC/MP3编码的FLV容器格式的播放 分段（segmented）视频播放 基于HTTP的FLV低延迟实时流播放 兼容主流浏览器 资源占用低，可以使用客户端的硬件加速
RTSP	实时流协议（Real Time Streaming Protocol），由RealNetworks等公司开发。此协议负责控制通信端点（Endpoint）之间的媒体会话（media sessions） —— 例如播放、暂停、录制。通常需要结合：实时传输协议（Real-time Transport Protocol）、实时控制协议（Real-time Control Protocol）来实现视频流本身的传递 大部分浏览器没有对RTSP提供原生的支持 RTSP 2.0版本目前正在开发中，和旧版本不兼容
MPEG-DASH	基于HTTP的动态自适应流（Dynamic Adaptive Streaming over HTTP），它类似于HLS，也是把流切分为很小的片段。DASH为支持为每个片段提供多种码率的版本，以满足不同客户带宽 协议的客户端根据自己的可用带宽，选择尽可能高（避免卡顿、重新缓冲）的码率进行播放，并根据网络状况实时调整码率 DASH不限制编码方式，你可以使用H.265, H.264, VP9等视频编码算法 Chrome 24+、Firefox 32+、Chrome for Android、IE 10+支持此格式 类似于HLS的高延迟问题也存在
WebRTC	WebRTC是一整套API，为浏览器、移动应用提供实时通信（RealTime Communications）能力。它包含了流媒体协议的功能，但是不是以协议的方式暴露给开发者的 WebRTC支持Chrome 23+、Firefox 22+、Chrome for Android，提供Java / Objective-C绑定 WebRTC主要有三个职责： 捕获客户端音视频，对应接口MediaStream（也就是getUserMedia） 音视频传输，对应接口RTCPeerConnection 任意数据传输，对应接口RTCDataChannel WebRTC内置了点对点的支持，也就是说流不一定需要经过服务器中转

视频监控通常都是CS模式（而非P2P），在服务器端，你需要部署流媒体服务。

这是一个开源的跨平台多媒体框架。通过它你可以构建各种各样的媒体处理组件，包括流媒体组件。通过插件机制，GStreamer支持上百种编码格式，包括MPEG-1, MPEG-2, MPEG-4, H.261, H.263, H.264, RealVideo, MP3, WMV, FLV

Kurento、Flumotion是基于GStreamer构建的流媒体服务器软件。

Live555是流媒体服务开发的基础库，支持 RTP/RTCP/RTSP/SIP等协议，适合在硬件资源受限的情况下使用（例如嵌入式设备）。

基于Live555的软件包括：

1. Live555媒体服务器，完整的RTSP服务器
2. openRTSP，一个命令行程序，支持提供RTSP流、接收RTSP流、把RTSP流中的媒体录像到磁盘
3. playSIP，可以进行VoIP通话
4. liveCaster，支持组播的MP3流媒体服务

流媒体服务实现有很多，它们中的一些在最初针对特定的流协议，大部分都走向多元化。例如，Red5是一个RTMP流媒体服务器，Wowza是一个综合的流媒体服务器，支持WebRTC的流媒体服务在后面的章节介绍。

HTML5支持 <audio>和 <video>标签（两者都对应了HTMLMediaElement的子类型）以实现视频、音频的播放。

此标签用于在浏览器中创建一个纯音频播放器。播放静态文件的示例：

此标签用于在浏览器中创建一个视频播放器。播放静态文件的示例：

在画布中，你可以进行任意的图形绘制，当然可以去逐帧渲染视频内容。

音频、视频播放器标签也可以利用JavaScript编程式的创建，示例代码：

媒体源扩展（Media Source Extensions，MSE）是一个W3C草案，桌面浏览器对MSE的支持较好。MSE扩展流video/audio元素的能力，允许你通过JavaScript来生成（例如从服务器抓取）媒体流供video/audio元素播放。使用MSE你可以：

1. 通过JavaScript来构建媒体流，不管媒体是如何捕获的
2. 处理自适应码流、广告插入、时间平移（time-shifting，回看）、视频编辑等应用场景
3. 最小化JavaScript中处理媒体解析的代码

MSE定义支持的（你生成的）媒体格式，只有符合要求的容器格式、编码格式才能被MSE处理。通常容器格式是ISO BMFF（MP4），也就是说你需要生成MP4的片断，然后Feed给MSE进行播放。

MediaSource对象作为video/audio元素的媒体来源，它可以具有多个SourceBuffer对象。应用程序把数据片段（segment）附加到SourceBuffer中，并可以根据系统性能对数据片段的质量进行适配。SourceBuffer中包含多个track buffer —— 分别对应音频、视频、文本等可播放数据。这些数据被音频、视频解码器解码，然后在屏幕上显示、在扬声器中播放：

 

要把MediaSource提供给video/audio播放，调用：

wfs是一个播放原始H.264帧的HTML5播放器，它的工作方式是把H.264 NAL单元封装为 ISO BMFF（MP4）片，然后Feed给MSE处理。

flv.js是一个HTML5 Flash视频播放器，基于纯JS，不需要Flash插件的支持。此播放器将FLV流转换为ISO BMFF（MP4）片断，然后把MP4片断提供给video元素使用。

flv.js支持Chrome 43+, FireFox 42+, Edge 15.15048+以上版本的直播流 。

Streamedian是一个HTML5的RTSP播放器。实现了RTSP客户端功能，你可以利用此框架直接播放RTSP直播流。此播放器把RTP协议下的H264/AAC在转换为ISO BMFF供video元素使用。Streamedian支持Chrome 23+, FireFox 42+, Edge 13+，以及Android 5.0+。不支持iOS和IE。

在服务器端，你需要安装Streamedian提供的代理（此代理收费），此代理将RTSP转换为WebSocket。Streamedian处理视频流的流程如下：

WebRTC是一整套API，其中一部分供Web开发者使用，另外一部分属于要求浏览器厂商实现的接口规范。WebRTC解决诸如客户端流媒体发送、点对点通信、视频编码等问题。桌面浏览器对WebRTC的支持较好，WebRTC也很容易和Native应用集成。

使用MSE时，你需要自己构建视频流。使用WebRTC时则可以直接捕获客户端视频流。

使用WebRTC时，大部分情况下流量不需要依赖于服务器中转，服务器的作用主要是：

1. 在信号处理时，转发客户端的数据
2. 配合实现NAT/防火墙穿透
3. 在点对点通信失败时，作为中继器使用

主要是捕获客户端摄像头、麦克风。在视频监控领域用处不大，这里大概了解一下。流捕获通过navigator.getUserMedia调用实现： 

三个调用参数分别是：

1. 约束条件，你可以指定媒体类型、分辨率、帧率 
2. 成功后的回调，你可以在回调中解析出URL提供给video元素播放
3. 失败后的回调

捕获音频类似：

MediaStream对象提供以下方法：

1. getAudioTracks()，音轨列表
2. getVideoTracks()，视轨列表

每个音轨、视轨都有个label属性，对应其设备名称。

Camera.js是对getUserMedia的简单封装，简化了API并提供了跨浏览器支持：

掠食者视觉是基于Camera实现的一个好玩的例子（移动侦测）。

在端点之间（Peer）发送流之前，需要进行通信协调、发送控制消息，即所谓信号处理（Signaling），信号处理牵涉到三类信息：

1. 会话控制信息：初始化、关闭通信，报告错误
2. 网络配置：对于其它端点来说，本机的IP和端口是什么
3. 媒体特性：本机能够处理什么音视频编码、多高的分辨率。本机发送什么样的音视频编码

WebRTC没有对信号处理规定太多，我们可以通过Ajax/WebSocket通信，以SIP、Jingle、ISUP等协议完成信号处理。点对点连接设立后，流的传输并不需要服务器介入。信号处理的示意图如下：

下面的代表片段包含了一个视频电话的信号处理过程：

主要牵涉到的接口是RTCPeerConnection，上面的例子中已经包含了此接口的用法。WebRTC在底层做很多复杂的工作，这些工作对于JavaScript来说是透明的： 

1. 执行解码
2. 屏蔽丢包的影响
3. 点对点通信：WebRTC引入流交互式连接建立（Interactive Connectivity Establishment，ICE）框架。ICE负责建立点对点链路的建立：
   1. 首先尝试直接
   2. 不行的话尝试STUN（Session Traversal Utilities for NAT）协议。此协议通过一个简单的保活机制确保NAT端口映射在会话期间有效
   3. 仍然不行尝试TURN（Traversal Using Relays around NAT）协议。此协议依赖于部署在公网上的中继服务器。只要端点可以访问TURN服务器就可以建立连接
4. 通信安全
5. 带宽适配
6. 噪声抑制
7. 动态抖动缓冲（dynamic jitter buffering），抖动是由于网络状况的变化，缓冲用于收集、存储数据，定期发送

通过RTCDataChannel完成，允许点对点之间任意的数据交换。RTCPeerConnection连接创建后，不但可以传输音视频流，还可以打开多个信道（RTCDataChannel）进行任意数据的交换。RTCDataChanel的特点是：

1. 类似于WebSocket的API
2. 支持带优先级的多通道
3. 超低延迟，因为不需要通过服务器中转
4. 支持可靠/不可靠传输语义。支持SCTP、DTLS、UDP几种传输协议
5. 内置安全传输（DTLS）
6. 内置拥塞控制

使用RTCDataChannel可以很好的支持游戏、远程桌面、实时文本聊天、文件传输、去中心化网络等业务场景。

WebRTC adapter是一个垫片库，使用它开发WebRTC应用时，不需要考虑不同浏览器厂商的API前缀差异。

本节列出一些WebRTC的代码示例，这些例子都使用adapter.js。

框架	说明
PeerJS	简化WebRTC的点对点通信、视频、音频调用 提供云端的PeerServer，你也可以自己搭建服务器
Sharefest	基于Web的P2P文件共享
webRTC.io	WebRTC的一个抽象层，同时提供了客户端、服务器端Node.js组件。服务器端组件抽象了STUN 类似的框架还有SimpleWebRTC、easyrtc
OpenWebRTC	允许你构建能够和遵循WebRTC标准的浏览器进行通信的Native应用程序，支持Java绑定
NextRTC	基于Java实现的WebRTC信号处理服务器
Janus	这是一个WebRTC网关，纯服务器端组件，目前仅仅支持Linux环境下安装 Janus本身实现了到浏览器的WebRTC连接机制，支持以JSON格式交换数据，支持在服务器端应用逻辑 - 浏览器之间中继RTP/RTCP和消息。特殊化的功能有服务器端插件完成 官网地址：https://janus.conf.meetecho.com
Kurento	这是一个开源的WebRTC媒体服务器

我们首先尝试的方案是直接使用RTSP源，原因是海康、大华主流厂商的较新的IP摄像头均支持暴露标准化的RTSP流。

使用VLC播放器，打开网络串流：rtsp://admin:12345@192.168.0.196:554/ch1/main/av_stream，视频源为公司门口的海康摄像头的主码流（main，子码流为sub）。

发现可以正常播放，说明视频格式应该是标准的。VLC菜单 Tool ⇨ Codec Info查看，编码格式为H264。

浏览器无法直接使用RTSP协议，因此，需要有服务器端来处理视频源的RTSP，将其转换为：

1. 通过WebSocket发送的视频片断，由客户端的：
   1. JSMpeg/Broadway直接解码，渲染到画布
   2. 或者，构造MP4片断Feed给MSE播放
2. 或者，通过WebRTC网关，转换后提供给客户端的WebRTC代码处理
3. 或者，使用浏览器插件机制，例如Chrome的NaCl

Streamedian的服务器端需要授权，我们选用了另外一个实现。

H5S是一个基于live555实现的开源的HTML5 RTSP网关，支持将RTSP/H264流输入转换为HTML5 MSE支持的H264，客户端基于MSE。

尝试在容器中运行H5S：

使用H5S自带的基于MSE的客户端代码 + Chrome 49，播放后发现画面静止。控制它查看发现解码错误。打开chrome://media-internals/，发现错误Media segment did not begin with key frame. Support for such segments will be available in a future version。看样子是提供给SourceBuffer的数据不是以关键帧开始导致，未来版本的Chrome可能取消此限制。

换成Chrome 50，可以正常播放，但是流畅度较差，播放一段时间后出现卡死的情况。

H5S实现不完善，在不修改源码的情况下，服务器端只能接入一路视频输入。客户端也存在不流畅、卡死的问题，不适合生产环境。

在上文中我们已经成功尝试了利用JSMpege + WebSocket的方式，在网页中显示摄像头捕获的视频。ffmpeg转换RTSP也是非常简单的：

可以使用JSMpeg自带的简单Node.js服务器测试：

下面是客户端代码，默认JSMpeg会基于WebGL渲染，但是我的机器最多开到8画面，开9画面时出现警告：

Too many active WebGL contexts. Oldest context will be lost，且第一画面丢失，简单的通融方法是，第9画面使用Canvas2D渲染：

渲染截图：

这种方式客户端解码压力较大，同时开9画面的352x288视频，我的机器上CPU占用率大概到40%左右，画面变化较为剧烈的时候会出现卡顿现象。

与JSMpeg类似，Broadway也是JavaScript解码工具。关键之处是，Broadway支持的视频编码是H.264，意味着可能免去消耗服务器资源的视频重编码。

最初的尝试并不顺利，根据IP摄像头的RTSP Describe应答（SDP），我们推断其H.264 Profile为Baseline，但是不转码的情况下Broadway根本无法播放。后来查看ffmpeg的日志输出，发现其实际上使用的Profile是Main。进一步尝试，发现摄像头是可以配置为Baseline的：

只需要把编码复杂度设置为低，H.264的Profile就从Main变为Baseline。

设置完毕后，仍然基于h264-live-player的Demo进行测试，使用如下命令行抽取原始H.264帧：

即可免转码的进行实时视频预览了。 

此实现方式更多细节信息请参考基于Broadway的HTML5视频监控。

Chrome放弃NPAPI之后，插件开发需要使用PPAPI /NaCl。目前能找到的实现有VXG Chrome Plugin，这是一个商业产品，需要授权。除了RTSP之外，还支持RTMP、HLS等协议。

插件方案的缺点是，需要安装，而且仅仅针对单种浏览器。优势则是灵活性高，理论上性能可以做的很好。

WebRTC相关的框架非常多，经过简单的比较，我们决定从Kurento入手。主要原因是：

1. 容易扩展的模块化设计
2. 提供Java客户端、JS客户端
3. 可以在服务器端合成多画面，这样可以减轻客户端解码压力，特别是那些低配置的客户端
4. 内置对RTSP协议的支持

基于Kurento搭建WebRTC服务器一文详细讨论了这种实现方式。

这里的设备，主要包括：网络硬盘录像机（NVR）、视频服务器、IP摄像头。为了便于二次开发，硬件厂商都为这些设备配置的相应的SDK套件。这些SDK通常都提供了：实时码流预览、录像文件回放、播放控制（如：暂停、单帧前进、单帧后退）、获取码流基本信息、播放截图等功能。

我们的基本目标是，通过SDK得到标准化的码流，例如H264格式。具体如何操作，得看厂商的SDK，但是思路基本是：

1. 如果SDK直接支持获取标准格式的流，例如RTSP，那么备选方案一就可以直接用上
2. 如果SDK支持获取标准编码的视频帧，例如H264，那我们只需要将其包装为合适的容器格式，再通过RTSP/HTTP的方式发送出去
3. 如果SDK支持获取解码后的原始图像数据，例如RGB、YV12，我们可以基于H264再次编码，然后按第2步方式处理。这种方式对服务器性能要求比较高，CPU压力较大，PC机处理不了多少个通道
4. 如果都不支持，只提供了封装好的播放控件 —— 这个就比较悲催了，不过通过OS底层API，例如Windows的GDI应该也是可以实现，否则那些屏幕录像软件怎么做的呢？

根据Linux版本的海康设备网络编程指南的描述，我们应该可以：

1. 调用NET_DVR_Init进行SDK初始化
2. 调用NET_DVR_Login登陆到目标设备
3. 调用NET_DVR_RealPlay进行播放，此时返回一个实时播放句柄
   1. 如果设备支持RTSP协议取流：针对上述句柄调用NET_DVR_SetStandardDataCallBack，可以设置一个标准的数据回调函数，此回调会接受到标准码流，这对应上面的第1种思路
   2. 如果设备不支持RTSP协议取流：针对上述句柄调用NET_DVR_SetRealDataCallBack，然后通过PlayM4播放库中的PlayM4_SetDecCallBack回调得到yv12格式的原始图像。这对应上面的第3种思路

cmake构建配置：

 C++代码：

运行脚本：

此程序运行后，会自动获取到基于RTSP协议的媒体流，回调函数会反复被调用：

1. 第一次调用为40字节的头，不太清楚有什么用
2. 第二次调用传递了SDP
3. 后续调用传递标准音视频数据，其内容是RTP封包

基于HTM5的视频监控，媒体流从采集设备到浏览器，主要路径如下图所示：

对上图的说明如下：

1. 在设备层，需要以某种方式获得码流，以流协议的方式发送出去。最常用的方式是RTSP/RTP。流的可能获取路径为：
   1. 设备直接暴露RTSP协议端点，并且发送标准码流
   2. 设备SDK允许获取标准码流，需要自己以RTSP协议发送
   3. 设备SDK允许获得解码后的逐帧，需要直接编码为H264，然后以RTSP发送
2. 流媒体层通常需要引入专门的流媒体服务器，这类服务器能够在内部进行各种流协议的转换，可以解除客户端对特定流协议的依赖
3. 客户端和服务器端的传输方式，可以有TCP、HTTP、P2P（WebRTC）、WebSocket等多种。其中
   1. 直接的TCP协议浏览器是不支持的，这意味着RTSP/RTMP等协议，在浏览器端必须要有插件才可以使用
   2. WebSocket通常配合JSMpeg或者MSE使用，由程序向JSMpeg/MSE不断Feed视频帧
4. 客户端解码展示的技术主要有三类：
   1. 浏览器内置的解码能力，主要通过video标签，MSE属于此类
   2. JavaScript软解码，主要是JSMpeg、Broadway
   3. 插件机制，例如Chrome的NaCl

能够免于引入流媒体层的方案，需要：设备能直接暴露标准码流的RTSP端点，并且安装浏览器插件。缺点也很明显，一个是设备的访问密码暴露给了客户端，第二个是目前没有成熟、开源的插件可用。我相信主要原因是合理技术方向不在于此，没人愿意去开发。

直接使用设备层的RTSP端点，可能存在兼容性问题。一个是它发送的码流是否标准化，第二个是市场上有多少设备没有暴露RTSP端点。

客户端方面，JSMpeg是兼容性较好的方案，WebRTC/MSE都有部分平台不支持（但是桌面级的浏览器大部分支持）。JSMpeg的缺点是：

1. 如果基于WebGL渲染，受限于浏览器WebGL上下文最大数量，多画面可能无法渲染。某些流媒体服务器支持在服务器端合成多画面Grid，可以规避此缺点
2. 如果基于Canvas2D渲染，画质较差（我的机器上还有莫名其妙的斜线）
3. 对码流格式要求严格，仅仅支持MPEG-TS，此格式压缩比差，网络带宽占用大
4. 性能相对较差，尽管使用了MPEG-TS这种简单的视频格式，基于JavaScript解码渲染仍然使客户端压力较大。我的机器（i7-4940MX / Quadro K5100M / Ubuntu 14.04 LTS）上会出现卡顿情况

和JSMpeg类似的库是Broadway，后者能够进行Baseline的H.264解码。如果设备支持Baseline H.264输出，使用Broadway可以很好的解决服务器端转码导致的资源消耗问题。

1. Audio and Video Delivery
2. W3C Recommendation - Media Source Extensions™
3. WebRTC Project Home
4. HTML5 视频直播（三）