现在这个时代，不管是为了娱乐还是学习，我们多多少少都是要看些视频的，而看视频的过程中，我们就会产生一些问题和思考。举个例子，我们看直播的时候，明明我们没有调画面设置，本地网络环境也是稳定的，但画面就是会有时候很清晰、有时候糊成一团，这是为什么呢？有的博主会说本地码率限制住了，没办法，那这个码率又是什么呢？相信你看完这篇文章，对此类问题都会有一个清晰的答案。

人眼看到的连续动态画面，本质是快速切换的静态图片序列，利用视觉暂留特性形成流畅的运动观感。模拟视频是连续的电磁波信号，而数字视频则是把画面离散成一个个像素、把时间离散成一帧帧画面，再经过压缩编码后存储或传输。

一个完整的数字视频文件，本质是一个 「容器」 ，里面至少包含视频流、音频流、元数据三类核心内容，还可以根据需求加入字幕、章节、多音轨等附加内容。其中视频流承载压缩后的画面像素数据，音频流承载压缩后的声音采样数据，元数据则记录了时长、分辨率、帧率等所有描述信息，相当于整个文件的“说明书”。

通用核心参数

分辨率 Resolution

分辨率指单帧画面包含的像素总数，通常以「宽度 × 高度」表示，单位为像素。像素是数字画面的最小发光单元，每个像素可独立显示颜色和亮度，像素总量决定了画面能承载的细节上限。

我们常说的 720p、1080p 是简化叫法。其中的字母 p​ 代表逐行扫描（Progressive），每一帧完整绘制；对应的 i 是隔行扫描（Interlace），把一帧拆成两场交替绘制，常见于老式电视。数字代表垂直方向的像素行数，例如 1080p = 垂直 1080 行像素，搭配 16:9 宽高比，完整分辨率为 1920×1080。

影院领域的 DCI 2K/4K 标准分辨率略有不同（2048×1080 / 4096×2160），民用领域以 16:9 的电视 / 显示器标准为主。

帧率 Frame Rate / FPS

帧率指每秒播放的画面帧数，单位为 fps（Frames Per Second），直接决定动态画面的流畅度。

人眼视觉暂留阈值约 16fps，低于这个值会明显感觉到卡顿。帧率越高，快速运动的画面越连贯，拖影、模糊感越弱，但数据量也同步上升。随着技术发展，现在我们看到的网络视频基本都是 30fps 起步了，60fps 和 120fps 的高帧率内容也越来越常见。

不同场景下的标准帧率差异很大。电影行业沿用百年的标准是 24fps，这是胶片时代成本与流畅度的平衡点，也造就了我们熟悉的“电影感”。广播电视领域则分为两大体系：国内和欧洲采用 25fps 的 PAL 制式，北美和日本采用 30fps 的 NTSC 制式，足够满足普通叙事内容的流畅需求。而游戏、体育、动作类内容更适合 60fps，高速运动场景下的顺滑感会有质的提升；120fps 及以上的超高帧率则多用于慢动作拍摄和专业电竞场景，既可以捕捉极致的运动细节，也能用于后期制作顺滑的慢放效果。

当我们需要把视频从一种帧率转换成另一种时，就会用到帧率转换算法，不同算法的效果和算力要求天差地别。最简单的是帧复制与帧丢弃，升帧时直接复制前一帧填充空缺，降帧时直接删掉多余帧，零计算量但动态画面会有明显卡顿感。稍好一些的是帧混合算法，对相邻两帧的像素颜色做加权平均生成过渡帧，流畅度有所提升，但运动物体会出现明显的拖影重影。

专业领域最主流的是运动估计+运动补偿算法，它会先追踪画面里每个像素块的移动方向和距离，生成运动向量，再沿着运动轨迹把像素移动到中间位置生成全新的过渡帧，动态画面清晰自然，流畅度远超前两种算法，但计算量也大得多。如今最新的 AI 智能插帧 则更进一步，基于深度学习模型预测光流、脑补遮挡细节，复杂场景的表现远超传统算法，当然对硬件算力的要求也更高。

码率 Bitrate

码率指单位时间内视频流的数据量，单位通常为 bps​（比特 / 秒）、kbps​（千比特 / 秒）、Mbps（兆比特 / 秒）。分辨率和帧率只是「潜力」，码率才是「实际给的数据量」：同样是 1080p 60fps，1Mbps 码率会糊成马赛克，10Mbps 码率就会非常清晰。

