H5直播入门(理论篇)

17,161 阅读10分钟

前言

这篇总结其实是去年公司每周技术分享会轮到我的时候写的。那时候公司正在大刀阔斧地准备直播业务,私以为主管会委以重任,就翻了不少论坛,做了一次简单的技术分享。后来直播业务让另一位同事承担了,自己也就没了实践直播的机会,有点可惜吧。好了,废话不多说,开始我们的理论篇~

技术背景

可以看到,直播从 PC 到一直发展到移动端,越来越多的直播类 App 上线,同时移动直播进入了前所未有的爆发阶段,但是对于大多数移动直播来说,还是要以 Native 客户端实现为主,但是 H5 在移动直播端也承载着不可替代的作用,例如 H5 有着传播快,易发布的优势,同时最为关键的是 H5 同样可以播放直播视频。

2016年是直播元年,一是由于各大宽带提供商顺应民意增宽降价,二是大量资本流进了直播板块,促进了技术的更新迭代。市面上,最常用的是 Apple 推出的 HLS 直播协议(原始支持 H5 播放),当然,还有 RTMP、HTTP-FLV、RTP等。

视频文件格式和直播协议

视频文件格式

视频文件格式实际上,我们常常称作为容器格式,也就是,我们一般生活中最经常谈到的格式,flv,mp4,ogg 格式等。它就可以理解为将比特流按照一定顺序放进特定的盒子里。那选用不同格式来装视频有什么问题吗?

答案是,没有任何问题,但是你需要知道如何将该盒子解开,并且能够找到对应的解码器进行解码。那如果按照这样看的话,对于这些 mp4,ogv,webm等等视频格式,只要我有这些对应的解码器以及播放器,那么就没有任何问题。那么将视频比特流放进一个盒子里面,如果其中某一段出现问题,那么最终生成的文件实际上是不可用的,因为这个盒子本身就是有问题的。

不过,上面有一个误解的地方在于,我只是将视频理解为一个静态的流。试想一下,如果一个视频需要持续不断的播放,例如,直播,现场播报等。这里,我们就拿 TS/PS 流来进行讲解。

  • PS(Program Stream): 静态文件流

  • TS(Transport Stream): 动态文件流

针对于上面两种容器格式,实际上是对一个视频比特流做了不一样的处理。

  • PS: 将完成视频比特流放到一个盒子里,生成固定的文件
  • TS: 将接受到的视频,分成不同的盒子里。最终生成带有多个盒子的文件。

那么结果就是,如果一个或多个盒子出现损坏,PS 格式无法观看,而 TS 只是会出现跳帧或者马赛克效应。两者具体的区别就是:对于视频的容错率越高,则会选用 TS,对视频容错率越低,则会选用 PS。

直播协议HLS

HTTP Live Streaming(简称 HLS)是一个基于 HTTP 的视频流协议。这是 Apple 提出的直播流协议。目前,IOS 和 高版本 Android 都支持 HLS。那什么是 HLS 呢?HLS 主要的两块内容是 .m3u8 文件和 .ts 播放文件。

HLS 协议基于 HTTP,而一个提供 HLS 的服务器需要做两件事:

编码:以 H.263 格式对图像进行编码,以 MP3 或者 HE-AAC 对声音进行编码,最终打包到 MPEG-2 TS(Transport Stream)容器之中;

分割:把编码好的 TS 文件等长切分成后缀为 ts 的小文件,并生成一个 .m3u8 的纯文本索引文件;

浏览器使用的是 m3u8 文件。m3u8 跟音频列表格式 m3u 很像,可以简单的认为 m3u8 就是包含多个 ts 文件的播放列表。播放器按顺序逐个播放,全部放完再请求一下 m3u8 文件,获得包含最新 ts 文件的播放列表继续播,周而复始。整个直播过程就是依靠一个不断更新的 m3u8 和一堆小的 ts 文件组成,m3u8 必须动态更新,ts 可以走 CDN。

这里,我们着重介绍一下客户端的过程。首先,直播之所以是直播,在于它的内容是实时更新的。那 HLS 是怎么完成呢?

我们使用 HLS 直接就用一个 video 进行包括即可:

<video autoplay controls>
    <source src="xxx.m3u8" type="application/vnd.apple.mpegurl" />
    <p class="warning">Your browser doesn't support video</p>
</video>

根据上面的描述,它实际上就是去请求一个 .m3u8 的索引文件。该文件包含了对 .ts 文件的相关描述,例如:

不过,这只是一个非常简单,不涉及任何功能的直播流。实际上,HLS 的整个架构,可以分为:
masterplaylist 主要干的事就是根据, 当前用户的带宽,分辨率,解码器等条件决定使用哪一个流。所以,master playlist 是为了更好的用户体验而存在的。

当填写了 master playlist URL,那么用户只会下载一次该 master playlist。接着,播放器根据当前的环境决定使用哪一个 media playlist(就是 子 m3u8 文件)。如果,在播放当中,用户的播放条件发生变化时,播放器也会切换对应的 media playlist。

当然,HLS 支持的功能,并不只是分片播放(专门适用于直播),它还包括其他应有的功能。

  • 使用 HTTPS 加密 ts 文件

  • 快/倒放

  • 广告插入

  • 不同分辨率视频切换

