同样 1080p，为什么有的清晰有的糊？——零基础看懂视频编码这件事

一句话：一个视频清不清晰，从来不是「是不是 1080p」决定的，而是由「分辨率 × 码率 × 编码」三件事一起决定；MP4 只是个「盒子」，根本不代表清晰度。把这篇里的几个词分清楚，你看任何视频文件、发任何平台都不会再懵。

说明：写给完全没接触过视频技术的人。这是「原理篇」，和本栏目已有的几篇 DaVinci 实操文（新手手把手、Speed Editor 上手）互补——那几篇教你「点哪里」，这篇讲清「为什么」。各平台的推荐发布参数为查证后整理，标注了来源与查证日期 2026-07-01；查不到官方数字的地方会老实写明。

0. 先建一张图：决定清晰度的，是「四个分开的东西」

新手最大的痛苦，是把一堆词搅成一团：MP4、编码、H.265、码率、1080p……感觉都在说「清不清晰」，其实它们是四个互不相同、各管一摊的东西。先用一个画画的比喻把它们彻底分开，后面所有细节都挂在这张图上：

像素（pixel）：屏幕上一个个发光的小方点，画面就是由它们拼出来的。1080p = 1920×1080，就是横着 1920 个点、竖着 1080 个点，约 207 万个像素。

记住一句话，下面每一节都是在展开它：

画布（分辨率）只决定格子多不多，每个格子画得准不准，是墨水（码率）和画笔（编码）的事；盒子（MP4）只管装，不管画。

1. 容器 vs 编码：MP4 只是个「盒子」，不是清晰度

这是最该先破除的误会。你看到一个文件叫 电影.mp4，只知道它装在 MP4 这个盒子里，完全不知道里面的画是怎么压的、清不清晰。

• 容器（container）：一个文件「盒子」，里面同时装着【视频流 + 音频流 + 字幕 + 封面 + 一堆说明信息】。常见盒子：MP4、MKV、MOV、WebM、AVI、TS。
• 编码（codec）：盒子里那段视频是用什么算法压出来的。这才是真正干活、决定大小和画质的东西。常见编码：H.264、H.265、AV1。

codec 这个词：是 coder + decoder（编码器 + 解码器）的缩写。编码 = 把原始画面压小存起来；解码 = 播放时把它还原成画面。一存一放，是同一套算法的两头。

★ Insight ───────────────────────────────────── - 同样是 .mp4，里面可能是 H.264 也可能是 H.265，画质体积差一倍。 所以「这是 MP4 所以清晰」是句没意义的话——盒子不背书画质。 - 换盒子常常不用重新压缩。 把 MKV 换成 MP4（叫 remux，「重新封装」），只是把里面的流原样搬进新盒子，几秒完成、零损失。但换编码（H.265→H.264）就必须把画一帧帧重压一遍，又慢又掉质量。分清「换盒子」和「换画笔」，能省掉大量无用功。 ─────────────────────────────────────────────────

怎么一眼看清一个文件「真实身份」？用 ffprobe（ffmpeg 自带的探查工具）：

ffprobe -hide_banner 你的视频.mp4
# 会打印出：容器格式、视频编码(如 hevc=H.265)、分辨率、码率、帧率、音频编码

2. 三代编码：H.264 / H.265 / AV1，到底差在哪

编码（画笔技术）一代比一代强。「强」的意思很具体：同样的清晰度，新编码能把文件压得更小（或者同样大小，画质更好）。代价是新编码压制更慢、播放更费力，老设备可能放不动。

这些都是区间，不是定值——差多少由画面内容、分辨率、压制精细度共同决定（用 VMAF/PSNR 这类「画质打分工具」测）。要点：H.265 和 AV1 相对 H.264 都能省大约一半（H.265 客观测约 35%、主观可达 50% 以上；AV1 约 45–51%，Meta 官方实测 51%）。但网上常说的「AV1 比 H.265 还省 30%」偏乐观——这个差距在 1080p 实测只有约 3%，要到 4K/8K 才拉大到约 40%；「省 30%」其实更接近 AV1 相对更老编码 VP9 的水平。精确数字与来源见文末核查清单。

