#7823 runffmpeg() got an unexpected keyword argument 'state_dict'

暂无法确定具体原因。该报错信息不完整，runffmpeg() got an unexpected keyword argument 'state_dict' 疑似为程序内部任务参数传递异常或模型加载相关代码在特定任务链中发生了不匹配（state_dict 通常与 PyTorch 模型权重加载相关，与 ffmpeg 调用无关，出现在同一栈中说明可能是多阶段流水线交叉导致的异常）。

请提供软件安装目录下的 logs/ 文件夹中最新的日志文件（复制底部约30行报错信息，包含完整调用栈 traceback），以便分析具体是在哪个处理阶段（语音识别 / 配音 / 合成）触发该错误的。

同时请补充以下信息：

1. 你执行的是哪个功能（视频翻译 / 语音转录 / 文字配音 / 翻译字幕）？
2. 所选用的语音识别渠道、翻译渠道、配音渠道分别是什么？
3. 该报错是首次出现，还是重复翻译同一文件时出现？

输出的视频，音频部分完整，视频部分停止在开始时，一直到结尾，视频就没走！
[ERROR] [Video-Concat] 忽略无效片段: clip={'start': 1422752.0, 'end': 1430816.0, 'target_time': 8064.0, 'pts': 1.0, 'tts_index': 241, 'filename': 'D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/clip_241_1.000.mp4', 'actual_duration': 0}
[ERROR] [Video-Concat] 忽略无效片段: clip={'start': 1430816.0, 'end': 1438784.0, 'target_time': 8770, 'pts': 1.100652610441767, 'tts_index': 242, 'filename': 'D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/clip_242_1.101.mp4', 'actual_duration': 0}
[ERROR] [Video-Concat] 忽略无效片段: clip={'start': 1438784.0, 'end': 1443808.0, 'target_time': 5024.0, 'pts': 1.0, 'tts_index': 243, 'filename': 'D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/clip_243_1.000.mp4', 'actual_duration': 0}
[ERROR] [Video-Concat] 忽略无效片段: clip={'start': 1443808.0, 'end': 1448128.0, 'target_time': 4320.0, 'pts': 1.0, 'tts_index': 244, 'filename': 'D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/clip_244_1.000.mp4', 'actual_duration': 0}
[ERROR] [Video-Concat]
......
08.0, 'target_time': 4128.0, 'pts': 1.0, 'tts_index': 246, 'filename': 'D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/clip_246_1.000.mp4', 'actual_duration': 0}
[ERROR] [Video-Concat] 忽略无效片段: clip={'start': 1459008.0, 'end': 1464946.0, 'target_time': 5938.0, 'pts': 1.0, 'tts_index': 247, 'filename': 'D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/clip_247_1.000.mp4', 'actual_duration': 0}
[DEBUG] [Video-Concat] 合并 7 个视频片段 -> D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/merged_video.mp4
[DEBUG] 共删除了 248 个临时视频切片
[DEBUG] 新视频连接生成完毕，实际总时长: 39100ms
[DEBUG] 第0条字幕原始左偏移值: self.audio0_left_pad=576
[DEBUG] 第0条字幕需恢复偏移值:_start_time=576
[DEBUG] 连接音频前，配音音频总时长累计: _total_ms=1466876.0ms , self.raw_total_time=39100ms
[DEBUG] 视频延长后实际时长 self.raw_total_time=1466966ms
[DEBUG] 变速处理后，音频片段连接前， 配音总时长: 1466966.0ms, 视频总时长: 1466966ms
[DEBUG] 音频片段连接后，实际时长 1466966ms, 已生成到: D:/win-pyvideotrans-v4.15/tmp/16212/d38f02058e/target.wav

[DEBUG]