可以看到 HLS 协议本质还是一个个的 HTTP 请求 / 响应,所以适应性很好,不会受到防火墙影响。但它也有一个致命的弱点:延迟现象非常明显。如果每个 ts 按照 5 秒来切分,一个 m3u8 放 6 个 ts 索引,那么至少就会带来 30 秒的延迟。如果减少每个 ts 的长度,减少 m3u8 中的索引数,延时确实会减少,但会带来更频繁的缓冲,对服务端的请求压力也会成倍增加。所以只能根据实际情况找到一个折中的点。

注意:HLS 在 PC 端仅支持safari浏览器,类似chrome浏览器使用HTML5 video标签无法播放 m3u8 格式,可直接采用网上一些比较成熟的方案,如:sewise-player、MediaElement、videojs-contrib-hls、jwplayer。

直播协议RTMP

Real Time Messaging Protocol(简称 RTMP)是 Macromedia 开发的一套视频直播协议,现在属于 Adobe。和 HLS 一样都可以应用于视频直播,区别是 RTMP 基于 flash 无法在 iOS 的浏览器里播放,但是实时性比 HLS 要好。所以一般使用这种协议来上传视频流,也就是视频流推送到服务器。

下面是 HLS 和 RTMP 的对比:

直播协议HTTP-FLV

HTTP-FLV 和 RTMP 类似,都是针对于 FLV 视频格式做的直播分发流。但,两者有着很大的区别。

  • 直接发起长连接,下载对应的 FLV 文件
  • 头部信息简单

现在市面上,比较常用的就是 HTTP-FLV 进行播放。但,由于手机端上不支持,所以,H5 的 HTTP-FLV 也是一个痛点。不过,现在 flv.js 可以帮助高版本的浏览器,通过 mediaSource 来进行解析。HTTP-FLV 的使用方式也很简单。和 HLS 一样,只需要添加一个连接即可:

<object type="application/x-shockwave-flash" src="xxx.flv"></object>

直播基本架构

目前较为成熟的直播产品,大致都是以 Server 端和 H5 和 Native(android,ios)搭配实现直播,基本是下图这个套路:

完整的直播可以分为以下几块:

  • 视频录制端:一般是电脑上的音视频输入设备或者手机端的摄像头或者麦克风,目前以移动端的手机视频为主。

  • 视频播放端:可以是电脑上的播放器,手机端的 Native 播放器,还有就是 H5 的 video 标签等,目前还是已手机端的 Native 播放器为主。

  • 视频服务器端:一般是一台 nginx 服务器,用来接受视频录制端提供的视频源,同时提供给视频播放端流服务。

而现行H5类似直播页面,实现技术难点不大,其可以通过实现方式分为:① 底部视频背景使用video视频标签实现播放 ② 关注、评论模块利用 WebScoket 来实时发送和接收新的消息通过DOM 和 CSS3 实现 ③ 点赞利用 CSS3 动画

对于弹幕来说,要稍微复杂一些,可能需要关注以下几点:

  • 弹幕实时性,可以利用 webscoket 来实时发送和接收新的弹幕并渲染出来。

  • 对于不支持 webscoket 的浏览器来说,只能降级为长轮询或者前端定时器发送请求来获取实时弹幕。

  • 弹幕渲染时的动画和碰撞检测(即弹幕不重叠)等等

H5直播方案

使用flv.js做直播

  • 简介

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

  • 优势

由于浏览器对原生Video标签采用了硬件加速,性能很好,支持高清。同时支持录播和直播。去掉对Flash的依赖。

  • 浏览器依赖

flv.js依赖的浏览器特性兼容列表

1、HTML5 Video

2、Media Source Extensions

3、WebSocket

4、HTTP FLV: fetch 或 stream

  • 原理

flv.js只做了一件事,在获取到FLV格式的音视频数据后通过原生的JS去解码FLV数据,再通过Media Source Extensions API 喂给原生HTML5 Video标签。(HTML5 原生仅支持播放 mp4/webm 格式,不支持 FLV)

flv.js 为什么要绕一圈,从服务器获取FLV再解码转换后再喂给Video标签呢?原因如下:

1、兼容目前的直播方案:目前大多数直播方案的音视频服务都是采用FLV容器格式传输音视频数据。

2、FLV容器格式相比于MP4格式更加简单,解析起来更快更方便。

  • 兼容方案

PC端

1、优先使用 HTTP-FLV,因为它延迟小,性能也不差1080P都很流畅。

2、不支持 flv.js 就使用 Flash播放器播 RTMP 流。Flash兼容性很好,但是性能差默认被很多浏览器禁用。

3、不想用Flash兼容也可以用HLS,但是PC端只有Safari支持HLS

移动端

1、优先使用 HTTP-FLV,因为它延迟小,支持HTTP-FLV的设备性能运行 flv.js 足够了。

2、不支持 flv.js 就使用 HLS,但是 HLS延迟非常大。

3、HLS 也不支持就没法直播了,因为移动端都不支持Flash。

好了,毕竟是入门理论篇,后续如果有业务实践我会更新的,感觉阅读至此,比心~