破滅のマルス的生肉实况做到第三期已经完结。三期内容没有现成的中文字幕制作链路覆盖游戏画面采集、日文OCR识别、翻译辅助、字幕烧录和最终压制发布。这篇文章不聊游戏剧情只聊这套实况视频是怎么做出来的以及如果你想复现同样的流程每一步需要准备什么、容易在哪里卡住。先说结论这套流程不需要一个月只做一个视频的中间商工具核心就四个东西。OBS Studio负责录制ffmpeg负责剪切、合并、压制和字幕烧录OCR工具负责把游戏里的日文对白从画面上抓出来最后用Python或Shell脚本把这些步骤串成批处理。硬件门槛也不高常见六核CPU加16GB内存就能跑显卡支持NVENC、AMD VCN或Intel QSV会舒服很多没有独显也能用x264软件编码只是压制速度更慢。整条链路最花时间的不是录制而是生肉内容的字幕处理。游戏内对话框的字体、背景、清晰度都会影响OCR识别率识别出来的日文还要经过翻译和校对。这一步想完全自动化很难但可以通过脚本把重复劳动压缩到最小。本文会从环境准备开始一路讲完OBS录制参数、OCR字幕工作流、ffmpeg批量压制、自动化投稿思路、性能观察方法和常见问题排查。适合准备做游戏实况、想做外语游戏生肉视频、或者想把多期视频批量处理成统一格式的读者。1. 核心能力速览能力项说明项目类型游戏实况视频制作流程覆盖录制、字幕、压制、批量处理核心工具OBS Studio、ffmpeg、PaddleOCR / Tesseract、Python 3主要功能游戏画面录制、日文OCR、字幕文件生成、视频剪辑、批量压制录制方式实机采集卡录制或模拟器窗口捕获编码方案硬件编码NVENC / AMD VCN / Intel QSV或软件编码x264是否支持批量任务支持通过 ffmpeg 脚本批量转码、加字幕、重命名是否支持接口 API平台投稿接口需以对应平台官方文档为准推荐硬件六核CPU加16GB内存起步独显建议4GB显存以上实际占用需按本机测试适合场景游戏实况制作、外语游戏字幕化、多期视频统一压制、个人自媒体这里需要强调一点上表中的显存和硬件建议是通用部署基准。录制场景下显存占用通常不高真正的资源压力来自视频编码和后续OCR/翻译模型。实际数字会因为游戏分辨率、编码器、帧率和后台程序不同而变化不要拿一个固定数值套所有情况。2. 适用场景与使用边界这套流程适合谁最典型的就是游戏实况创作者。你录了一款没有官方中文的日文游戏想自己加上翻译字幕再发布录制、识别、翻译、压制全链路都在本地完成。其次是经常做多期视频的作者比如一个系列录了十期原始素材每期需要相同的转码参数脚本跑一遍就能生成统一格式的成品。它还适合需要批量处理视频素材的场景。比如你手里有一批会议录屏、课程录像或直播回放需要统一裁剪片头、压制到指定分辨率、添加字幕ffmpeg脚本比一个个手动处理高效得多。不适合的场景也很明确。第一如果你的核心需求是直播实时字幕这套后期流程不适用直播场景需要实时OCR和实时翻译链路。第二如果视频素材体量非常大又要求尽快交付单机脚本不如云端转码服务。第三如果你完全不会看日志遇到报错就不知道从哪下手那建议先用现成的剪辑软件做一期再考虑脚本化。使用边界必须说清楚。游戏画面、角色立绘、背景音乐、字体资源都属于游戏开发商的版权内容。录制游戏实况并上传到视频平台需要遵守平台关于游戏内容的规定。翻译字幕如果参考了其他汉化组的文本也要特别注意版权问题。商业用途、二次创作、素材再分发之前先确认版权授权不要等收到投诉再处理。涉及真人声音、人脸、个人信息的素材同样要获得当事人明确授权。3. 环境准备与前置条件3.1 操作系统Windows、Linux、macOS 都可以。Windows 下安装 OBS 和 ffmpeg 最省事Linux 服务器跑批量压制脚本更稳定。下面的命令示例同时给出 Windows PowerShell 和 Bash 两种写法实际用哪种看你的主力环境。3.2 软件依赖清单软件用途安装建议OBS Studio游戏画面录制、推流官网下载安装包ffmpeg剪切、合并、压制、字幕烧录官网下载构建版或包管理器安装Python 3运行OCR脚本和批量处理脚本官方安装包建议3.9以上PaddleOCR日文文字识别pip 安装注意版本差异Tesseract备用OCR引擎apt / brew / 官方安装包版本号不要照抄网上旧教程。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(langjapan) result ocr.predict(frame_052300.png) print(result)如果不想用 PythonTesseract 也可以在命令行下做日文识别。tesseract frame_052300.png out -l jpnTesseract 的优点是安装简单缺点是日文长文本识别效果通常不如 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 subtitlessub.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 左下角统计信息降低分辨率或码率换 SSD 录制ffmpeg 提示找不到 libx264构建版本未包含 x264 编码器运行ffmpeg -encoders查看安装完整版 ffmpegsubtitles 滤镜无法烧录字幕libass 未开启运行ffmpeg -filters查询改用开启 libass 的构建版本字幕文件乱码SRT 不是 UTF-8 编码文本编辑器查看编码另存为 UTF-8 编码OCR 识别率低游戏字体、背景复杂、截图分辨率不够先在原分辨率截图后测试提高截图分辨率预处理增强对比度字幕时间轴对不上翻译文本长度与原文时长不匹配逐条核对 SRT 时间轴手动调整或按语音停顿分割字幕批量压制中途停止文件路径含空格或特殊字符查看命令行报错日志脚本中给文件路径加引号自动上传接口报错鉴权过期、速率限制查看接口返回的错误码刷新 token、增加延时重试一个容易被忽略的问题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做成一个从截图到字幕的半自动脚本。第二把批量压制参数抽成配置文件不同系列用不同配置避免每次改命令行。第三如果平台开放官方接口尝试把上传环节也纳入脚本流程彻底把重复劳动交给程序。希望这套流程能帮你少走几步弯路。