[DEBUG] 当前音频时长 1466965ms, 视频时长: 1466966ms
[DEBUG] 原始hw_type='h264_qsv'
[DEBUG] 整理后hw_type='qsv'
[DEBUG] [尝试硬件编解码执行命令]
-y -progress compose1791178408.570986.txt -i novoice.mp4 -i will_embed.m4a -filter_complex [0:v]subtitles=filename='end.ass'[v_out] -map [v_out] -map 1:a -c:v h264_qsv -c:a copy -global_quality 23 -preset slow -movflags +faststart -fps_mode vfr -shortest laste_target.mp4

[DEBUG] The file info after process:result={'video_fps': 30.0, 'r_frame_rate': 30.0, 'video_codec_name': 'h264', 'audio_codec_name': 'aac', 'width': 1920, 'height': 1080, 'time': 33277, 'streams_len': 2, 'streams_audio': 1, 'video_streams': 1, 'color': 'yuv420p'}

这是由于视频切片（clip）在生成阶段全部无效（actual_duration: 0），导致视频轨只有首帧画面被定格，而音频轨正常。根源在于视频片段切割/慢速处理环节出错，而非音频或 FFmpeg 合成阶段的问题。

关键日志点：

1. [Video-Concat] 忽略无效片段: ... actual_duration: 0 —— 248 个视频切片全部被判定为 0 时长无效，最终只合并出 7 个片段、总时长 39100ms（远小于音频的 1466966ms）。
2. 随后视频被强行延长（视频延长后实际时长 self.raw_total_time=1466966ms）来匹配音频时长，所以画面从开始就定格不动一直到结尾。
3. 最终合成时 time: 33277（约 33 秒）也印证了视频轨实际内容严重缺失。

这通常由以下原因引发：

1. 启用了「视频慢速」，且源视频切片的原始时长低于切分下限（MIN_CLIP_DURATION_MS = 40），导致大量切片在慢速/裁剪后长度归零被丢弃。

2. 临时目录被中途清理：日志开头路径 tmp/16212/... 表明任务 ID 为 16212。若同时运行了多个 sp.exe 实例，或某实例被关闭，会清空共享的 tmp 目录，使切片文件提前丢失。请确认：

   • 是否同时开着多个 pyVideoTrans 实例？
   • 任务运行途中是否关闭过软件或清空过 tmp 文件夹？
3. FFmpeg 切片命令在本机硬件编码（h264_qsv）下执行失败，切片文件虽被创建但内容为空。日志末尾 尝试硬件编解码执行命令 使用 h264_qsv，若 Intel QSV 驱动异常，切片阶段可能就已失败。

建议排查步骤

1. 尝试重新翻译，并先做以下调整：

   • 主界面取消勾选「视频慢速」，仅保留「音频加速」，避免大量切片因变速归零。
   • 进入 菜单-工具-高级选项-视频输出控制，勾选 强制软编码视频？，绕过 h264_qsv 等硬件编码器，排除 QSV 驱动问题。
   • 确保只运行一个 sp.exe 实例，中途不要关闭软件或手动清空 tmp 文件夹。
   • 重试时勾选清理已生成。
2. 若仍复现，请提供完整日志文件 D:/win-pyvideotrans-v4.15/logs/ 下当天的 .log 文件（尤其包含视频切片生成阶段，[Video-Concat] 上方关于 clip_xxx.mp4 生成的相关日志），以便确认切片失败的具体命令和返回码。
3. 请补充告知：翻译该视频时是否选中了「视频慢速」？本机显卡是否为 Intel 核显？任务运行过程中是否出现过软件重启或临时文件夹被清空的情况？

请查阅相关文档：

• 视频翻译中的配音、字幕、画面同步对齐 原理
• 高级选项详解

设备名称 机械师mini
处理器 Intel(R) Core(TM) Ultra 5 225H (1.70 GHz)
机带 RAM 32.0 GB (31.6 GB 可用)
图形卡 Intel(R) Arc(TM) 130T GPU (16GB) (128 MB)
存储 已使用 954 GB 中的 505 GB
设备 ID 59222188-C09D-4473-B4B2-0AE9BCED0A9E
产品 ID 00342-31892-14370-AAOEM
系统类型 64 位操作系统, 基于 x64 的处理器
笔和触控 没有可用于此显示器的笔或触控输入

