导出参数对照表：1080P、H.264、9:16 或 16:9、码率按平台要求设

一、为什么“导出参数”值得单独写一篇长文

在视频工程领域，导出参数长期处于一种尴尬位置：它足够重要，重要到直接决定画质、体积与平台审核通过率；又足够琐碎，琐碎到很多人只记住“1080P、H.264、码率拉满”这九个字。但当同一份素材要同时投放到抖音、B站、YouTube Shorts、视频号与小红书时，这九个字立刻失效——因为每个平台的转码管线、码率阈值与画幅偏好并不相同。

本文的核心主线是：以平台分发约束为起点，反推编码参数，而不是以剪辑软件默认值为起点。这条主线贯穿全文。笔者认为，导出参数的本质是一道“约束满足问题”：分辨率、编码标准、画幅、码率、帧率、色彩空间、音频编码共同构成解空间，平台规范与终端解码能力构成约束条件，而创作者要做的，是在可行域内找到画质与体积的帕累托最优。

这一视角并非凭空而来。MPEG 与 ITU-T 联合制定的 H.264 标准（ITU-T Rec. H.264 / ISO/IEC 14496-10）在设计之初就强调“面向网络友好”，其档次（Profile）与级别（Level）机制本身就是为不同分发场景预留的约束接口。本文评述：把导出参数视为约束满足问题，能解释为什么“同一参数在不同平台表现不同”——因为约束变了，最优解自然要变。

1.1 三个常见误区

误区一：分辨率越高越好。4K 导出后上传到只支持 1080P 播放的通道，平台会二次压缩，反而可能因码率分配不当导致画质下降。YouTube 官方帮助文档明确指出，上传高分辨率素材有助于其 VP9/AV1 转码保留更多细节，但这建立在码率充足的前提下，并非无条件成立。

误区二：码率越高越清晰。码率与画质的关系存在明显的边际递减。当码率超过内容复杂度所需阈值后，继续增加只会增大文件体积，对主观画质提升有限。Netflix 在其编码技术博客中多次讨论过“感知码率”概念，强调内容自适应编码（CAE）比单纯堆码率更有效。

误区三：9:16 就是 16:9 裁一刀。画幅变更涉及安全区、字幕位置、主体构图与平台 UI 遮挡区域，简单裁剪往往导致关键信息被裁掉或与平台按钮重叠。本文将在第四章详细展开。

1.2 本文的阅读方式

如果你只想要一张对照表，可直接跳到第六章；如果你正在排查“为什么上传后变糊”，第八章的排查清单更实用；如果你关心未来两三年编码趋势，第九章值得一读。全文尽量保持技术叙述而非学术论文腔调，但所有关键数据均标注来源，模拟与整合数据会明确说明。

二、分辨率：1080P 不是终点，而是分发基线

1080P 指 1920×1080 像素的逐行扫描画面，约 207 万像素。它之所以成为分发基线，是历史、带宽与终端三方博弈的结果。从 DVD 的 720×480 到 Blu-ray 的 1920×1080，再到流媒体的自适应码率，1080P 恰好卡在“多数终端能流畅解码”与“多数网络能稳定传输”的交汇点。

2.1 分辨率与像素密度的关系

分辨率决定像素总量，但人眼感知的清晰度还取决于观看距离与屏幕像素密度。ITU-R BT.2020 与 BT.2100 建议书给出了不同分辨率下的最佳观看距离参考。简单说，手机竖屏观看 1080P 与 4K 的差异，在正常持握距离下并不总是显著；但在大屏电视上，差异会被放大。

本文评述：这张表的关键不在数字，而在最后一列。分辨率选择应由分发场景倒推，而非由拍摄设备上限决定。用 4K 拍摄、1080P 导出是常见且合理的做法，因为拍摄留出裁剪与稳定余量，导出匹配平台基线。

2.2 竖屏 1080P 的特殊性

9:16 竖屏下，1080P 通常指 1080×1920，即短边 1080、长边 1920。注意这与横屏 1920×1080 的像素总量相同（约 207 万），但长宽比互换。部分平台对竖屏上传有单独的码率建议，因为竖屏内容的运动分布与横屏不同——上下滑动时纵向运动更多，编码器的运动估计策略可能需要调整。

TikTok 官方创作者学院与 YouTube Shorts 帮助文档均建议竖屏上传时保持 1080×1920，并避免在上下边缘放置关键文字，因为平台 UI（进度条、按钮、描述）会遮挡。这一建议的工程含义是：竖屏安全区比横屏更窄，导出时需预留边距。

三、编码标准：H.264 的统治力从何而来

H.264（又称 AVC，Advanced Video Coding）由 ITU-T 视频编码专家组与 ISO/IEC 动态图像专家组联合制定，2003 年发布第一版。二十多年过去，它仍是分发端兼容性最好的编码标准。原因不复杂：硬件解码支持广泛、专利池相对成熟、编码工具链完善、平台转码管线长期围绕它优化。

