SRT字幕烧录实战：用 Rendi 自动生成带字幕 MP4

先说结论：SRT字幕该烧录还是外挂？

如果无论播放器如何处理字幕轨，每位观众都必须看到相同字幕，就应当烧录 SRT。若观众需要关闭字幕、切换语言或使用播放器的无障碍控制，则应保留独立 SRT。

使用 Rendi 时，可靠的流程是：

1. 对照检查最终视频与 SRT。
2. 将两个文件放在 Rendi 能抓取的 URL 上，或先把本地文件上传到 Rendi。
3. 提交文档规定的 FFmpeg 字幕命令。
4. 轮询 command ID，或通过 webhook 接收最终结果。
5. 在继续提交更多任务前，检查 MP4 元数据并完整观看输出。

这个顺序很重要。即使编码成功，只要字幕提前出现、人名写错，或文字被平台界面遮住，成片依然不合格。

Rendi 实际负责什么

Rendi 负责执行，不负责编辑。你提交的仍是本来会在本地运行的 FFmpeg 指令，只是改为通过 HTTP API 执行。可以把一次请求理解成加工单：输入别名告诉机器原料在哪里，FFmpeg 字符串规定要做什么，输出别名则为成品命名。

当前请求结构要求提供 ffmpeg_command 和 output_files。输入键必须以 in_ 开头，输出键必须以 out_ 开头，这些名称还要以双花括号形式出现在命令中。提交成功后会返回 command_id，它就是这项任务的取件凭证。

最简单的做法，是把视频和 SRT 放在公开 HTTP URL 或有时限的签名 HTTP URL 上，并让文件名出现在 URL 末尾。笔记本电脑上的本地路径不能充当输入 URL。Rendi 也提供用于本地文件的 multipart 直接上传流程，支持最大 5 TB 的文件，但那是另一个准备步骤。

烧录字幕与可选字幕轨是两种交付物

烧录字幕会成为每一帧解码画面的一部分。它的显示效果更可控，但这个决定也是永久的：改一个错别字就要重新渲染视频，观众也无法隐藏字幕。

可选字幕轨与画面保持分离。Rendi 自己的字幕示例建议在 MP4 中使用 mov_text 作为软字幕轨，并省略视频滤镜。这样既保留观众的控制权，也不会把文字烙进画面。

我的判断标准很直接：如果必须保证视觉一致，就为审核母版或社交平台交付文件烧录字幕。同时保留原始 SRT；凡是涉及无障碍、搜索、翻译或观众选择的场景，都应提供可选字幕轨或外挂字幕文件。

花钱渲染前，先把 SRT 查清楚

最省钱的渲染，就是无需重做的那一次。请用 SRT 对照最终剪辑版，而不是更早的导出版本。逐项确认字幕顺序、起止时间、人名和数字的拼写、刻意安排的换行，以及有代表性的重音字符或非拉丁字符。还要留意字幕是否撞上画面下方的图文条，或离底边太近。

不要在心里把 AI 转写混进这个步骤。语音识别可以在上游生成 SRT 初稿，但只有文字与时间轴经过人工或可信审核流程批准后，文件才应进入这里。Rendi 在这个环节只负责渲染。

用 Rendi 提交带样式的 SRT字幕烧录任务

下面的 Node.js 示例使用 Rendi 的公开视频样本和 SRT 样本，因此运行时只需要 RENDI_API_KEY。请求体采用 Rendi 当前 OpenAPI 中的字段名和别名规则。force_style 会生成带黑色描边和底部边距的白色字幕，libx264 与 AAC 则按 Rendi 的字幕方案输出 MP4。

const headers = {
  "X-API-KEY": process.env.RENDI_API_KEY,
  "Content-Type": "application/json",
};

const submit = await fetch("https://api.rendi.dev/v1/run-ffmpeg-command", {
  method: "POST",
  headers,
  body: JSON.stringify({
    input_files: {
      in_video: "https://storage.rendi.dev/sample/big_buck_bunny_720p_16sec.mp4",
      in_srt: "https://storage.rendi.dev/sample/subtitles.srt",
    },
    output_files: { out_1: "subtitled.mp4" },
    ffmpeg_command:
      "-i {{in_video}} -vf \"subtitles={{in_srt}}:force_style='FontSize=22,PrimaryColour=&H00FFFFFF,OutlineColour=&H00000000,BorderStyle=1,Outline=2,Shadow=0,MarginV=36'\" -c:v libx264 -crf 20 -c:a aac -b:a 192k {{out_1}}",
  }),
});