你使用的是 Intel Arc 130T 核显，没有 NVIDIA 独立显卡。这正是导致画面定格问题的直接硬件诱因。

原因分析：

• 该机默认会启用硬件编解码 h264_qsv（Intel Quick Sync Video），日志末尾 原始hw_type='h264_qsv' 证实了这一点。
• Intel Arc 核显的 QSV 驱动在部分版本下与 FFmpeg 兼容性较差，尤其在视频切片（split）和慢速（setpts）阶段，容易生成 0 时长或损坏的空切片文件，从而触发 actual_duration: 0 被全部丢弃，最终视频轨只剩首帧定格。
• 同时，视频切片的慢速处理也高度依赖编码器的稳定性，属于你当前场景下的高风险环节。

解决步骤（按优先级）：

1. 强制软编码，绕过 QSV：进入 菜单-工具-高级选项-视频输出控制，勾选 强制软编码视频？，让 FFmpeg 改用 libx264 软件编码，彻底排除 Intel 核显编码器问题。这是最关键的修复。
2. 取消「视频慢速」：主界面仅保留「配音加速」，避免大量切片在减速后长度归零被丢弃。
3. 确保单实例运行：只开一个 sp.exe，中途不关闭软件、不手动清空 tmp/ 文件夹（多实例共享 tmp 会导致切片被互相清空）。
4. 重试时勾选「清理已生成」：防止复用上次损坏的切片缓存。
5. 可选：安装 VC++ 运行库：部分 QSV 报错与系统缺少底层 C++ 组件有关，可安装 https://aka.ms/vs/17/release/vc_redist.x64.exe 后重启。

补充说明：

• 本软件 CUDA 加速仅支持 NVIDIA 显卡，Intel Arc 核显无法开启 CUDA 加速，语音识别走 CPU 会较慢，属正常现象，与本次问题无关。
• 若希望用 Intel 核显加速，本软件暂不提供相应支持；AMD 用户可考虑 Whisper.net 渠道（需源码部署，复杂，不建议）。

若按上述操作后仍复现画面定格，请提供完整日志 D:/win-pyvideotrans-v4.15/logs/ 当天 .log 文件（重点包含切片生成阶段 clip_xxx.mp4 的相关命令与返回码），以便进一步确认是否降级为纯软件编码后仍有切片失败。

请查阅相关文档：

• 高级选项详解
• 视频翻译中的配音、字幕、画面同步对齐 原理
• Windows上配置CUDA和cuDNN

[DEBUG]

[DEBUG] 当前音频时长 983100ms, 视频时长: 983100ms
[DEBUG] [最终视频合成]不支持硬件编解码或指定了强制软编解码:
['-y', '-progress', 'compose1791180380.379679.txt', '-i', 'novoice.mp4', '-i', 'will_embed.m4a', '-filter_complex', '-map', '[v_out]', '-map', '1:a', '-c:v', 'libx264', '-c:a', 'copy']

