企业官网建设流程全解析

破滅のマルス的生肉实况做到第三期，已经完结。三期内容没有现成的中文字幕，制作链路覆盖游戏画面采集、日文OCR识别、翻译辅助、字幕烧录和最终压制发布。这篇文章不聊游戏剧情，只聊这套实况视频是怎么做出来的，以及如果你想复现同样的流程，每一步需要准备什么、容易在哪里卡住。

先说结论：这套流程不需要一个月只做一个视频的中间商工具，核心就四个东西。OBS Studio负责录制，ffmpeg负责剪切、合并、压制和字幕烧录，OCR工具负责把游戏里的日文对白从画面上抓出来，最后用Python或Shell脚本把这些步骤串成批处理。硬件门槛也不高，常见六核CPU加16GB内存就能跑，显卡支持NVENC、AMD VCN或Intel QSV会舒服很多，没有独显也能用x264软件编码，只是压制速度更慢。

整条链路最花时间的不是录制，而是生肉内容的字幕处理。游戏内对话框的字体、背景、清晰度都会影响OCR识别率，识别出来的日文还要经过翻译和校对。这一步想完全自动化很难，但可以通过脚本把重复劳动压缩到最小。

本文会从环境准备开始，一路讲完OBS录制参数、OCR字幕工作流、ffmpeg批量压制、自动化投稿思路、性能观察方法和常见问题排查。适合准备做游戏实况、想做外语游戏生肉视频、或者想把多期视频批量处理成统一格式的读者。

1. 核心能力速览

这里需要强调一点：上表中的显存和硬件建议是通用部署基准。录制场景下显存占用通常不高，真正的资源压力来自视频编码和后续OCR/翻译模型。实际数字会因为游戏分辨率、编码器、帧率和后台程序不同而变化，不要拿一个固定数值套所有情况。

2. 适用场景与使用边界

这套流程适合谁？最典型的就是游戏实况创作者。你录了一款没有官方中文的日文游戏，想自己加上翻译字幕再发布，录制、识别、翻译、压制全链路都在本地完成。其次是经常做多期视频的作者，比如一个系列录了十期原始素材，每期需要相同的转码参数，脚本跑一遍就能生成统一格式的成品。

它还适合需要批量处理视频素材的场景。比如你手里有一批会议录屏、课程录像或直播回放，需要统一裁剪片头、压制到指定分辨率、添加字幕，ffmpeg脚本比一个个手动处理高效得多。

不适合的场景也很明确。第一，如果你的核心需求是直播实时字幕，这套后期流程不适用，直播场景需要实时OCR和实时翻译链路。第二，如果视频素材体量非常大，又要求尽快交付，单机脚本不如云端转码服务。第三，如果你完全不会看日志，遇到报错就不知道从哪下手，那建议先用现成的剪辑软件做一期，再考虑脚本化。

使用边界必须说清楚。游戏画面、角色立绘、背景音乐、字体资源都属于游戏开发商的版权内容。录制游戏实况并上传到视频平台，需要遵守平台关于游戏内容的规定。翻译字幕如果参考了其他汉化组的文本，也要特别注意版权问题。商业用途、二次创作、素材再分发之前，先确认版权授权，不要等收到投诉再处理。涉及真人声音、人脸、个人信息的素材，同样要获得当事人明确授权。

3. 环境准备与前置条件

3.1 操作系统

Windows、Linux、macOS 都可以。Windows 下安装 OBS 和 ffmpeg 最省事，Linux 服务器跑批量压制脚本更稳定。下面的命令示例同时给出 Windows PowerShell 和 Bash 两种写法，实际用哪种看你的主力环境。

3.2 软件依赖清单

版本号不要照抄网上旧教程。ffmpeg 的构建版本直接决定有没有 libx264、有没有 libass、能不能用 subtitles 滤镜烧录字幕。建议先运行ffmpeg -version确认输出里包含--enable-libx264和--enable-libass，没有这两个特性，后面的压制和字幕命令会直接报错。

3.3 硬件建议

