第二期分享 | WebSocket+MSE——HTML5直播技术解析

谁践踏了优雅 2022-03-18 14:50 284阅读 0赞

分享 | 刘博（[又拍云][Link 1]多媒体开发工程师）

又小拍：  
如何实现HTML5直播技术是直播创业团队一直想要攻克的难题。12月1日20:00，深度参与“[又拍直播云][Link 2]”开发的工程师刘博就如何利用WebSocket+MSE实现HTML5直播在微信群里进行了分享。小拍马不停蹄将刘博的分享内容整理成了文字，并插入一些PPT便于大家了解。全文整理如下：

下面就是分享内容啦~

当前为了满足比较火热的移动Web端直播需求，一系列的HTML5直播技术迅速的发展起来。  
常见的可用于HTML5的直播技术有HLS、WebSocket与WebRTC。今天我向大家介绍WebSocket与MSE相关的技术要点，并在最后通过一个实例来展示具体用法。

### 分享大纲 ###

*  WebSocket协议介绍
 *  WebSocket Client/Server API介绍
 *  MSE介绍
 *  fMP4介绍
 *  Demo展示

### **WebSocket** ###

通常的Web应用都是围绕着HTTP的请求/响应模型构建的。所有的HTTP通信都通过客户端来控制，由客户端向服务器发出一个请求，服务器接收和处理完毕后再返回结果给客户端，客户端将数据展现出来。由于这种模式不能满足实时应用需求，于是出现了SSE、Comet等 "服务器推" 的长连接技术。

WebSocket是基于TCP连接之上的通信协议，可以在单个TCP连接上进行全双工的通信。WebSocket在2011年被IETF定为标准RFC 6455，并被RFC 7936补充规范，WebSocket API被W3C定为标准。

WebSocket是独立地创建在TCP上的协议，HTTP协议中的那些概念都和WebSocket没有关联，唯一关联的是使用HTTP协议的101状态码进行协议切换时，使用的TCP端口是80，可以绕过大多数防火墙的限制。

![Image 1][]

### **WebSocket握手** ###

为了更方便地部署新协议，HTTP/1.1引入了Upgrade机制，使得客户端和服务端之间可以借助已有的HTTP语法升级到其它协议。这个机制在RFC7230的6.7 Upgrade一节中有详细描述。  
要发起HTTP/1.1协议升级，客户端必须在请求头部中指定这两个字段 ▽

> Connection: Upgrade  
> Upgrade: protocol-name\[/protocol-version\]

如果服务端同意升级，那么需要这样响应 ▽

> HTTP/1.1 101 Switching Protocols  
> Connection: upgrade  
> Upgrade: protocol-name\[/protocol-version\]  
> \[... data defined by new protocol ...\]

可以看到，HTTP Upgrade响应的状态码是101，并且响应正文可以使用新协议定义的数据格式。

WebSocket握手就利用了这种HTTP Upgrade机制。一旦握手完成，后续数据传输直接在TCP上完成。

### **WebSocket JavaScrip\*\*\*\*t API** ###

目前主流的浏览器提供了WebSocket的API接口，可以发送消息（文本或者二进制）给服务器，并且接收事件驱动的响应数据。  
Step1. 检查浏览器是否支持WebSocket

> if(window.WebSocket) \{  
> // WebSocket代码  
> \}

Step2. 建立连接

> var ws = new WebSocket('[ws://localhost:8327'][ws_localhost_8327]);

Step3. 注册回调函数以及收发数据  
分别注册WebSocket对象的onopen、onclose、onerror以及onmessage回调函数。

通过ws.send()来进行发送数据，这里不仅可以发送字符串，也可以发送Blob或ArrayBuffer类型的数据。

如果接收的是二进制数据，需要将连接对象的格式设为blob或arraybuffer。  
ws.binaryType = 'arraybuffer';

### **WebSocket Golang API** ###

服务器端WebSocket库我推荐使用Google自己的golang.org/x/net/websocket，可以非常方便的与net/http一起使用。也可以将WebSocket的handler function通过websocket.Handler转换成http.Handler，这样就可以跟net/http库一起使用了。  
然后通过websocket.Message.Receive来接收数据，通过websocket.Message.Send来发送数据。

具体代码可以看下面的Demo部分。

### **MSE** ###

在介绍MSE之前，我们先看看HTML5<audio>和<video>有哪些限制。  
\*\*HTML5<audio>和<video>标签的限制\*\*\*\*\*\*

*  不支持流
 *  不支持DRM和加密
 *  很难自定义控制, 以及保持跨浏览器的一致性
 *  编解码和封装在不同浏览器支持不同

MSE是解决HTML5的流问题。