从这份完整日志看，你已经按之前的建议做了处理：日志中出现 [最终视频合成]不支持硬件编解码或指定了强制软编解码，说明最终合成阶段已改用 libx264 软件编码，绕开了 Intel QSV。但问题依然存在 —— 音频总时长被错误地计算为 983100ms，self.raw_total_time 也从 33033ms 被强行改写成 983100ms。这说明切片阶段的问题并未解决，属于另一处诱因。核心异常点：音频总时长累计 _total_ms=982993ms，但视频原始总时长 self.raw_total_time=33033ms。两者相差近 30 倍，明显不正常。983100ms ≈ 16 分钟，而该视频实际应约为 33 秒（对应前一份日志的 39100ms）。软件随后错误地"视频延长后实际时长 self.raw_total_time=983100ms"，把音频时长当成视频目标时长强行拉伸，导致视频轨被拉开到 16 分钟以上、画面继续定格（或严重拉伸）。根因定位：问题不在最终合成编码器，而在「音频加速 / 配音片段」环节。日志中大量 [rubberband] 配音时长 XXXms 倍率 1.xx，说明音频加速正通过 Rubber Band 算法逐条处理配音片段。若 Rubber Band 处理异常（输出损坏或时长被误统计），会使累计 _total_ms 被严重放大，进而污染后续的时长对齐逻辑。日志中配音片段共 167 个，其中可见倍率多为 1.0x~1.9x，单看每条正常，但累计值飙升到 98 万毫秒，说明某处对「配音总时长」的累加逻辑被异常数据污染（可能是某条 Rubber Band 输出文件被重复统计，或读取了错误的时长）。请按以下顺序排查：检查 Rubber Band 是否可用：你已配置代理，但 Rubber Band 是本地算法，与代理无关。确认软件目录 ffmpeg/ 下是否存在 Rubber Band 可执行文件（rubberband.exe）。若不存在，软件会回退到 FFmpeg atempo，但由于两种算法的时长统计路径不同，回退路径下若出现异常也可能触发本问题。在 菜单-工具-高级选项-字幕配音 中，暂时取消「移除每条字幕配音开头结尾静音缓冲」与「移除每条字幕配音全部静音缓冲」，避免静音处理与加速叠加干扰时长计算，重试观察 _total_ms 是否恢复为 3 万毫秒级别。若仍异常：进入输出目录，检查 tmp/16460/2c0c2fac7e/ 下是否有名为 clip_*.wav 或配音切片存在极端异常的时长（比如某个文件大小异常大或异常小）。该问题需开发者进一步确认是否为 v4.15 音频时长累计统计的 bug。请补充以下信息以便精准定位：该视频原始时长是多少秒（用播放器确认）？是否勾选了「移除每条字幕配音开头结尾静音缓冲 / 全部静音缓冲」？软件目录 ffmpeg/ 文件夹下是否存在 rubberband 相关可执行文件？请查阅相关文档：视频翻译中的配音、字幕、画面同步对齐 原理高级选项详解

你上传了两张截图，但我目前无法从图片中直接读取内容（当前对话未提供图片的文字识别结果，也无从判断截图里展示的是界面、报错还是文件目录）。为避免凭空猜测，请你用文字补充截图中的关键信息，我再针对性分析。请告诉我：第一张截图（1791180919_6ac34077154a3.png）显示的是什么？是软件界面参数、报错弹窗、还是文件目录？第二张截图（1791181043_6ac340f3c0fae.png）同样，展示的是哪部分内容？如果截图是文件目录：请特别说明 软件目录/ffmpeg/ 下是否存在 rubberband.exe（用于确认音频加速用的是 Rubber Band 还是 FFmpeg atempo 回退方案，这直接关系到上次那 983100ms 异常时长是否由 Rubber Band 引发）。如果截图是音频/视频文件：请说明 tmp/16460/2c0c2fac7e/ 下是否有异常大小的文件，或某个 clip 文件的时长信息。如果截图是报错：请直接把报错文字复制出来。方便的话，也一并回答上次我追问的三个问题：原视频实际时长约多少秒？是否勾选了「移除每条字幕配音开头结尾静音缓冲 / 全部静音缓冲」？ffmpeg/ 目录下是否有 rubberband 可执行文件？请查阅相关文档：视频翻译中的配音、字幕、画面同步对齐 原理

有rubberband.exe！

