从 MacBook 的 AV1 开始：一部视频编码编年史

最近一个朋友准备从 Windows 切到 Mac 阵营，让我帮忙看看买哪台 Mac 比较合适。

众所周知，Mac 从 Intel 转向 M 系列芯片之后，无论性能、续航还是日常体验都有了很大变化。从 2020 年的 M1 一路到刚发布的 M6，市面上已经横跨好几代产品，很多开发者手里的 M1、M2 也仍然用得好好的。新款性能更强、支持的功能更多，价格也更高；旧款便宜不少，放到今天又未必不够用。

这样一来，选 Mac 就不只是比较谁的跑分最高，而是在预算、内存、硬盘、便携性和打算使用多久之间做取舍。为了弄清旧款究竟少了什么，我把几代 MacBook 的技术规格放在一起，一项一项往下看。

CPU、GPU 和内存带宽的变化都不难理解。继续翻到媒体引擎时，M2 和 M3 看起来也几乎一样：都能硬件加速 H.264、HEVC、ProRes 和 ProRes RAW，也都有视频编解码引擎。只有 M3 那一栏多出了一行：

AV1 decode

Apple 的 M2 技术规格没有列出 AV1，而 M3 MacBook Air 的技术规格明确写有 AV1 decode engine。Apple 发布 M3 系列时也把它称为媒体引擎第一次支持 AV1 解码，并把收益落在流媒体播放效率和电池续航上。

起初我以为这只是又一个不太常见的视频格式，和普通开发者选电脑关系不大。但 Apple 特意把它单独列出来，视频网站和浏览器又在不断增加 AV1 支持，这行小字就不能只当成规格表里的装饰了。

AV1 到底是什么？平时看的视频里真有 AV1 吗？没有硬件解码就播不了吗？它对功耗、画质和网速能有多大影响，又值不值得成为 M2 和 M3 之间的购买理由？要回答这些问题，就不能只盯着 MacBook 的规格表，而要先看看一段视频究竟是怎样被压缩、传输和重新播放出来的。

MacBook 播放 AV1 的选流与解码路径

AV1 是什么

AV1 的全名是 AOMedia Video 1。它和 H.264、H.265 一样，是一套视频编码格式：标准规定压缩后码流怎样组织，也规定解码器怎样把码流还原成一帧帧画面。

它不是播放器，也不是文件后缀。一个 .mp4 文件可以装 H.264、H.265 或 AV1；一个 .mkv 文件也可以装这些编码。MP4、MKV、MOV、WebM 是容器，H.264、H.265、VP9、AV1 才是容器里视频轨所用的编码格式。

AV1 由开放媒体联盟 AOMedia 推动。AOMedia 2015 年成立，创始成员包括 Amazon、Cisco、Google、Intel、Microsoft、Mozilla 和 Netflix，目标是在免版税专利政策下发展面向互联网的开放媒体标准；AV1 规范在 2018 年发布。这里的「免版税」更准确地说是联盟对标准及其必要专利所采用的政策目标，不应被理解成世界上绝不会出现任何专利争议，但它确实让浏览器、流媒体平台和芯片厂商有了一个不同于 HEVC 授权体系的选择。AOMedia 对这段历史有一份简明说明。

AV1 想做的事并不神秘：在主观画质相近时，比上一代编码少传一些数据；或者在码率相同时，保住更多细节。困难在于它提供了更多块划分、预测、变换和滤波工具，编码器要从更大的候选集合里寻找好方案，因此编码通常更慢，软解码也比老格式更吃计算资源。

这正是专用硬件存在的理由。

「硬件支持」究竟支持了什么

播放视频包含两个方向相反的动作：

  • 编码：把原始画面压成 H.264、HEVC 或 AV1 码流，发生在拍摄、导出、直播推流和平台转码时。
  • 解码：把已经压缩的码流还原成画面，发生在你点开视频观看时。

Apple 给 M3 写的是 AV1 decode。看 AV1 视频时，为这类码流设计的专用电路可以接管大量固定、重复的计算，不必一直占用 CPU 核心或让 GPU 运行通用解码程序。通常结果是 CPU 占用更低、风扇更安静、电池消耗更少，也更容易稳定播放 4K、8K 或高帧率内容。

如果设备没有 AV1 硬解，也不代表视频一定播不了。实际还有两条路：

  1. 平台发现设备不合适，改发 VP9、HEVC 或 H.264 版本。
  2. 播放器用 CPU 做软件解码。

