作者：京东科技吴磊

音视频基本概念

视频格局便是通常所说的.mp4,.flv,.ogv,.webm等。简略来说，它其实便是一个盒子，用来将实际的视频流以必定的顺序放入，确保播映的有序和完整性。

视频紧缩格局和视频格局详细的差异便是，它是将原始的视频码流变为可用的数字编码。因为，原始的视频流十分大，打个比便利是，你直接运用手机录音，你会发现你几分钟的音频会比市面上呈现的 MP3 音频巨细大许多，这便是紧缩格局起的首要作用。

首要，由原始数码设备供给相关的数字信号流，然后经由视频紧缩算法，大幅度的削减流的巨细，然后交给视频盒子，打上相应的dts，pts字段，最终生成可用的视频文件。

DTS（Decoding Time Stamp）：即解码时刻戳，这个时刻戳的含义在于告诉播映器该在什么时候解码这一帧的数据。

PTS（Presentation Time Stamp）：即显示时刻戳，这个时刻戳用来告诉播映器该在什么时候显示这一帧的数据。

视频编码

视频实际上便是一帧一帧的图片，拼接起来进行播映罢了。而图片自身也能够进行相关的紧缩，比方去除重复像素，兼并像素块等等。不过，还有别的一种紧缩办法便是，运动估计和运动补偿紧缩，因为相邻图片必定会有一大块是相似的，所以，为了处理这个问题，能够在不同图片之间进行去重。

所以，总的来说，常用的编码办法分为三种：

改换编码：消除图像的帧内冗余

运动估计和运动补偿：消除帧间冗余

熵编码：提高紧缩功率

熵编码即编码过程中按熵原理不丢失任何信息的编码。信息熵为信源的均匀信息量（不确定性的度量）。常见的熵编码有：香农(Shannon)编码、哈夫曼(Huffman)编码和算术编码(arithmetic coding)。

直播

现在，常用的直播协议有 RTMP，HLS，HTTP-FLV。最常用的仍是 HLS 协议，因为支撑度高，技能简略，但是推迟十分严重。这对一些对实时性比较高的场景，比方运动赛事直播来说十分的不友好。这儿来细分的看一下每个协议。

协议对比

协议	优势	劣势	延时
HLS	支撑性广	延时巨高	10s 以上
RTMP	延时性好，灵活	量大的话，负载较高	1s 以上
HTTP-FLV	延时性好，游戏直播常用	只能在手机 APP 播映	2s 以上

HLS

HLS 全称是 HTTP Live Streaming。这是Apple提出的直播流协议。

HLS 由两部分构成，一个是.m3u8文件，一个是.ts视频文件（TS 是视频文件格局的一种）。整个过程是，浏览器会首要去恳求.m3u8的索引文件，然后解析m3u8，找出对应的.ts文件链接，并开始下载。

他的运用办法为：

<video>
    <source src="http://..../xxxx.m3u8" type="application/x-mpegURL" /> 
</video>

直接能够将m3u8写进src中，然后交由浏览器自己去解析。当然也能够采取fetch来手动解析并获取相关文件。HLS 详细版的内容比上面的简版多了一个playlist，也能够叫做master。在master中，会依据网络段完结设置好不同的 m3u8 文件，比方，3G/4G/wifi 网速等。比方，一个 master 文件中为：

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2855600,CODECS="avc1.4d001f,mp4a.40.2",RESOLUTION=960x540
live/medium.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=5605600,CODECS="avc1.640028,mp4a.40.2",RESOLUTION=1280x720
live/high.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1755600,CODECS="avc1.42001f,mp4a.40.2",RESOLUTION=640x360
live/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=545600,CODECS="avc1.42001e,mp4a.40.2",RESOLUTION=416x234
live/cellular.m3u8

我们只要关注BANDWIDTH（带宽）字段，其他的看一下字段内容大致就清楚了。假如这儿选择high.m3u8文件，那么，里边内容为：

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:26
#EXTINF:9.901,
http://media.example.com/wifi/segment26.ts
#EXTINF:9.901,
http://media.example.com/wifi/segment27.ts
#EXTINF:9.501,
http://media.example.com/wifi/segment28.ts

