抖音相信大家都听说过，但是知道有 Web 版抖音 的人可能要少一些，和 TikTok一样抖音也有 Web 版本，可以让我们在浏览器中就可以刷短和观看抖音。抖音是如何实现在浏览器中的呢？本篇文章来解析抖音的技术原理。

调试

首先点击 https://live.douyin.com 进入抖音页面。

首先可以发现原来抖音也是使用的xgplayer。另外还可以发现 video 元素的 src 属性是 blob: 开头的地址，和我们平时用 videoblob:开头的，就需要了解接下来介绍的 MSE API。

Media Source Extensions 介绍

Media Source Extensions API（MSE）媒体源扩展 API 提供了实现无插件且基于 Web 的流媒体的功能，不同于简单的使用video 元素，video可以自定义获取流媒体数据并且还可以对数据做一些操作。

MSE 的兼容性如下图所示。

可以发现 MSE 的兼容性还算可以，IE 11 都支持。但是号称现代 IE 的 Safari 浏览器的 iphone 版

MSE API 主要有 MediaSource 和 SourceBuffer 两个对象，MediaSource 表示是一个源，它下有一个或多个 SourceBuffer，SourceBuffer 表示一个源数据，比如一个分为和音频，我们可以创建两个 SourceBuffer

通过上图还可以发现 SourceBuffer 下面还细分了 TrackBuffer，因为你还可以不创建两个 SourceBuffer，只用一个 SourceBuffer

首先我们使用 fetch 或 XHR 去数据，然后做些处理过后，将数据交给MediaSource，通过 video

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

下面来看看使用

const video = document.querySelector(video)const mediaSource = newMediaSource()

mediaSource.addEventListener(sourceopen, ({ target }) => { URL.revokeObjectURL(video.src) const mime = video/webm; codecs=”vorbis, vp8″
const sourceBuffer = target.addSourceBuffer(mime) // target 就是 mediaSourcefetch(/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。每个都与一种内容类型关联，可能是、音频、和音频等。

HTTP-FLV 介绍

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

LV 格式还是很有必要的。

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

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

fetch(./a.flv)
.then((res) => { const reader = res.body.getReader() const pump = async () => { constdata =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 格式的文件构成是比较简单的，整个文件是由一个文件头和一个文件体组成，文件体是由一个个标签组成。

FLV 文件头

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

FLV 文件体

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

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

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

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

FLV 音频标签

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

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

FLV 标签

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

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

CVIDEOPACKET表示 C 数据结构，它的结构如下表所示。

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

FLV 数据标签

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 是文件的大小，单位是字节

FMP4 格式

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 格式转换成 fmp4 格式。根据上面介绍的 flv 文件格式对 flv 进行解析，这个操作一般称为解封装（demux），解析出来音等信息数据后，再封装（remux）成 fmp4

如上图所示，我们需要将 FLV 格式转换成 FMP4 格式，其中的音流是不变的，这个操作也称为转封装。

LV 流的整体流程如下所示。

首先使用 fetch 去拉 flv 流。使用 HTTP/1.1 的 chunked transfer encoding 功能，流式 chunk 片段。使用 FlvDemuxer 流式解封装 flv 流。对流进行修复做音同步。（一些音流可能会有问题）使用 FMP4Remuxer 将流封装成 FMP4 格式。将封装好的 FMP4 片段数据交给 M

上面 FlvDemuxer 和 FMP4Remuxer的代码需要自己根据 flv 和 fmp4 文件格式编写，将 flv 中的每一帧的音频、和元信息都解出来，然后再将它们封装成 fmp4 格式。

总结

相当于了解了所有平台的技术原理。不过各个平台会在 HTTP-FLV 基础上加点自己的东西，例如斗鱼还使用了 P2P 技术来节服务器流量。相比和其他平台用一样方案的抖音，抖音短

作者:羽月

羽月技术

出处

:https://mp.weixin.qq.com/s/6qDBhjHk0ejzAg_kCkDEWw