通过上图还可以发现 SourceBuffer 下面还细分了 TrackBuffer，因为你还可以不创建两个 SourceBuffer，只用一个 SourceBuffer 来播放视频和音频，让它内部自己分离音视频，用不同的解码器进行解码播放。

使用 MSE 播放视频的流程如下图所示。

首先我们使用 fetch 或 XHR 去下载数据，然后做些处理过后，将数据交给 MediaSource，最后通过 video 元素进行播放，

如何将 MediaSource 和 video 元素连接呢？这就需要用到 URL.createObjectURL 它会创建一个 DOMString 表示指定的 File 对象或 Blob（二进制大对象） 对象。这个 URL 的生命周期和创建它的窗口中的 document 绑定。这就是为什么上面调试中的 video 元素的 src 是一个 blob 开头的字符串。

下面来看看使用 MSE 播放视频的最小代码。

const video = document.querySelector('video')const mediaSource = new MediaSource() mediaSource.addEventListener('sourceopen', ({ target }) => { URL.revokeObjectURL(video.src) const mime = 'video/webm; codecs="vorbis, vp8"' const sourceBuffer = target.addSourceBuffer(mime) // target 就是 mediaSource fetch('/static/media/flower.webm') .then(response => response.arrayBuffer()) .then(arrayBuffer => { sourceBuffer.addEventListener('updateend', () => { if (!sourceBuffer.updating && target.readyState === 'open') { target.endOfStream() video.play() } }) sourceBuffer.appendBuffer(arrayBuffer) }) }) video.src = URL.createObjectURL(mediaSource)

addSourceBuffer 方法会根据给定的 MIME 类型创建一个新的 SourceBuffer 对象，然后会将它追加到 MediaSource 的 SourceBuffers 列表中。

我们需要传入相关具体的编解码器（codecs）字符串，这里第一个是音频（vorbis），第二个是视频（vp8），两个位置也可以互换，知道了具体的编解码器浏览器就无需下载具体数据就知道当前类型是否支持，如果不支持该方法就会抛出 NotSupportedError 错误。更多关于媒体类型 MIME 编解码器可以参考 RFC 4281。

这里还在一开始就调用了 revokeObjectURL。这并不会破坏任何对象，可以在 MediaSource 连接到 video 后随时调用。它允许浏览器在适当的时候进行垃圾回收。

视频并没有直接推送到 MediaSource 中，而是 SourceBuffer，一个 MeidaSource 中有一个或多个 SourceBuffer。每个都与一种内容类型关联，可能是视频、音频、视频和音频等。

了解了 Web 环境是如何播放流媒体，现在来看看抖音直播是使用的什么流媒体协议吧。打开开发者工具的网络面板，如下图所示。

可以发现抖音直播使用的是 HTTP-FLV 协议，其实不看也知道抖音使用的是 HTTP-FLV，因为国内直播平台全部都使用 HTTP-FLV！所以国内直播基础建设对 HTTP-FLV 支持比较好。但是在国外 HTTP-FLV 几乎没有人用，国外用的最多的是 HLS 和 DASH 协议。

FLV（全称 Flash Video）是一种流媒体格式，由 Adobe 公司开发，并在 2003 年发布。它的出现有效的解决了视频文件在网络上传播放的问题，在当时它是实际意义的 Web 流媒体标准，非常多的流媒体平台都使用它来播放视频。

但是随着技术的进步， HTML5 的 Video 元素，已经替换 Flash 视频播放，目前 Flash 技术已经被弃用，各大流媒体平台也切换到了 HLS 或 DASH 技术来实现 Web 流媒体播放。虽然 Flash 被弃用，在国外 FLV 也几乎没人使用，但是在国内它并没有被弃用，反而被广泛用于国内直播场景，所以了解 FLV 格式还是很有必要的。

要在 Web 环境拉取 flv 直播流，不能使用 XHR，需要使用 fetch API 去拉流，因为 HTTP-FLV 会用到 HTTP/1.1 的 chunked transfer encoding 功能流式去加载数据，是客户端和服务器建立起一个 HTTP 连接后保持连接不断开，服务器不断发送直播流数据给客户端，类似于 IM 中的长轮询。

下面是使用 fetch 拉流的实例代码。

fetch('./a.flv') .then((res) => { const reader = res.body.getReader() const pump = async () => { const data = await reader.read(); if (!data.done) pump(); } pump() })

可能大家还听过 WS-FLV，这是使用 WebSocket 去拉 FLV 流，相比 HTTP-FLV 没啥优势，所以开始尽可能使用 HTTP-FLV。在我看来 WS-FLV 唯一的作用是兼容 IE 11 浏览器，因为 IE 11 是不支持 fetch 的，并且 IE 自带的 MSStream 又有很多问题，这时候只有用 WebSocket 去拉流。

接下来让我们再更深入了解下 FLV 文件格式，FLV 格式的文件构成是比较简单的，整个文件是由一个文件头和一个文件体组成，文件体是由一个个标签组成。

FLV 文件由 9 个字节的文件头开始，FLV 文件头结构如下表所示。

FLV 文件头之后就是文件体，文件体是由上一个 FLV 标签大小和 FLV 标签循环组成，如下表所示。

需要注意的是，FLV 标签大小是标签它之前的 FLV 标签大小，所以第一个标签大小总是为 0。

一共有 3 种类型的 FLV 标签，FLV 标签如下表所示。

FLV 标签中的数据字段的结构会因为标签的类型不同而不同，音频标签数据字段为 AUDIODATA，视频标签为 VIDEODATA，脚本数据标签为 SCRIPTDATAOBJECT。

音频 FLV 标签数据字段结构如下表所示。

对于常用的 AAC 编码的音频数据，FLV 规范还定义了 AACAUDIODATA 数据结构，如下表所示。

视频 FLV 标签数据字段结构如下表所示。

编码 ID 一般为 7 表示 AVC 编码，官方规范是不支持 HEVC 编码的，但是现在 HEVC 编码越来越流行，所以社区一般把编码 ID 12 定义为 HEVC 编码。

AVCVIDEOPACKET 表示 AVC 视频数据结构，它的结构如下表所示。

关于 AVCDecoderConfigurationRecord 数据结构，请查看 ISO 14496-15 的第 5.2.4.1 章节。

FLV 视频元数据存放在 FLV 数据标签里面，它的结构如下表所示。

SCRIPTDATAOBJECT 描述的是一个对象，它由一个键值对组成，结构如下表所示。

键和值的数据结构如下表所示。

FLV 文件的元信息一般放在 onMetaData 字段中，解析完成 FLV 数据标签后将返回下面这个对象。

interface FLVScriptData { onMetaData?: { duration?: number; width?: number; height?: number; videodatarate?: number; framerate?: number; videocodecid?: number; audiosamplerate?: number; audiosamplesize?: number; stereo?: boolean; audiocodecid?: number; filesize?: number; } }

onMetaData 对象的字段含义如下。

• duration 是视频的总时长，单位是秒。
• width 是视频的宽度，单位是像素。
• height 是视频的高度，单位是像素。
• videodatarate 是视频的码率，单位是 kb 每秒。
• framerate 是视频的帧率。
• videocodecid 是视频的编码 ID，同 FLV 视频标签中的编码 ID。
• audiosamplerate 是音频的采样率。
• audiosamplesize 是音频的位深。
• stereo 表示是否为立体声。
• audiocodecid 是音频的编码 ID，同 FLV 音频标签中的编码 ID。
• filesize 是文件的大小，单位是字节

MP4 格式相信大家都听说过，MP4 或称 MPEG-4 第 14 部分是一种标准的数字多媒体容器格式，它被定义在 ISO 14496-14 中，是由苹果的 QuickTime 视频格式演化而来（也就是我们常见的 .mov 视频格式）。

FMP4 是 fragmented MP4 的缩写，FMP4 更适合流媒体传输，它们的区别如下所示。

这是一个普通的 MP4 文件，可以看到它有一个很大的 mdat （实际电影数据）box，所有视频元信息都存放在 moov 盒子，所有音视频数据都存放在 mdat 盒子，所以 mp4 格式并不适合流媒体传输。

这是 fragmented MP4 的截图，它是由 ISO BMFF 初始化分片（ftyp 后跟单个电影标题盒子 moov），加上一个个 moof 和 mdat 盒子组成的视频分片组成，它的元信息和音视频数据分散到一个个的 moof 和 mdat 盒子中，一次性只加载需要展示的部分，有点类似于前端的瀑布流分页的数据加载。

因为 MP4 格式比 FLV 复杂的多，这里篇幅有限就不再详细介绍了，感兴趣的同学可以去看看 ISO 14496-12。

上面之所以介绍 FMP4 格式是因为 MSE API 并不是所有视频格式都支持（比如上面介绍的 flv，或者普通的 mp4 格式就不会支持）根据浏览器的不同，可能支持的视频格式也不同，但是 FMP4 格式所有的浏览器都支持，更多信息可以查看 ISO BMFF Byte Stream Format。

上面介绍的 FLV、MP4、FMP4、MOV 这些全都是视频封装格式，他们就像一个盒子来存放真正的音视频流数据。

所以要在浏览器中播放 flv 直播流，还需要将 flv 视频格式转换成 fmp4 视频格式。根据上面介绍的 flv 文件格式对 flv 进行解析，这个操作一般称为解封装（demux），解析出来音视频等信息数据后，再封装（remux）成 fmp4 视频格式，最后交给 MSE API 来播放。