这是我参与「第四届青训营 」笔记创作活动的第6天
该笔记主要是对青训营第五课知识点的简单总结和自己的小思考。

视频的基本元素

像素（点阵图）

由一个数字序列来表示图像中的最小单位
一般用RGB表示（R、G、B各256级，一般用十六进制值来表示）
【音频数据用脉冲编码调制(Pulse Code Modulation,PCM)，与视频数据分开存储，无法进行关联】

分辨率

纵横方向的像素数量

码率/比特率

单位时间内传送bit的数量(单位bps)

---

ffmpeg Tools （视频的开源库）
ffmpeg：视频处理工具（截取视频、格式转换等）
ffplay：视频播放工具
ffprobe：视频分析工具（主要看到视频的流信息）

帧&帧率

每秒传输帧数通俗来说是指动画或视频的画面数（刷新率）

轨道/流

【每种不同的声音和字幕（语言）分为 不同的流】
视频流、音频流数据相互交错排列，形成混流（为了顺序下载，防止卡顿、音画不同步）

视频压缩

颜色空间Chroma

将RGB转化为YUV，方便压缩（Y是亮度Luma，U和V则是色度Chroma）
将更多带宽给黑白信号即亮度，将较少带宽给彩色信号即色度（进行降采样，有损压缩）

压缩：利用视频画面的相关性减少数据量

帧内压缩/空间压缩

当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息（对一帧中类似的像素点进行引用）

帧间压缩/时间压缩

连续帧之间具有很大的相关性，即连续视频其相邻帧之间具有冗余信息

帧的编码类型

I-frame:Intra-frame 帧内帧
P-frame:Predicted Frame 前向预测帧
B-frame:Bi-Directional frame 双向编码帧（需要缓存帧，延时高，RTC场景不适合）
【P-frame（降低帧的大小）参考前面的I-frame（压缩比较小）得到画面的信息,而B帧参考和插入在它之前和之后的帧（两个或更多），显著降低帧的大小，根据先解码I再是P最后是B】
【视频改变播放进度后，如果不在同一个GOP（Group of Pictures）中，需要从新位置所在的GOP的I帧开始解码，拖动后起播所需的耗时取决于位置在GOP中的位置，越靠前越能更快响应，应对策略：有可能从改组GOP的I帧位置开始播放】
视频点播：节省带宽，高压缩率，会使用B帧
直播：低延迟，不适用B帧
视频编辑：提高响应，个别会使用全I帧

视频编码格式

H264：AVC 广泛普及
H265：HEVC 逐渐推广
H266：VVC 未来可期
其他
Google：VP9
Netflix：AV1
压缩比越高的编码算法需要越高的算例来支撑

直播推拉流协议

封装格式

MP4：
结构化，在文件头或尾有一个表结构Moov：Movie Box，来存储mp4的metadata，包含了很多信息和数据
【而起播时为了追求秒播率需要加载更多的信息，不利于直播】
FLV：
FLV采用链式结构，由文件头和很多tag组成，tag又可以分为三类：audio（音频流）,video（视频流）,script（脚本流：关键字或文件信息之类）
【FLV缺乏头信息，有时没有办法进行拖拽】

CDN： 通过多级分发，在最近的边缘节点进行播放

点播：视频播放
直播看播：观众观看直播
推流：主播将数据发送到CDN网络
拉流：观众从CDN拉取直播数据
【互动性较强的直播利用WebRTC技术进行低延迟直播】

推拉流协议方案：

【常见方案：主播通过RTMP协议转发到边缘节点，边缘节点在通过CDN节点转发扩散，而观众通过FLV拉取数据】
RTMP：Real-Time Messaging Protocol
优势：
基于tcp协议（不用去考虑数据丢包等问题）
技术成熟、ffmpeg项目中有RTMP库
低延迟
劣势：
停止更新
规范上没有支持H265
使用1935端口，会被防火墙阻碍
HTTP-FLV：HTTP+FLV
协议友好，格式简单、便于分发
不转码的情况下直接转发即可，延迟较低
HLS：HTTP Live Steaming（苹果公司）
把整个流分成一个个小的基于HTTP的文件来下载
.m3u8二级请求后为.ts

客户端工作及总结

开播过程：
图像采集=》图像处理（可选）=》编码+封装=》推流
图像采集：摄像头、屏幕、图像采集卡
图像处理：美颜、绿幕、头饰等

看播过程：
拉流=》解封装+解码=》图像处理（可选）=》渲染
拉流：HLS、HTTP-FLV
解封装+解码：将视频数据解码成RGB图像、硬件解码（有兼容性问题）、软件解码（CPU）
图像处理：超分辨率、美颜
渲染：OpenGL、VULKAN、Native window

【音画同步一般优先保证音频的流畅，再是画面的流畅，因为人类对于声音相较来说比较敏感】