第一条路最常见，因为大型平台本来就会给同一内容准备多种分辨率、码率和编码版本。第二条路是否顺畅，则取决于 CPU 性能、视频分辨率、位深、帧率和软件解码器。1080p 可能毫无压力，4K60、8K 或 10-bit 内容就更容易表现出占用、发热和续航差异。

WebKit 在 Safari 17 加入 AV1 视频支持时，边界写得很明确：只在有 AV1 硬件解码能力的设备上支持。WebKit 后续还会在可选的多路视频中优先考虑可硬解版本，因为硬解会显著影响功耗和电池时间。这也说明「芯片支持、操作系统支持、浏览器支持、网站下发」缺一不可。

哪些视频资源已经在用 AV1

AV1 已经不是只存在于测试实验室里的未来格式，但平台也不会把所有内容、所有清晰度都统一切成 AV1。

来源 AV1 现状 使用时要注意什么
YouTube 已支持 AV1 播放和 AV1 直播输入；播放器可按设备与内容选择 av01 码流 不是每条视频、每个清晰度都会拿到 AV1；右键播放器打开 Stats for nerds 可看当前 codec
Netflix 2020 年先在 Android 上部署，随后扩展到电视和浏览器；Netflix 2025 年披露 AV1 已约占其流量的 30% 实际下发仍受设备认证、内容和播放能力影响
哔哩哔哩 2022 年开始在 PC 点播部署，已有自研 BILIAV1 编码器 网页播放器会按设备与播放策略选择 AV1、HEVC 或 AVC，并非所有稿件都有完整三路
本地下载与自制视频 MP4、MKV、WebM 都可能承载 AV1 容器能打开不代表视频轨能硬解，还要看播放器、系统和芯片

YouTube 的官方直播编码文档已经把 AV1、HEVC 和 H.264 一起列为可用输入编码。YouTube 早在 2018 年就用 AV1 测试播放列表验证点播；Chrome 70 的媒体更新说明记录了当时的播放入口。现在更直接的确认办法仍是播放器统计信息：codec 以 av01 开头就是 AV1，以 vp09 开头是 VP9，以 avc1 开头通常是 H.264。

Netflix 的路径很有代表性。它先在 Android 上用 dav1d 软件解码验证收益，再进入电视和浏览器硬件生态；到 2025 年，Netflix 技术团队称 AV1 已承担约 30% 的串流。哔哩哔哩则在自研 BILIAV1 的复盘里提到，PC 点播业务已上线 AV1 转码，并说明了其块划分、预测、变换和环路滤波工具。

本地文件可以用 ffprobe 看视频轨：

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,profile,pix_fmt,width,height,r_frame_rate \
  -of default=noprint_wrappers=1 input.mkv

看到 codec_name=av1 就说明文件里是 AV1。至于播放时有没有走硬解，还要继续看播放器的解码信息或系统功耗，单看文件格式无法判断。

回到购买问题：这个影响大吗

如果 M2 和 M3 的价差明显，AV1 不应该压过内存、硬盘、屏幕尺寸和整机成色成为第一优先级。M2 仍能通过其他编码版本看绝大多数在线视频，也能用软件方式处理部分 AV1 内容。

但下面几类使用方式，会放大 M3 这类具备 AV1 硬解芯片的优势：

  • 经常在电池供电时看 YouTube、Netflix、B 站等在线视频；
  • 经常看 4K、8K、高帧率或 10-bit AV1；
  • 外接高分辨率显示器长时间播放；
  • 保存、整理大量 AV1 本地片源；
  • 打算把电脑用很多年，希望跟上平台逐渐增加的 AV1 下发比例。

反过来，如果你的主要工作是剪辑并导出视频，就要把「解码」和「编码」分开看。M3 的 AV1 decode engine 能帮助读取 AV1 素材，但 Apple 公布的媒体引擎规格没有列出 AV1 硬件编码。导出 AV1 时，具体速度仍取决于软件编码器、应用实现和通用计算性能。此时 ProRes、H.264、HEVC 的媒体引擎数量、内存容量和持续性能通常更值得优先比较。

到这里，购买问题已经能回答了。但如果继续追问「为什么一种新编码能让芯片规格单独多出一行」，就会走进视频压缩真正有意思的部分。

为什么视频非压不可

视频最朴素的形态就是每秒播放很多张图片。假设一帧是 1920 × 1080，帧率 30 fps，用 8-bit RGB 保存，每个像素需要 3 字节：

1920 × 1080 × 30 × 3 = 186,624,000 bytes/s

也就是每秒约 186 MB，一分钟超过 11 GB。即使先转成常见的 8-bit YCbCr 4:2:0，平均每个像素约 1.5 字节，1080p30 仍接近 93 MB/s。这样的数据量不适合日常存储，更不可能直接塞进普通家庭网络持续传输。