注意，其间以ts结束的链接便是在直播中真实需求播映的视频文件。该第二级的m3u8文件也能够叫做media文件。该文件，其实有三种类型：

live playlist: 动态列表。顾名思义，该列表是动态变化的，里边的 ts 文件会实时更新，并且过期的 ts 索引会被删除。默认，情况下都是运用动态列表。

event playlist: 静态列表。它和动态列表首要差异便是，原来的 ts 文件索引不会被删除，该列表是不断更新，并且文件巨细会逐步增大。它会在文件中，直接增加 #EXT-X-PLAYLIST-TYPE:EVENT 作为标识。

VOD playlist: 全量列表。它便是将一切的 ts 文件都列在 list 当中。假如，运用该列表，就和播映一整个视频没有啥差异了。它是运用 #EXT-X-ENDLIST 表明文件结束。

developer.apple.com/library/arc…

HLS 缺点

HLS 缺点便是推迟性太大了。HLS 中的延时包含：

TCP 握手

m3u8 文件下载

m3u8 文件下一切 ts 文件下载

这儿先假定每个 ts 文件播映时长为 5s，每个 m3u8 最多可带着的 ts 文件数为 3~8。那么最大的推迟则为 40s。注意，只有当一个m3u8文件下一切的 ts 文件下载完后，才能开始播映。这儿还不包含 TCP 握手，DNS 解析，m3u8 文件下载。所以，HLS 总的延时是十分令人失望的。

那处理办法有吗？有，很简略，要么削减每个 ts 文件播映时长，要么削减m3u8的中包含 ts 的数量。假如超过平衡点，那么每次恳求新的 m3u8 文件时，都会加上必定的延时，所以，这儿需求依据业务指定合适的战略。

RTMP

RTMP 全称为：Real-Time Messaging Protocol。它是基于FLV格局进行开发的，所以，榜首反应便是，又不能用了！！！

是的，在现在设备中，因为 FLV 的不支撑，基本上 RTMP 协议在 Web 中，根本用不到。不过，因为MSE（MediaSource Extensions）的呈现，在 Web 上直接接入 RTMP 也不是不可能的。基本思路是依据 WebSocket 直接建立长衔接进行数据的沟通和监听。RTMP 协议依据不同的套层，也能够分为：

纯 RTMP: 直接经过 TCP 衔接，端口为 1935

RTMPS: RTMP + TLS/SSL，用于安全性的沟通。

RTMPE: RTMP + encryption。在 RTMP 原始协议上运用，Adobe 自身的加密办法

RTMPT: RTMP + HTTP。运用 HTTP 的办法来包裹 RTMP 流，推迟性比较大。

RTMFP: RMPT + UDP。该协议常常用于 P2P 的场景中，针对延时有反常的要求。

RTMP 内部是借由 TCP 长衔接协议传输相关数据，所以，它的延时性十分低。并且，该协议灵活性十分好（所以，也很复杂），它能够依据 message stream ID 传输数据，也能够依据 chunk stream ID 传递数据。两者都能够起到流的划分作用。流的内容也首要分为：视频，音频，相关协议包等。

HTTP-FLV

该协议和 RTMP 比起来其实差别不大，仅仅落地部分有些不同：

RTMP 是直接将流的传输架在 RTMP 协议之上，而 HTTP-FLV 是在 RTMP 和客户端之间套了一层转码的过程，因为，每个 FLV 文件是经过 HTTP 的办法获取的，所以，它经过抓包得出的协议头需求运用chunked编码。

Content-Type:video/x-flv
Expires:Fri, 10 Feb 2017 05:24:03 GMT
Pragma:no-cache
Transfer-Encoding:chunked

它用起来比较便利，不过后端完结的难度和直接运用 RTMP 来说仍是比较大的。

前端音视频流

因为各大浏览器的对 FLV 的围追堵截，导致 FLV 在浏览器的生计情况堪忧，但是，FLV 凭借其格局简略，处理功率高的特点，使各大视频后台的开发者都舍不得弃用，假如一旦更改的话，就需求对现有视频进行转码，比方变为 MP4，这样不仅在播映，并且在流处理来说都有点重的让人无法接受。而 MSE 的呈现，彻底处理了这个尴尬点，能够让前端能够自定义来完结一个 Web 播映器，确实完美。（不过，苹果觉得没这必要，所以，在 IOS 上无法完结。）

