闲庭信步聊前端 - 揭开视频直播神秘面纱
共 2256字，需浏览 5分钟
·
2021-01-17 04:34
前话
大家好，从今天开始到12月底，我们开始一个新的系列文章 “闲庭信步聊前端”，希望在这个系列中，大家在前端的领域更有收货，也给自己年底画上一个圆满的句号。感兴趣的小伙伴可以关注下公众号，持续关注~~~
今天给大家介绍一些相关于直播和视频的基础知识。视频的播放对于前端人员来说其实很简单只需要拿到视频的播放地址然后放到 video 标签中就行了，其实我们没有必要去关注视频的编码、解码等过程，但是呢其中的一些术语和小知识还是要了解的。（ 一些东西可能有问题敬请指出和谅解，感谢各位大佬们 ）
视频原型
翻页动画：就是一连串的静态画片，然后钉到一起后手动快速翻页形成类似的视频效果
胶片动画：以前的那种老式胶片，一大块类似于胶卷的东西，体积也挺大的
基础概念
视频编码格式：H.261、H.263、H.264等（通过某种压缩技术将初始的视频格式转换成另一种视频格式） 封装格式：.FLV、.MP4、.AVI等（视频轨和音频轨的结合文件） 帧率：FPS（每秒钟传输的画面数） 字节：byte（计算机的储存单位） 比特：bit（计算机的传输单位） 码率：Kbps（ ps就是/s ）
b：bit（位），B：byte(字节)，1B=8b
码率
码率就是数字信号的传输速率，每秒传送信息，一般用的单位是Kbps即千位每秒。单位内的码率越高，精度就越高就越清晰度就越高但是同样有一个缺点就是码率越高对网速的要求就越高
不同的码率清晰度完全不同：
4000码率：
10000码率：
帧率
以帧为单位的位图图像连续出现形成的画面播放就是帧率，游戏中的FPS也是帧率，越高画面越流畅，如果FPS掉到30以下你就会以为是ppt在慢慢动一般，60帧以上就会明显的提升交互感和逼真感。
说到 60 帧想起了一个方法 requestAnimationFrame(callback)，这个方法是用来实现动画效果的。回调函数执行次数通常是每秒60次，但在大多数遵循W3C建议的浏览器中，回调函数执行次数通常与浏览器屏幕刷新次数相匹配。
那么动画效果如何做到流畅呢，就是达到60帧，动画每 16.67 毫秒刷新一次，然后人眼捕捉到动画后就会感觉东西在流畅的移动，这个时间其实就是 1000/60 = 16.6666666666666... ≈ 16.67。
下面是一个简单的演示效果及代码：
const element = document.getElementById('test');
let start;
function step(timestamp) {
if (start === undefined) {
start = timestamp;
}
const elapsed = timestamp - start;
//这里使用`Math.min()`确保元素刚好停在400px的位置。
element.style.transform = 'translateX(' + Math.min(0.1 * elapsed, 400) + 'px)';
if (elapsed < 4000) { // 在四秒后停止动画
window.requestAnimationFrame(step);
}
}
window.requestAnimationFrame(step);
PS：通过某软件进行的屏幕录制可能是刷新率和录制的原因导致感觉有点卡卡的，动画的实际效果会比 gif 中效果流畅自然，可以自行测试一番。timestamp 是回调函数会被传入 DOMHighResTimeStamp 参数指当前被 requestAnimationFrame() 排序的回调函数被触发的时间。官方提示有一个需要注意的地方，如果要这么用的话请确保总是使用第一个参数(或其它获得当前时间的方法)计算每次调用之间的时间间隔，否则动画在高刷新率的屏幕中会运行得更快。
requestAnimationFrame 的执行执行机制是由系统决定回调函数的来自动计算，不会引起丢帧或者卡顿，比起 setInterval 优势明显。setInterval 任务被放入异步队列，只有当主线程任务执行完后才会执行队列中的任务，因此实际执行时间总是比设定时间要晚；setInterval 的固定时间间隔不一定与屏幕刷新率相同，会引起丢帧。还有一点就是在大多数浏览器里，当 requestAnimationFrame 运行在后台标签页或者隐藏的 iframe 中时，requestAnimationFrame 会被暂停调用以提升性能和电池寿命。
回到正题，那怎么怎么把一幅幅的图像拼接成一个视频呢？这就需要一个东西编码器，它可以将多张图像进行编码后生成很多GOP（Group of Pictures），解码器在播放时就是读取一段一段的GOP进行解码后在进行渲染的，这就是很多播放器在播放本地视频文件时为什么要下载解码器的原因（比如快播、暴风影音、迅雷播放器呀什么的）
GOP：两个 I 帧之间的间隔
I帧、P帧、B帧
视频压缩中每帧代表一副静止图像，而在实际压缩时会采取各种各样的算法去减少数据的体积，其中IPB就是最常见的
I帧：又称关键帧，自带全部信息的独立帧无需参考其他图像便可独立解码，可以理解为一张静态画面 P帧：又称差别帧，参考前面的I帧或者P帧然后缓存画面叠加本帧的差别，生成最终画面 B帧：又称双向差别帧，记录本帧与前后帧的差别，通过前后帧与本帧结合去的最终画面，可以有更高的压缩比并且解码速度增加，可以多线程解码，所以解码更快（压缩比查了一些资料都说不清楚只需要了解就行了，想深究的可以自行研究，ps：研究清楚后请通知一哈）
所以一个GOP中，只有加载出I帧才会渲染出一段视频，这就引申出了一堆问题比如说视频花了一小段啊、刚打开的延迟呀等等。。。
花屏：不是所有的地方都花有些部分是好的，有些部分是有问题的，我们假设这个GOP只有3帧，IPP，如果第一个P帧丢失，那么第二P帧的参考帧就变成了I帧，这样就出现了对硬不上的问题然后这个GOP整个都是花屏，直到加载出下一个GOP（P帧只会参考P帧或者I帧，花屏见下图）
延迟：有的时候打开一个视频或直播时，你会发现不是立马就播放的，因为一个GOP是从I帧开始的，所以你打开时可能正好处于I帧之后的几帧中，所以你要等待直到加载到下一个I帧才能开始播放
直播
直播行业大概是啥时候兴起的呢，我没具体调查，但是在我的印象中最早的是12年时候的yy直播，在我感觉直播行业的兴起时间大概是14年~15年左右，最火的是斗鱼，然后出了虎牙、战旗、龙珠、熊猫、网易CC、企鹅电竞等
然后就是近期发生的大事件的斗鱼和虎牙合并，合并后斗鱼将退市，还有企鹅电竞把用户都统一管理了，只是大概看了下没深入了解有兴趣的同学可以深入了解一下……
轻松时刻
其实中间有一段挺有意思的事情，日本有一个弹幕网站叫做 Niconico，然后中国模仿了一个类似的网站就是最初的 A站（Acfun）。
13年的时候A站推出了一个板块“生放送”，然后14年独立了出去就是斗鱼TV，规模和用户量和盈利都超过的 A站。
再后来！200几年的时候A站内部出了问题，然后A站的一个资深用户建立了一个类似于A站的网站，然后也完全超过了A站，这个就是B站
ps：A站太惨了
直播流程及常用软件
主播：获取流地址 -> 推流 服务端：接流 -> 流处理 -> 分发 用户：拉流 -> 解码 -> 观看 常用软件：OBS和各个直播平台推送的自己封装的直播推流软件（想当主播的同学可以去研究研究OBS哦，很多功能的）
直播流媒体协议
HTTP：点播使用的基本都是HTTP协议，就是各个电视台使用的 RTMP：基于TCP协议，是Flash播放器和服务器之间音频、视频和数据传输的开放协议（主流），使用flash播放可以降低延迟和声音的问题，但是Chrome马上不支持flash，具体还没有去了解（应用PC居多） Hls：基于HTTP的流媒体实时传输协议，服务器把直播数据生成新的一个一个小文件，它将多个小文件下载后按顺序不停的播放，每次下载若干个然后实现的直播（应用H5居多） HTTP-FLV：将音视频数据封装成HLV，然后通过HTTP协议传输给客户端 WebRTC：支持浏览器进行实时语音、视频对话的开源协议，现在Google等公司在推动其成为W3C标准（其实不算协议） UDP：无需建立连接就可以发送封装的IP数据包协议，有的直播平台使用UDP协议作为底层协议开发自己的私有协议，因为在弱网环境下一样有很好的效果，缺点就是对CDN要求很高（知道有但是没深入了解，有兴趣的同学可以去深入研究一下）
播放流地址大致规则
RTMP: rtmp://x/appName/StreamName?鉴权串FLV: http://x/appName/StreamName.flv?鉴权串HLS: http://x/AppName/StreamName.m3u8?鉴权串UDP: artc://x/AppName/StreamName?鉴权串
相关直播协议的内容再此不再赘述，我们大转转公众号之前的文章有详细介绍，大家感兴趣的欢迎点击，请参考 《科普：直播知多少》 这篇文章
结尾
大致就介绍到这里，这篇只是介绍一下基础知识和一些词汇，可能不太准确敬请谅解！后面还有其他的文章深入介绍相关技术，欢迎广大读者关注下公众号，方便大家以后浏览其他技术文章。