# VOD 深度剖析（一）：视频基础——视频到底是什么？ > VOD 流媒体系列（共 12 篇）的开篇之作。从字节层面理解视频究竟是什么——像素、分辨率、帧率、码率、I/P/B 帧、GOP、色彩空间与 HDR。 - 作者: zhuermu - 发布: 2026-05-10 - 网页版: https://zhuermu.com/blog/vod-deep-dive-part-1-video-fundamentals/ --- > *这是 VOD 流媒体深度剖析系列的第 1 篇——一份共 12 篇的技术指南，涵盖从原始像素到全球规模分发的方方面面。* --- ## 那些你或许从未想过的问题 你每天都在看视频，但你有没有想过： - 从点击"播放"到看到第一帧画面，中间到底发生了什么？ - 为什么一部 2 小时的 Netflix 电影只有 2 GB，而 2 小时的 iPhone 原始素材却有 20 GB？ - 为什么网络差的时候视频会"变糊"，而不是直接卡住不动？ - 为什么 iPhone 只能原生播放 HLS，却播不了 DASH？ - 为什么你没法把下载好的 Netflix 电影拷给别人的手机？ - 短视频 App 是怎么做到你一滑就几乎瞬间开播的？ 读完这个系列，上面每一个问题你都能答上来。 --- ## 什么是视频点播（VOD）？ **视频点播**——**VOD**——顾名思义：用户想看什么就看什么，想什么时候看就什么时候看。视频文件早在播放之前就已经录制好并存放在服务器上了。 与之相对的是**直播**： | | **VOD（点播）** | **直播** | |---|---|---| | 内容来源 | 预先录制好的文件 | 摄像机/编码器实时产出 | | 能否拖动进度？ | 能 | 不能（或仅有限的 DVR 时移窗口） | | 举例 | Netflix、YouTube、Bilibili、在线课程 | 体育转播、电商直播、游戏直播 | | 工程难点 | 以最低成本触达最多用户 | 保持低延迟、实时编码 | 短视频（TikTok、YouTube Shorts）也属于 VOD。虽然它*感觉上*是实时的，但每一个片段其实都是预先上传好的录制内容。它被切成秒级的分片，再由推荐算法投喂给你——这正是信息流看起来永无尽头的原因。 本系列聚焦于 **VOD**，但其中的大多数技术（编解码器、封装容器、传输协议、DRM）同样适用于直播。 --- ## VOD 的旅程：从摄像机到你的屏幕 一段视频要经过六个阶段才能到达你的手机： ``` ①Capture/Upload ②Transcode ③Package ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Director │ ────► │ Compress │ ──────► │ Cut into │ │ uploads │ │ into many│ │ small │ │ raw file │ │ qualities│ │ segments │ └─────────┘ └─────────┘ └─────────┘ │ ┌───────────────────────────────────────┘ │ ▼ ④Store in Cloud ⑤CDN Distribution ⑥Playback ┌─────────┐ ┌─────────┐ ┌─────────┐ │ Put into │ ────► │ Copy to │ ──────► │ Auto- │ │ object │ │ nearest │ │ select │ │ storage │ │ data │ │ quality │ │ (S3 etc) │ │ center │ │ & play │ └─────────┘ └─────────┘ └─────────┘ ``` 每个阶段都对应本系列的一个章节： | 阶段 | 它解决的问题 | 对应篇章 | |-------|------------------|-------------| | ①采集/上传 | 如何可靠地把大文件传到服务器 | [第 11 篇](/blog/vod-deep-dive-part-11-end-to-end-workflow/) | | ②转码 | 如何把 20 GB 的母版压到 200 MB，还依然清晰好看 | [第 2 篇](/blog/vod-deep-dive-part-2-video-codecs-h264-h265-av1/)、[第 3 篇](/blog/vod-deep-dive-part-3-audio-fundamentals/) | | ③封装 | 如何把视频 + 音频 + 字幕组合起来并切成分片 | [第 4 篇](/blog/vod-deep-dive-part-4-container-formats-mp4-fmp4-cmaf/)、[第 5 篇](/blog/vod-deep-dive-part-5-streaming-protocols-hls-dash/) | | ④存储 | 如何低成本地存放海量视频 | [第 11 篇](/blog/vod-deep-dive-part-11-end-to-end-workflow/)、[第 12 篇](/blog/vod-deep-dive-part-12-building-vod-on-aws/) | | ⑤CDN | 如何让全球用户都能快速访问 | [第 7 篇](/blog/vod-deep-dive-part-7-cdn-distribution/) | | ⑥播放 | 如何自适应网速并防盗版 | [第 6 篇](/blog/vod-deep-dive-part-6-adaptive-bitrate-streaming/)、[第 8 篇](/blog/vod-deep-dive-part-8-drm-content-protection/)、[第 9 篇](/blog/vod-deep-dive-part-9-video-players/) | 而贯穿始终的那条主线——**你如何知道用户的体验好不好？**——就是[第 10 篇：QoE 指标](/blog/vod-deep-dive-part-10-qoe-metrics/)。 --- ## 视频不过是一叠照片 这是本章最重要的一句话： > **视频 = 一连串快速播放的图像 + 一条音轨。** 当你看视频时，你的大脑看到的是： ``` Frame 1 Frame 2 Frame 3 Frame 4 Frame 5 ... ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │ │ │ │ │ │ │ │ │ │ │ 🚗 │ │ 🚗 │ │ 🚗 │ │ 🚗 │ │ 🚗 │ │ │ │ │ │ │ │ │ │ │ └────┘ └────┘ └────┘ └────┘ └────┘ (car shifts slightly right) ┃ ▼ Play 30 images per second → you see "smooth driving" ``` 每一张图像都称为一**帧**（frame）。 --- ## 像素与分辨率 把任意一张图片放得足够大，你就会看到一个个小方块——每一个方块记录一种颜色。这个方块就是**像素**（pixel）。 - 一张 1920×1080 的图像有 1920 列 × 1080 行 = **2,073,600 个像素**（约 200 万像素）。 - 每个像素存储一个颜色值，占用几个字节。 **分辨率**就是像素的尺寸。常见的标识有： | 标识 | 分辨率 | 总像素 | 相对大小 | |-------|-----------|-------------|--------------| | 240p | 426 × 240 | ~10 万 | 1x（基准） | | 360p | 640 × 360 | ~23 万 | 2.3x | | 480p (SD) | 854 × 480 | ~41 万 | 4.1x | | 720p (HD) | 1280 × 720 | ~92 万 | 9.2x | | 1080p (FHD) | 1920 × 1080 | ~200 万 | 20x | | 1440p (2K) | 2560 × 1440 | ~370 万 | 37x | | 2160p (4K UHD) | 3840 × 2160 | ~830 万 | 83x | | 4320p (8K) | 7680 × 4320 | ~3320 万 | 332x | 注意："4K"有两种版本——**UHD 4K**（消费级：3840×2160）和 **DCI 4K**（电影级：4096×2160）。 竖屏手机视频采用 **9:16** 比例（例如 720×1280），正好是横屏 **16:9**（1920×1080）的倒置。 --- ## 像素如何存储颜色：RGB、YUV 与位深 ### RGB 最直观的方式：为每个像素分别存储**红、绿、蓝**三种颜色的强度。 - 黑色 = R:0 G:0 B:0 - 白色 = R:255 G:255 B:255 - 每个通道占 **8 位（1 字节，0–255）**，因此一个 RGB 像素 = **3 字节**。 算笔账：单张 1080p 的 RGB 帧 = 1920 × 1080 × 3 字节 ≈ **6.2 MB**。按 30 fps 计算，就是 **186 MB/秒**——一部 2 小时的电影如果不压缩将高达 **1.3 TB**！ 这正是**视频必须压缩**的原因。 ### YUV（视频行业标准） 视频使用 **YUV**（也写作 YCbCr）： - **Y**（亮度 Luma）：像素有多亮（0 = 黑，255 = 白） - **U、V**（色度 Chroma）：像素是什么颜色 为什么不直接用 RGB？因为： > **人眼对亮度的敏感程度远高于对颜色的敏感程度。** YUV 正是利用了这一点：你可以记录*更少*的颜色信息，而肉眼几乎察觉不到差别。 ### 色度二次采样（Chroma Subsampling） | 方案 | 说明 | 相对 4:4:4 的数据量 | 应用场景 | |--------|------------|--------------|---------| | **4:4:4** | 每个像素都有完整的 Y/U/V | 100% | 影视后期制作 | | **4:2:2** | 相邻两个像素共用一组 U/V | 67% | 广播、专业级 | | **4:2:0** | 相邻四个像素共用一组 U/V | **50%** | **几乎所有消费级流媒体** | ``` Luma Y (all kept) Chroma U/V (one per 2×2 block) ┌──┬──┬──┬──┐ ┌─────┬─────┐ │Y │Y │Y │Y │ │ │ │ ├──┼──┼──┼──┤ │ UV │ UV │ │Y │Y │Y │Y │ │ │ │ ├──┼──┼──┼──┤ ├─────┼─────┤ │Y │Y │Y │Y │ │ │ │ ├──┼──┼──┼──┤ │ UV │ UV │ │Y │Y │Y │Y │ │ │ │ └──┴──┴──┴──┘ └─────┴─────┘ 16 Y values 4 UV pairs RGB 4:4:4 = 16 × 3 = 48 bytes YUV 4:2:0 = 16 + 4 + 4 = 24 bytes (half the data) ``` 代价是：纯黑背景上的鲜红色文字可能会出现轻微的色彩溢出。但 99% 的自然场景看起来毫无差别。 ### 位深（Bit Depth） 即每个通道用多少位来表示： | 位深 | 每通道取值范围 | 每像素可表示的颜色 | 应用场景 | |-----------|------------------|-----------------|---------| | **8 位** | 0–255 | 1670 万 | 大多数消费级流媒体 | | **10 位** | 0–1023 | 10.7 亿 | **HDR 必备**；Netflix 4K、蓝光 | | **12 位** | 0–4095 | 687 亿 | 影视母版、Dolby Vision | 8 位通常够用，但在平滑的渐变上（例如从深蓝逐渐过渡到浅蓝的天空），会出现明显的**色带**（banding）——不自然的阶梯状分界。HDR 内容需要 10 位来消除这种现象。 --- ## 帧率（fps） **fps** = 每秒帧数（frames per second）。 - **24 fps**：自 1920 年代以来的电影标准，带来那种"电影感"。 - **25 / 50 fps**：PAL 制式电视（欧洲、中国）。 - **29.97 / 30 fps**：NTSC 制式（北美、日本）。大多数手机录制的默认值。 - **60 fps**：游戏、体育、YouTube 高帧率视频。 - **120 / 240 fps**：慢动作、专业级拍摄。 为什么电影 24 fps 就够了？人的"视觉暂留"效应在大约 16 fps 时便会起作用——你的大脑此时已经看到连续的运动了。24 fps 是 1920 年代"足够流畅 + 最省胶片"的甜蜜点。但对于快速动作（体育、游戏），则需要 60 fps 以上来避免运动模糊。 留意一下 29.97 fps——这可不是打错了。NTSC 彩色电视故意把频率偏移了一点，以避免与黑白信号相互干扰。 帧率越高，文件越大。在相同分辨率和画质下，60 fps 的体积大约是 30 fps 的 1.7 倍。 --- ## 码率：每秒消耗多少数据 **码率**（Bitrate）是指每秒视频所消耗的比特数。 - **kbps**（千比特/秒）：1 Mbps = 1000 kbps - **Mbps**（兆比特/秒）：常用单位 文件大小 ≈ 码率 × 时长： ``` 1 Mbps × 60 seconds ÷ 8 (bits to bytes) ≈ 7.5 MB ``` ### 典型码率（H.264） | 分辨率 | 推荐码率 | 1 分钟文件大小 | |-----------|-------------------|----------------| | 240p | 0.3–0.5 Mbps | ~3 MB | | 360p | 0.5–0.8 Mbps | ~5 MB | | 480p | 0.8–1.2 Mbps | ~8 MB | | 720p | 1.5–3 Mbps | ~15 MB | | 1080p | 3–6 Mbps | ~30 MB | | 4K | 15–30 Mbps | ~150 MB | ### CBR / VBR / CRF 三种码率控制模式： | 模式 | 含义 | 类比 | |------|---------|------| | **CBR**（恒定码率） | 每秒固定比特数 | 每次都正好点 2 个菜 | | **VBR**（可变码率） | 复杂场景多给比特，简单场景少给 | 饭量大的多点，饭量小的少点 | | **CRF**（恒定质量因子） | 质量保持恒定，码率随之变化 | 不管点什么，都吃到八分饱为止 | VOD 偏好 **VBR 或 CRF**——在相同文件大小下画质更好。直播偏好 **CBR**——码率可预测，网络传输更稳定。 --- ## I 帧、P 帧、B 帧：视频压缩的核心 这是本章最关键的概念。理解了它，编解码器那一章的内容便会豁然开朗。 ### 视频为什么能被如此激进地压缩？ 想象一段视频：一个人坐在沙发上看电视： ``` Frame 1: Person on couch, TV playing animation Frame 2: Person on couch, TV playing animation (TV image changes slightly) Frame 3: Person blinks, TV playing animation Frame 4: Person on couch, TV playing animation ``` **相邻两帧之间 99% 的像素都是完全相同的。**把每一帧都完整存下来是巨大的浪费。 聪明的做法是： - 偶尔存一张"完整快照" - 其余时间只存"相比上一帧发生了什么变化" ### 三种帧类型 | 类型 | 全称 | 内容 | 大小 | 能否独立解码？ | |------|-----------|---------|------|--------------------------| | **I 帧**（关键帧） | 帧内编码（Intra-coded） | 一张完整图像（类似 JPEG） | **大** | 能 | | **P 帧** | 预测帧（Predicted） | "与前面某一帧的差异" | **小** | 不能——需要先有参考帧 | | **B 帧** | 双向预测帧（Bidirectional） | "与前一帧和后一帧的差异" | **最小** | 不能——需要前后两个参考帧 | ``` Timeline → I - P - P - P - B - P - P - B - I - P - P - P ... ▲ ▲ Keyframe Next keyframe (appears every N frames) ``` ### IDR 帧 **IDR 帧**（Instantaneous Decoder Refresh，即时解码刷新）是一种特殊的 I 帧：它之后的所有帧都被禁止引用它之前的任何内容。IDR 帧是"安全的起始点"。当你把进度拖到视频中间时，播放器会跳到最近的 IDR 帧开始解码。 ### GOP（图像组，Group of Pictures） **GOP** 是两个 I 帧之间的那一组帧： ``` ┌──── GOP 1 ────┐ ┌──── GOP 2 ────┐ ┌──── GOP 3 ... I P B P P B I P B P P B I P ... ▲ New IDR starts here ``` **GOP 长度**决定了分片的粒度： - **短 GOP（1–2 秒）**：分片更细，拖动和起播更快；文件略大（I 帧更多） - **长 GOP（4–10 秒）**：文件更小，但拖动更慢 短视频 App 通常采用**短 GOP（1–2 秒）**，因为用户会在不同片段之间频繁滑动切换。长片 VOD 则可以采用更长的 GOP 来节省带宽。 --- ## 色彩空间与 HDR ### 色彩空间 同一组 RGB 数值，在不同标准下会显示出*不同的实际颜色*： | 标准 | 应用场景 | 色域大小 | |----------|---------|-----------| | **sRGB** | 网页、电脑 | 基准 | | **BT.709** | 高清电视、1080p 流媒体 | ≈ sRGB | | **BT.2020** | HDR、4K/8K | 比 BT.709 大约 72% | | **DCI-P3** | 电影、Apple 生态 | 介于 BT.709 与 BT.2020 之间 | ### HDR：更亮的亮部、更暗的暗部、更丰富的色彩 传统 SDR 的峰值亮度约为 100 尼特（nits）。**HDR** 可达到 1,000–4,000 尼特的峰值亮度，再结合 10 位位深 + BT.2020 色域： - 夜空中的星星显得更亮 - 阴影中的细节得以保留 - 颜色更饱和且不会溢出（clipping） 主流 HDR 格式： | 格式 | 出品方 | 关键特性 | |--------|------|------------| | **HDR10** | 蓝光光盘协会 | 免版税；每部电影使用静态元数据 | | **HDR10+** | 三星 / Amazon | 每个场景使用动态元数据 | | **Dolby Vision** | Dolby | 12 位、动态元数据；画质最高；**需付版税** | | **HLG** | BBC / NHK | 兼容 SDR 显示器；广播首选 | 请注意：HDR 视频在 SDR 显示器上并不会神奇地更好看。如果不做**色调映射**（tone mapping），它看起来会灰蒙蒙、发白。 --- ## 动手实践：用 ffprobe 检查一段视频 ```bash # macOS / Linux brew install ffmpeg # or: apt install ffmpeg # Inspect a video ffprobe -v error -show_streams -select_streams v:0 myvideo.mp4 ``` 典型输出： ```ini codec_name=h264 # Codec (H.264) — see Part 2 profile=High # Encoding profile width=1920 height=1080 # Resolution: 1080p r_frame_rate=30000/1001 # Frame rate: 29.97 fps pix_fmt=yuv420p # Pixel format: YUV 4:2:0, 8-bit color_space=bt709 # Color space: SDR bit_rate=4500000 # Bitrate: 4.5 Mbps ``` 读完本章，上面每一行你都应该能看懂。 --- ## 核心要点 1. 视频 = 一连串图像 + 音频。每一张图像就是一**帧**。 2. 每一帧由**像素**组成；**分辨率**就是像素的尺寸。 3. 视频世界使用 **YUV 4:2:0**（数据量只有 RGB 的一半，肉眼无差别）。 4. **位深**：8 位是标准；HDR 需要 10 位。 5. **帧率**：24 fps（电影）/ 30 fps（电视）/ 60 fps（游戏/体育）。 6. **码率** = 每秒数据量。VOD 首选 VBR/CRF。 7. **I/P/B 帧**是视频实现 50–100 倍压缩的方式。 8. **GOP** = 关键帧之间的那组帧。短视频使用短 GOP（1–2 秒）。 9. **HDR** = 10 位 + 更宽色域 + 更高亮度——与 SDR 有着本质区别。 --- ## 三对处处可见的概念 在深入之前，先把这三对概念钉牢： 1. **编解码器 ≠ 封装容器**——H.264 是一种压缩算法（编解码器）；MP4 是一种文件格式（封装容器）。一个 `.mp4` 文件里可以装 H.264，*也可以*装 H.265，*或*装 AV1。 2. **协议 ≠ 封装**——HLS 和 DASH 是"如何分发"的规则（协议）；fMP4 和 TS 是"如何切片和封装"的格式（封装）。 3. **加密 ≠ DRM**——HLS AES-128 是轻量级加密（密钥一旦泄露就全盘皆输）。DRM 则是一整套体系：密钥分发 + 设备限制 + 输出保护。 这三对概念都会在本系列中详细展开。 --- *下一篇：一部 4K 电影是如何塞进 5 GB 的？* → **[第 2 篇：视频编解码器——H.264、H.265 与 AV1](/blog/vod-deep-dive-part-2-video-codecs-h264-h265-av1/)** --- ## 常见问题 ### 视频里的 I 帧、P 帧、B 帧有什么区别？ I 帧（关键帧）存储一张完整图像，可以独立解码，类似一张 JPEG；P 帧只存储与前面某一帧的差异，体积小得多；B 帧同时参考前后两帧的差异，体积最小。由于相邻帧之间绝大部分像素完全相同，只记录差异而不是每帧都存完整画面，正是视频能实现 50–100 倍压缩的核心原理。 ### 视频为什么用 YUV 4:2:0 而不是 RGB？ 因为人眼对亮度的敏感度远高于对颜色。YUV 把亮度（Y）和色度（U、V）分开存储，编码时保留全部亮度信息，让相邻四个像素共用一组色度数据。这种 4:2:0 采样把数据量压到 RGB 的一半，而肉眼几乎察觉不到差别，所以几乎所有消费级流媒体都采用它。 ### 电影为什么是 24 帧而不是 60 帧？ 人的视觉暂留效应在大约 16 fps 时就能让大脑感知到连续运动，24 fps 已经足够流畅。它是 1920 年代“足够流畅 + 最省胶片”的折中方案，沿用至今并形成了独特的电影感。体育、游戏等快速画面才需要 60 fps 以上；而帧率越高文件越大，同等条件下 60 fps 的体积大约是 30 fps 的 1.7 倍。 --- ## 参考资料 - [FFmpeg documentation](https://ffmpeg.org/documentation.html) — FFmpeg - [H.264: Advanced video coding](https://www.itu.int/rec/T-REC-H.264) — ITU-T