既然软件目录 ffmpeg/ 下确实存在 rubberband.exe，说明音频加速走的是 Rubber Band 算法，这也印证了上次日志中 [rubberband] 倍率 1.xx 的处理路径。但请注意：Rubber Band 本身是本次问题的最大嫌疑，因为它会改变音频时长，而日志中累计出来的 983100ms 严重异常，恰恰出现在 Rubber Band 加速之后。请继续按以下步骤排查，并回答关键问题：问题确认：你上传的两张截图内容，我仍无法读取。请用文字描述截图里显示的是什么——是文件目录（能否看到 clip 文件或音频文件列表）、还是报错弹窗、还是软件界面参数？这是继续定位的必要信息。隔离 Rubber Band：请暂时做一次对照测试，在 菜单-工具-高级选项-字幕配音 中，将「移除每条字幕配音开头结尾静音缓冲」和「移除每条字幕配音全部静音缓冲」两块都取消勾选，重新翻译并勾选「清理已生成」。观察新日志中 _total_ms 是否恢复为几万毫秒（约等于视频原始时长）的正常量级。如果取消静音处理后时长恢复正常，则说明是静音移除与 Rubber Band 加速的叠加处理导致了时长统计污染。若仍异常：请提供重新翻译后的完整日志（同样是含 [rubberband] 和 _total_ms 的那段），对比新的累计时长是否仍被异常放大。并请务必回答：原视频实际时长约多少秒？这个视频文件本身是否正常、能在播放器里完整播放到结尾？另外提醒：Rubber Band 相关可执行文件应放在软件根目录的 ffmpeg/ 文件夹内（与 ffmpeg.exe、ffprobe.exe 同级）。如果你放置的位置不对，软件虽检测到文件但调用路径可能出错，反而引入异常，请一并确认其具体所在路径。请查阅相关文档：视频翻译中的配音、字幕、画面同步对齐 原理高级选项详解

时长00:16:22;30720kb;mp4

这条信息非常关键，直接推翻了之前的长度判断：原视频实际时长是 16 分 22 秒（约 982 秒 ≈ 982000ms）。这说明上次日志中的 self.raw_total_time=983100ms、_total_ms=982993ms 其实是正确的，并没有异常放大——是我此前误判了。所以本问题需要重新定性：音频时长计算正确，视频轨同样被正确延长到 983100ms 以匹配音频，但画面依然定格在首帧不动，这才是真正的故障点。重新定位问题：既然音频、时长、最终合成（libx264 软编码）都正常，问题就集中在「视频画面轨」本身——即视频切片的生成与合并环节。结合你第一份日志里的关键证据：[Video-Concat] 忽略无效片段: ... actual_duration: 0 —— 大量视频切片被判定为 0 时长而丢弃。但请特别注意：第一份日志里 raw_total_time=39100ms，而这份是 983100ms，说明这是两次不同的任务/不同的视频。因此需要确认：本次（16 分 22 秒这个视频）对应的日志里，是否同样出现了 [Video-Concat] 忽略无效片段 ... actual_duration: 0 的字样？如果本次日志中同样有大量视频切片被丢弃、最终合并出的视频总时长远小于 983100ms，那画面定格就是由切片失败直接导致的，根源仍在视频切片环节。请提供以下信息以最终确认：本次（16分22秒视频）任务对应的日志文件中，搜索 [Video-Concat] 相关行，看是否存在「忽略无效片段」以及最后「合并 N 个视频片段」的 N 是多少、合并后实际总时长是多少？本次翻译时，主界面是否还勾选着「视频慢速」？既然已强制软编码，请确认「视频慢速」是否已取消（若视频需被减速拉伸，本身也会产生大量切片并重新编码，是主要风险来源）。同时，请直接回答截图内容：你上传的两张截图里显示的到底是什么？是 tmp/ 下的文件列表，还是报错信息？——这点我一直没能读取到，是继续判断的关键。请查阅相关文档：视频翻译中的配音、字幕、画面同步对齐 原理

[DEBUG] line_roles={}
[DEBUG] 文字配音前参数:[{'language': 'zh-cn'}, {'uuid': '2c0c2fac7e'}, {'play': False}, {'tts_type': 0}, {'is_cuda': False}, {'is_redubb': False}]
[DEBUG] self.volume='+0%', self.rate='+0%', self.pitch='+0Hz'