★ Insight ───────────────────────────────────── - 编码越新越省，不等于越新越好用。 AV1 能省空间，但用 CPU 软压可能比 H.264 慢几十倍；想流畅播放还得设备「硬件支持」（见第 7 节）。所以选编码是一场权衡：发布给大众看 → H.264 最稳妥；自己存档省空间 → H.265/AV1。 - 你前面那个 1.8G 的片子就是 H.265。 同样画质如果用 H.264，体积会接近翻倍。这就是为什么现在手机拍的视频默认越来越多用 H.265（苹果叫「高效」HEVC）。 ─────────────────────────────────────────────────

3. 码率：清晰度的「油门」，也是「同样 1080p 有的糊」的真正答案

码率（bitrate）= 每秒钟用多少 bit（数据量）来描述画面，单位 Mbps（兆比特每秒）。这是清晰度最直接的旋钮。

• 码率高 → 每一帧能保留更多细节 → 清晰、干净。
• 码率低 → 编码器数据不够用，被迫扔掉细节 → 出现糊、马赛克方块、运动时拖影。这些瑕疵专业上叫 压缩失真（compression artifacts）。

为什么「同样 1080p，清晰度不一样」？

到这里答案就清楚了。1080p 只规定了「画布是 207 万个格子」，没规定每个格子画得多准。让两个都是 1080p 的视频清晰度天差地别的，是这三件事叠加：

1. 码率给得够不够——预算。2 Mbps 的 1080p 和 10 Mbps 的 1080p，前者糊后者清。
2. 编码新不新——同样码率下 AV1 比 H.264 清晰得多（画笔更好）。
3. 压制用不用心——「快速导出」为了省时间会牺牲画质，「慢速精压」同码率更清。

还有个隐藏杀手：二次压缩（重复压制）。 很多「1080p」其实是别人压过的视频你又压一遍，或者从 720p 硬「拉伸」上来的——画布够大，但细节早被前几轮压没了，再标 1080p 也救不回来。这叫 画质代损（generation loss），第 6 节细讲。

导出时你真正要调的那个旋钮：CRF / 码率模式

剪完导出，控制「画质 vs 体积」有两种思路，新手务必分清：

CRF（Constant Rate Factor，恒定质量因子）：一个数字旋钮，越小越清晰越大，越大越糊越小。经验值：H.264 用 18–24，H.265/AV1 用 23–28。18 接近肉眼无损，28 已经偏糊。

# 定质量导出（推荐）：-cq 23 是目标质量，越小越清晰
ffmpeg -i in.mp4 -c:v h264_nvenc -cq 23 out.mp4
# 定码率导出：卡死 8 Mbps（适合平台有码率上限时）
ffmpeg -i in.mp4 -c:v h264_nvenc -b:v 8M out.mp4

4. 帧率：每秒几张画，别乱改

帧率（frame rate，fps）= 每秒钟播放多少张画面。视频本质是「一张张静止画快速翻播」，翻得越快越流畅。

★ Insight ───────────────────────────────────── - 帧率不是越高越好，关键是「全片统一、和素材一致」。 把 30fps 素材硬塞进 60fps 时间线，软件得「无中生有」造帧，反而可能卡顿或发虚。这就是为什么 DaVinci 导入素材会弹窗问你「要不要把工程帧率改成跟素材一样」——点是，最省事（见 DaVinci 手把手）。 - 慢动作的原理：用高帧率（如 120fps）拍，再按低帧率（如 30fps）播放，等于把同一段时间的画面「摊开慢放」，每一刻都有真实拍到的画面，所以慢下来依然清晰流畅——而不是软件硬生生插出来的。 ─────────────────────────────────────────────────

5. 调色和编码怎么配合：顺序错了，白调

「调色（color grading）」就是调整画面的明暗、冷暖、鲜艳度和风格——从「手机直出的平淡」变成「有电影味」。它和编码的关系，关键在一个字：顺序。

