When mkv file uploaded to Gradio it converts to mp4 and this takes massive time

快速结论：Gradio 在接收 .mkv 格式视频时，因默认不将其视为浏览器可播放格式，会无条件执行完整转码（re-encode），导致大文件上传显示耗时极长。优先排查目标是确认视频实际编码是否为浏览器兼容的 H.264，并尝试在 Gradio 侧跳过转码或改用 ffmpeg 的 -c copy 容器 remux 方案。

适用环境：Gradio 6.22.0（main 分支，commit bf3b4e39c）；操作系统、具体 Python 版本、显卡等环境在 Issue 中未提供明确证据。

最快修复方案：暂无确认的一步修复方案。Issue 本身尚未被官方修复，但已确认其根源在于 gradio/processing_utils.py 第 1103 行的 convert_video_to_playable_mp4 函数未传入任何 codec 参数，导致 ffmpeg 无条件使用默认编码器重编码。

注意事项：用户提到的“ChatGPT 5.5 补丁”属于个人修复方案，未在 Gradio 官方代码库中验证，不应视为通用解决方案。对比测试表明，使用 -c copy 仅做容器转换可将耗时从 3.7 秒降至 0.04 秒（约 90 倍提速），且无画质损失，但此优化是否合并到正式版尚未确认。

问题场景

在 Gradio 中将较大的 .mkv 文件（例如 2.4GB）上传到视频预览字段时，页面长时间无响应，显示“转码中”状态。用户期望 Gradio 能直接播放 H.264 编码的 .mkv 文件，而不是强制转成 mp4。

报错原文

When mkv file uploaded to Gradio it converts to mp4 and this takes massive time

video_is_playable(h264 in .mkv): False
convert_video_to_playable_mp4: 3.7s -> /tmp/t1.mp4      # 54 MB -> 21 MB (re-encoded, lossy)

real 0.04s                                              # 54 MB -> 54 MB (bit-identical streams)

原因分析

可能原因：Gradio 的 video_is_playable() 函数仅检查文件格式（如 mp4、webm 等）是否在浏览器可播放白名单中，并不实际探测容器内视频流的编码类型。因此一个内部已经是 H.264 编码的 .mkv 文件，只要扩展名不在白名单内，就会被判定为“不可播放”。随后 convert_video_to_playable_mp4() 在调用 ffmpeg 时不指定任何编码参数，导致 ffmpeg 自动选择默认编码器进行完整重编码（关键帧、画质、编码参数全部改变），而非仅做容器层面的 remux（复制流）。

此外，该函数没有任何“先尝试 remux，失败再转码”的回退机制。这意味着即使是浏览器兼容的 H.264 流，也会被强行重编码，造成不必要的性能开销和画质损失。

环境排查

Gradio 版本：确认是否 ≥6.22.0（在 main 分支 commit bf3b4e39c 上可复现）
ffmpeg 版本：需支持 -c copy（几乎所有现代版本均支持），但需确认 ffmpeg 路径能被 Gradio 正确调用
上传视频的容器格式与内部编码：用 ffprobe 确认 .mkv 内部视频流是否为 H.264、音频流是否为 AAC（浏览器兼容编码）
Python 环境：Gradio 的运行 Python 版本（Issue 未给出具体版本，不需要额外确认）

解决步骤

先用 ffprobe 确认真实编码：运行 ffprobe -show_streams -select_streams v yourfile.mkv，检查 codec_name 是否为 h264。如果是，说明文件本身完全兼容浏览器播放，Gradio 的转码是多余的。
验证 remux 是否可行：执行 ffmpeg -i yourfile.mkv -c copy output.mp4。若命令成功且耗时极短（毫秒级），说明只需容器转换，不需要重新编码。
修改 Gradio 处理逻辑（可优先尝试）：若你有能力修改 Gradio 源码或 fork 补丁，可修改 gradio/processing_utils.py 中的 convert_video_to_playable_mp4 函数，在执行完整转码前先尝试调用 ffmpeg -c copy 做 remux，只在 remux 失败时才进行完整转码。
检查 video_is_playable 逻辑：考虑扩展其判断逻辑，不仅检查扩展名，还应探测内部视频流编码，如果容器内是 H.264 + AAC，则直接判定为可播放。
临时规避方案：在官方修复之前，对于上传的 .mkv 文件，可在上传前先用 ffmpeg -c copy 手动转成 .mp4 容器再传到 Gradio，即可避免转码等待。

验证方法

确认问题已解决的标志是：.mkv 文件上传到 Gradio 视频预览字段后，不再出现长时间等待；且服务端日志中没有触发 ffmpeg 重编码操作。若修改了源码，可重新运行 Issue 中的对比测试：processing_utils.video_is_playable() 对 H.264 编码的 .mkv 返回 True，或 convert_video_to_playable_mp4() 在 remux 路径下耗时低于 0.1 秒且输出文件大小与原文件几乎一致。