3.1 档次与级别：H.264 的约束接口

H.264 定义了多个档次（Profile），常见的有 Baseline、Main、High。档次决定可用的编码工具集，级别（Level）决定分辨率、帧率与码率的上限。例如 Level 4.0 支持 1080P 30fps，Level 4.2 支持 1080P 60fps。

本文评述：对绝大多数创作者，High Profile 是默认且合理的选择。Baseline 仅在需要兼容极旧设备或极低延迟时使用。把档次选对，比把码率调高更能改善“同码率下的画质”。

3.2 GOP、B 帧与参考帧

GOP（Group of Pictures）指两个 I 帧之间的帧序列。GOP 越长，压缩效率越高，但随机访问与错误恢复能力越差。B 帧通过双向预测提升压缩效率，但增加编码延迟与解码复杂度。参考帧数量影响运动补偿精度。

工程实践中，短视频导出常用 GOP 为帧率的 1 至 2 倍（如 30fps 用 30 或 60），B 帧开启 2 至 3 层。直播场景则倾向短 GOP 甚至全 I 帧，以降低延迟。FFmpeg 中可通过 -g 设置 GOP，-bf 设置 B 帧数量。

ffmpeg -i input.mov -c:v libx264 -profile:v high -level 4.2 \
  -preset slow -crf 18 -g 60 -bf 3 -pix_fmt yuv420p \
  -c:a aac -b:a 192k output.mp4

上述命令中，-pix_fmt yuv420p 是兼容性关键：多数平台与播放器要求 4:2:0 色度采样，若导出为 yuv444p 可能导致部分设备无法播放。本文评述：兼容性优先于理论画质，是分发场景的铁律。

3.3 H.264 与 H.265、AV1 的取舍

H.265（HEVC）在同画质下可节省约 30% 至 50% 码率，但专利授权复杂、部分浏览器与旧设备支持不佳。AV1 开源免专利，压缩效率更高，但编码速度慢、硬件解码支持仍在普及。YouTube 已对部分上传启用 AV1 转码，Netflix 也在其技术博客中讨论 AV1 的部署进展。

笔者认为，未来两三年内，“上传用 H.264 保证兼容，平台侧转 AV1 保证分发效率”会成为主流分工。创作者无需在导出端强行追新，除非目标平台明确支持并推荐。

四、画幅之争：9:16 与 16:9 的构图迁移代价

16:9 是横屏内容的经典画幅，源自电影与电视的宽银幕传统。9:16 是移动端竖屏的原生画幅，随智能手机普及与短视频崛起成为主流。两者并非简单旋转关系，而是两套构图语言。

4.1 安全区与平台 UI 遮挡

竖屏平台通常在底部放置描述与按钮，右侧放置点赞、评论、分享图标，顶部可能有标题或话题标签。这意味着 9:16 画面的有效安全区往往接近中央 1080×1420 甚至更小。导出时若把字幕放在底部 15% 区域，很可能被遮挡。

横屏平台如 B 站、YouTube 的播放器 UI 相对克制，但仍有进度条与控制栏。一般建议横屏字幕距底边至少 5% 至 8%。

4.2 从 16:9 到 9:16 的三种迁移策略

1. 裁剪（Crop）：取横屏画面中央竖条。优点是主体突出，缺点是丢失两侧信息，广角镜头可能变得局促。
2. 模糊填充（Blur Fill）：竖屏画布中放置完整横屏画面，上下用模糊背景填充。优点是信息完整，缺点是有效画面变小，观感偏“搬运”。
3. 重新构图（Reframe）：在剪辑阶段按竖屏逻辑重新安排镜头与字幕。成本最高，效果最好，适合原创内容。

本文评述：三种策略没有绝对优劣，取决于内容类型。访谈、口播适合裁剪；教程、演示适合模糊填充；剧情、Vlog 建议重新构图。关键是在拍摄阶段就决定分发画幅，而不是后期硬转。

4.3 方形与 4:5 的中间态

Instagram 与部分信息流平台偏好 4:5 或 1:1，因为它们在移动端信息流中占据更大视觉面积。若一份素材要覆盖多平台，可考虑“拍摄 16:9、导出 9:16 与 1:1 双版本”，而非只做一个画幅。

五、码率控制：CBR、VBR、CRF 与平台约束

码率控制是导出参数中最容易“调错”的一环。CBR（恒定码率）适合直播与固定带宽通道；VBR（可变码率）适合点播分发；CRF（恒定速率因子）适合追求画质一致性的归档与上传。

5.1 CRF 与 VBR 的工程差异

CRF 模式下，编码器根据内容复杂度动态分配码率，简单画面少给码率，复杂画面多给码率，目标是维持恒定感知质量。VBR 则设定目标码率与最大码率，编码器在约束内波动。平台上传通常建议 VBR 两遍编码或 CRF，因为平台会二次转码，上传码率略高有助于保留细节。

本文评述：对多数创作者，CRF 18 至 23 是安全区间。CRF 越低画质越高、体积越大。若平台有明确码率上限，则改用 VBR 并设置目标码率与最大码率。