CPU 建议六核以上，压制 x264 时多核心优势明显。内存 16GB 起步，OCR 处理超大截图或同时打开多个工程文件时会从容一些。显卡方面，NVIDIA 的 NVENC、AMD 的 VCN、Intel 的 QSV 都能做硬件编码，好处是录制时 CPU 压力小，坏处是画质和码率控制不如 x264 slow 预设精细。如果显卡太老或者没有独立显卡，就用 x264 保底。磁盘空间是经常被忽略的坑，录制一小时的 1080p 视频轻松超过 10GB，建议给素材单独留 50GB 以上空间，并且尽量放在 SSD 上。

4. 游戏实况录制：采集与推流

4.1 实机采集卡方案

老主机实机录制需要采集卡。PSP 这类设备要先把画面通过色差或 AV 线输出到采集卡，再由 OBS 添加“视频采集设备”来源。采集卡方案的好处是画面来自实机，操作手感真实，坏处是额外硬件成本，而且老主机输出分辨率不高，放大到电脑屏幕上会有点糊。如果你手里的采集卡不支持对应分辨率采集，OBS 里看到的画面可能会黑屏或花屏，先检查采集卡的输入规格。

4.2 模拟器录制方案

以 PSP 模拟器 PPSSPP 为例，在电脑上运行游戏，再用 OBS 捕获窗口。好处是不用采集卡，录制窗口画面稳定，可以随时用 OBS 截图。坏处是对电脑性能有要求，模拟器渲染必须保证流畅，否则录出来的视频会一卡一顿。建议先用 PPSSPP 自带的开销显示确认游戏帧率稳定，再开始录制。

OBS 捕获窗口时，不要把窗口最小化，也不要用窗口模式切换游戏分辨率。更稳妥的做法是使用“显示器采集”或“窗口采集”加裁剪，让输出画面固定在一个分辨率，避免后期出现黑边。

4.3 OBS 录制参数建议

录制参数没有绝对唯一解，但中间格式建议用 MKV。MKV 不怕录制中途断电或程序崩溃，文件损坏的概率比 MP4 低很多，录完再转成 MP4 发布。编码器优先选硬件编码，比如 NVIDIA NVENC H.264，如果显卡不支持就换 x264。分辨率从 720p/30fps 起步，机器能稳定跑满再尝试 1080p/60fps。

音轨设置容易被忽略。建议把游戏声音和麦克风分成两条音轨录制，后期压制时可以只保留游戏声音，也可以把两条混在一起。如果后续要剪辑，最好在 OBS 里开启自动重连和录像缓冲，这样剪辑时不会因为掉帧导致音画不同步。

5. 生肉实况字幕处理：OCR 与翻译辅助

“生肉”指没有现成翻译字幕的原始内容。生肉实况的后期核心，是把游戏画面里的日文对白识别出来，翻译成目标语言，再做成字幕。这一步做得好，整期视频的观看体验会明显提升；做得不好，识别结果乱七八糟，翻译也无从下手。

5.1 用 ffmpeg 从视频中提取关键帧

手工截图效率太低，用 ffmpeg 按时间点批量截取更直接。下面命令从input.mkv的 5 分 23 秒处截取一帧，保存为frame_052300.png。

ffmpeg -ss 00:05:23 -i input.mkv -frames:v 1 frame_052300.png

如果对白比较密集，可以写一个循环，每 10 秒截一帧，跑完再从结果里挑包含文字的帧。截图分辨率越高，OCR 识别率越好，所以尽量在原始分辨率下截图，不要提前缩放。

5.2 日文 OCR 识别

PaddleOCR 提供日文识别模型，使用方式比较直接。需要注意不同版本接口有差异，实际运行时先查看当前版本的帮助文档。

# 以本机安装的 PaddleOCR 版本为准，接口可能有差异 from paddleocr import PaddleOCR ocr = PaddleOCR(lang="japan") result = ocr.predict("frame_052300.png") print(result)

如果不想用 Python，Tesseract 也可以在命令行下做日文识别。

tesseract frame_052300.png out -l jpn

