乐趣区

关于html5:H5直播技术起航

作者:京东科技 吴磊

音视频基本概念

视频格式就是通常所说的 .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 文件。该文件,其实有三种类型:

  1. live playlist: 动静列表。顾名思义,该列表是动态变化的,外面的 ts 文件会实时更新,并且过期的 ts 索引会被删除。默认,状况下都是应用动静列表。

<!—->

  1. event playlist: 动态列表。它和动静列表次要区别就是,原来的 ts 文件索引不会被删除,该列表是不断更新,而且文件大小会逐步增大。它会在文件中,间接增加 #EXT-X-PLAYLIST-TYPE:EVENT 作为标识。

<!—->

  1. VOD playlist: 全量列表。它就是将所有的 ts 文件都列在 list 当中。如果,应用该列表,就和播放一整个视频没有啥区别了。它是应用 #EXT-X-ENDLIST 示意文件结尾。

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

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 SourceSource 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"');

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

SourceBuffer

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

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

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

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

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

基于 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 材料:https://www.npmjs.com/package…

参考资料:

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

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

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

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

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

退出移动版