[DEBUG] 本次EdgeTTS配音：重试延迟:5,出错将重试:4,并发:10, 代理:http://127.0.0.1:10808
[DEBUG] 所有配音任务结束。
[DEBUG] 本次配音 166 个成功， 0 个失败
[DEBUG] 本次 Edge-TTS(免费) 配音成功 166 个，失败 0 个
[DEBUG] 配音结束后，移除原始字幕中所有标点

[DEBUG] 开始语音视频字幕对齐处理：音频加速=False, 视频慢速=False
[DEBUG] 未选中任何变速，进入普通拼接模式。
[DEBUG] 视频延长后实际时长 self.raw_total_time=33133ms
[DEBUG] 音频片段连接后，实际时长 982904ms, 已生成到: D:/win-pyvideotrans-v4.15/tmp/16460/2c0c2fac7e/target.wav

[DEBUG]

[DEBUG] 当前音频时长 982904ms, 视频时长: 33133ms
[DEBUG] [最终视频合成]不支持硬件编解码或指定了强制软编解码:
['-y', '-progress', 'compose1791181339.2008436.txt', '-i', 'novoice.mp4', '-i', 'will_embed.m4a', '-filter_complex', '-map', '[v_out]', '-map', '1:a', '-c:v', 'libx264', '-c:a', 'copy']

这次日志终于把根因彻底暴露出来了，问题非常明确：未选中任何变速，进入普通拼接模式。请看这几行关键日志：[DEBUG] 开始语音视频字幕对齐处理：音频加速=False, 视频慢速=False[DEBUG] 未选中任何变速，进入普通拼接模式。[DEBUG] 视频延长后实际时长 self.raw_total_time=33133ms[DEBUG] 音频片段连接后，实际时长 982904ms[DEBUG] 当前音频时长 982904ms, 视频时长: 33133ms核心矛盾：音频总时长 982904ms（约 16 分 22 秒，与你的视频实际时长吻合），而视频被处理成只有 33133ms（约 33 秒）。两者相差近 30 倍，音频是完整的，视频却只有 33 秒的长度，然后被强行拉到 16 分钟去匹配音频，于是画面定格在开头一直到最后。这正是画面定格的真相——不是切片损坏，而是视频根本没有被正确处理到完整时长。根本原因：你在主界面的「配音加速 / 视频慢速」两个选项都没有勾选，导致软件进入了普通拼接模式。而在普通拼接模式下，软件的时长对齐逻辑出现了严重错误：它没有把视频铺满整个音频时长，而是只保留了一小段（33133ms）。关于 33133ms 这个数字：它大约就是被你最前面那批配音片段里、某一段的累计值，或某个错误统计出的视频短片段长度。结合你前一份日志同样的现象（视频时长 33133ms 也对不上 16 分钟），可以确认这不是偶然，而是普通拼接模式下视频时长统计错误的稳定复现。

结论：这是普通拼接模式（音频加速、视频慢速均不勾选）下的一个时长对齐缺陷。 它会在视频慢速/音频加速都关闭时，错误地把视频输出时长截短到几十秒，而非完整时长，最终导致成片画面定格。

解决方案（务必执行）：重新翻译时，在主界面务必勾选「配音加速」。 这是最直接有效的规避方式。视频慢速可不勾选，但配音加速必须勾选。这样软件会走「仅音频加速」的正常对齐路径（即你之前 3412 那条日志里能正常处理 167 个配音片段的模式），不会再进入这个有问题的普通拼接模式。重试时勾选「清理已生成」，避免复用本次已损坏的缓存。事实上，回看你更早那份能生成 [rubberband] 加速倍率的日志，当时音频加速是开启的，那时问题表现为切片 actual_duration: 0；而这次关闭变速后，问题变成视频时长被截短到 33 秒。两种表现都指向同一个薄弱环节——视频轨的时长处理。请补充确认（用于开发者定位）：翻译这个 16 分 22 秒视频时，你确实没有勾选「配音加速」和「视频慢速」吗？勾选「配音加速」后重新翻译，画面是否恢复为完整 16 分钟的正常画面？如果勾选配音加速后仍有定格，请提供新日志中 [Video-Concat] 与 self.raw_total_time 相关行，以便继续追查切片环节。请查阅相关文档：视频翻译中的配音、字幕、画面同步对齐 原理高级选项详解