Tesseract 的优点是安装简单，缺点是日文长文本识别效果通常不如 PaddleOCR，容易把汉字和假名混在一起。识别质量受游戏字体、文字背景、屏幕噪点影响很大，遇到对话框底纹复杂的情况，先把截图做一次灰度化和对比度增强，再丢给 OCR，效果会好很多。

5.3 翻译与校对

OCR 拿到文字后，翻译环节可以用外部翻译 API，也可以用本地翻译模型。这里要提醒：如果游戏文本被发送到外部翻译服务，文本内容就经过了第三方平台，发布前要确认游戏文本的版权允许这样做。批量翻译前，先拿 10 到 20 条文本测试，确认输出语言风格、术语准确性和配额都符合要求。

翻译结果不能直接当最终字幕。OCR 识别错误会直接导致翻译偏离原意，校对时建议把 OCR 原句和翻译结果放在同一行，逐条过一遍。游戏里的专有名词、角色名、物品名最好维护一个术语表，三期系列里统一使用。

5.4 生成字幕文件

把校对后的文本整理成 SRT 格式，每一条字幕包含序号、时间轴和文本。

1 00:00:01,000 --> 00:00:04,000 第一句翻译后的字幕文本 2 00:00:05,000 --> 00:00:08,000 第二句翻译后的字幕文本

SRT 文件用 UTF-8 编码保存，不要用 ANSI，否则后面烧录字幕时中文和日文容易乱码。

5.5 烧录字幕

想让字幕成为视频画面的一部分，用 ffmpeg 的 subtitles 滤镜烧录。下面命令把sub.srt烧进input.mp4，输出为output.mp4。

ffmpeg -i input.mp4 -vf "subtitles=sub.srt" -c:v libx264 -c:a aac output.mp4

这个命令依赖 ffmpeg 编译时开启 libass 支持。如果报错说找不到 subtitles 滤镜，就得更换 ffmpeg 构建版本。烧录字幕之前先在 10 秒的小片段上试一次，确认字体、位置、时间轴都正常，再对完整视频下手。

6. 视频剪辑与批量压制

6.1 按片段剪切

录制素材里如果有多余的片头片尾，用 ffmpeg 裁剪。

ffmpeg -ss 00:01:00 -i input.mkv -t 30 -c copy cut_1.mkv

-ss指定开始时间，-t指定时长。加-c copy是流复制，不重新编码，速度快但切得不够精确；需要精确到帧时，去掉-c copy，代价是重新编码耗时更长。

6.2 合并视频

把多个片段合并成一个文件，先创建一个文本文件list.txt，列出所有要合并的文件。

file 'cut_1.mkv' file 'cut_2.mkv'

再执行合并命令。

ffmpeg -f concat -safe 0 -i list.txt -c copy merged.mkv

注意，所有片段的编码参数、分辨率、帧率必须一致，否则直接流复制合并会出现音画不同步。最稳妥的做法是先统一转成相同参数，再合并。

6.3 批量压制脚本

一个系列里多期视频往往需要统一转码。Windows 下用 PowerShell 写循环。

Get-ChildItem -Path .\videos -Filter *.mkv | ForEach-Object { ffmpeg -i $_.FullName -c:v libx264 -preset medium -crf 18 -c:a aac "$($_.BaseName).mp4" }

Linux 或 macOS 下用 Bash。