对于压缩后的视频，码率是决定画质和体积的唯一直接变量。我们可以通过一个简单的公式计算视频流的体积：视频文件体积（字节）= 视频码率(bps) × 时长(秒) ÷ 8，这里除以 8 是因为 1 字节 = 8 比特。

时长 Duration

时长即视频的总播放时间，单位就是常见的 s​ / min 等时间单位。它和帧率、码率有两个基础关系：

总帧数等于帧率乘以时长，比如 30fps 的 10 秒视频，总共有 300 帧画面；而文件体积大致等于视频码率加音频码率的总和乘以时长再除以 8，在固定码率模式下，时长和体积基本成正比，只有在可变码率模式下会因为画面复杂度出现小幅波动。

色彩底层 - 像素格式、位深与色彩空间

很多人对视频的理解停留在“像素数量”层面，但分辨率只决定了像素的多少，每个像素能承载多少颜色信息，同样会深刻影响画面观感和文件体积。

多数人熟悉的是 RGB 像素格式，每个像素由红、绿、蓝三个独立通道组成，是图像编辑和显示器输出的标准格式。但在视频存储与传输领域，绝对主流的是 YUV 格式，这背后利用了人眼的生理特性：我们对亮度细节的敏感度，远高于对颜色细节的敏感度。YUV 格式将画面拆分为亮度（Y）和色度（U、V）两部分，Y 通道承载全部的明暗细节，而 U、V 通道只负责颜色信息。既然人眼对色度不敏感，我们就可以对色度通道做降采样，减少色度的数据量，肉眼却几乎察觉不到差异，这也是视频编码能实现高效压缩的基础之一。

日常接触的绝大多数网络视频和直播，都采用 YUV420 采样标准：色度在水平和垂直方向的分辨率均为亮度的一半，每 2×2 的像素块共用一组 UV 分量，单个像素平均仅占用 12 bit（1.5 字节），整体数据量比全采样减少近一半，是压缩效率与观感的绝佳平衡。更高规格的 YUV422 和 YUV444 采样多用于专业拍摄与后期母版制作，普通用户日常很少接触。

与像素格式相伴的参数是位深，它决定了每个颜色通道能表达的明暗层级数量。我们最常见的 8bit 位深，每个通道有 256 级亮度，三通道混合可呈现约1677万种颜色，足以覆盖绝大多数日常场景。但在天空渐变、暗部过渡等平缓色彩变化的场景中，8bit 有时会出现肉眼可见的颜色分层，也就是常说的“色带”。

10bit 位深则能将每个通道的明暗层级提升至 1024 级，灰阶数量是普通 8bit 的 4 倍，总颜色数超过 10 亿，色彩过渡平滑自然，基本消除了色带问题。如今的 HDR 视频、高清流媒体基本都已普及 10bit 编码，它不仅提升了色彩细腻度，也是实现高动态范围光影效果的基础。

有了像素格式和位深，还需要色彩空间来定义可显示的颜色范围。我们日常接触最多的 Rec.709 是 SDR 视频的通用标准，几乎所有普通显示器和网络视频都基于这一色彩空间。而 DCI-P3 广色域能呈现的颜色范围比 Rec.709 多出约 25%，红绿色彩更鲜艳通透，是高端显示器和 HDR 视频的主流配置。更高级的 Rec.2020 则覆盖了几乎所有人类可见颜色，是未来 8K 超高清的标准，目前仍在普及阶段。对普通用户而言，视频与显示设备的色彩空间匹配，才能看到准确自然的颜色，否则会出现偏淡或过饱和的问题。

压缩 - 编码原理与码率控制

如果直接存储未压缩的原始视频，体积会大到完全无法使用。一段 1080p、30fps、YUV420 8bit 的视频，每秒原始数据量就超过 120MB，一分钟就要 7GB 以上，根本无法存储和网络传播。视频编码技术的核心意义，就是在尽量不损失观感的前提下，将视频体积压缩至几十分之一甚至更小。

编码压缩的本质是消除画面中的两类冗余信息。一类是空间冗余：同一帧画面内，相邻像素的颜色往往高度相似，比如一片蓝天的大部分像素都是接近的蓝色，不需要每个像素都独立存储，可以通过算法简化表达，原理和 JPG 压缩图片类似，也叫帧内压缩。另一类是时间冗余：连续两帧画面的绝大多数内容都是相同的，比如人物行走的视频里背景基本不动，只有人物位置变化，因此不需要每一帧都存完整画面，只存储两帧的差异部分即可，也叫帧间压缩。