压缩之所以可行，是因为真实视频不是随机噪声。它至少有三类可以利用的冗余。

视频压缩利用的三类冗余

空间冗余来自同一帧。天空、墙面、皮肤和桌面上的邻近像素往往相似，没有必要逐个独立描述。

时间冗余来自相邻帧。镜头没有切换时，大部分画面只是物体移动、镜头平移或局部变化，也没有必要每帧从头写一遍。

感知冗余来自人眼。我们通常对亮度边缘更敏感，对色度细节和某些高频信息更宽容，因此常见视频会使用 4:2:0 色度采样，也会在量化时有选择地舍弃不容易察觉的细节。

无损压缩只能消除可完全还原的统计冗余，空间有限。在线视频真正依赖的是有损压缩：允许重建画面和原始画面有差异，只要这种差异在目标码率下尽量不碍眼。

一条延续三十多年的主线

现代视频标准名称很多，主干却很稳定。它们大多属于「混合视频编码」：

  1. 把画面切成块；
  2. 从当前帧邻域或其他参考帧里预测这个块；
  3. 原始块减去预测块，得到残差；
  4. 对残差做变换，让能量集中到少量系数；
  5. 量化系数，把次要细节变粗，制造大量 0；
  6. 对模式、运动向量和系数做熵编码；
  7. 在编码器内部重建并滤波，作为后续帧的共同参考。

视频编码器的核心流水线

编码器先猜画面，再只写猜错的部分。

例如画面里有一个向右移动六个像素的方块。最笨的方法是把下一帧所有像素重新写一遍；帧间预测会在参考帧里找到相似方块，记录一个「向右 6 像素」的运动向量，再只保存新露出的背景、遮挡边缘和预测不准的纹理。预测越准，残差越接近 0，后面就越容易压缩。

量化是有损压缩最主要的损失来源。它把变换系数按一定步长取整，小系数会直接变成 0。QP 越高，量化通常越强，文件越小，细节损失也越明显。CRF、CQ、目标码率这些编码器参数，最终都在影响「每一帧、每一个块该分到多少比特」。

编码器与解码器并不对称。编码器可能试几十种块划分、多个参考帧和大量运动向量，再用率失真代价挑一个方案；解码器不需要重新搜索，只要按码流给出的决定执行。因此同一标准下，编码器可以越做越聪明、越来越慢，而所有合规解码器仍应得到一致的重建结果。

一部视频编码编年史

从 DCT、H.120 到 AV2 的视频编码时间线

1970s—1980s：先有 DCT，再有第一个数字视频标准

模拟电视同样要节省带宽，只是当时主要依靠隔行扫描、限制色度带宽和广播调制完成，还没有今天这种由码流语法约束的数字 codec。画面真正进入计算机后，像素变成可以逐项存储和传输的数字，原始数据量也立刻成了绕不开的问题。

1974 年，Nasir Ahmed、T. Natarajan 和 K. R. Rao 发表离散余弦变换论文。DCT 能把自然图像中分散的像素变化集中到少量低频系数，后续量化就可以优先保留这些主要能量，把许多高频小系数压成 0。JPEG、MPEG 以及 H.26x 家族后来使用的具体整数变换并不完全等同于原始 DCT，但「先把信号换到更容易取舍的变换域」从此成为压缩的基本手法。

1984 年的 H.120 是第一个国际数字视频压缩标准，初版使用条件更新、DPCM、标量量化和变长编码，1988 年修订版又加入运动补偿与背景预测。它运行在 1544 或 2048 kbit/s，实际部署很少，却把数字视频从研究方法推到了国际标准。ITU 对视觉编码历史的回顾把 H.120 称为第一个标准，把随后出现的 H.261 称为第一个商业上成功的数字视频编码标准。

1990：H.261 把混合编码骨架搭起来

H.120 证明数字视频可以形成国际标准，H.261 则把这条路线带进可实际部署的视频会议系统。它面向 ISDN 上的可视电话和视频会议，码率以 p × 64 kbit/s 组织。ITU 的 H.261 文档写明标准在 1990 年形成、1993 年修订。

H.261 已经有今天熟悉的轮廓：宏块、运动补偿、离散余弦变换、量化和变长编码。分辨率和工具都很有限，但「帧间预测处理时间冗余，变换编码处理空间冗余」的组合从这里稳定下来。

1992—1994：MPEG 把数字视频送进消费市场

