音视频小白系统入门课-4
本系列笔记为博主学习李超老师课程的课堂笔记，仅供参阅
往期课程笔记传送门：
- 音视频小白系统入门笔记-0
- 音视频小白系统入门笔记-1
- 音视频小白系统入门笔记-2
- 音视频小白系统入门笔记-3
将mp4文件转换为yuv文件
ffmpeg -i demo.mp4 # 输入文件-an # 禁用音频流（audio no）-c:v rawvideo # 视频流用rawvideo处理（非编码）-pix_fmt yuv420p # 指定输出像素格式为YUV420平面demo.yuv # 输出原始YUV数据文件
rawvideo是一个伪编码器，仅仅进行数据格式转换，不进行有损编码
yuv数据仅仅存储视频，不存储音频
ffplay -f rawvideo -video_size 640x360 # 分辨率需要根据视频内容手动指定-pixel_format yuv420p -framerate 24 # -vf extractplanes=y # 简单滤波demo.yuv #播放yuv数据
yuv没有元信息，需要手动指定分辨率等信息
ffmpeg支持filter_complex复杂滤波
ffmpeg -i demo.mp4 -c:v rawvideo # 输出yuv格式时默认rawvideo-filter_complex "extractplanes=y+u+v[y][u][v]" -map '[y]' y.yuv -map '[u]' u.yuv -map '[v]' v.yuv# 播放
ffplay -f rawvideo -video_size 640x360 -pixel_format gray -framerate 24 y.yuv
ffplay -f rawvideo -video_size 320x180 -pixel_format gray -framerate 24 u.yuv
yuv格式：https://fourcc.org/yuv.php
H264视频编码
yuv420 640x480 15 → 52Mbps
H264建议码流：500kbps，压缩比1/100
码流推荐表：https://blog.csdn.net/huapeng_guo/article/details/132625661
交互通讯码流较低，需要时延较低；直播通讯码流较高，因为用户不和主播直接交换
GOP
Group of Picture 一组帧
GOP中帧的差距较小
- 低码率环境：减少I帧频率（延长GOP）以节省带宽，但可能降低随机访问能力。
- 高动态内容：频繁插入I帧（如GOP=15）以应对快速运动，但会增加文件体积。
I/P/B帧
I帧（Interframe frame）：关键帧，采用帧内压缩技术，不依赖其他帧。
- 例如IDR帧（Instantaneous Decoding Refresh Frame）瞬时解码刷新帧，清空IDR帧之前的所有数据，后面的数据不会依赖IDR帧之前的数据。每当遇到IDR帧，解码器会清空解码器参考buffer中的内容
- 每个GOP中的第一帧是IDR帧
- 可以防止错误传播
P帧（forward Predicted frame）：向前参考帧。压缩时只参考前面已经处理的帧，采用帧间压缩技术。约占I帧的 1/2 大小
B帧（Bidirectionally predicted frame）：双向参考帧。压缩时，既参考前面已经处理的帧，也参考后面的帧，帧间压缩技术。它约占I帧 1/4 大小。提高B帧的数量可以提高压缩比，但是会提高编解码的耗时。实时通讯中B帧不能太多，云服务中可以很多。
解码顺序：I帧是帧内压缩，不参考其他帧 → P帧依赖前面紧邻的I帧 → B帧依赖前面和后面的I/P帧
播放顺序：I → B → P → B → …
SPS （Sequence Parameter Set）序列参数集：位于GOP的头部（IDR帧之前），表征GOP中每一帧的序列特性
seq_parameter_set_id- 帧数
- POC（picture order count）的约束
- 参考帧数目
- 解码图像尺寸
- 帧长编码模式选择标识等
PPS（Picture Parameter Set）图像参数集：位于GOP的头部（IDR帧之前），表征GOP中每一帧的图片特性
pic_parameter_set_id- 熵编码模式选择标识（无损压缩）
- 片组数目
- 初始量化参数
- 去方块滤波洗漱调整标识等
H264压缩技术
帧内压缩：解决空（间）域数据冗余问题
帧间压缩：解决时（间）域数据冗余问题
整数离散余弦变换（DCT），将空间上的相关性变为频域上无关的数据然后进行量化
CABAC压缩（老）
有损压缩
- 帧内：DCT/整数DCT + 量化 + 熵编码（解决空间冗余）。
- 帧间：运动估计 + 残差变换/量化（解决时间冗余）。
无损压缩
- 预测编码：如DPCM、线性预测（FLAC）。
- 熵编码：如霍夫曼、算术编码（CABAC压缩）、LZ77（ZIP/PNG）、VLC压缩
宏块
宏块是视频压缩操作的基本单元
H.265/HEVC：用编码树单元（CTU）替代宏块，支持更大块（如64×64）和更灵活的划分
16x16 8x16 16x8 8x8
宏块大 → 运动预测和数据头开销减少 → 压缩比提升，但细节丢失风险增加
宏块小 → 运动预测更精确且残差数据更少 → 细节保留更好，但压缩比可能降低（因运动向量增多）
帧内压缩
针对I帧
理论基础：
- 相邻像素差别不大，所以可以进行宏块预测
- 人眼对亮度的敏感度超过色度
- YUV很容易将亮度和色度分开
帧内预测：H264 9种模式，将亮度块和色度块分开预测
预测模式信息+残差值压缩
帧间压缩
运动估计：宏块匹配 → 运动矢量
运动补偿：残差值 Residual
宏块匹配算法：
- 三步搜索、四步搜索
- 二维对数搜索
- 钻石搜索
花屏：部分帧丢失
卡顿：当有帧丢失时，丢失GOP内所有帧，显示前一个I帧，直到下一个IDR帧
H264标准支持：https://en.wikipedia.org/wiki/Advanced_Video_Coding
H264码流
码流分层
-
NAL层：Netword Abstraction Layer，视频数据网络抽象层。
NAL层是视频编码与网络传输之间的适配层，即使底层用TCP，仍需NAL解决视频特有的问题（如帧划分、参数集管理）。而在UDP场景下，NAL层的设计更是不可或缺。
VLC层：Video Coding Layer，视频数据编码层
一般情况下：一个slice对应一个图像
SODB（String of Data Bits）：原始数据比特流，二进制数据，不一定是8的倍数，由VCL层产生的，需要补齐。
RBSP（Raw Byte Sequence Payload）
补齐为8的倍数，补1和多个0
NALU
NAL Header(1 Byte) + RBSP
/
Annexb格式：用于本地文件存储
RTP格式：用于直播推流