Media Source Extensions（MSE）是Chrome、Safari、Edge等主流浏览器支持的一个新的Web API。MSE是一个W3C标准，允许JavaScript动态构建<video>和<audio>的媒体流。它定义了对象，允许JavaScript传输媒体流片段到一个 HTMLMediaElement。  
通过使用MSE，你可以动态地修改媒体流而不需要任何插件。这让前端JavaScript可以做更多的事情—— 在JavaScript进行转封装、处理，甚至转码。  
虽然MSE不能让流直接传输到media tags上，但是MSE提供了构建跨浏览器播放器的核心技术，让浏览器通过JavaScript API来推音视频到media tags上。

### **Browser Support** ###

通过caniuse来检查是否浏览器支持情况。

![Image 1][]

通过MediaSource.isTypeSupported()可以进一步地检查codec MIME类型是否支持。

### **fMP4** ###

比较常用的视频封装格式有WebM和fMP4。

WebM和WebP是两个姊妹项目，都是由Google赞助的。由于WebM是基于Matroska的容器格式，天生是流式的，很适合用在流媒体领域里。

下面着重介绍一下fMP4格式。

我们都知道MP4是由一系列的Boxes组成的。普通的MP4的是嵌套结构的，客户端必须要从头加载一个MP4文件，才能够完整播放，不能从中间一段开始播放。  
而fMP4由一系列的片段组成，如果服务器支持byte-range请求，那么，这些片段可以独立的进行请求到客户端进行播放，而不需要加载整个文件。  
为了更加形象的说明这一点，下面我介绍几个常用的分析MP4文件的工具。  
gpac，原名mp4box，是一个媒体开发框架，在其源码下有大量的媒体分析工具，可以使用testapps；

*  mp4box.js，是mp4box的Javascript版本；
 *  bento4，一个专门用于MP4的分析工具；
 *  mp4parser，在线MP4文件分析工具。

### **fragment mp4 VS non-fragment mp4** ###

