关于html5:H5直播技术起航

3次阅读

共计 7843 个字符，预计需要花费 20 分钟才能阅读完成。

作者：京东科技吴磊

视频格式就是通常所说的 .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 全称是 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 示意文件结尾。

https://developer.apple.com/l…

HLS 缺点就是提早性太大了。HLS 中的延时包含：

TCP 握手

<!—->

m3u8 文件下载

<!—->

m3u8 文件下所有 ts 文件下载

这里先假如每个 ts 文件播放时长为 5s，每个 m3u8 最多可携带的 ts 文件数为 3~8。那么最大的提早则为 40s。留神，只有当一个 m3u8 文件下所有的 ts 文件下载完后，能力开始播放。这里还不包含 TCP 握手，DNS 解析，m3u8 文件下载。所以，HLS 总的延时是十分令人失望的。

那解决办法有吗？有，很简略，要么缩小每个 ts 文件播放时长，要么缩小 m3u8 的中蕴含 ts 的数量。如果超过平衡点，那么每次申请新的 m3u8 文件时，都会加上肯定的延时，所以，这里须要依据业务指定适合的策略。

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 传递数据。两者都能够起到流的划分作用。流的内容也次要分为：视频，音频，相干协定包等。

该协定和 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 全称就是 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 是 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"');

材料：https://developer.mozilla.org…

SourceBuffer 接口示意通过 MediaSource 对象传递到 HTMLMediaElement 并播放的媒体分块。它能够由一个或者多个媒体片段组成。

一旦利用 MS 创立好 SourceBuffer 之后，后续的工作就是将额定取得的放逐进 Buffer 外面进行播放即可。所以，SourceBuffer 提供两个最根本的操作 appendBuffer，remove。之后，就能够通过appendBuffer 间接将 ArrayBuffer 放进去即可。

其中，SourceBuffer 还提供了一个应急的办法 abort() 如果该流产生问题的话能够间接将指定的流给废除掉。

音视频的 ArrayBuffer 通过 MediaSource 和 SourceBuffer 的解决间接将 <audio>&&<video> 接入。而后，就能够实现失常播放的成果。

材料：https://developer.mozilla.org…

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

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

<!—->

同时反对录播和直播

<!—->

去掉对 Flash 的依赖

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 数据，再通过 Media Source Extensions API 传递给原生 HTML5 Video 标签。(HTML5 原生仅反对播放 mp4/webm 格局，不反对 FLV)

// 下载 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 材料：https://www.npmjs.com/package…

参考资料：

https://segmentfault.com/a/11…

https://blog.csdn.net/An10902…

https://zhuanlan.zhihu.com/p/…

https://juejin.cn/post/690054…

正文完

html5

发表至： html5

2023-01-11

0

关于html5:Vue3-Teleport-简介请过目这个是真的好用

关于html5:分享web前端学习资源清单持续更新

关于html5:如何在React框架中使用ECharts图库表制图

关于html5:免费视频直播点播H5播放器SkeyeWebPlayer多屏九宫格双击分屏放大缩小拖动拖入分屏播放等功能的使用

关于前端:为什么我对JavaScript的未来持乐观态度

关于html5:H5直播技术起航

作者：京东科技吴磊

音视频基本概念

视频编码

直播

协定比照

HLS

HLS 缺点

RTMP

HTTP-FLV

前端音视频流

MSE

MediaSource

SourceBuffer

基于 flv.js 实现 H5 直播

flv.js 简介

flv.js 劣势

flv.js 限度

flv.js 原理

vue + flv.js

站内搜索

关于html5:H5直播技术起航

作者：京东科技 吴磊

音视频基本概念

视频编码

直播

协定比照

HLS

HLS 缺点

RTMP

HTTP-FLV

前端音视频流

MSE

MediaSource

SourceBuffer

基于 flv.js 实现 H5 直播

flv.js 简介

flv.js 劣势

flv.js 限度

flv.js 原理

vue + flv.js

站内搜索

作者：京东科技吴磊