| name | workflow-bilibili-whisper-transcription |
| description | Bilibili/YouTube 视频批量下载 + Whisper 语音识别 |
视频下载与语音识别工作流
元数据
- 类型: Workflow
- 适用场景: Bilibili/YouTube 视频批量下载 + Whisper 语音识别
- 创建日期: 2025-02-12
- 最后更新: 2026-03-11
- 原项目已归档(不再保留在 workspace 中)
路径约定
- 临时下载与中间产物:
tmp/<task_name>/
- 最终可长期保留的 transcript:
adhoc_jobs/videos_transcribe/transcripts/
- 最终默认只保留不带时间轴的纯文本脚本,文件名建议:
YYYYMMDD_platform_videoid_short_slug.md
- 音频、
.srt、.vtt、.tsv、.json 等中间产物在 transcript 落盘后清理到废纸篓
核心流程
三阶段工作流:
- 获取列表 → 使用 yt-dlp 提取视频ID(注意B站API限制,可能返回352错误)
- 单线程下载 → 逐个下载音频,每次间隔2-3秒,避免触发反爬
- 多进程转录 → 并行运行Whisper,4-8个进程,根据硬件选择模型大小
关键决策
| 决策点 | 选择 | 原因 |
|---|
| 下载并发 | 单线程 | 避免触发B站反爬机制 |
| 转录并发 | 多进程(4-8) | CPU密集,充分利用多核 |
| 模型选择 | 根据需求 | 见下表 |
| 输出格式 | 最终保留纯文本 transcript | 后续检索更稳定,中间产物可回收 |
Whisper 模型选择
| 模型 | 参数量 | 速度(CPU) | 准确度 | 推荐场景 |
|---|
| tiny | 39M | 1-2分钟/10分钟 | 较低 | 快速预览 |
| base | 74M | 2-5分钟/10分钟 | 中等 | 平衡选择 |
| small | 244M | 5-10分钟/10分钟 | 较高 | 日常使用 |
| medium | 769M | 10-20分钟/10分钟 | 高 | 高质量需求 |
| large-v3 | 1550M | 20-60分钟/10分钟 | 最高 | 最高质量要求 |
性能参考:12个视频(3.5小时)+ large-v3 + 7进程 ≈ 20分钟
LLM 后处理
Whisper 原始输出通常需要后处理:
- 转换为简体中文 — 识别可能为繁体
- 添加标点符号 — 根据语义添加逗号、句号、问号
- 合理分段 — 按主题划分段落,添加小标题
- 纠正术语 — 专业名词识别错误(如"木质布"→"木质部"、"筛管细胞")
- 优化可读性 — 调整语序、补充缺失内容
踩坑记录
| 问题 | 现象 | 解决方案 |
|---|
| 352错误 | 请求被B站拦截 | 添加User-Agent/Referer headers,增加延迟,或手动获取ID |
| 404错误 | 视频已删除或ID错误 | 验证ID有效性,跳过无效视频,记录失败ID |
| 内存不足 | 多进程转录时内存溢出 | 减少并行进程数(4-6个),使用较小模型,分批处理 |
| 下载不完整 | .m4a文件无法播放 | 检查文件大小,重新下载,添加完整性验证 |
| 转录太慢 | large-v3单个视频20-60分钟 | 选择合适模型大小,使用GPU加速,分块处理长视频 |
最佳实践
下载阶段: 单线程 + 2-3秒延迟 + User-Agent headers + 只下载音频 + 记录失败ID
转录阶段: 多进程(4-8) + 指定language参数 + 跳过已处理文件 + 根据硬件选择模型
落盘阶段: 在 tmp/ 完成下载和转录,整理出纯文本脚本后移入 adhoc_jobs/videos_transcribe/transcripts/
清理阶段: transcript 落盘后删除或回收音频、时间轴字幕和 sidecar 文件,只保留最终脚本
质量优化: 关键内容用large-v3,快速预览用base/small,必要时人工校对
错误处理: 实现重试机制,验证文件完整性,处理异常避免脚本中断