你以前的4.08版本好像没有这个问题。

你反馈的这一点很有价值：v4.08 没有这个问题，说明这是较新版本在「普通拼接模式」下引入的回归（regression），而非一直存在的固有缺陷。这正是开发者需要修复的 bug。当前的问题定性：v4.15 在你这种场景下（不勾选音频加速、不勾选视频慢速，即普通拼接模式），视频轨时长被错误计算为 33133ms，而音频为 982904ms，导致成片画面定格。这在 v4.08 中并不存在，属于版本迭代中引入的新问题。你可以选择以下任一种方式继续：方式一（推荐，用当前版本）：重新翻译时勾选「配音加速」，让软件走正常的音频加速对齐路径，即可规避这个普通拼接模式的缺陷。方式二（临时降级）：如果新版本对你的场景始终不友好，可以退回旧版本使用。历史版本下载地址：https://pyvideotrans.com/downpackage。下载 v4.08 完整包解压即可，注意新版与旧版配置文件不通用，建议备份好现有 videotrans/ 下的 params.json、cfg.json 后再操作。建议你把这个版本差异反馈给开发者，这是明确的回归 bug，附带关键证据即可高效定位：版本对比：v4.08 正常，v4.15 出现画面定格。复现条件：关闭「配音加速」和「视频慢速」，处理任意长视频（本例为 16 分 22 秒）。错误表现：日志中 self.raw_total_time 被错误计算为 33133ms，与音频实际时长 982904ms 相差近 30 倍，最终视频只有 33 秒的静止画面。反馈时把这条日志片段的底部内容一并附上即可。反馈渠道可参考文档站的「技术支持」或 GitHub 仓库 Issue。请查阅相关文档：Windows版下载（历史版本）视频翻译中的配音、字幕、画面同步对齐 原理技术支持

[DEBUG]

[DEBUG] 当前音频时长 983100ms, 视频时长: 983100ms
[DEBUG] 返回缓存的编解码器 Windows-264: h264_qsv
[DEBUG] [最终视频合成]不支持硬件编解码或指定了强制软编解码:
['-y', '-progress', 'compose1791181986.3019083.txt', '-i', 'novoice.mp4', '-i', 'will_embed.m4a', '-filter_complex', '-map', '[v_out]', '-map', '1:a', '-c:v', 'libx264', '-c:a', 'copy']

这份日志是勾选「配音加速」后的结果，状况明显好转，但仍有一个关键细节需要注意。本次运行的好消息：日志显示 [rubberband] 配音时长与目标时长逐条加速，倍率 1.01~1.33，属正常范围。_total_ms=982993ms 与 self.raw_total_time 最终都被正确对齐到 983100ms，音频、视频、时长三者一致。最终合成使用 libx264 软编码，绕开了 QSV。这意味着：时长对齐计算本身这次是正确的，不会再出现上次那种视频被截短到 33 秒的情况。本次日志里仍存在的一处隐患：[DEBUG] 连接音频前，配音音频总时长累计: _total_ms=982993ms , self.raw_total_time=33033ms。请注意：这里 self.raw_total_time 的初始值仍然是 33033ms（33 秒）。但它的来源是「视频段本身」——也就是说，视频被读取/切分出来的原始总时长只有 33 秒，而音频有 16 分钟。软件随后靠「视频延长后实际时长 self.raw_total_time=983100ms」这一步，把视频目标时长强行改成了 983100ms。所以关键问题在于：视频轨的内容是否真的被铺满到了 16 分钟？ 日志只能证明「目标时长被设成了 983100ms」，不能证明「画面确实动了起来」。请你在这次输出的成品视频上做一次确认：播放成品，画面是否从开头到结尾都正常播放、有连续动作？还是画面仍然偏向静止/定格/只有极少画面在动？这一步是判定问题是否真正解决的唯一标准，比日志更重要。关于 self.raw_total_time=33033ms 这个初始值：它稳定地出现在多次日志中，很可能就是该视频被软件初步探测/切分出的「有效视频流时长」被错误低估（实际 16 分钟，被读成 33 秒）。如果成品画面正常播放，说明后续的延长逻辑补救了它，属于可接受的容错；如果成品画面仍定格，则说明视频轨内容确实缺失，问题依旧在视频切片读取环节，需要向开发者反馈这个「33 秒」的异常初始值。请回复：本次成品视频播放时，画面是否完整连续、全程有动态？是否还存在定格现象？这决定了我们下一步是收尾还是继续追查视频读取环节。请查阅相关文档：视频翻译中的配音、字幕、画面同步对齐 原理技术支持

