视频编解码——视频编解码器工作原理做视频这行的人迟早都得面对一个问题为什么一段几秒钟的4K原始视频体积能大到让你硬盘报警为什么同样是1080p有的视频一帧画面模糊得像马赛克拼图有的却锐利到能数清楚树叶的脉络答案都指向同一个东西——视频编解码器。我最早接触这个概念是在转码一个监控视频的时候一个1小时的原始文件占了几十个GB后来用H.264重新编码体积缩到不到原来的十分之一画质肉眼几乎看不出差别。当时我就觉得这事特别神奇后来真正去研究编解码器的工作原理才发现这背后不是黑魔法而是一套非常成熟、环环相扣的信号处理数学体系。这篇文章想把视频编解码器的工作原理拆开讲清楚。不管你是刚入行的音视频开发、做视频剪辑的创作者还是单纯好奇视频为什么能被压这么小都可以跟我把这套逻辑过一遍。我会从最底层的冗余消除讲起讲到帧内预测、帧间预测、变换量化、熵编码再到实际工作中经常调的编码参数和踩过的坑。尽量说人话尽量让每个概念都能落地。1. 视频编解码器到底在解决什么问题1.1 一段原始视频的体积有多离谱先说个最简单的算术题。假设你有一段1080p、30帧/秒、时长1分钟的视频像素格式是常见的YUV420。要算它的原始码率我一般直接用这个公式码率bit/s 分辨率宽度 × 分辨率高度 × 帧率 × 每像素平均比特数这里YUV420每像素平均是12bit也就是1.5字节。所以1920 × 1080 × 30 × 12 746,496,000 bit/s约等于747Mbps。1分钟就是5.6GB左右。如果换成4K分辨率这个数字直接乘4一分钟就是22GB。这就是未压缩的裸视频体积。如果直接这样存储或传输你看一部90分钟的电影需要差不多1TB空间而网络带宽按20Mbps算看一分钟4K视频得缓冲一小时。所以视频编码的本质目的就是把这个天文数字级的原始数据量通过去掉冗余信息压缩到可用的码率同时尽量保住主观画质。1.2 视频里的三类冗余从哪来编解码器能压缩那么多不是靠变魔术而是因为视频里有大量可以去掉的冗余信息。我习惯把它们分成三类来理解第一是空间冗余。看任何一帧画面天空是整片蓝色纯色区域的相邻像素值几乎一模一样。如果逐像素保存等于把同一块蓝色重复存了几十万个副本毫无必要。帧内压缩解决的就是这类冗余。第二是时间冗余。一段人物说话的采访视频背景几乎全程不动面部表情的变化也局限在小区域。如果把每一帧都完整保存等于把同一个背景重复存了几千遍。实际上前后帧之间的差异非常小帧间压缩就是靠这个特点做文章。第三是视觉冗余。人眼对高频细节、色彩差异的敏感度远低于对亮度差异的敏感度人眼的生理结构决定了我们天然能容忍一部分信息丢失。编解码器会利用这个特性把一些肉眼几乎感知不到的高频细节舍弃掉换取大幅压缩。在实际编码时这三种冗余是层层递进处理的。先做空间压缩再做时间压缩最后做感知层面的信息舍弃和熵编码缺一不可。这也是为什么现代视频编码器都有一个类似的分层架构。1.3 编解码器的通用工作框架所有的视频编解码器不管是最老的H.261还是最新的AV1、VVC整体框架都大同小异。核心流程可以概括成一句话对每一帧画面先用预测模型去掉冗余再把预测残差变换到频域通过量化丢弃不重要的信息最后用熵编码把数据压成二进制流。听起来有点抽象我用一个日常的场景类比。把一帧画面想象成一份同事发给你的文档你要转发给另一个人但网络只能传几百个字节。你不会把整份文档原封不动发出去而是会先看这页和上一页改了什么只把改动的语句发过去时间冗余。对于完全没变的部分就直接告诉对方“沿用上一页”。如果页面里有大段纯色背景你会说“左上角到右下角整块全是白色”而不是逐行描述每个像素空间冗余。最后如果有些无关紧要的错别字或者格式瑕疵对方根本不会在意你也就不修了直接略过视觉冗余。视频编码器干的就是这件事只不过它把这个过程做成了高度数学化、可量化的算法。整条流水线里预测是第一步它决定了你能减掉多少冗余变换和量化决定了画质损失控制在哪里熵编码则负责最后的收尾压缩。2. 编解码器最核心的工作原理拆解2.1 帧内预测先猜一遍再只存猜错的部分编码一个I帧关键帧时编码器不能参考任何其他帧只能靠这一帧内部的信息来做压缩。它做的事叫帧内预测。它的思路是这样的把一帧画面切成一个个小块最常见的尺寸是4×4、8×8、16×16现代编解码器比如HEVC和AV1还支持更大的块最大可以到64×64甚至128×128。编码器逐个处理这些块对每一块它会用周围已经编码完成、重建好的相邻像素去“预测”这一块的像素值。比如如果上方和左方的像素都是蓝色那当前块很可能也是蓝色如果上方是天空的渐变蓝色那当前块很可能是天空的延续亮度继续变暗一点。编解码器定义了一整套可选的预测方向——水平、垂直、对角线、DC平均值等H.264里有9种HEVC里有35种VVC里更是扩充到了67种。关键一步在于编码器不是简单地把预测结果存下来而是把原始像素值跟预测值做一个减法得到一个“残差块”。如果预测得准这个残差块里的数值会非常小甚至全接近0。压缩小数值比压缩大数值容易得多残差越接近0后面变换和熵编码的压缩效果就越理想。所以帧内预测的质量直接决定了一个I帧内部压缩效率的上限。编码器通常会把所有可能的预测模式都试一遍然后从中选出率失真代价最小的那一种代价公式大概是失真 λ × 码率失真用SSD或SATD来度量λ则由量化参数控制。模式信息本身也要占码流编码器会在“预测得多准”和“描述这个预测模式要花多少bit”之间做一个权衡。2.2 帧间预测把时空穿越变成日常操作帧间预测是视频压缩最大的功臣尤其是在对话、访谈这类静态场景里。它的原理如果用一句话说就是“这一帧的内容大概率在之前的某帧里出现过只是挪了个位置或者变化了一点点”。编码器处理当前帧时会从前面已经编码的帧里找一个参考帧。然后为当前帧的每个编码块在参考帧里搜索最相似的块找到后算出它从哪里搬过来的存一个运动矢量Motion Vector这两个块之间的像素差就是运动补偿残差。举个例子一个人从左往右走背景不动。编码器发现脸上某一块之前在左边第20个像素的位置出现过于是记下“这个块是从坐标(100, 80)搬到(120, 80)”以及运动补偿后的残差。因为搬过来的块和当前块几乎一模一样残差几乎为0整体码流就被压缩到了一个很小的体积。实际操作中运动搜索是整个编码器最耗算力的部分。在全帧范围内暴力搜索是不现实的所以编码器会用各种快速搜索算法比如三步搜索、菱形搜索、六边形搜索在候选位置附近快速收敛。搜索范围由运动矢量搜索窗口控制窗口越大能处理越剧烈的运动但也越费时间。进一步地现代编码器还引入了一个概念叫多参考帧。编码P帧时不仅可以用前一个I帧或P帧作参考还可以用更早的多个帧。B帧则更夸张它可以同时参考前面和后面的帧。这意味着一个中间帧可以从未来帧里找相似内容。这就带来一个很实际的影响B帧能显著提高压缩率但编码延迟会变大因为它必须等未来帧先编码完才能动手。直播场景对延迟极其敏感所以通常禁用B帧点播和文件存储场景则相反非常喜欢B帧。还有一个细节验证环节是“重建”。解码器看到的画面并不是原始画面而是“原始画面 编码损失”之后的重建画面。为了让编码端的预测参照和解码端保持一致编码器会先完成重建用重建帧作为参考而不是用原始帧。如果这一步偷懒用了原始帧解码端和编码端的参考就不一致误差会一帧一帧累积最后画面花的没法看。这个原因我后面讲花屏问题时会再展开。2.3 变换与量化把能量集中起来再扔掉看不懂的部分预测做完剩下的残差块经过变换编码和量化进一步去掉视觉冗余。这一步的直观理解是把空间域的像素信息转换到频域然后把频域系数中不重要的部分丢弃掉。最经典的变换方式是离散余弦变换DCT。它能把一个N×N的像素块转换成一个同尺寸的频域系数矩阵。在这个矩阵里左上角代表低频分量画面平滑变化的部分右下角代表高频分量细节纹理和锐利边缘。自然图像的残差块经过DCT之后能量会非常集中到低频区域高频系数往往接近0。我举个例子方便理解。把残差块想象成一段音频DCT相当于做频谱分析。你会发现大部分能量集中在少数几个频率上其他频率基本是噪声。接下来量化做的事就是把这些频率的数值除以一个步长再取整。量化步长越大越是高频的系数就越容易被除成0。这就好比你说“那些细节反正人眼也看不清干脆全算成0”大量的系数因此变成了零整体数据量大幅下降。量化是不可逆的。这一步丢掉的细节再也找不回来这也是“有损编码”真正的损失发生点。量化力度由量化参数QP控制H.264里QP典型范围是0到51QP越小量化步长越小画质越好、码率越高QP越大画质越差码率越低。为了让码率控制更平滑现代编码器会在帧内和帧间分配不同的QP。关键帧为了保质量QP通常会稍微低一点B帧因为预测残差本来就很低QP可以放开一些。这类分配策略叫自适应量化AQ它可以根据画面的局部复杂度动态调整QP纹理复杂的区域提高QP平坦区域降低QP。这是一把双刃剑调好了画面观感极佳调激进了一点会出现局部模糊和色块我后面会做一些说明。2.4 熵编码把0和1进一步压缩成更短的0和1量化和变换之后数据里满是0和少量的非零系数。最后一步叫熵编码本质上就是一个无失真的数据压缩。前面所有步骤都是有损的但熵编码是无损的它对输入数据做一个“优化编码”的动作保证解码端能完全还原。最经典的算法是CAVLC基于上下文的自适应可变长编码和CABAC基于上下文的自适应二进制算术编码。H.264里CABAC能比CAVLC多省10%~15%左右的码率代价是运算复杂度更高。HEVC以后CABAC成了主流标配AV1里则发展成了多符号算术编码。熵编码的核心思想可以类比成摩尔斯电码常用的字母用短码表达少用的字母用长码表达。视频编码里经过预测和量化后出现概率最高的事件是“这一块系数全是0”这个事件会用极短的码字表示而那些很少出现的较大非零系数则用较长的码字表示。CABAC更进一步它会根据已经编码过的相邻块的统计特性动态调整概率模型时刻保持最优的编码效率。到这里一帧视频的编码流程就走完了。从原始像素帧开始切割成块做预测得到残差残差做变换和量化得到系数系数做熵编码输出码流。解码过程基本是这套流程的逆操作熵解码得到系数反量化反变换得到残差再加上预测结果得到重建画面画面参考链交给下一个帧使用。3. 编码参数怎么影响体积、画质和延迟3.1 码率控制模式CBR、VBR还是CRF了解核心原理之后所有编码参数就不再是“随便填的数字”了每个参数都在对一条特定的逻辑线做调优。码率控制是所有参数里最影响输出码率曲线的部分。三种常见模式固定码率CBR适合带宽严格受限的场景比如直播、视频会议它的码率恒定但会在画质上有波动遇到复杂画面只能牺牲细节可变码率VBR适合存储和点播它允许码率在一个范围内上下浮动复杂画面分配更多码率简单画面分配更少画质整体更均匀。VBR也分若干档次可以在限制峰值码率的前提下尽量优化画质适合上传平台时控制文件体积和审核要求。CRF恒定质量是我个人最常用的模式。它不直接指定码率而是指定一个质量档位。x264里CRF默认是23数值越小质量越高文件越大18左右可以视为视觉无损28以上画质损失就比较明显了。CRF的底层逻辑是对每一帧算出一个合适的QP让同样质量的帧用差不多的码率来编码整体画面观感稳定。对于想要在“画质可控”和“文件不太大”之间找一个平衡的需求CRF几乎是最省心的选择。还有一个环节叫VBV缓冲区设置配合CBR和VBR用。编码器的输出速率不是恒定平稳的它需要先发数据填满一个缓冲区再平滑地发出去。缓冲区大小用--vbv-maxrate和--vbv-bufsize指定决定了码率波动的耐受程度。直播场景缓冲设小了容易瞬时爆码率设大了延迟变高这个平衡实际调试时很容易让人挠头。3.2 GOP结构I帧、P帧、B帧怎么排布GOPGroup of Pictures画面组是指两个I帧之间的一组帧。GOP长度越长I帧出现频率越低压缩率越高但是随机访问点越少错码扩散后恢复越慢。常见的GOP结构是一个I帧后面跟一串P帧和B帧直到下一个I帧。比如GOP长度为60的典型排布可能是I B B P B B P B B……。B帧越多压缩率越好但编码延迟越大、需要缓存帧越多。硬件解码性能和播放器的兼容性也会影响B帧数量的选择。开头的那个I帧特别重要。它是解码器从流中间切入时唯一能“一切进来就能看懂”的帧。直播推流每隔2秒左右强制放一个I帧观众切进直播间时才能尽快看到画面否则解码器会黑屏等很久等GOP开头到了才能起播。这个设置通常叫关键帧间隔或者GOP长度在直播里习惯设为2秒或更小在点播里设为5到10秒很常见。I帧体积也比P帧和B帧大不少通常是一个GOP里体积最大的那一部分。所以GOP设得越短整体码率越高。同一路视频如果GOP从2秒改成4秒总码率经常能省10%以上代价是直播切流恢复变慢。3.3 编解码器的标准、预设和硬件编码目前市面上最常见的编解码器往前排是H.264也就是AVC兼容性无敌所有设备几乎都支持是目前存量最大的格式。它后面是HEVC也就是H.265压缩率比H.264高大约50%但专利授权和许可证问题比较复杂普及度虽然走高但还没有全面取代H.264。再往后是AV1开放免专利费压缩率又比HEVC高约20%到30%但编码复杂度极高软件编码速度很慢硬件编码支持还在快速普及。VVC也就是H.266是新一代标准压缩率比HEVC再提升30%左右目前主要面向8K、沉浸式媒体等高端场景。选编解码器时不只是看压缩率还要看生态。转码完必须考虑播放端是什么设备、支持硬解吗、浏览器能不能播、版权费成本能不能接受。H.264到H.265再到AV1就是典型的“压缩率和生态成熟度”之间的权衡。x264和x265提供了一整套preset预设从ultrafast到placebo不等。编码器预设的本质是“算力投入度”预设越慢运动搜索越精细、划分模式试得越多压缩率越高耗时也越长。实际工作中我用得比较多的是medium到slow之间再慢收益就变得很低了。快档预设适合实时场景不追求极限压缩率只保证速度。硬件编码在直播和实时通信里几乎不可或缺。NVIDIA NVENC、AMD AMF、Intel QSV、Apple VideoToolbox都是常见的硬件编码方案。硬件编码的优势是极低功耗和极高吞吐缺点是压缩率比同码率的软件编码稍低可控参数也更少。很多视频平台在直播流场景都优先用硬件编码来保证低延迟和低功耗再通过加强网络传输控制来弥补压缩率上的那一点差距。4. 用FFmpeg实测一遍编解码全流程4.1 把一条视频编码成H.264并对比体积理论讲再多最后还是要靠实操验证。FFmpeg是我工作中最常用的工具下面带你完整过一遍编码、分析码流、观察关键帧的流程。准备一段未压缩或近无损的视频源比如test.y4m。我习惯先用一段高清素材做测试比如1080p、30fps、10秒。最简单的转码命令ffmpeg -i test.y4m -c:v libx264 -preset medium -crf 23 -pix_fmt yuv420p test_h264.mp4这条命令的意思是用libx264编码器medium预设CRF质量23输出8bit YUV420像素格式的H.264文件。跑完之后用一个命令看输出统计ffprobe -v error -show_entries formatduration,bit_rate,size -show_streams test_h264.mp4一条10秒的1080p30素材CRF23中等复杂度场景输出码率大概在4~8Mbps之间。对比原始素材的747Mbps压缩率已经接近100倍。打开视频看一眼几乎看不出明显损伤。这就是预测、变换、量化、熵编码四个工具一起发力的结果。如果想要控制目标文件大小可以用二遍VBR编码ffmpeg -i test.y4m -c:v libx264 -preset slow -b:v 5M -maxrate 8M -bufsize 12M -pass 1 -f null /dev/null ffmpeg -i test.y4m -c:v libx264 -preset slow -b:v 5M -maxrate 8M -bufsize 12M -pass 2 test_h264_2pass.mp4第一遍只分析内容复杂度计算每帧合理分配多少码率第二遍按这个分配方案执行真实编码。二遍编码比一遍CRF能更精准地控制码率曲线非常适合点播文件需要控制在某个码率上限以内的场景。4.2 分析GOP结构和帧类型分布编码之后可以用FFmpeg把帧类型打印出来看看GOP的排布ffprobe -v error -select_streams v:0 -show_entries framepict_type -of csv test_h264.mp4输出会是一串I、B、P字符。试着数一下B帧的分布规律你会看到I帧开头然后按GOP长度周期性出现P帧和B帧交错排布。如果CRF编码时使用了B帧它们的体积通常最小I帧体积最大。用ffprobe把每个帧的pkt_size字段打出来就很直观ffprobe -v error -select_streams v:0 -show_entries framepict_type,pkt_size -of csv test_h264.mp4做过一次之后你会对“I帧到底有多占体积”有一个直观的认知。一条GOP长度为60的1080p视频I帧可能达到P帧的10倍以上。这也是为什么码率控制代码里I帧QP通常单独处理、不能完全跟P帧共用一套参数的原因。想进一步分析码流结构还可以装一个CodecVisa或者用命令行工具ffprobe提取macroblock信息不过日常用ffprobe就够了。真做编码器调试或码流分析时专业的码流分析仪比如Elecard StreamEye能看到每个块的划分和运动矢量那种视角对理解原理帮助非常大有条件值得一看。4.3 用极低码率观察画质劣化过程把码率拉到极低值是理解“有损编码损失在哪”的捷径。做一次测试ffmpeg -i test.y4m -c:v libx264 -preset slow -crf 35 test_h264_low.mp4CRF35的编码结果通常会把码率压得非常低代价是画面出现明显的块效应、振铃和细节丢失。用播放器放大画面看平滑区域会变成一片片色带边缘处会出现类似“鬼影”的纹理高频细节干脆被抹掉。这些现象的原理就是量化步长过大DCT系数被大量削成0高频信息完全被丢弃。如果你再做一次更极端的测试把CRF调到40以上你会发现运动区域还会出现残影。这是因为帧间预测时运动搜索精度下降、量化残差过大画面在运动物体边缘出现拖影。这种测试虽然是“暴力压低画质”但它能把编解码器各种劣化模式一次性暴露出来。做编码器调优时我经常故意跑这种极端参数来观察问题表现。5. 常见问题与排障经验实录5.1 解码花屏、绿屏和黑屏怎么排查这类问题的根源几乎都在“参考帧不一致”这条线上。解码器必须严格依赖码流里携带的参考帧信息重建画面一旦参考帧丢失或者不一致后面所有帧都会跟着错。最常见的表现是播放过程中某处突然花屏过一会儿自己恢复了。这多半是传输丢包导致的参考帧数据缺失而I帧周期到达后解码器重建了参考链画面就恢复了。直播场景里遇到花屏我一般先排查GOP设置、推流丢包率和服务端转码日志。如果传输环节丢包最有效的解决方法是开启前向纠错FEC或者重传ARQ。点播场景则优先用ffmpeg做码流完整性校验ffmpeg -v error -i test.mp4 -f null -如果输出大量metadata错误、非法的帧类型基本都能判断为源文件损坏。另外单个关键帧损坏导致的花屏也可以换一个播放器试试有些播放器会在遇到I帧损坏时主动等待下一个I帧而有些则会把残废的画面继续在这条链路上叠加。还有个特别容易被忽略的问题编码端用B帧但解码端缓存不足或者播放器实现得太烂B帧被丢弃过多画面就会卡顿或者出现切片闪烁。遇到兼容性问题时尝试编码时加一句-bf 0来禁用B帧看问题是否消失。如果确实消失了基本就能锁定在B帧和播放器兼容性上。5.2 编码延迟过高、实时性上不去实时通信和直播场景对端到端延迟要求很高最常见的编码侧提速手段是关闭B帧、缩短GOP、开启硬件编码。B帧的引入会让编码器需要先缓存未来帧延迟直接增加1~2帧以上GOP越小虽然恢复越快但I帧频率升高会让码率上升。如果既要低延迟又要码率可控可以试试调大参考帧距离、降低运动搜索精度、打开“zerolatency”这类tune选项。软件编码延迟的另一个瓶颈是并行度。x264和x265支持多线程编码会按帧并行或者切片并行跑。切片并行能降低延迟但会让压缩率小幅下降。很多推流软件默认没有打开这些参数手动调一下经常能看到延迟明显下降。硬件编码器在这块省心很多因为它的流水线是硬件大并发的延迟天然低这也是实时场景几乎都用硬件编码的原因。5.3 编解码器选型和参数适配心得选编码器不只是看新老还要看平台生态。我维护过的项目里面向web播放的优先保证H.264因为浏览器兼容性最稳面向大视频文件存储的会优先考虑HEVC或AV1以节省存储成本面向实时会议和连麦直播的则倾向优先用硬件编码的H.264或VP8严格规避B帧和长GOP。实际测试占很大的比重。我处理过一段场景反差极大的素材肉眼看上去平平无奇但编码后马赛克严重。排查半天发现是有大量类似“细雨”的高频噪声这种画面人眼注意力低但编码器会为它消耗大量码率。这时候用自适应量化提高平坦区域质量、降低纹理区域码率分配就能明显改善观感。另一个例子是暗光场景暗部噪声和色带非常明显适当调低CRF、开启denoise预处理或者提高像素位深10bit编码都能有效缓解。批量转码时还要注意源和输出的色彩格式。YUV420和YUV422互转如果不做正确的chroma siting处理经常会出现颜色偏紫或偏绿的问题。我踩过不少这种坑最后养成了习惯任何转码任务第一步先用ffprobe看源文件的色彩空间、色深、像素格式、色度采样位置再决定输出参数绝不跳过这一步。6. 一些值得养成的调试习惯做视频编解码相关工作这几年我最大的感受是编解码器不是黑盒它有一套非常清晰的逻辑链在驱动。遇到问题不要乱猜按“预测 → 变换 → 量化 → 熵编码”这条链路去定位绝大多数问题都能很快找到方向。我的习惯是桌面上常备四个工具FFmpeg、ffprobe、MediaInfo、以及一个能可视化查看码流结构的工具。调试任何一个编解码问题先从这几个工具的输出里找数据支撑。很多看似诡异的现象一查码流结构就一目了然。比如你怀疑B帧太多导致兼容性问题一条ffprobe就把帧类型分布列出来了。还有一个小技巧准备几段不同类型的标准测试素材包括高速运动场景、纯色渐变场景、暗光噪点场景、文字滚动场景每次测试都跑同一套素材。有了固定样本库对比不同编码参数造成的差异会变得非常直观比拿一个随机视频反复试要高效得多。编码参数不是越多越好。每加一个参数都会增加出问题的概率。我现在一般先把最关键的三四个参数定下来编码器、preset、码率控制模式、GOP长度其他参数按需追加。追求“完美输出”反而容易把问题搞复杂。我自己在实操中经常会做的一件事是把编码前后的同一帧导出成PNG用像素级的差值计算去量化画质的实际损失。这个习惯帮我发现了很多“看起来还行但实际有隐藏问题”的情况。比如某些暗部场景的色块问题肉眼看视频不觉得但做像素对比后能清楚地看到那些细节已经被抹平了。做编码质量评估的话从PSNR到SSIM再到VMAF这些客观指标都有局限最终还是人眼加真实设备播放测试说了算。