MSE

MSE 全称便是Media Source Extensions。它是一套处理视频流技能的简称，里边包含了一系列 API：Media Source，Source Buffer等。在没有 MSE 呈现之前，前端对 video 的操作，仅仅约束在对视频文件的操作，而并不能对视频流做任何相关的操作。现在 MSE 供给了一系列的接口，使开发者能够直接供给 media stream。

来看一下 MSE 是如何完结基本流的处理的。

var vidElement = document.querySelector('video');
if (window.MediaSource) {
  var mediaSource = new MediaSource();
  vidElement.src = URL.createObjectURL(mediaSource);
  mediaSource.addEventListener('sourceopen', sourceOpen);
} else {
  console.log("The Media Source Extensions API is not supported.")
}
function sourceOpen(e) {
  URL.revokeObjectURL(vidElement.src);
  var mime = 'video/webm; codecs="opus, vp9"';
  var mediaSource = e.target;
  var sourceBuffer = mediaSource.addSourceBuffer(mime);
  var videoUrl = 'droid.webm';
  fetch(videoUrl)
    .then(function(response) {
      return response.arrayBuffer();
    })
    .then(function(arrayBuffer) {
      sourceBuffer.addEventListener('updateend', function(e) {
        if (!sourceBuffer.updating && mediaSource.readyState === 'open') {
          mediaSource.endOfStream();
        }
      });
      sourceBuffer.appendBuffer(arrayBuffer);
    });
}

上面这个比方能够简略理解为：

榜首步，经过异步拉取数据。

第二步，经过 MediaSource 处理数据。

第三步，将数据流交给 audio/video 标签进行播映。

而中心传递的数据都是经过Buffer的形式来进行传递的。

中心有个需求注意的点，MS 的实例经过URL.createObjectURL()创立的 url 并不会同步衔接到 video.src。换句话说，URL.createObjectURL()仅仅将底层的流（MS）和 video.src 衔接中心者，一旦两者衔接到一同之后，该目标就没用了。

MediaSource

MediaSource 是 Media Source Extensions API 表明媒体资源 HTMLMediaElement 目标的接口。MediaSource 目标能够附着在 HTMLMediaElement 在客户端进行播映。

MS(MediaSource) 仅仅一系列视频流的管理工具，它能够将音视频流完整的暴露给 Web 开发者来进行相关的操作和处理。所以，它自身不会形成过度的复杂性。

MS 整个只挂载了 4 个特点，3 个办法和 1 个静态测验办法。

4 个特点：

sourceBuffers: 取得当时创立出来的 SourceBuffer

activeSourceBuffers: 取得当时正处于激活状态的 SourceBuffer

readyState: 回来当时 MS 的状态，比方:closed,open,ended.

duration: 设置当时 MS 的播映时长。

3 个办法：

addSourceBuffer(): 依据给定的 MIME 创立指定类型的 SourceBuffer

removeSourceBuffer(): 将 MS 上指定的 SourceBuffer 移除。

endOfStream(): 直接终止该流

1 个静态测验办法：

isTypeSupported(): 首要用来判断指定的音频的 MIME 是否支撑。

最基本的便是运用addSourceBuffer该办法来取得指定的 SourceBuffer。

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

材料：developer.mozilla.org/zh-CN/docs/…

SourceBuffer

SourceBuffer 接口表明经过 MediaSource 目标传递到 HTMLMediaElement 并播映的媒体分块。它能够由一个或许多个媒体片段组成。

一旦使用 MS 创立好 SourceBuffer 之后，后续的作业便是将额外取得的流放进 Buffer 里边进行播映即可。所以，SourceBuffer 供给两个最基本的操作appendBuffer，remove。之后，就能够经过appendBuffer直接将 ArrayBuffer 放进去即可。

其间，SourceBuffer 还供给了一个应急的办法abort()假如该流发生问题的话能够直接将指定的流给废弃掉。

音视频的 ArrayBuffer 经过 MediaSource 和 SourceBuffer 的处理直接将<audio>&&<video>接入。然后，就能够完结正常播映的作用。

