使用 MediaSource 搭建流式播放器

「爱情、让人受尽委屈。」 2024-04-17 06:22 11阅读 0赞

[https://zhuanlan.zhihu.com/p/26374202][https_zhuanlan.zhihu.com_p_26374202]

# 使用 MediaSource 搭建流式播放器 #

[![Starkwang][]][Starkwang 1]

[Starkwang][Starkwang 1]

[JavaScript][] 话题的优秀回答者

137 人赞同了该文章

好久好久没有写文章了呀，感觉再不写点啥的话这个专栏就要掉粉了=。=

马上就要正式毕业了，毕业设计是做自适应流媒体相关的优化（说白了就是弄个算法更先进的、码率根据网速自适应的、基于现代浏览器的流式播放器），正好最近这块开始步入正轨了，就介绍一下现在浏览器已经普及的 MediaSource Extension，以及一些实践的细节吧。

## 一、背景 ##

[Media Source Extensions][]（媒体源扩展）大大地扩展了浏览器的媒体播放功能，提供允许JavaScript 生成媒体流。这可以用于自适应流（adaptive streaming，也是我毕设的研究方向）及随时间变化的视频直播流（live streaming）等应用场景。

在这之前，浏览器提供的媒体播放功能（音频、视频）都是相当简陋的，一个 video 或者 audio 标签再加上相对应的数据 url 就搞定了。

但这缺少了诸如视频分段加载、视频码率切换、部分加载等等现代播放器应该有的功能，所以绝大部分的浏览器视频播放器过去都是基于 Flash 开发的，这也是为什么直到现在2017年中旬，Flash 这个老古董依然在各大视频网站上活着的原因。

![format_png][]

如果你是一位经常上 B 站的朋（shēn）友（shì），特别是用 mac 的，一定会注意到 B 站在去年就上线了 HTML5 的播放器，大大缓解了 mac 看 B 站时发热严重的问题。

用 HTML5 播放器替代 Flash，是现在的一大趋势，Flash 过去占据的版图正在逐渐被现代浏览器吞噬，身为前端工程师要做的，就是给 Flash 的坟墓上再加一铲子土吧……

![format_png 1][]

## 二、MediaSource 的简单使用 ##

在浏览器里，首先我们要判断是否支持 MediaSource：

var supportMediaSource = 'MediaSource' in window

然后就可以新建一个 MediaSource 对象，并且把 mediaSource 作为 objectURL 附加到 video 标签上上：

var mediaSource = new MediaSource()
    var video = document.querySelector('video')
    video.src = URL.createObjectURL(mediaSource)

接下来就可以监听 mediaSource 上的 sourceOpen 事件，并且设置一个回调：

mediaSource.addEventListener('sourceopen', sourceOpen);
    function sourceOpen {
        // todo...
    }

接下来会用到一个叫 [SourceBuffer][] 的对象，这个对象提供了一系列接口，这里用到的是 appendBuffer 方法，可以动态地向 MediaSource 中添加视频/音频片段（对于一个 MediaSource，可以同时存在多个 SourceBuffer）

上面这些代码基本上就是一个最简化的流程了，加载了一段视频 chunk，然后把它『喂』到播放器中。

可以参考：

[MediaSource][Media Source Extensions]

[构建简单的 MPEG-DASH 流媒体播放器][MPEG-DASH]

## 二、实践中的一些坑 ##

**1、mime 字符串**

mime 字符串指的就是下面这个东西，会在新建 SourceBuffer 中使用到：

var mime = 'video/mp4; codecs="avc1.42E01E, mp4a.40.2"'
    var sourceBuffer = mediaSource.addSourceBuffer(mime);

这个神奇的字符串是什么意思呢？

首先，前面的 **video/mp4** 代表这是一段 mp4 格式封装的视频，同理也存在类似 **video/webm**、**audio/mpeg**、**audio/mp4** 这样的 mime 格式。一般情况下，可以通过 [canPlayType][] 这个方法来判断浏览器是否支持当前格式。

后面的这一段 **codecs="...."** 比较特别，以逗号相隔，分为两段：

第一段，**'avc1.42E01E'**，即它用于告诉浏览器关于视频编解码的一些重要信息，诸如编码方式、分辨率、帧率、码率以及对解码器解码能力的要求。

在这个例子中，**'avc1'** 代表视频采用 H.264 编码，随后是一个分隔点，之后是 3 个两位的十六进制的数，这 3 个十六进制数分别代表：

1.  AVCProfileIndication（**42**）
2.  profile\_compability（**E0**）
3.  AVCLevelIndication（**1E**）

第一个用于标识 H.264 的 profile，后两个用于标识视频对于解码器的要求。

对于一个 mp4 视频，可以使用 [mp4file][] 这样的命令行工具：

mp4file --dump xxx.mp4

找到 avcC Box 后，就可以看到这三个值：

mp4file --dump movie.mp4
    ...
        type avcC (moov.trak.mdia.minf.stbl.stsd.avc1.avcC) // avc1
         configurationVersion = 1 (0x01)
         AVCProfileIndication = 66 (0x42)    // 42
         profile_compatibility = 224 (0xe0)  // E0
         AVCLevelIndication = 30 (0x1e)      // 1E
    ...

有一处要注意，后面两个值（profile\_compability、AVCLevelIndication）只是浏览器用于判断自身的解码能力能否满足需求，所以不需要和视频完全对应，更高也是可以的。

下面来看 **codecs** 的第二段 **'mp4a.40.2'**，这一段信息是关于音频部分的，代表视频的音频部分采用了 AAC LC 标准：

**'mp4a'** 代表此视频的音频部分采用 MPEG-4 压缩编码。

随后是一个分隔点，和一个十六进制数（**40**），这是 ObjectTypeIndication，**40** 对应的是 Audio ISO/IEC 14496-3 标准。（不同的值具有不同的含义，详细可以参考[官方文档][Link 1]）

然后又是一个分隔点，和一个十进制数（**2**），这是 MPEG-4 Audio Object Type，[维基百科][Link 2]中的解释是 "MPEG-4 AAC LC Audio Object Type is based on the MPEG-2 Part 7 Low Complexity profile (LC) combined with Perceptual Noise Substitution (PNS) (defined in MPEG-4 Part 3 Subpart 4)"，具体是什么意思就不翻译了，其实就是一种 H.264 视频中常用的音频编码规范。

这一整段 codecs 都有完善的官方文档，可以参考：

[The 'Codecs' and 'Profiles' Parameters for "Bucket" Media Types][The _Codecs_ and _Profiles_ Parameters for _Bucket_ Media Types]

**2、如何转码出符合标准的视频**

目前有很多开源的视频处理工具，比如 [FFMPEG][]、[HandBrake][]，我用的后者转码，前者切割。

转码其实很简单，HandBrake 打开后，加入想要处理的视频（mp4 格式），窗口下半部分 video 标签，H.264 Profile 选择 "Baseline"，level 选择 "3.0"；audio 标签，选择 Encoder 为 "AAC"。

然后就是把视频切割为比较小的 chunk，ffmpeg 就可以很方便地切割：

ffmpeg -ss 00:00:00 -i source2.mp4 -c copy -t 00:00:05 xxxx.mp4

上面这段命令就切出了视频的第 0 秒到第 5 秒。

注意一个问题，ffmpeg 在切割视频的时候无法做到时间绝对准确，因为视频编码中关键帧（I帧）和跟随它的B帧、P帧是无法分割开的，否则就需要进行重新帧内编码，会让视频体积增大。所以，如果切割的位置刚好在两个关键帧中间，那么 ffmpeg 会向前/向后切割，所以最后切割出的 chunk 长度总是会大于等于应有的长度。

**3、向 SourceBuffer 中添加多个 chunk**

第一部分的范例中只是请求了一段 chunk 然后加入到播放器里，如果视频很长，存在多个chunk 的话，就需要不停地向 SourceBuffer 中加入新的 chunk。

这里就需要注意一个问题了，即 appendBuffer 是异步执行的，在完成前，不能 append 新的 chunk：

sourceBuffer.appendBuffer(buffer1)
    sourceBuffer.appendBuffer(buffer2)
    
    // Uncaught DOMException: Failed to set the 'timestampOffset' property on 'SourceBuffer': This SourceBuffer is still processing an 'appendBuffer' or 'remove' operation.

而是应该监听 SourceBuffer 上的 updateend 事件，确定空闲后，再加入新的 chunk：

sourceBuffer.addEventListener('updateend', () => {
        // 这个时候才能加入新 chunk
        // 先设定新chunk加入的位置，比如第20秒处
        sourceBuffer.timestampOffset = 20
        // 然后加入
        sourceBuffer.append(newBuffer)
    }

**4、码率自适应算法**

对于随时变化的网络情况，我们会根据情况加载不同码率的视频，这里就需要一些控制算法决定当前加载哪个码率的视频。

很容易就能想到一种简单的算法：**上一段 chunk 加载完后，计算出加载速度，从而决定下一个 chunk 的码率。**

但这种朴素的算法有很严重的问题，即它假设网络是相当稳定的，我们可以根据当前的信息预测出未来的网速。但这已经被大量的统计数据证明是不现实的，换句话说，**我们没办法预测未来的网络环境。**

所以学术界提出了一系列新的算法，比如最常见的 Buffer-Based 算法，即**根据当前缓冲区里视频的长度，决定下一个 chunk 的码率。**如果有很长的缓冲，那么就加载高码率的视频。这在相当于一个积分控制器，把时刻变化的无法预测的网络环境在时间维度上积分，以获得一个更平缓更能预测的函数。

但是 Buffer-Based 算法依然有问题，在视频起步阶段，缓冲区里的视频很短，导致无论网络环境如何，起步阶段的码率都是很低的。所以 Buffer-Based 算法只适用于视频 startup 后的稳态阶段。在起步阶段，依然有很多优化的空间，这也不是本文的重点，具体就不再详述了。

编辑于 2017-04-16

[前端开发][Link 3]

[多媒体播放器（软件）][Link 4]

赞同 13711 条评论

[https_zhuanlan.zhihu.com_p_26374202]: https://zhuanlan.zhihu.com/p/26374202
[Starkwang]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMzLnpoaW1nLmNvbS92Mi0xNzgwZGU3M2M5MjRiNTYxZmM2NTFhZWZiZmNkODNhMV94cy5qcGc?x-oss-process=image/format,png
[Starkwang 1]: https://www.zhihu.com/people/starkwei
[JavaScript]: https://www.zhihu.com/people/starkwei/creations/19552521
[Media Source Extensions]: https://link.zhihu.com/?target=https%3A//developer.mozilla.org/en-US/docs/Web/API/MediaSource
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMxLnpoaW1nLmNvbS84MC92Mi1lNjhiZjNiNmE4YmRiNzA4NzI4N2ZjOGVhMTI4OWQ5NF9oZC5wbmc?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMxLnpoaW1nLmNvbS84MC92Mi02MWJhOTM0NDZmZThiOGM2NGQzOWNmMzM0ZDE2OTFlMF9oZC5qcGc?x-oss-process=image/format,png
[SourceBuffer]: https://link.zhihu.com/?target=https%3A//developer.mozilla.org/en-US/docs/Web/API/SourceBuffer
[MPEG-DASH]: https://link.zhihu.com/?target=https%3A//msdn.microsoft.com/zh-cn/library/windows/apps/dn551368.aspx
[canPlayType]: https://link.zhihu.com/?target=http%3A//www.w3school.com.cn/tags/av_met_canplaytype.asp
[mp4file]: https://link.zhihu.com/?target=http%3A//code.google.com/p/mp4v2/
[Link 1]: https://link.zhihu.com/?target=http%3A//www.mp4ra.org/object.html
[Link 2]: https://link.zhihu.com/?target=https%3A//en.wikipedia.org/wiki/MPEG-4_Part_3%23MPEG-4_Audio_Object_Types
[The _Codecs_ and _Profiles_ Parameters for _Bucket_ Media Types]: https://link.zhihu.com/?target=https%3A//tools.ietf.org/html/rfc6381
[FFMPEG]: https://link.zhihu.com/?target=http%3A//ffmpeg.org/
[HandBrake]: https://link.zhihu.com/?target=https%3A//handbrake.fr/
[Link 3]: https://www.zhihu.com/topic/19550901
[Link 4]: https://www.zhihu.com/topic/19553460