5.2 平台码率建议的来源逻辑

平台给出的码率建议通常基于其转码管线的输入要求，而非最终播放码率。例如 YouTube 建议 1080P 上传码率为 8 Mbps 至 12 Mbps（SDR），因为其 VP9/AV1 转码器需要足够码率来保留细节。抖音、B站等平台的建议值可在其创作者帮助中心查到。

需要注意的是，这些建议值会随平台技术更新而变化。本文整理的是截至撰写时可查到的公开信息，实际使用时请以平台最新文档为准。

六、平台码率对照表与来源说明

以下对照表整合了各平台公开帮助文档中的建议值，并标注来源。部分平台未公开精确数值，表中以“建议区间”呈现，并注明为整合数据。

本文评述：这张表的使用方式是“取交集”。若同一视频要投多个平台，建议按最高建议码率导出，再让平台自行压缩。码率略高通常比略低安全，因为平台转码器对高码率输入的容忍度更高。

6.1 音频参数同样重要

音频常被忽视。主流平台建议 AAC 编码、48 kHz 采样率、立体声、码率 128 kbps 至 320 kbps。若源素材为 44.1 kHz，导出时重采样到 48 kHz 可减少平台二次处理带来的音质损失。

七、实操路径：从素材到成品的分步参数配置

以下路径以“一份素材、多平台分发”为目标，给出可复用的步骤。

7.1 第一步：确定分发矩阵

列出目标平台，标注每个平台的画幅偏好、分辨率上限与码率建议。例如：抖音 9:16、1080×1920、8 Mbps；B站 16:9、1920×1080、8 Mbps。若平台要求冲突，优先保证主平台。

7.2 第二步：设定时间线

在剪辑软件中建立对应画幅的时间线。若需双画幅，建议分别建立 16:9 与 9:16 时间线，而非缩放同一时间线。

7.3 第三步：导出母版

导出高质量母版，建议使用 ProRes 422 HQ 或 DNxHR HQ，便于后续多版本导出。若存储有限，可用 H.264 CRF 14 至 16 作为中间版。

7.4 第四步：按平台导出

# 竖屏 1080×1920 平台版
ffmpeg -i master.mov -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" \
  -c:v libx264 -profile:v high -level 4.2 -preset slow -crf 20 \
  -maxrate 10M -bufsize 20M -pix_fmt yuv420p \
  -c:a aac -b:a 192k -ar 48000 output_vertical.mp4

横屏版同理，将 scale 与 pad 改为 1920×1080。注意 force_original_aspect_ratio=decrease 保证不拉伸，pad 填充黑边或模糊背景。

7.5 第五步：校验与上传

用 MediaInfo 或 ffprobe 检查导出文件的编码、分辨率、码率、帧率、色彩空间与音频参数。确认无误后上传，并观察平台转码后的实际播放效果。

八、常见故障与排查清单

本文评述：排查顺序建议从“容器与编码”到“参数细节”，先确认能播，再追求好看。多数“上传后变糊”问题，根源在上传码率不足或分辨率不匹配，而非剪辑软件导出设置错误。

九、前沿预判：AV1、VVC 与平台转码趋势

AV1 由开放媒体联盟（AOMedia）推出，免专利费，压缩效率较 H.265 进一步提升。YouTube、Netflix、Twitch 等平台已在部分场景部署 AV1 转码。VVC（H.266）由 ITU-T 与 ISO/IEC 联合制定，压缩效率更高，但专利与生态仍在推进。

笔者认为，未来分发端的编码分工将更清晰：上传端保持 H.264 兼容，平台侧按终端能力动态选择 AV1、H.265 或 H.264 转码。创作者应关注平台转码策略变化，而非盲目追新编码。

另一个趋势是“内容自适应编码”（CAE）与“感知优化编码”（Per-Title Encoding）。Netflix 在其技术博客中多次分享按内容复杂度分配码率的实践，这意味平台对上传码率的建议可能从“固定值”转向“按内容类型浮动”。

十、结语：把参数变成可复用的决策树

回到开头那条主线：以平台分发约束反推编码参数。1080P 是基线，H.264 是兼容性保险，9:16 与 16:9 是两套构图语言，码率按平台要求设是约束满足。把这四者放进同一决策框架，导出参数就不再是零散口诀，而是一棵可复用、可验证、可迭代的决策树。

本文评述：技术参数会变，平台规则会变，但“先明确约束，再优化目标”的方法不会过时。希望这份对照表与操作路径，能成为你下次点击“导出”前的实用参考。

拓展学习链接

• FFmpeg 官方文档：https://ffmpeg.org/documentation.html
• YouTube 上传编码建议：https://support.google.com/youtube/answer/1722171
• ITU-T H.264 标准页面：https://www.itu.int/rec/T-REC-H.264
• AOMedia AV1 官网：https://aomedia.org/
• Netflix 技术博客：https://netflixtechblog.com/