大前端，这个词语大家并不陌生，这两年来的热词，对于前端来说，如果自己不是大前端，已经相对来说技术上落后，如果还停留在ES6、Vue这些基本的技能学习，只能说处于一个及格线，如果想做的卓越，必须具备另一种大前端技能，比如：
- 服务类 Node.js、express.js、koa.js
- 3d数据图像 three.js
- 二位图像 d3.js、rephael.js、echart.js
- 视频 video.js、hls.js、flv.js
也就是说对于一个大前端来讲，如果只会ES6、Vue这些基本技能，只能算一个知识面比较窄的前端，算不上一个大前端，如果想作为一个优秀的前端工程师，要掌握大前端的至少一项目技能，本着这个初衷，我们来学习一下视频领域下面的直播。
直播原理
下图完整的展示了直播的整个流程，从左到右，从采集到中间的处理过程，最后到用户所看到的播放，这块就是整个流程。
采集
大家平时再看斗鱼、yy、熊猫直播等等，通常是在PC端看，或者是移动端看，对于采集来说，其实PC端为主，对于主播来说，他们要保证直播源的质量，通常要买一些直播的设备，比如说，麦克风、高清摄像头等等，这个是能保证一定的分辨率，到达终端的时候会非常清楚，如果你采用手机上面的摄像头，那可能这个分辨率比较低，在手机整个画面也会卡顿等等。
说这么多，虽然我们列了三种采集方式，但是真正的大规模直播，还是以PC端采集为主，总之呢这块是关于摄像头和麦克风视频和音频的收集，记住这个阶段是没有弹幕的，也没有弹幕这回事，这块只是单纯的视频和音频的收集，是已一种流的形式，它需要上传到服务器，也就是中间的几个步骤。
编码
由于原始的流是不能直接让播放器播放，它必须采用一定的协议去编码，后面我们会讲述有多少种协议做直播，总之这块会有视频压缩编码的过程，下面给大家介绍一下视频编码常见的格式
- H.264（视频编码）
- AAC（音频编码）
这块概念大家了解即可，如果大家想详细了解，可以去搜集相关资料
这里给大家提出来是因为这是直播领域最常用的编码形式，直播流播出失败的时候，最容易想到的排查点就是要看下它的编码是不是正确
字幕叠加
编码完成后，会进行一个字幕的叠加，当然这不是一个必经的过程，有可能会叠加字幕可能不会叠加，也可能做一些水印等等，也就是说对视频本身的处理可能会在这个环节做。
推流
推流就是说经过编码和字幕等处理之后，它要把这个东西推送到服务器上去，服务器再推送到CDN上面去
CND
我们最终静态资源，多媒体资源肯定要发布到CDN，来保证用户体验和拉取的速度，CDN就是用户直接访问的直播地址
回放
对于播放来说，又分为三种
- PC回放
- Android回放
- IOS回放
视频格式
下面介绍常见的视频格式，每种格式浏览器支持是不一样的。
mp4
通常见到的格式就是mp4，mp4的好处就是兼容性非常好，各大主流浏览器都识别
webm
webm是一直流式的视频格式，IE、Safari不支持
hls
hls标准的严格意义来说它不是一种视频格式，它是一种视频协议，其实对于格式来说它是ts文件.ts格式，我们为了让大家好清楚名称，我们通常写hls格式，这个种格式只有Safari支持，因为这个协议是苹果自身研发的。
flv
这个大家比较熟悉，B站所有的格式都是flv，flv其实是早期的flash视频格式，B站退出了H5播放器，flash播放器，但是它都能播放flv格式，为什么他们都能播flv格式，这个先给大家留个疑问。
直播协议
- HLS
- RTMP
- HTTP-FLV
HLS
HLS 协议本质还是一个个的 HTTP 请求 / 响应，所以适应性很好，不会受到防火墙影响。但它也有一个致命的弱点：延迟现象非常明显。如果每个 ts 按照 5 秒来切分，一个 m3u8 放 6 个 ts 索引，那么至少就会带来 30 秒的延迟。如果减少每个 ts 的长度，减少 m3u8 中的索引数，延时确实会减少，但会带来更频繁的缓冲，对服务端的请求压力也会成倍增加。所以只能根据实际情况找到一个折中的点。
RTMP
RTMP 基于 flash 无法在 iOS 的浏览器里播放，但是实时性比 HLS 要好。所以一般使用这种协议来上传视频流，也就是视频流推送到服务器。
HTTP-FLV
- 可以在第一定程度上避免防火墙的干扰（列如，有的机房只允许80端口通过）
- 可以很好的兼容HTTP 302 跳转，做到灵活调度
- 可以使用HTTPS做加密同道
- 很好的支持移动端
本文使用 mdnice 排版