整条流水线的正确顺序是：

拍摄/录制  →  剪辑  →  调色  →  ①导出压缩（你这一关）  →  平台再压一次（第8节）
（高质量源）  （排片）  （调风格）   ↑ 压缩永远放最后一步

为什么调色必须在压缩之前？ 因为压缩会「扔细节」。如果你先把视频压小（细节扔了）再调色，等于在一张已经损失的画上动刀，暗部一拉就是一片噪点和断层。先在最完整的画面上调好，最后才压，才留得住细节。

一个进阶但重要的词：8-bit vs 10-bit（色彩位深）

位深（bit depth）= 每个像素能表达多少种颜色层次。8-bit 每个通道 256 级，10-bit 是 1024 级。10-bit 在调色时优势巨大：天空、渐变这类地方拉曲线不容易出现一圈圈「色带（banding，本该平滑过渡却变成一层层台阶）」。

★ Insight ───────────────────────────────────── - 调色这件事「在哪做」本栏目已有手把手：三个调色轮（Lift/Gamma/Gain）、LUT（一种「一键套色」的预设滤镜）怎么用，见 DaVinci 新手手把手 的调色节。这篇只讲「为什么压缩要放在调色之后」这个原理。 - 想认真调色，拍的时候就要给「料」：用 10-bit、甚至 Log（一种故意拍得灰平、把明暗信息尽量保留下来等后期再还原的方式）。料给得足，后期空间才大；手机直出的 8-bit，调色一狠就崩。 ─────────────────────────────────────────────────

6. 剪辑时，不同码率/编码/帧率的素材怎么「配合」

你问到的「不同码率之间剪辑」是个真问题。一条时间线上，素材往往来源杂：手机拍的 H.265、下载的 H.264、录屏的高帧率……它们能不能凑一起剪？

能，但要懂两件事：会发生「重新编码」，以及怎么用「代理」让剪辑变顺。

6.1 一旦混剪 + 加了效果，导出必然「重新编码」

第 1 节说过，纯裁剪可以「流拷贝」不重压。但只要你把多段拼一起、调了色、加了字幕转场，导出时软件就必须把整条时间线重新算一遍、重新压一遍（re-encode）。这时：

• 所有素材会被统一成你导出设置的那一种编码 / 分辨率 / 帧率 / 码率——杂来源不再是问题，出来是一致的成片。
• 但每重压一次，画质就掉一点（generation loss，画质代损）。所以原则是：中间环节尽量保持高质量，只在最后导出压一次。 别压一版传一版、再下回来接着剪——那是越剪越糊。

6.2 素材太大剪不动？用「代理」

代理剪辑（proxy editing）：素材是 4K H.265 时，电脑解码很吃力、拖时间线一卡一卡。解法是先生成一份又小又好解码的「替身」（低分辨率/低码率副本）用来剪，导出时软件自动换回原始高清素材去压。剪得飞快，成片仍是全质量。DaVinci 里叫 Optimized Media / Proxy。

7. 硬件解码 vs 软件解码：为什么同一个视频，有的设备烫、有的不烫

播放视频要「解码」（把压缩的数据还原成画面）。这活有两种干法：

• 硬件解码（hardware decode）：用芯片里专门为某种编码定制的电路来还原。又快又省电，几乎不占 CPU。
• 软件解码（software decode）：芯片里没有对应电路，只能让 CPU 硬算。费电、发热、风扇狂转，老设备甚至卡成幻灯片。

这就解释了一个常见现象：同一个 H.265 视频，新手机/新电脑放得又顺又凉（硬解），一台老电脑放就卡、风扇狂转（被迫软解）。编码越新（H.265→AV1），「硬件支持」的设备就越少、越要新硬件。

硬解到底省多少？ 同行评审研究实测：硬件解码器耗电不到软件解码的 9%；在 MacBook 上软解 AV1 实测比硬解多耗约 10 倍电、性能核全程满载。这就是「老设备放新编码又烫又卡又费电」的根源——不是视频坏了，是它在硬扛 CPU 软解。各设备精确支持代际见文末核查清单。