基于这一逻辑，编码后的视频帧被分为三类。第一类是 I 帧，也叫关键帧，它是一张完整独立的画面，不依赖任何其他帧就能解码，相当于视频里的“锚点”。第二类是 P 帧，即向前预测帧，只存储与前一帧的差异数据，体积远小于 I 帧，必须参考前面的帧才能还原画面。第三类是 B 帧，即双向预测帧，同时参考前后帧进行压缩，压缩效率最高、体积最小，但解码时需要等待后续帧，会带来一定延迟。

这些帧按固定规律组合形成 GOP（图像组），两个 I 帧之间的帧数就是 GOP 长度。GOP 越长，P 帧和 B 帧占比越高，整体压缩率越高、文件体积越小，但代价是跳转进度时要等待下一个 I 帧才能显示完整画面，切入延迟更高。我们拖动视频进度条时偶尔出现的瞬间花屏，就是因为跳到了 P 帧或 B 帧位置，尚未等到 I 帧刷新。

主流编码标准至今已迭代多代。经典的 H.264 是当之无愧的全能选手，推出二十余年仍是兼容性最好、应用最广的编码，全平台全设备均可完美支持。后续的 H.265（HEVC）在同等画质下可将体积再压缩 30%~50%，大幅节省带宽与存储空间，是当前 4K 视频和高清直播的主流选择。最新一代的 AV1 编码压缩效率比 H.265 更胜一筹，且开源免费。

编码的另一核心是码率控制策略，它决定了码率如何随画面内容变化，直接影响体积、画质与稳定性。

恒定码率（CBR）全程码率基本保持稳定，画面简单时填充冗余数据凑数，画面复杂时强行压缩画质。它的优势是带宽占用极其稳定，无突发峰值，非常适合直播场景——主播上传带宽固定，码率超限就会导致推流卡顿，CBR可以完美规避这一问题。但缺点也很明显：静态画面浪费码率，动态画面画质不足，整体画质不均，带宽利用率低。

可变码率（VBR）则会根据画面复杂度动态分配码率，简单画面少给码率，复杂画面多给码率，全程保持相对一致的感知画质。它的带宽利用率最高，同等体积下画质最优，同等画质下体积最小，非常适合本地存储和点播视频压制。但码率波动大、峰值不可控，不适合对带宽稳定性要求高的直播场景。

介于两者之间的平均码率（ABR）会设定一个平均码率目标，允许编码器在目标上下小幅浮动，将简单场景节省的码率留给复杂场景，兼顾体积可控与画质均匀，是很多视频平台压制点播内容的折中方案。

还有一种面向画质的恒定质量因子（CRF）模式，只需设定一个画质等级，编码器就会自动调整码率，保证全程感知画质一致，最终文件体积完全由画面内容决定。它的压制效率最高、画质最均匀，不需要手动预估码率，适合个人收藏和母版制作。常用的 x264 编码器默认 CRF 值为 23，数值越低画质越高、体积越大，通常 ±1 的调整会带来约 10% 的码率变化。但因为体积不可控，CRF 几乎不会用于网络传播和直播场景。

容器 - 封装格式的区别与场景

很多人会混淆编码与封装，以为 MP4 是一种编码格式，其实二者完全不同。编码是压缩画面和声音的算法，而封装是将压缩好的视频流、音频流、字幕、元数据打包成一个文件的“容器”。同一段 H.264 编码的视频，可以封装成 MP4，也可以封装成 MKV，画面质量一致，只是适配的设备和场景不同。

首先我们来说大伙最常见的 MP4。MP4 可以说是通用性最强的数字视频封装格式，兼容性几乎无死角，手机、电脑、电视、网页均可直接播放，文件体积小巧，元数据支持完善，是网络传播、上传下载的绝对首选，我们日常接触的绝大多数视频都是 MP4 格式。

x相比之下，我们熟知的 MKV 则更像“万能容器”，几乎支持所有编码格式，可容纳多条音轨、多条字幕、章节信息，自由度极高，非常适合本地收藏高清影视资源。但它的兼容性弱于 MP4，很多设备和网页不支持直接播放，更适合本地使用专业播放器观看。

还有一些面向特定场景的封装格式。比如 FLV，它是 Flash 时代直播的主流，体积小巧、流式传输友好，至今很多直播平台的底层仍在使用。TS 格式即传输流，容错性极强，即使丢失部分数据也能继续播放，不会导致整个文件损坏，因此是 HLS 直播切片的标准格式。MOV 是苹果生态的原生格式，在苹果剪辑软件和设备中适配最优。