if (!submit.ok) throw new Error(await submit.text());
const { command_id } = await submit.json();

for (;;) {
  const poll = await fetch(
    `https://api.rendi.dev/v1/commands/${command_id}`,
    { headers: { "X-API-KEY": process.env.RENDI_API_KEY } },
  );
  const job = await poll.json();
  if (job.status === "SUCCESS") {
    console.log(job.output_files.out_1);
    break;
  }
  if (job.status === "FAILED") throw new Error(job.error_message);
  await new Promise((resolve) => setTimeout(resolve, 2000));
}

字幕滤镜会改动画面帧，因此必须重新编码视频。样式、编码器和质量都可以调整，但每次改动都应视为新的输出，并重新验收。Rendi 官方的 FFmpeg 速查表还说明了如何通过 fontsdir 与 FontName 使用自定义字体。批量应用前，务必用实际字体和字形集合进行测试。

实际验证了什么

2026 年 9 月 11 日，上述 API 端点、请求字段、别名规则、状态值和响应字段均对照 Rendi 当前的 OpenAPI 文件完成检查。同一个字幕滤镜也在本地使用 FFmpeg 8.0.1，针对 Rendi 的公开视频和 SRT 样本实际运行过。最终生成了一段 16 秒、1280 × 720 的 MP4，视频为 H.264、音频为 AAC；视频第 5 秒的一帧中可以清楚看到预期字幕。

由于当前环境没有 Rendi API key，因此没有提交 Rendi 云端任务。代码已按请求结构核对，FFmpeg 操作也已在本地验证，但本文不声称完成过云端执行。

短任务用轮询，长任务用 webhook

Rendi 的状态端点可能返回 QUEUED、PROCESSING、PREPARED_FFMPEG_COMMAND、FAILED 或 SUCCESS。POST 被接受并不代表视频已经完成。必须等待最终状态；失败时显示 error_message，成功后再读取输出。

Rendi 建议，对预计约 30 秒或更短的任务使用轮询，更长的任务则使用 webhook。webhook 携带的已完成命令数据与轮询相同。用于生产环境时，完成处理器应保持幂等、快速返回；如果 webhook 最终投递失败，还要保留轮询作为恢复路径。

敏感输出可以在付费套餐中设置 is_private: true，并在轮询时申请预签名 URL。默认使用公开存储。私有文件没有永久公开 URL，申请的下载链接最长只能有效 7 天。

批量处理前，先验收输出

SUCCESS 只证明 FFmpeg 已经完成，并不证明字幕合格。机器可读的响应和实际画面都要检查。

先确认 output_files.out_1 存在，而且其中的 storage_url 可以打开。把返回的时长、尺寸、编码和文件格式与交付目标逐一核对。然后完整观看视频，重点检查第一条字幕、最后一条字幕、语速最快的对话、换行、人名、数字，以及剪辑点或图形叠加附近的字幕。

通过这轮审核后，才能把同一套样式预设送进队列。把源视频版本、SRT 版本、FFmpeg 命令、Rendi command ID、输出文件 ID 和审核决定存放在一起。这样才能把零散的渲染结果变成一套生产系统。

成本看字节，不看时长

Rendi 按输入媒体与输出媒体的合计大小计量。它的价格示例把 1 GB 输入加 0.5 GB 输出计为 1.5 GB 处理量。严格按这个示例计算，Free 套餐的 50 GB 额度可以完成 33 个完整任务，并剩余 0.5 GB；入门 Pro 套餐的 250 GB 则可完成 166 个完整任务，并剩余 1 GB。

这些任务数量只是根据 Rendi 示例得出的算术结果，并非字幕处理基准数据。真实的字幕烧录 MP4 可能更大，也可能更小，取决于源文件、编码设置和输出。预测处理量前，应先测量自己的输入加输出总量。

Free 套餐每月 $0，包含 50 GB 处理量，单条命令的运行上限为 1 分钟。入门 Pro 套餐每月 $25，包含 250 GB，并把单条命令上限提高到 10 分钟。Rendi 完整价格解析已经介绍了更高 CPU 配置和不限运行时长的方案，这里无需重复整张价格表。