成品画面仍定格

结论明确：勾选「配音加速」只修复了时长对齐，但没有修复视频画面本身——画面依然定格。这说明问题不在音频、不在对齐、不在最终编码，而在更前端的「视频读取/切片」环节：视频轨根本没有拿到完整的 16 分钟画面。核心证据锁定：你的多份日志中，self.raw_total_time 初始值稳定为 33033ms（约 33 秒），而原视频是 16 分 22 秒。这个 33 秒就是病灶——软件从原视频里只读出了约 33 秒的有效视频内容，其余画面一片空白。后续的「视频延长至 983100ms」只是把这段/这张画面在时间轴上拉长，并不能凭空补出缺失的画面，所以成片必然定格。为什么是 33 秒：这通常意味着在「提取无声视频（novoice.mp4）」或「视频切片」阶段，FFmpeg 处理提前中断或只处理了开头一小段，未能完整遍历整个视频流。你的显卡是 Intel Arc 核显，第一份日志里出现过 原始hw_type='h264_qsv'，视频的分离/解码阶段很可能仍走了 QSV 硬件解码路径。Intel Arc 核显的 QSV 驱动与 FFmpeg 在长视频解码时出现兼容性问题，是导致解码中途停摆、只输出 33 秒的常见原因。请按以下顺序操作并验证：第一步，彻底禁用硬件解码（关键）。 进入 菜单-工具-高级选项-视频输出控制，勾选 强制软编码视频？，并确认同时勾选 视频合成cuda硬解码 为不选中状态。更彻底的方式：在「高级选项」中确认没有任何启用 QSV/硬件解码的选项被打开，确保视频从头到尾都用 CPU 软解码。第二步，重新翻译并勾选「清理已生成」，确保不复用上次那段 33 秒的损坏缓存（tmp 目录里的 novoice.mp4 等）。第三步，翻译时观察日志里 self.raw_total_time 的值。重试后，请再次查看日志中 连接音频前... _total_ms=xxxxms , self.raw_total_time=xxxxms 这一行：如果 self.raw_total_time 这次接近 982000ms（16 分钟量级），说明视频被完整读取，问题解决；如果它仍然是 33033ms，说明软解码也没能解决，问题指向 FFmpeg 对该视频文件的解析兼容性。第四步（若第三步仍失败）：用其他工具（如格式工厂、ShanaEncoder 或 FFmpeg 命令 ffmpeg -i input.mp4 -c copy output.mp4）把原视频无损重封装/转码为标准的 H.264 + AAC + MP4，再导入软件翻译。原视频若是非常规封装（如某些下载工具生成的变体容器），可能导致解析中途失败。请回复（这几点是定位的必要条件）：重试后日志中 self.raw_total_time 的值是否变成 16 分钟量级？原视频文件是用什么工具下载/生成，可否用普通播放器从头到尾完整播放？该视频的编码格式，可用命令 ffprobe -v error -select_streams v -show_entries stream=codec_name,width,height input.mp4 查看。请查阅相关文档：Windows上配置CUDA和cuDNN高级选项详解常见问题FAQ技术支持