1. 为什么我把视频字幕提取拆成了"两条腿走路"
视频字幕提取这个活，看起来简单——不就是把字幕从视频里扒出来吗？但真干过的人都知道，坑从第一步就开始了。你拿到一个视频文件，里面到底有没有字幕轨、字幕是软字幕还是硬字幕、编码格式是 SRT 还是 ASS 还是 PGS 图形字幕，这些信息在没探测之前全是未知数。我最早做这套流程的时候，天真地以为 ffmpeg 一条命令就能通吃，结果遇到图形字幕直接给我返回一堆乱码，遇到硬字幕更是连字幕轨都找不到。
所以这套方案的核心思路是：先让 ffmpeg 试探，能软提取就软提取，提取不出来再上 OCR 硬啃。这不是多此一举，而是两种字幕的本质差异决定的。软字幕是独立于画面的文本流，ffmpeg 可以直接解复用拿到；硬字幕是"烧"在画面像素里的，本质上属于图像内容，任何工具都没法直接读出文字，只能靠 OCR 逐帧识别。把这两条路径分开处理，既保证了效率（软字幕几秒钟搞定），又保证了覆盖率（硬字幕兜底），这是我在实际项目里反复权衡后定下来的架构。
先说清楚这套流程适合谁。如果你是要做视频内容归档、字幕翻译、二创素材整理、课程录像转文字稿，或者要给一批历史视频补字幕，这套方法基本可以直接抄。前置要求不算高：会用命令行、装得了 ffmpeg、能跑 Python 脚本就行。OCR 部分我会用 PaddleOCR 举例，因为它对中文的识别效果在我实测的几款里比较稳，但思路是通用的，换成别的 OCR 引擎逻辑完全一样。
整个流程我拆成四个阶段：探测视频信息、尝试软提取、判断失败原因、启动 OCR 兜底。下面挨个拆开讲，包括每一步我踩过的坑和参数怎么定。
2. 动手前必须搞清楚的几个基础概念
2.1 软字幕、硬字幕、图形字幕到底差在哪
很多人把"视频里有字幕"当成一件事，实际上这是三种完全不同的东西，处理方式天差地别。
软字幕（Soft Subtitle）是封装在容器里的独立字幕流，和视频流、音频流并列。MKV 最常见，一个文件里塞七八条不同语言的字幕轨都很正常。这种字幕是纯文本数据，ffmpeg 提取它本质上是"解复用"，不涉及任何图像处理，速度快、准确率 100%。
硬字幕（Hard Subtitle）是压制视频时直接把字幕像素烧进画面了。从文件结构上看，它根本不存在——你拿 ffmpeg 探测，只会看到一条视频流，没有任何字幕轨。想拿到文字，唯一的办法是对画面做 OCR。
图形字幕（Bitmap Subtitle）是个容易被忽略的中间态。它确实是独立的字幕流，能被 ffmpeg 探测到，但内部存的是图片而不是文字。DVD 的 VobSub、蓝光的 PGS 都属于这类。这种字幕 ffmpeg 能"提取"出来，但提取的结果是一堆 .sup 或 .sub 图片文件，直接转文本会失败或者出乱码。
我做个对照表，方便你一眼判断自己手上的视频属于哪种情况：
| 字幕类型 | 容器内是否有独立流 | ffmpeg 能否直接转文本 | 典型来源 | 处理方案 |
|---|---|---|---|---|
| 软字幕（文本型） | 有 | 能，直接转 SRT | MKV 封装、部分 MP4 | ffmpeg 直接提取 |
| 图形字幕（PGS/VobSub） | 有 | 不能，提取出的是图片 | 蓝光原盘、DVD 转制 | 提取图片后 OCR |
| 硬字幕 | 无 | 不能 | 网络视频、录屏、直播回放 | 抽帧后 OCR |
| 无字幕 | 无 | 不适用 | 原始素材 | 只能语音转写 |
这张表是我排查问题的第一道分诊台。拿到一个视频，先看它在表里落在哪一行，方案立刻清晰，不用瞎试。
2.2 ffmpeg 在这套流程里到底扮演什么角色
ffmpeg 不是万能的字幕工具，它的定位是多媒体流的解复用器和转码器。在这套流程里它承担三件事：探测有哪些流、把文本字幕流导出成 SRT、把视频帧按固定间隔抽出来喂给 OCR。它不负责识别画面里的文字，这点必须说清楚，否则你会一直纠结"为什么 ffmpeg 认不出我的字幕"。
我见过不少人卡在这一步，反复调 ffmpeg 参数想让它识别硬字幕，这就是方向错了。ffmpeg 的-map 0:s:0只能选中已存在的字幕流，流不存在，参数调到天亮也没用。理解这个边界，后面的流程才不会走歪。
2.3 为什么 OCR 环节要单独抽帧而不是直接喂视频
OCR 引擎吃的是图片，不是视频。所以硬字幕路线必须先抽帧。这里有个关键权衡：抽帧频率定多少。
按每秒 1 帧抽，一个 1 小时的视频就是 3600 张图，OCR 跑起来要好几分钟；按每 2 秒 1 帧抽，图减半，但如果某句字幕只停留 1.5 秒就可能被漏掉。我的经验值是每 0.5 到 1 秒抽一帧，具体看视频里字幕的停留时长——正常影视剧一句字幕停留 2 到 4 秒，1 秒一帧足够覆盖且有冗余；短视频节奏快，字幕可能只闪 1 秒，就得提到 0.5 秒一帧。
代价是图片数量翻倍，OCR 时间线性增长。所以这一步不是越密越好，得结合你的视频类型和算力预算来定。后面第 4 节我会给出具体的抽帧命令和去重逻辑。
3. 第一阶段实操：用 ffmpeg 探测和软提取字幕
3.1 先探测：一条命令看清视频里有什么
拿到视频第一件事不是急着提取，而是探测。用ffprobe（ffmpeg 套件自带）列出所有流：
ffprobe -v error -show_entries stream=index,codec_type,codec_name:stream_tags=language,title -of json input.mp4这一步会返回 JSON，重点看codec_type为subtitle的条目。如果压根没有 subtitle 条目，说明是硬字幕或无字幕，直接跳到第 5 节的 OCR 流程。如果存在 subtitle 条目，还要看codec_name：
subrip、ass、mov_text：文本型，可以走软提取hdmv_pgs_subtitle、dvd_subtitle：图形型，走 OCR，但素材是提取出来的图片而不是抽帧
我更习惯用一条更直观的命令快速扫一遍：
ffmpeg -i input.mp4 2>&1 | grep -i subtitle输出里会显示类似Stream #0:2(eng): Subtitle: subrip的信息，一眼就能看到字幕轨的编号、语言和编码。编号很重要，后面-map要用。
注意：
ffmpeg -i只是探测，不加输出文件不会真的处理，可以放心跑。但它的信息是输出到 stderr 的，所以命令末尾要加2>&1才能被 grep 捕获，这个细节很多人第一次会漏。
3.2 软提取：把文本字幕流原样导出
确认是文本型字幕流后，提取命令很直接。假设字幕流编号是 0:2：
ffmpeg -i input.mp4 -map 0:2 -c:s srt output.srt拆解一下这几个参数。-map 0:2是选中第 0 个输入文件的第 2 号流，这个编号必须和探测结果对上，选错会得到别的字幕或者报错。-c:s srt指定字幕编码器为 SRT，这个参数的作用是转封装而不是转码——文本字幕在 SRT 和 ASS 之间互转是无损的，这一点和视频转码完全不同，不用担心画质或信息损失。
如果视频里有多条字幕轨，想全部提取，可以这样批量处理：
ffmpeg -i input.mkv -map 0:s:0 sub_0.srt -map 0:s:1 sub_1.srt0:s:0表示"第 0 个输入的第 0 条字幕流"，0:s:1是第二条。这种写法比写死流编号更稳，因为有些容器里流编号不连续，用:s:前缀直接按"字幕流序号"取，不容易错。
实测下来有几点值得记一下。MKV 里的 ASS 字幕转 SRT 时，样式信息（位置、颜色、特效）会丢失，只保留文字和时间轴，这个属于预期行为，如果你要保留样式就别转，直接用-c:s copy导出为 .ass。还有一种情况是字幕轨被标记为forced（强制字幕），通常只包含外语对白的翻译，提取时它和普通轨一样处理，但内容会稀疏很多，别误以为提取失败了。
3.3 提取结果的自检：别急着删原视频
导出 SRT 之后一定要打开抽查，我一般看三个点：文件大小是否合理（几秒的空文件说明提取失败）、时间轴是否连续（断档可能是流损坏）、文字编码是否正常（乱码通常是原始字幕用了非 UTF-8 编码）。
如果是编码问题，可以用-sub_charenc指定源编码：
ffmpeg -i input.mp4 -map 0:2 -c:s srt -sub_charenc GBK output.srt这条命令在我处理一批国产老剧的时候救过场——原字幕是 GBK 编码，不指定的话导出来全是问号。这个参数不常用但必须知道，遇到乱码先想到它。
4. 第二阶段实操：硬字幕的抽帧与预处理
4.1 抽帧命令与参数怎么定
探测不到字幕流，就说明要走 OCR 路线了。第一步是把视频画面抽成图片序列。基础命令：
ffmpeg -i input.mp4 -vf fps=1 frames/%06d.jpg-vf fps=1是视频滤镜，表示每秒抽 1 帧。frames/%06d.jpg是输出模板，%06d表示 6 位数字补零，这样文件名排序和帧顺序一致，后面按顺序读不会乱。实测这个小细节很重要，用%d的话文件名长度不一致，某些读取逻辑会排错序。jpg 后面还可以加-q:v 2控制质量，取值范围 2 到 31，数字越小质量越高，2 已经接近无损，对 OCR 来说完全够用。
如果视频很长，抽帧会占用大量磁盘。1 小时的视频按 1 fps 抽，大约 3600 张图，每张 100KB 左右就是 360MB 上下，还算能接受。但如果是 4K 视频或者要高密度抽帧，磁盘压力就大了，建议先切片段测试，跑通了再全量跑。
4.2 字幕区域裁剪：能省一半 OCR 时间
直接对整帧做 OCR 不是不行，但效率低而且容易误识别——画面里的招牌、台标、水印都可能被当成文字。实际视频里字幕几乎都在画面下方固定区域，把它裁出来单独识别，准确率和速度都会明显提升。
用 ffmpeg 的 crop 滤镜，参数格式是crop=宽:高:x:y：
ffmpeg -i input.mp4 -vf "fps=1,crop=1920:200:0:880" frames/%06d.jpg这条命令的意思是：从坐标 (0, 880) 开始，裁剪一块 1920 宽、200 高的区域，也就是画面底部约 200 像素高的字幕带。具体数值必须根据你的视频分辨率来调，1080p 视频字幕通常落在 y=850 到 y=1000 之间，4K 视频要翻倍。
怎么确定准确位置？我常用的笨办法是：先按原样抽一帧，用图片工具量一下字幕的像素坐标范围，再定 crop 参数。别嫌麻烦，这一步做对了，后面 OCR 的准确率能从六七成提到九成以上。如果视频里字幕位置会浮动（比如有的居中有的靠左），crop 区域就要放宽一些，宁可多裁一点也别把字幕切掉。
4.3 帧去重：OCR 最大的时间陷阱
抽帧之后有个容易被忽略的问题：相邻帧的内容高度重复。一句字幕停留 3 秒，按 1 fps 抽出来就是 3 张几乎一样的图，全送进 OCR 就是三倍浪费。1 小时的视频 3600 帧，实际有效字幕画面可能只有几百个，剩下的全是重复。
我处理的办法是在 OCR 之前做一次图像相似度去重。最简单的实现是计算相邻两帧的哈希值（比如 dHash 或 aHash），差异小于阈值就跳过。用一个 Python 脚本处理：
from PIL import Image import imagehash import os def dedupe_frames(frame_dir, threshold=5): files = sorted(os.listdir(frame_dir)) kept, prev_hash = [], None for f in files: img = Image.open(os.path.join(frame_dir, f)) h = imagehash.dhash(img) if prev_hash is None or (h - prev_hash) > threshold: kept.append(f) prev_hash = h return keptdhash是差值哈希，对亮度变化敏感但计算极快，单张图毫秒级。阈值设 5 是个经验值，太小会把正常变化的字幕误判为重复，太大则去重不干净。实测这个步骤能把 OCR 工作量压到原来的三到四成，是整个流程里性价比最高的优化。
注意：去重只能跳过"和上一帧相同"的画面，如果字幕是淡入淡出效果，相邻帧会有渐变差异，哈希可能判定为不同而保留下来。这种情况问题不大，多几张图而已，别为了极致去重把有效帧误杀了。
5. 第三阶段实操：OCR 识别与结果整理
5.1 PaddleOCR 的安装与最小可用配置
OCR 引擎我选 PaddleOCR，主要原因是中文识别效果稳定、有现成的方向分类器、安装相对省心。安装命令：
pip install paddlepaddle paddleocr第一次运行时它会自动下载模型文件，体积几百MB，需要联网。如果你的环境不能联网，提前在有网机器上跑一次，然后把模型目录拷过去，用det_model_dir、rec_model_dir参数指定本地路径。
最小可用代码：
from paddleocr import PaddleOCR ocr = PaddleOCR(use_angle_cls=True, lang='ch') result = ocr.ocr('frames/000001.jpg', cls=True) for line in result[0]: text = line[1][0] score = line[1][1] if score > 0.8: print(text)lang='ch'指定中文模型，use_angle_cls=True开启方向分类，对横排字幕必要。返回结果里score是置信度，我一般加一个 0.8 的过滤门槛，低于这个值的多半是误识别或者噪声，宁可漏也别让垃圾文本混进来污染后续处理。
5.2 批量识别与进度控制
单张识别验证通过后，就可以批量跑了。这里要注意的是 OCR 是计算密集型操作，CPU 跑起来很慢，一张图几十毫秒到几百毫秒不等，3600 张图就是十几分钟到一个多小时。所以脚本里必须加进度输出和断点续跑能力：
import json from tqdm import tqdm results = [] for f in tqdm(kept_frames): try: res = ocr.ocr(os.path.join(frame_dir, f), cls=True) texts = [l[1][0] for l in res[0] if l[1][1] > 0.8] results.append({"frame": f, "texts": texts}) except Exception as e: print(f"failed on {f}: {e}")用tqdm看进度是基本操作，更重要的是那个 try-except——批量 OCR 里总有那么几张图会出问题（尺寸异常、文件损坏、显存不足），不能让单张失败把整个任务打断。把失败帧记录下来，最后单独重跑，比从头再来省事得多。
显存充足的话可以考虑开 GPU 版，速度提升是数量级的。但要注意批量跑长任务时显存可能缓慢泄漏，我的做法是每处理 500 张重建一次 OCR 对象，代价可以忽略，稳定性明显提升。
5.3 从"每帧文字"到"完整字幕"：合并与去重逻辑
OCR 出来的结果是"帧 -> 文字列表"的映射，还不是可用的字幕文件。中间要做两件事：跨帧合并（同一句字幕在多帧里重复出现）和时间轴重建（把帧序号换算回时间戳）。
合并的核心是判断相邻帧的文字是否属于同一句。我的做法是比较文字相似度，用简单的序列比对：
from difflib import SequenceMatcher def merge_texts(prev, cur, threshold=0.7): if not prev: return cur ratio = SequenceMatcher(None, prev, cur).ratio() return prev if ratio > threshold else cur阈值 0.7 是反复调出来的。OCR 对同一句字幕的不同帧，识别结果往往有一两个字符的差异（标点、模糊字），相似度通常在 0.8 以上；而不同的句子相似度一般低于 0.5，中间这段区间给了容错空间。
时间轴按下式换算：帧序号 / 抽帧帧率 = 起始秒。一句字幕的结束时间取"下一句的起始时间"或"该句最后出现的帧时间"，取两者的较小值。这样生成的 SRT 时间轴虽然不如原始字幕精确，但足以支撑阅读和后续编辑。
生成的 SRT 结构就是标准的：
1 00:00:05,000 --> 00:00:08,000 这一句是识别出来的字幕 2 00:00:08,000 --> 00:00:11,500 下一句内容写文件时注意用 UTF-8 编码，且时间格式必须严格是HH:MM:SS,mmm（毫秒用逗号分隔），这是 SRT 规范的硬要求，写错了播放器直接不认。
6. 常见问题与排查技巧实录
6.1 问题速查表
| 现象 | 可能原因 | 排查与解决 |
|---|---|---|
| ffprobe 看不到字幕流 | 硬字幕或无字幕 | 走抽帧 OCR 路线 |
| 提取出的 SRT 为空 | 选错流编号 | 重新 ffprobe 确认 subtitle 流序号 |
| SRT 内容全是乱码 | 原始字幕非 UTF-8 | 加-sub_charenc GBK或对应编码 |
| 提取出 .sup/.sub 图片 | 图形字幕 | 提取图片后逐张 OCR |
| OCR 结果错字多 | 抽帧密度不足或未裁剪 | 提高帧率、裁剪字幕区域 |
| OCR 速度极慢 | 未去重、CPU 运行 | 加哈希去重、上 GPU |
| 生成 SRT 播放器不认 | 时间格式或编码错误 | 检查HH:MM:SS,mmm与 UTF-8 |
| 字幕有大量重复行 | 未做跨帧合并 | 加相似度合并逻辑 |
这张表基本覆盖了我遇到过的八成问题。用的时候先从上往下扫，落到哪一行就按对应方案处理，不要一上来就怀疑工具本身。
6.2 几个只有踩过才知道的坑
坑一：图形字幕的提取结果不是文本。我第一次遇到 PGS 字幕时，ffmpeg 顺利导出了文件，我还以为成功了，打开一看全是 XML 索引加一堆 .png。图形字幕本质是图片序列，必须走 OCR。判断方法看 ffprobe 的codec_name，是hdmv_pgs_subtitle或dvd_subtitle就立刻切成 OCR 路线，别在提取上浪费时间。
坑二：抽帧的起点偏移。fps=1抽帧默认从第 0 秒开始，但有些视频开头几秒是黑屏或片头，字幕从第 30 秒才开始，这段时间抽出来的全是废帧。可以在滤镜里加时间偏移，或者抽完之后按图片内容过滤掉纯黑帧。我一般用后者，因为纯黑帧的哈希值高度一致，去重步骤顺带就把它干掉了一半。
坑三：中英混排字幕的识别断裂。OCR 有时会把"Hello 世界"识别成两个独立的文本框，导致一句话被拆成两条字幕。处理办法是在合并阶段，如果相邻两个文本块在图像上的 y 坐标接近且 x 坐标连续，就拼接起来。这个逻辑要看 OCR 返回的坐标信息，PaddleOCR 的返回里带框坐标，稍微处理一下就能实现。
坑四：字幕带的动态位置。少数视频（尤其是解说类）字幕位置会上下跳动，固定的 crop 区域会切掉一部分。遇到这种情况要么放弃裁剪，要么把裁剪区域放大到覆盖整个跳动范围，代价是 OCR 多处理一些无用区域。我一般选择放大裁剪区，稳字优先。
坑五：批量处理中途磁盘写满。抽帧加 OCR 中间文件积累很快，一个中长视频就能吃掉几十 GB。养成习惯：每处理完一个视频就清理一次临时帧目录，或者在脚本里处理完一个就删一个。这个坑踩过之后我所有脚本都加了自动清理逻辑。
6.3 一套值得固化的参数经验
跑多了之后我整理出一套默认参数，新视频直接套用，八成情况不用调：
- 抽帧帧率：影视剧 1 fps，短视频 0.5 秒一帧
- 去重哈希阈值：5
- OCR 置信度过滤：0.8
- 文本合并相似度阈值：0.7
- 裁剪区域：以 1080p 为基准 y=850 到 y=1050，其他分辨率等比缩放
这套参数不是死的，遇到特殊视频再微调，但有了基准，调参就不是从零开始猜，而是有方向地修。这也是我做这类批处理任务的一贯思路：先把流程跑通，固化成可复用的一套配置，再针对个例打补丁，而不是每个视频都从头设计一遍。
7. 流程编排与工程化的一点经验
把前面几个阶段串起来，完整的处理逻辑是这样的：探测视频流，判断字幕类型，文本型直接提取，图形型提取图片后 OCR，硬字幕抽帧后 OCR，最后统一生成 SRT 并做质量抽查。这个判断分支不复杂，但实际跑批量任务时，工程化的细节决定了这套东西是"能演示"还是"能干活"。
我自己的编排方式是一个主控脚本加若干独立函数，每个阶段都能单独调用。好处是遇到问题可以只重跑某一段——比如 OCR 结果不对，不用重新抽帧，直接从图片目录开始跑；字幕合并逻辑改了，可以拿已有的 OCR 结果重新生成 SRT，不用再花几十分钟识别一遍。这种"阶段解耦"的设计，在需要反复调试的流程里比一条龙脚本好用太多。
另一个经验是保留中间产物。帧图片、OCR 的原始 JSON 结果、合并前的文本列表，这些看起来是垃圾，但出问题时是唯一能定位的线索。我一般保留到项目验收后才清理，中间的磁盘成本换来的是排查效率。
最后说一个容易被轻视的环节：抽查。自动化流程最大的风险是"看起来跑完了但结果是错的"，比如 OCR 大面积误识别、时间轴整体偏移、字幕顺序乱掉。我固定会在生成 SRT 后随机抽 10 条核对原文，这个动作花不到两分钟，但拦住过好几次问题。流水线跑得再顺，也得留一道人工确认的口子，这是我做了这么多批处理任务之后最实在的一条心得。