下面是一个fragment mp4文件通过 mp4parser（[http://mp4parser.com][http_mp4parser.com] ）分析后的截图 ▽

![Image 1][]

下面是一个non-fragment mp4文件通过mp4parser分析后的截图 ▽

![Image 1][]

我们可以看到non-fragment mp4的最顶层box类型非常少，而fragment mp4是由一段一段的moof+mdat组成的，它们已经包含了足够的metadata信息与数据, 可以直接seek到这个位置开始播放。也就是说fMP4是一个流式的封装格式，这样更适合在网络中进行流式传输，而不需要依赖文件头的metadata。  
Apple在WWDC 2016大会上宣布会在iOS 10、tvOS、macOS的HLS中支持fMP4，可见fMP4的前景非常的好。  
值得一提的是，fMP4、CMAF、ISOBMFF其实都是类似的东西。  
**MSE JavaScript API**  
从高层次上看，MSE提供了

*  一套 JavaScript API 来构建 media streams
 *  一个拼接和缓存模型
 *  识别一些 byte 流类型：
 *  WebM
 *  ISO Base Media File Format
 *  MPEG-2 Transport Streams

### **MSE内部结构** ###

![Image 1][]

MSE本身的设计是不依赖任务特定的编解码和容器格式的，但是不同的浏览器支持程度是不一样的。  
可以通过传递一个MIME类型的字符串到静态方法：

> MediaSource.isTypeSupported来检查。比如 ▽  
> MediaSource.isTypeSupported('audio/mp3'); // false  
> MediaSource.isTypeSupported('video/mp4'); // true  
> MediaSource.isTypeSupported('video/mp4; codecs="avc1.4D4028, mp4a.40.2"'); // true

获取Codec MIME string的方法可以通过在线的 [mp4info][]，或者使用命令行mp4info test.mp4 | grep Codecs，可以得到类似如下结果 ▽

> mp4info fmp4.mp4| grep Codec  
> Codecs String: mp4a.40.2  
> Codecs String: avc1.42E01E

当前，H.264 + AAC的MP4容器在所有的浏览器都支持。  
普通的MP4文件是不能和MSE一起使用的, 需要将MP4进行fragment化。  
检查一个MP4是否已经fragment的方法 ▽

> mp4dump test.mp4 | grep "\[m"

如果是non-fragment会显示如下信息 ▽

> mp4dump nfmp4.mp4 | grep "\[m"  
> \[mdat\] size=8+50873  
> \[moov\] size=8+7804  
> \[mvhd\] size=12+96  
> \[mdia\] size=8+3335  
> \[mdhd\] size=12+20  
> \[minf\] size=8+3250  
> \[mdia\] size=8+3975  
> \[mdhd\] size=12+20  
> \[minf\] size=8+3890  
> \[mp4a\] size=8+82  
> \[meta\] size=12+78

如果已经fragment，会显示如下的类似信息 ▽

> mp4dump fmp4.mp4 | grep "\[m" | head -n 30  
> \[moov\] size=8+1871  
> \[mvhd\] size=12+96  
> \[mdia\] size=8+312  
> \[mdhd\] size=12+20  
> \[minf\] size=8+219  
> \[mp4a\] size=8+67  
> \[mdia\] size=8+371  
> \[mdhd\] size=12+20  
> \[minf\] size=8+278  
> \[mdia\] size=8+248  
> \[mdhd\] size=12+20  
> \[minf\] size=8+156  
> \[mdia\] size=8+248  
> \[mdhd\] size=12+20  
> \[minf\] size=8+156  
> \[mvex\] size=8+144  
> \[mehd\] size=12+4  
> \[moof\] size=8+600  
> \[mfhd\] size=12+4  
> \[mdat\] size=8+138679  
> \[moof\] size=8+536  
> \[mfhd\] size=12+4  
> \[mdat\] size=8+24490  
> \[moof\] size=8+592  
> \[mfhd\] size=12+4  
> \[mdat\] size=8+14444  
> \[moof\] size=8+312  
> \[mfhd\] size=12+4  
> \[mdat\] size=8+1840  
> \[moof\] size=8+600

把一个non-fragment MP4转换成fragment MP4。  
可以使用FFmpeg的 -movflags来转换。  
对于原始文件为非MP4文件 ▽

> ffmpeg -i trailer\_1080p.mov -c:v copy -c:a copy -movflags frag\_keyframe+empty\_moov bunny\_fragmented.mp4

对于原始文件已经是MP4文件 ▽

> ffmpeg -i non\_fragmented.mp4 -movflags frag\_keyframe+empty\_moov fragmented.mp4

或者使用mp4fragment ▽

> mp4fragment input.mp4 output.mp4

--------------------

### **DEMO TIME** ###

**刘博在分享的最后阶段，展示了两个demo，分别是MSE Vod Demo、MSE Live Demo**

**MSE Vod Demo**

展示利用MSE和WebSocket实现一个点播服务

后端读取一个fMP4文件，通过WebSocket发送给MSE，进行播放

![Image 1][]

展示利用MSE和WebSocket实现一个直播服务

后端代理一条HTTP-FLV直播流，通过WebSocket发送给MSE，进行播放

前端MSE部分做了很多工作, 包括将flv实时转封装成了fMP4，这里引用了videojs-flow的实现

![Image 1][]

--------------------

### **Q & A** ###

--------------------

**Q1：对于没有公网iIP的客户如何通过RTMP协议推流？**  
A1：用户客户端进行RTMP推流，不需要公网IP，推到直播系统分配给你的地址就可以了。

**Q2：MSE客户端做很多东西，可以转码、解码， 这个会有性能问题吗？ 还有这个技术，目前有公司在大批量用吗？**  
A2：目前该技术在实验阶段，转封装的话，对性能要求不高，我们在各自型号的手机上测试都没有问题。目前除了微信内置浏览器对MSE支持不好，大部分浏览器对MSE支持都比较好。

**Q3：没做过相关内容，能简单介绍一下HTTP-FLV么？**  
A3：HTTP-FLV就是将FLV流以HTTP长连接的形式分发出去，目前在各大直播平台都用的比较多。大家可以关注下[又拍云][Link 1]微信公众账号，之前专门有一篇文章介绍HTTP-FLV。

**Q4：不大了解HTTP-FLV，既然是长时间的状态性连接，为什么不用tcp／socket呢？**  
A5: FLV不能在<video>标签直接播放，所以需要通过MSE转封装成MP4，再吐到<video>标签进行播放。

**Q5：哔哩哔哩H5播放器是基于WebSocket与MSE技术实现的嘛？**  
A5：B站开源的flv.js是一个非常好的项目，是基于 MSE 实现的，实时性做的也比较好，B 站自己已经在网站播放器上使用了。

--------------------

**Q6：VLC器播放和网页播放，哪个快啊？**  
A6：播放器端延时，一个重要指标是播放器的缓存区大小。VLC的默认缓存区比较大，所以，VLC通常延时会大一些。

--------------------

**Q7：可以介绍下秒开技术么，以及秒开的原理？**  
A7：秒开可以在服务器端多缓存一个GoP来实现，这样播放器请求的第一帧能保证是I帧，可以立即播放，以此达到秒开的效果.

### **Refs** ###

**WebSocket**

*  rfc6455
 *  HTTP Upgrade
 *  WebSocket API
 *  MDN WebSocket
 *  videojs-flow

**MSE**

*  W3C
 *  MDN MSE
 *  HTML5 Codec MIME

作者：又拍云  
链接：https://www.jianshu.com/p/5b4cff42bdc0  
來源：简书  
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

[Link 1]: https://link.jianshu.com?t=https://www.upyun.com/
[Link 2]: https://link.jianshu.com?t=https://www.upyun.com/products/live
[Image 1]: 
[ws_localhost_8327]: https://link.jianshu.com?t=ws://localhost:8327'%20rel=
[http_mp4parser.com]: https://link.jianshu.com?t=http://mp4parser.com
[mp4info]: https://link.jianshu.com?t=http://nickdesaulniers.github.io/mp4info