真正值得比较的是操作方式。Kapwing Pro 按年付费时标价为每位成员每月 $16，按月付费则是 $24。偶尔处理一个视频，图形化编辑器更省事；如果字幕收尾已经成为一项可重复的系统步骤，由已批准素材触发并全程留痕，而且无需再让人打开编辑器，Rendi 就更合适。

最值得自动化的 7 类工作流

最适合的并非所有需要添加字幕的人，而是已经有审核通过的 SRT，并不断重复最终渲染的团队。

值得做的 3 个产品

1. 品牌安全的批量字幕收尾工具

这是最值得做的产品方向。可以为内容团队和机构搭建一个目标单一的门户：接收视频 URL、已批准 SRT、命名的样式预设，提供审核页面与可下载 MP4。产品卖的是可重复执行与审批能力，而不是一个无所不包的编辑器。

美国每月约有 1,900 次搜索指向 add subtitles to a video，而 Kapwing Pro 按年付费时每位成员每月起价为 $16。这类需求足以带来用户，反复出现的团队工作流又足够具体，可以支撑一款聚焦的产品。

最小可售版本需要签名 URL 输入、SRT 校验、少量锁定的品牌预设、Rendi 任务提交、webhook 处理、输出元数据，以及人工接受或拒绝。难点在于建立壁垒：给一次 FFmpeg 调用套个表单很容易被复制，持久价值必须来自审批历史、可复用品牌规则、版本匹配和可靠的故障恢复。

2. 自动化优先的字幕渲染 API

面向不想让客户接触 FFmpeg 语法的机构，提供一个稳定的 API 端点。客户发送视频 URL、SRT URL、预设名称和回调 URL；服务把预设转换成经过审核的命令，并返回标准化任务结果。

Burn subtitles into video 在美国每月有 40 次搜索，CPC 为 $8.16。搜索量很小，但意图异常明确。PAA 问题“怎样把 SRT字幕永久烧录进视频？”几乎就是一份产品需求。

MVP 需要身份验证、请求校验、Rendi 任务映射、幂等键、webhook 验证、可安全重试的状态和用量记录。难点在分发：单靠搜索无法支撑业务，而且 Rendi 已经开放底层 API。这层封装必须靠机构集成、预设、可观测性和支持服务胜出。

3. 字幕预检与双版本交付

搭建一道审核关卡，用一份 SRT 对照一份最终视频，然后从获批的文件组合中同时生成烧录字幕的审核 MP4，以及带可选字幕轨的交付 MP4。目标客户是经常无法对应字幕版本与剪辑版本的本地化、培训或媒体运营团队。

真实的 PAA 问题“怎样给视频添加 SRT字幕？”与当前搜索结果中反复出现的永久字幕和可选字幕混淆并列。这个产品同时解决两类任务，不必再让操作者独自处理容器格式的细节。

MVP 需要字幕段解析、时长对比、安全区域预览、版本 ID、两套受控 FFmpeg 方案，以及签核记录。难点在于：基础 SRT 校验只是一项功能，不足以独立成为一家公司。审核历史与交付控制必须有足够价值，才能让团队把产品留在发布流程里。

局限与客观看法

Rendi 让这套流程不必自行维护 FFmpeg 基础设施，却没有免除编辑责任。它不会修正转写稿、修复错误时间轴、选择易读的换行，也不会判断烧录字幕是否是正确的无障碍格式。

它也无法让烧录过程无损。字幕滤镜会改变视频帧，所以视频必须重新编码。质量、运行时间和输出大小都取决于命令与源文件。API 默认安全上限为 300 秒，套餐则决定你能申请的最大值。长任务或计算密集型任务，需要选择命令运行时长上限能够容纳实际编码过程的套餐。

如果只是偶尔处理一个视频，而且免费的浏览器工具已经能解决问题，就不要采用这条路径。需要观众开关字幕时，也不要烧录。未经审核的样式更不能批量运行。只有当同一套已批准的收尾规则必须可靠地作用于大量素材时，Rendi 才真正有吸引力。

下一步：先跑通一个样片

选择一段较短、已经批准的视频及其最终 SRT。把两个文件放到可抓取的 URL 上，使用选定样式运行示例请求，检查返回的元数据，再在你支持的最小屏幕上完整观看 MP4。审核通过后才能把这条命令保存成预设，然后将预设接入现有工作流中标记“视频和字幕已批准”的节点。

如果希望把这类经过审核的媒体流程接入业务，可以了解 AI 生产系统。