直播流 - 实时传输的实现原理

讲完点播视频的基础体系，我们再延伸到直播领域。点播与直播最本质的区别在于：点播是先完成整个视频的压制，再逐步传输给观众；而直播是边采集、边编码、边传输、边播放，整个过程完全实时。

一场完整的直播链路远长于点播。首先由采集端获取摄像头、麦克风或游戏画面的原始信号，经过美颜、降噪等预处理后送入编码器压缩；编码完成后，主播端通过推流协议将直播流上传至流媒体服务器；服务器再将流分发至全国各地的 CDN 节点，让观众可以就近拉流，降低延迟与卡顿；最终观众端下载直播流，解码后呈现画面。链路中的每一环，都会影响最终的画质、延迟与稳定性。

传输协议是直播技术的核心，不同协议在延迟、兼容性、弱网表现上差异极大。早期的 RTMP 基于 TCP 传输，延迟通常在 2~5 秒，曾是主播推流的标准协议，至今多数平台仍支持 RTMP 推流，但它原生不支持网页播放，依赖插件实现。后续衍生的 HTTP-FLV 将 FLV 封装在 HTTP 长连接中传输，延迟与 RTMP 相当，同时兼容 CDN 分发，网页播放更便捷，一度成为网页直播的主流。

抛开前面这些老东西，当下兼容性最好的直播协议当属 HLS。它的原理是将直播流切割成一段段的 TS 视频文件，通过 m3u8 索引文件管理这些切片，观众通过持续下载新的切片实现连续播放。由于基于标准 HTTP 协议，任何浏览器、微信、移动端均可原生支持，分享传播极其方便。但它的缺点也很突出：必须等待完整切片生成后才能下载，普通切片长度为 2-10 秒，导致原生 HLS 延迟通常在十几秒到三十秒，互动性较差。后续出现的低延迟 HLS（LL-HLS）通过分片传输技术将延迟降至 2-3 秒，兼顾了兼容性与实时性。

如果追求低延迟，当前的首选方案是 WebRTC。它基于 UDP 传输，不保证数据百分百可靠到达，丢包也不重传，以极少量的画质损失换取了极低的延迟，通常可做到 50~300 毫秒，几乎接近面对面交流的体验，目前连麦互动、实时视频会议基本都基于 WebRTC 实现。除此之外，SRT 这类专门针对弱网优化的传输协议，通过前置纠错算法对抗网络丢包，在网络不稳定的户外推流场景中表现优异。

这里额外补充一点：很多人好奇直播延迟的来源，其实这个东西是多段延迟叠加的结果。我们可以设想下，采集与编码需要几十毫秒，推流传输到服务器需要几十到几百毫秒，CDN 分发与缓存需要几百毫秒到数秒，最终解码播放还要几十毫秒。其中延迟的主要来源是播放器缓冲：为了对抗网络波动，播放器会预先缓存几百毫秒到数秒的数据，网络短暂波动时用缓存数据填补，避免立刻卡顿。缓冲越大，抗卡顿能力越强，但延迟也越高，这就涉及到平台如何在不同需求之间做出权衡。

这也是为什么我们看直播时总会慢主播一拍，包括想和主播在游戏里撞车需要主播主动给出北京时间。

当网络持续变差、缓存耗尽时，就会出现熟悉的卡顿转圈。网络恢复后，播放器有两种处理逻辑：一种是按正常速度播放，延迟会越积越大，逐渐与现场脱节；另一种是追帧，即轻微加快播放速度，追回积累的延迟，保证与现场的同步性，代价是画面会有不易察觉的加速感。绝大多数直播平台都会默认开启追帧机制，保障直播的实时性。

当然也有一些平台会按照正常速度播放，导致出现明显延迟，比如虎牙。

The End

Ok，以上基本就是这次我想记录的关于数字视频的基础知识点。我感觉了解以上内容之后呢，我们平常看视频、看直播时有的一些问题应该都能大致了解原理了。

总的来说呢，数字视频的所有参数与技术，不同平台的不同策略和技术选型，本质上都是在画质、体积、延迟三者之间做不同的权衡。本地收藏优先画质，就选择高码率、高效编码、长 GOP，不用在意延迟；网络传播优先兼容与体积，就选择通用编码、适中码率、MP4 封装，覆盖最多设备；直播优先稳定与实时，就选择恒定码率、短 GOP、低延迟协议，保障流畅观看。

‍