长期探索性想法，非近期计划。这里的条目甚至不属于"已知、计划修复"级别，仅作为可行性记录。
背景：当前 pipeline 各阶段（download → whisper → split → optimize → translate → embed → upload）是严格顺序执行的。对于正在直播的视频，download 会阻塞数小时直到直播结束，后续阶段全部等待。
思路：将 pipeline 改为流式处理——download 产出固定时长窗口（如 30 秒）的音视频片段后，立即交给 whisper 处理，whisper 输出再交给 split/optimize/translate。各阶段可以 pipeline 并行。
可行性：
- 当前 ASR 处理单位约 30 秒，与流式窗口天然匹配
- 大模型处理按 sentence 数量配置，也可以适配固定窗口
- 需要处理窗口边界的断句/上下文连续性问题
- embed（字幕烧录）和 upload 需要等全量完成，或改为分片上传
- 改动范围大，涉及 pipeline executor、每个 step 的接口设计
现状：尚未调研同类实现。需评估当前框架是否适合扩展为流式处理。
思路：将输入改为直播流（YouTube/B 站直播接口），按固定窗口走完整 pipeline 后输出字幕流，预估端到端延迟约 1 分钟。
现状：尚未调研同类实现。需评估是否有成熟的开源方案可直接集成。优先级低。依赖"流式 Pipeline"能力。
思路：对视频画面中超过固定时长（如 3 秒以上）的日语文字进行 OCR 提取，翻译后嵌入（overlay）到画面中。适用于游戏内 UI 文字、聊天弹幕、活动说明等场景。
可行性：
- OCR 部分：有成熟方案（PaddleOCR、EasyOCR、manga-ocr 等），日语识别效果一般可用
- 文字区域检测：需要检测文字出现的时间范围和位置，避免对每帧做 OCR（采样帧 + 变化检测）
- 翻译：复用现有 LLM 翻译 pipeline
- 嵌入：需要在视频对应区域叠加翻译文本，涉及字体、位置、背景半透明等排版问题
- 技术硬伤：手写体/艺术字 OCR 识别率低；动态文字（滚动/旋转）定位困难；遮挡原文同时放置译文的空间问题
现状：纯想法阶段。OCR + 翻译的基础技术可行，但画面嵌入的工程复杂度高，且可能存在真正的技术限制（特别是艺术字/手写体场景）。