MPEG-1 面向 CD-ROM 一类数字存储介质，后来最广为人知的落点是 VCD。它让带 I、P、B 帧的 GOP 结构走进大规模消费场景：I 帧独立解码，P 帧参考过去，B 帧可以利用前后参考得到更准预测。

MPEG-2 随后把目标转向数字电视、卫星广播和 DVD，也就是 ITU-T H.262。它支持更高码率、隔行视频和更丰富的 profile/level，最终成为广播和光盘时代的基础设施。MPEG 的历史页把 MPEG-1 的批准时间列为 1992 年、MPEG-2 列为 1994 年。

这两代标准已经说明一个现实：编码格式能否成功，不只看压缩率。采集设备、制作软件、传输网络、光盘、机顶盒、电视芯片和专利授权必须一起形成生态。

1996：H.263 把低码率视频继续往前推

H.263 仍然面向低码率通信，但运动补偿精度、可选编码工具和画面格式更灵活。它在早期网络视频、视频会议和 Flash Video 时代留下过很深的痕迹，也成为 H.264 之前的重要过渡。

2003：H.264 成为互联网视频的共同语言

H.264 同时也叫 AVC、MPEG-4 Part 10。三个名字指向同一套联合标准。它在 2003 年获批，ITU 对初版 H.264 的说明直接列出了视频会议、数字存储、电视广播、互联网流媒体和通信等目标场景。

H.264 的基本编码单元仍是 16 × 16 宏块，预测分区则可以继续拆小。新增工具包括帧内预测方向、多参考帧、四分之一像素运动补偿、整数变换、CABAC 熵编码，以及重建过程中的去块滤波。

这些工具被组合成一套便于硬件实现、解码负担可控、又能明显节省码率的标准。Blu-ray、网络视频、手机拍摄、监控、视频会议、直播推流几乎都能找到 H.264。二十多年后，它依然是最可靠的兼容性兜底。

2013：HEVC 面向 4K，VP9 面向开放 Web

分辨率从 720p、1080p 走向 4K 后，16 × 16 宏块开始显得局促。H.265/HEVC 改用最大 64 × 64 的 CTU，并允许按四叉树递归划分：平坦区域用大块减少描述开销，遇到边缘、纹理和复杂运动再拆成小块。

HEVC 还有更多帧内预测方向、更大变换尺寸、更灵活的运动补偿，以及去块滤波之外的 SAO。Tiles 和 WPP 帮助并行处理。ITU 在 2013 年公布 HEVC 时，把目标描述为相较 H.264 用约一半码率提供相当质量。这个数字是标准设计和当时测试的目标级表达，不是对任何片源、任何编码器都成立的固定折扣。

HEVC 很适合 4K、HDR、广播、摄像设备和受控播放链路，但其专利许可由多个池和权利人构成，Web 生态的实现与分发选择因此更谨慎。同一时期，Google 推动 VP9，为 YouTube 和 WebM 生态提供一条更开放的路线。Google 的文档仍将 VP9 描述为 YouTube 使用的自适应流媒体编码。

视频编码从此更明显地分成多条生态路线：电视与设备链路大量使用 HEVC，Web 平台大量使用 VP9，H.264 继续覆盖最广兼容面。

2018：AV1 把开放生态与高压缩效率合到一起

AV1 吸收了 VP9、Daala、Thor 等项目的经验，同时由流媒体平台、浏览器厂商、芯片厂商和设备厂商共同参与。它仍然沿用预测、残差、变换、量化、熵编码的主干，但给编码器提供了更大的工具箱。

  • 超级块常用 128 × 128，也可使用 64 × 64，并支持比 HEVC 更丰富的非方形划分；
  • 帧内预测方向和模式更多，还包含适合屏幕内容的调色板、帧内块复制等工具；
  • 帧间预测支持复合预测、全局运动、局部扭曲运动等模型；
  • 变换尺寸和类型组合更丰富；
  • 去块滤波之后还有 CDEF 与 Loop Restoration；
  • Film Grain Synthesis 可以先去掉难压的随机颗粒，再把颗粒模型写进码流，由解码端重建相似质感。

AOMedia 的 AV1 工具说明对 CDEF、Loop Restoration 等模块给出了完整定义。工具越多，编码器越有机会找到省码率的表达方式，但搜索空间也越大。这就是早期 AV1 编码很慢、硬件解码普及又格外重要的原因。

AV1 并不存在一个对所有内容都恒定的「比 HEVC 小 20%」结论。结果会随片源、分辨率、画质指标、编码器版本、preset 和调参变化。更稳妥的理解是：AV1 为平台提供了更高的压缩上限，特别适合可以离线慢慢转码、随后向大量用户重复分发的点播业务；实时直播和个人导出则更看重编码速度与硬件能力。

