视频基础知识
约 2492 字大约 8 分钟
2026-03-29
| 场景 | 核心诉求 | 可接受延迟 | 典型特点 | 常见技术路线 |
|---|---|---|---|---|
| 直播 | 一对多分发 | 秒级 | 大规模观众、依赖 CDN | RTMP 推流 + HLS / HTTP-FLV / LL-HLS |
| 视频会议 | 双向互动 | 200ms 左右 | 低延迟、强交互 | WebRTC |
| 实时监控 | 稳定播放与录制 | 亚秒到秒级 | 以设备端为中心 | RTSP / RTP，再转浏览器可播格式 |
这三类场景看起来都在“播视频”，但目标并不一样：
- 直播更关心大规模分发和兼容性
- 视频会议更关心双向互动和低延迟
- 实时监控更关心稳定性、录像和设备生态
所以后面看到不同协议时，不要先问“谁更先进”，而是先问“它为哪类场景设计”
基本概念
分辨率
分辨率指的是画面中像素点的数量，通常用 宽 × 高 表示，比如 1280 × 720、1920 × 1080。同一块屏幕上，分辨率越高，像素越密，画面通常越细腻
| 分辨率 | 描述 |
|---|---|
| 1280 × 720 | 720P，高清 |
| 1920 × 1080 | 1080P，全高清 |
| 2560 × 1440 | 2K，超高清 |
| 3840 × 2160 或 4096 × 2160 | 4K，超高清 |
在音视频系统里， "更清晰" 往往意味着 "更占带宽、更吃编码、更难实时"
逐行扫描和隔行扫描
在视频工程里，经常会看到 1080P 和 1080i 这种写法。这里面的 P 和 i，并不是分辨率本身的一部分，而是扫描方式：
P：逐行扫描，一帧画面按从上到下的顺序完整显示i：隔行扫描，一帧画面拆成奇数行和偶数行两个半场，交替显示，再让人眼把它们 "合成" 成一帧
相关信息
隔行扫描是早期电视时代为了在有限带宽下提升清晰度而做出的工程折中。现代液晶屏和浏览器播放环境下，逐行扫描已经更自然，也更适合数字视频处理。所以今天在做前端视频播放、WebRTC、直播分发时，通常会更经常接触到逐行扫描的视频流
帧率
帧率是单位时间内显示的画面数量，常见单位是 fps（frames per second）。帧率越高，画面通常越流畅，但同时也意味着：单位时间内要处理更多帧、编码压力更大、带宽占用更高。所以在实时系统里，帧率不是越高越好，而是要和码率、分辨率、网络条件一起平衡
码率
码率（bitrate）是指单位时间内 传输或处理的数据量，视频中就是每秒钟有多少 "位"（bits）用于描述视频画面，码率 = 每秒钟包含的比特数
| 单位 | 解释 |
|---|---|
| bps | bit per second（比特/秒） |
| Kbps | 千比特/秒（1 Kbps = 1000 bps） |
| Mbps | 兆比特/秒（1 Mbps = 1000 Kbps） |
| Gbps | 千兆比特/秒 |
视频格式
视频格式有封装格式和编码格式之分，常说的 AVI、MP4、MKV 是封装格式，H.264、H.265、VP9 是编码格式。封装格式决定了视频文件的结构和组织方式，而编码格式决定了视频内容的压缩算法和质量表现
封装格式
封装格式 就是把视频数据和音频数据打包成一个文件的规范。 一个完整的视频文件，包括音频、视频和基础元信息，我们常见的视频文件如 mp4、mov、flv、avi、3GP 等视频文件，就是一个容器的封装，里面包含了音频和视频两部分
封装格式不会影响视频的画质，封装成什么格式就看在使用的时候解码器是否支持这个封装格式即可
| 封装格式 | 常见扩展名 | 常见编码 | 特点与用途 | 优点 | 缺点 |
|---|---|---|---|---|---|
| MP4 | .mp4 | H.264/H.265/AAC | 最常见的通用视频封装 | 兼容性最好（网页、手机、电视全支持）适合在线视频分发和点播 | 流式播放能力一般，直播不是最优选择 |
| MKV | .mkv | H.264/H.265/VP9/音轨多种 | 高扩展性、支持多音轨、字幕 | 支持 4K / HDR / 多音轨 / 字幕 开源、封装灵活 | 浏览器播放兼容性较差 |
| MOV | .mov | ProRes/H.264/H.265 | 苹果常用、常用于剪辑 | 高质量、适合专业制作 | 文件大、跨平台兼容性较差 |
| AVI | .avi | 旧式编码 | 老格式，逐渐淘汰 | 过去广泛使用 | 压缩效率低、文件体积大 |
| FLV | .flv | H.264/AAC | Flash 时代网络视频封装 | 过去用于直播/点播 | Flash 淘汰，已基本退出历史舞台 |
| TS / M2TS | .ts/.m2ts | H.264/H.265/AAC | 流媒体常用封装（如 HLS 分片） | 适合直播、切片传输 | 单文件播放不友好 |
| WEBM | .webm | VP8/VP9/Opus | Google 开源，为网页优化 | 浏览器兼容好、体积小 | 苹果生态支持不如 mp4 |
| RMVB | .rmvb | RealVideo | 曾经很流行 | 小体积 | 过时，不再推荐 |
编码格式
视频编码格式本质上就是一种视频压缩技术 因为原始视频数据太大，因此必须压缩，否则没办法存、没办法传、没办法播。常见编码格式：H.264、H.265、VP9、AV1、MPEG2
它们不是视频文件本身，而是压缩算法
| 编码格式 | 同样 1080p 1 分钟视频大小 |
|---|---|
| MPEG-2 | 300 MB |
| H.264 | ~60 MB |
| H.265 | ~30 MB |
| AV1 | ~20 MB |
压缩内容之后，再用封装容器打包起来
视频压缩
视频虽然看起来是连续运动，但本质上仍然是一帧一帧的图像序列。相邻帧之间往往有大量相同信息，所以没有必要把每一帧都完整存储一遍。压缩算法会利用 画面之间的相似性 来减少数据量
帧内压缩
只压缩当前这一帧，不参考前后帧。它更像是 "把单张图片压小"。帧内压缩产生的帧叫：I 帧，也就是常说的关键帧。每隔一段时间放一个 I 帧，保证视频能从任何地方开始播
优缺点
- 解码简单
- 可以从任意关键帧开始播放
- 压缩率相对没那么高
- 文件较大，但画质保真
帧间压缩
利用前后帧的相似性进行压缩，只记录变化部分，而不是重复存整帧。这类压缩会引入：P 帧和B 帧
优缺点
- 压缩率更高
- 需要依赖前后帧才能解码，CPU 负担更大
浏览器的 video 标签能做什么
浏览器最基础的播放入口当然是 video 标签。
<video controls src="/demo.mp4"></video>如果是已经存在的完整文件，比如点播视频，video 标签配合浏览器原生解码就够用了。
但它也有明显局限：
- 它天然更适合播放完整文件
- 它不能直接理解 RTSP 这类设备协议
- 它本身不会帮你处理实时分片、低延迟播放和协议转换
所以当我们进入流媒体和实时通信领域时，单纯依赖 video src="xxx" 就不够了。
传统 MP4 和 fMP4
传统 MP4 更偏向“完整文件播放”。它通常需要依赖完整的索引信息，浏览器先知道这段视频怎么解码、总时长多长，才能比较自然地播放。
而流媒体场景里，视频数据往往是边生产边发送的，不存在一个预先完整写好的文件。这时就更适合使用 fMP4（fragmented MP4），也就是分片 MP4。
可以把它理解成：
- 传统 MP4：更像一个完整成品文件
- fMP4：更像把视频拆成一段一段可持续追加的媒体片段
fMP4 并不是另一种全新容器，而是更适合流式播放的 MP4 组织方式。
MSE
当服务端把媒体数据切成片段以后，还需要有一套机制把这些片段持续“喂”给浏览器播放器，这就是 MSE（Media Source Extensions） 的工作。
它的核心能力是：
让 JavaScript 可以把一段段音视频数据主动追加给
video元素播放。
大致流程是：
服务端输出分片媒体数据
-> 浏览器通过 JS 拉取数据
-> 通过 MediaSource / SourceBuffer 追加片段
-> video 标签持续播放所以如果你要在浏览器里做流式点播、低延迟 HLS、HTTP-FLV 转封装播放等能力，MSE 往往是非常关键的一环。
HLS 和 DASH
当媒体片段的生产、索引、分发和播放进一步标准化后，就有了更完整的流媒体协议，比如：
- HLS
- MPEG-DASH
它们的共同思路都是：
- 把音视频切成一段一段的小片段
- 提供一个索引文件描述有哪些片段
- 浏览器或播放器按顺序拉取并播放
区别主要体现在：
- 具体的索引格式不同
- 常用的媒体片段格式不同
- 生态和兼容性不同
其中：
- HLS 在苹果生态和网页场景非常常见
- DASH 是更开放的标准，但浏览器端生态通常没有 HLS 那么统一
FFmpeg 在这条链路里做什么
如果说 video、MSE、HLS 是浏览器播放侧的能力，那么 FFmpeg 更像是音视频处理中间层最常见的工具。
它经常负责：
- 转码
- 转封装
- 推流 / 拉流
- 切片
- 录制
- 协议转换
在实时音视频体系里，FFmpeg 经常出现在：
- 摄像头流转成浏览器可播格式
- RTMP 推流到媒体服务器
- 直播流切成 HLS 片段
- 把已有视频文件模拟成实时流
所以你可以把它理解成音视频世界的“中间加工厂”。