for f in ./videos/*.mkv; do ffmpeg -i "$f" -c:v libx264 -preset medium -crf 18 -c:a aac "${f%.*}.mp4" done

-crf 18在 x264 里属于接近无损的画质，适合高质量成品；如果发布平台之后还要再转码，可以适当提高 CRF 到 20 或 23。批量压制时建议先只跑一个文件，确认输出参数正确，再放开循环跑全量，避免一晚上跑出一批不想要的文件。

7. 自动化投稿与批量任务

如果一个系列包含多期视频，发布前还有大量重复劳动：检查文件名、核对字幕、统一封装格式、计算时长。这些可以用脚本先做一遍基础检查。

建议给自己定一套命名规则，例如mars_ep03_final.mp4。配合 ffmpeg 的-metadata参数，可以在压制时写入标题、作者、备注信息，减少上传前的手工编辑。

如果要走平台自动投稿接口，需要以对应平台官方开放平台的文档为准。不要相信网上流传的旧版 API 字段，授权方式、鉴权 token、上传限制都会变。一般流程包括：申请开发者权限、获取鉴权凭证、上传视频文件、等待审核结果。批量上传时要注意平台的速率限制，建议每次上传之间加延时，并记录每个文件的返回状态，失败的上传任务要能单独重试。

自动上传前，先在测试账号上跑通完整流程，不要直接操作正式账号。

8. 资源占用与性能观察

录制时，游戏程序、模拟器、OBS 三者在同一台机器上同时运行，CPU 和内存压力最大。开启 NVENC 硬件编码后，CPU 占用会下降，但显卡显存会多出一部分用于编码。具体占多少显存，要看游戏分辨率和编码参数。建议打开任务管理器或 GPU-Z，观察录制过程中的显存占用趋势，不要在录第一视角视频时才发现显存不够。

压制阶段 x264 是 CPU 密集任务。-preset medium是性能和画质的平衡点，veryslow压缩率更高但速度慢很多。如果电脑要同时做其他事情，压制脚本可以和 OCR、翻译步骤分开运行，避免互相抢资源。

降低资源占用可以从几个方向入手。录制时先 720p/30fps，机器稳定后再向上调。压制时大文件分批发，不要同时开多个 ffmpeg 进程。剪辑阶段如果电脑卡顿，可以先转出低分辨率代理文件，剪辑完成后再用原始素材全分辨率导出。另外，OCR 和本地翻译模型也可能占用显存，如果用大模型跑翻译，显存需求会明显上升，务必给这些环节预留资源。

9. 常见问题与排查方法

一个容易被忽略的问题：OBS 录制的 MKV 文件如果和 ffmpeg 后缀参数不一致，会出现 ffmpeg 无法自动识别音轨的情况。可以先用ffmpeg -i input.mkv查看文件内置的流信息，确认视频流、音频流都正常，再执行压制命令。

10. 最佳实践与使用建议

第一次接触整套流程，不要直接拿完整视频开跑。先录一段 10 秒的游戏片段，依次跑通录制、截图、OCR、翻译、生成 SRT、烧录字幕、输出 MP4，全流程没有问题再开始正式素材。这样能快速暴露编码器、字体、路径等基础问题。

项目目录建议固定下来，素材和脚本分开管理。

mars_series/ ├── raw/ # 原始录制文件 ├── frames/ # OCR 截图 ├── subs/ # SRT / ASS 字幕文件 ├── final/ # 压制成品 └── scripts/ # 批处理脚本

批量任务务必加日志。每个脚本在关键步骤打印一条记录，记录处理了哪个文件、是否成功、消耗了多少时间。出现失败时，靠日志定位问题，不要通篇打印刷屏。

涉及游戏素材和翻译内容的版权问题，发布前一定要确认授权范围。游戏画面用于实况是否被允许，翻译文本是否可以商用，字幕字体是否可以嵌入视频，这三个问题每个都可能踩雷。另外，如果实况中用到其他创作者的音乐或音效，也要单独确认授权。

发布前至少完整看一遍成品视频，重点检查字幕错字、时间轴偏移、音画同步。AI 驱动的 OCR 加翻译流程虽然能省不少时间，但自动生成的内容始终需要人工复核。

11. 总结与下一步

破滅のマルス这个系列做完整套流程，最值得试的点，是把录制、OCR、翻译、压制、上传准备用本地脚本串起来。现在最该先验证的功能，是用 OBS 录一段短素材，再用 ffmpeg 跑通转码和字幕烧录。最容易踩的坑集中在 ffmpeg 构建版本、字幕文件编码和 OCR 识别质量这三个地方，第一次做的时候优先确认这三项。

后续可以继续扩展的方向有三个。第一，把 OCR 结果自动整理成 SRT，做成一个从截图到字幕的半自动脚本。第二，把批量压制参数抽成配置文件，不同系列用不同配置，避免每次改命令行。第三，如果平台开放官方接口，尝试把上传环节也纳入脚本流程，彻底把重复劳动交给程序。希望这套流程能帮你少走几步弯路。