★ Insight ───────────────────────────────────── - 「编码」和「解码」是两件事，硬件支持也分开。 你那台 5090 显卡能硬件编码（NVENC）H.264/H.265/AV1，导出飞快——这是本栏目 5090 本地 AI 视频 那篇用到的能力。但「能编」不代表观众「能顺畅解」：发布给大众，还得照顾他们设备的解码能力。 - 这是「为什么发布优先选 H.264」的根本原因：不是 H.264 画质最好，而是它谁都能流畅解码。你自己存档可以用 H.265/AV1 省空间，对外发布求稳就用 H.264。 ─────────────────────────────────────────────────

8. 各平台到底该发什么：码率、帧率、分辨率、比例

这是最实用的一节。先讲一个反直觉但关键的事实，否则你会一直纳闷「我发的明明很清楚，怎么到平台就糊了」：

几乎所有平台，你传上去后它都会「再压一次」（re-encode，为了节省它自己的带宽和存储）。你传的是「源」，观众看的是「平台压过的版本」。所以策略是：按平台推荐参数的上限发、甚至略高一点、码率给足，让平台那一道压缩有足够「料」可压，最终观众看到的才清楚。别自己先压到很低再传——那是把糊喂给平台再糊一遍。

下面是各平台的推荐上传参数。横屏看（YouTube/B站）一般 16:9，竖屏看（抖音/小红书/视频号/Reels/TikTok）一般 9:16（即 1080×1920）。

图例：✅ = 已核实为平台官方明文；⚠️ = 平台没有公开规格表，表中数字为社区/行业经验值，请以 App「发布」页实际提示为准。「经验值」不是官方背书——尤其抖音、小红书的码率，各家说法互相矛盾（小红书码率有 6 / 8–12 / 8–15 / 10–20 Mbps 多种说法，不收敛），别当成精确标准。

比例（aspect ratio）：画面的「宽:高」。16:9 是横屏（电视/电脑/横看），9:16 是竖屏（手机竖着刷）。1:1 是正方形，3:4 是小红书常见的竖图比例。发之前先想清楚观众是横看还是竖看，比例错了平台会自动加黑边、很难看。

★ Insight ───────────────────────────────────── - 「发布」是整条链最后一环，前面所有概念在这里汇合：选对分辨率（多数平台 1080p 足够，4K 仅在平台支持且你有 4K 源时才发）、给足码率（让平台再压时有料）、对齐帧率（拍 30 就发 30，别乱改）、选稳的编码（H.264 通吃）、套对比例（横 16:9 / 竖 9:16）。 - 平台会再压，所以纠结自己导出那点画质差没意义到某个程度——把码率给到平台推荐上限就够了，再高只是浪费上传时间，平台照样压。 ─────────────────────────────────────────────────

9. 小结：一张「判断 + 发布」速查

把全文压成一页能用的东西：

① 判断一个视频清不清晰，别只看「是不是 1080p」，看三件事一起：

分辨率（多大）× 码率（多清，最关键）× 编码（多省）。一个 8Mbps 的 H.265 1080p，会明显比 2Mbps 的 H.264 1080p 清楚。

② 自己处理视频的原则：

• 纯掐头去尾 → 流拷贝（-c copy），秒完成、零损失。
• 混剪/调色/加字幕 → 必然重新编码，所以中间保持高质量，最后才压一次。
• 顺序铁律：剪 → 调色 → 压缩导出，压缩永远最后。
• 素材卡 → 用代理剪；有 5090 → 导出走硬件编码。

③ 发布原则：

• 编码选 H.264 求通吃（自己存档才用 H.265/AV1 省空间）。
• 比例：横屏 16:9、竖屏 9:16，别发错。
• 帧率跟素材走，别乱改。
• 码率按平台推荐上限给足——反正平台还要再压一次。

④ 三个最该记住的「分清」：