材料：developer.mozilla.org/zh-CN/docs/…

基于flv.js完结H5直播

flv.js 简介

flv.js是来自Bilibli的开源项目。它解析FLV文件传给原生HTML5 Video标签播映音视频数据，使浏览器在不凭借Flash的情况下播映FLV成为可能。

flv.js 优势

因为浏览器对原生Video标签采用了硬件加速，性能很好，支撑高清。

同时支撑录播和直播

去掉对Flash的依靠

flv.js 约束

FLV里所包含的视频编码有必要是H.264，音频编码有必要是AAC或MP3， IE11和Edge浏览器不支撑MP3音频编码，所以FLV里采用的编码最好是H.264+AAC，这个让音视频服务兼容不是问题。

关于录播，依靠原生HTML5 Video标签和 Media Source Extensions API

关于直播，依靠录播所需求的播映技能，同时依靠 HTTP FLV 或许 WebSocket 中的一种协议来传输FLV。其间HTTP FLV需经过流式IO去拉取数据，支撑流式IO的有fetch或许stream

因为依靠Media Source Extensions，现在一切iOS和Android4.4.4以下里的浏览器都不支撑，也便是说现在关于移动端flv.js是有约束性的。

flv.js 原理

flv.js只做了一件事，在获取到FLV格局的音视频数据后经过原生的JS去解码FLV数据，再经过Media Source Extensions API 传递给原生HTML5 Video标签。(HTML5 原生仅支撑播映 mp4/webm 格局，不支撑 FLV)

vue + flv.js

//下载flv.js包
npm i flv.js -S
//引入flv.js包
import flv from 'flv.js'
//HTML部分
<video ref="myVideo" autoplay muted controls/>
//script部分
//创立一个Player实例，它接收一个MediaDataSource(必选), 一个Config(可选) flvjs.createPlayer(mediaDataSource: MediaDataSource, config?: Config)
export default {
    data() {
        return {
            player: null,
        }
    },
    created() {
        if (flv.isSupported()) {
            this.player = flv.createPlayer({
                    type: 'flv',
                    isLive: true,
                    url: 'https://api.tjdataspace.com/flv.flv'
                }, {
                    enableWorker: true,
                    enableStashBuffer: false,
                    stashInitialSize: 128,
                }
            );
        }
    },
    mounted() {
        this.player.attachMediaElement(this.$refs.myVideo);
        this.player.load();
        this.player.play();
        setInterval(() => {
            if (!this.player.buffered.length) {return;}
            let end = this.player.buffered.end(0);
            let diff = end - this.player.currentTime;
            if (diff >= 1.5) { //延时假如大于1.5秒，就让直播跳到当时时刻位置播映
                this.player.currentTime = end - 0.5;
            }
        }, 3 * 60 * 1000);
    },
}

flv.js材料：www.npmjs.com/package/flv…

参考材料：

segmentfault.com/a/119000000…

segmentfault.com/a/119000001…

blog.csdn.net/An109023978…

zhuanlan.zhihu.com/p/47773064

/post/690054…

H5直播技术起航

作者：京东科技吴磊

音视频基本概念

视频编码

直播

协议对比

HLS

HLS 缺点

RTMP

HTTP-FLV

前端音视频流

MSE

MediaSource

SourceBuffer

基于flv.js完结H5直播

flv.js 简介

flv.js 优势

flv.js 约束

flv.js 原理

vue + flv.js

作者信息

H5直播技术起航

作者：京东科技 吴磊

音视频基本概念

视频编码

直播

协议对比

HLS

HLS 缺点

RTMP

HTTP-FLV

前端音视频流

MSE

MediaSource

SourceBuffer

基于flv.js完结H5直播

flv.js 简介

flv.js 优势

flv.js 约束

flv.js 原理

vue + flv.js

相关文章

【PyTorch深度学习项目实战100例】—— Python+OpenCV+MediaPipe手势识别系统 | 第2例

安卓navigation系列——入门篇

掘金日新计划 ｜ 12月更文挑战来袭，开启掘金成长之旅

Android 应用程序的启动流程

作者信息

作者：京东科技吴磊

掘金日新计划｜ 12月更文挑战来袭，开启掘金成长之旅