H.264、H.265 与 AV1 的编码工具箱对比

2020 以后：标准继续前进，生态不会瞬间搬家

H.266/VVC 在 2020 年获批，继续减少超高清、HDR、360 度视频达到相同质量所需的码率。AV1 的下一代 AV2 规范则已在 2026 年发布。AOMedia 的客观指标测试显示，在相同质量下 AV2 相对 AV1 约可少用 30% 码率；软件实现会先成熟，硬件支持随后跟进，AV1 与 AV2 也会长期共存。AOMedia 对 AV2 落地节奏的解释很值得读。

这恰好能反过来解释 MacBook 的规格表：标准发布只是起点。编码器要成熟，浏览器和操作系统要接入，平台要完成转码，芯片要加入解码单元，设备还要经历几年换代。2026 年已经有 AV2，并不意味着今天买电脑就该跳过 AV1；相反，AV1 正处在规范成熟、内容增长、硬件广泛进入设备的实际部署期。

三种常见编码该怎么理解

维度 H.264 / AVC H.265 / HEVC AV1
最突出的优势 兼容性最好、编码快、硬件普及 4K/HDR 与受控设备链路成熟 开放 Web 生态、压缩上限高
基础块思路 16 × 16 宏块及子分区 最大 64 × 64 CTU，四叉树划分 最大 128 × 128 超级块，划分更丰富
编码复杂度 相对较低 明显高于 H.264 通常更高，具体看编码器和 preset
常见场景 通用分发、会议、录屏、兼容兜底 4K/HDR、Apple 设备、电视与摄像链路 YouTube、Netflix、B 站等大规模点播和新设备
主要顾虑 同画质所需码率较高 授权与 Web 兼容边界复杂 老设备硬解不足，编码耗时较长

不要把 codec 名称直接当成画质排名。一条认真编码的 H.264 高码率视频，完全可能比一条被压得太狠的 AV1 更好看。画质由片源、码率、分辨率、位深、色度采样、编码器实现、preset 和率控策略共同决定。

编码标准也不等于编码器实现。x264 输出 H.264，x265 输出 HEVC；libaom、SVT-AV1、rav1e 和 BILIAV1 都可以输出 AV1。标准只规定「合规码流如何解」，没有替编码器决定搜索策略，所以不同 AV1 编码器的速度和压缩效果仍会差很多。

用一次小实验把概念落地

如果本机 FFmpeg 构建包含对应编码器，可以选一段 20 到 30 秒、同时有静态细节和快速运动的视频，分别压成三版：

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -an out-h264.mp4
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -an out-hevc.mp4
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 32 -preset 6 -an out-av1.mkv

这些 CRF 数值不能横向当成同一画质刻度，只适合作为实验起点。观察时至少看四件事：

  1. 文件大小与实际码率；
  2. 编码耗时；
  3. 暗部、文字边缘、头发、树叶、水面和快速运动处的伪影；
  4. 播放时 CPU 占用、功耗，以及播放器是否显示硬件解码。

你会很快发现，视频编码从来不是「越新越好」这么简单。新标准提供更高上限，但也要求更多计算和更完整的生态；慢 preset 可能省下一些码率，却要花成倍时间；固定码率便于控制带宽，CRF/CQ 则更适合让简单镜头少花、复杂镜头多花。

最后再看那行 AV1 decode

现在回到最开始的 MacBook 对比表，那一行小字已经可以被翻译成更具体的话：

当视频平台决定给这台电脑一条 AV1 码流时，M3 可以让专用媒体引擎负责解码，M2 则需要平台换一路编码，或让软件承担更多计算。

它不会改变屏幕分辨率，不会替低码率片源凭空补出细节，也不是 AV1 导出加速器。它真正改善的是一条越来越常用的播放路径：同样的画质，用更少网络数据；同样的码流，用更少通用计算和电量解开。

所以，选 MacBook 时可以这样排序：先选够用的内存、硬盘、屏幕和整机性能；如果 M2 与 M3 的其他条件接近，AV1 硬解是一个真实、有长期价值的加分项。它不是非买不可的功能，却也绝不是规格表里为了凑行数写下的装饰。

从 H.261 到 AV1，再到刚刚发布的 AV2，视频编码三十多年都在做同一件事：用更多聪明的计算，少搬一点重复的像素。芯片规格表里的每一个新 codec 名字，背后其实都是网络带宽、算法复杂度、专利生态和几十亿台播放设备共同走过的一段历史。