1. MP4 是盒子，不是清晰度（容器 ≠ 编码）。
2. 1080p 只管画布大小，码率才管清晰度。
3. 能编码 ≠ 能流畅解码（所以发布优先 H.264）。

想动手实操（剪辑、调色、导出预设点哪里），接着看本栏目的 DaVinci 系列：新手手把手、Speed Editor 上手。这篇负责让你「想清楚」，那几篇负责让你「做出来」。

来源与查证

查证日期 2026-07-01。下列数字均经联网核查官方/权威来源；平台没有公开规格表的（抖音、小红书），正文已明确标注为社区经验值。

各平台上传参数

• YouTube 官方《推荐上传编码设置》：support.google.com/youtube/answer/1722171（封装/编码/音频/帧率/SDR+HDR 码率表逐项核实）。
• B站 官方投稿规范（专栏 cv527957）：bilibili.com/read/cv527957；8K 规范来自官方 8K 上线公告。1080P 均码 ≤6Mbps/峰值 ≤24Mbps、AAC ≤320kbps 已核实；二压后下发码率、大会员各档码率官方从未公布，网传数字均为社区实测。
• 抖音：唯一可核实的官方技术规格是开放平台上传 OpenAPI（developer.open-douyin.com，规定 mp4/webm、≥720p、单文件≤100MB、总≤4GB），码率/帧率/编码官方未规定；「1080×1920 / 30fps / 8Mbps」为社区经验值。
• TikTok 官方：Content Posting API（developers.tiktok.com，H.264 推荐、23–60fps、360–4096px、≤4GB/10min）+ 广告规格页（9:16 推荐、码率下限 ≥516kbps）。「1080×1920 / 30fps / 8–15Mbps」为第三方说法。
• 小红书：官方帮助页为 JS 动态渲染、无法核验，无公开规格表；表中均为多家第三方创作者指南的共识，码率无统一口径。
• 视频号 官方：助手帮助中心「作品规则」（比例 0.33–3.0、≥1080p、≤2GB、手机端≤60min、不支持 HDR/GIF）+ 微信开放社区官方防压帖（developers.weixin.qq.com，码率 ≤10Mbps、帧率 ≤60fps、音频 AAC ≥128kbps/48kHz）。
• Instagram Reels 官方：Meta Graph API 媒体规格 + Meta Business 广告规格页（H.264/HEVC、23–60fps、码率上限 25Mbps、9:16、3s–15min）。

编码压缩效率

• H.265 vs H.264：约 25–50%（Wikipedia HEVC 词条；客观 PSNR BD-rate 约 35%、主观 MOS 49.3%、1080p 主观 62%）；Netflix x265 vs x264 实测 35.4–53.3%。
• AV1 vs H.264：约 45–51%（Meta 工程博客 engineering.fb.com，vs x264 Main 实测 51%）。
• AV1 vs H.265：实测约 3%（1080p）→ 44%（8K）（Wikipedia AV1、MDPI Electronics 2024）；网传「省 30%」偏乐观，更接近 AV1 vs VP9（Netflix 实测约 20%）。
• 真实流媒体交付节省小于实验室 BD-rate（Streaming Learning Center）。

硬件解码

• H.265 起点：苹果 A8（2014）、英伟达 GTX 960（2015）、Intel Skylake（2015）。
• AV1 起点：英伟达 RTX 30 / Ampere（官方页，2020）、苹果 A17 Pro（Apple newsroom，2023）/ M3、骁龙 8 Gen 2（2022）、MediaTek Dimensity 1000（2019 发布/2020 上市）、Google Tensor（Pixel 6, 2021）、Intel Tiger Lake（2020）、AMD RDNA2。来源：Wikipedia NVDEC / Apple / 各厂商官方页。
• 能耗：硬解耗电 < 软解的约 9%（arXiv 同行评审综述）；软解 AV1 实测多耗约 10 倍电（独立 powermetrics 实测）。具体瓦数随设备/码率波动，官方未公布精确值。