录制中断导致视频无法播放的典型表现
在视频采集或直播推流过程中，最令人抓狂的情况莫过于生成了一个'僵尸文件'。比如使用 OBS 录制教程或行车记录仪正在工作时，突然发生断电、程序崩溃或强制关机。重启后你会发现，虽然视频文件占用几个 GB 的空间，但在任何播放器中都无法打开，或者提示'文件格式不支持'。查看属性时，时长显示为 00:00:00，比特率也是未知。这种现象通常发生在 MP4 或 MOV 格式的文件上，如果数据没有根本性丢失，仅仅是文件'封口'失败，其实是有很大概率能够修复的。
MP4 容器结构与索引丢失原理
要理解视频损坏的原因，需要了解 MP4 容器的存储机制。MP4 文件类似于一个数据库，主要由多个 Atom（原子）组成，其中最关键的是 mdat（媒体数据盒子）和 moov（电影原子盒子）。mdat 存放实际的音视频流数据，通常占据文件绝大部分体积；而 moov 则存储了时间轴、帧索引、关键帧位置等元数据。
在正常的录制流程中，程序会先不断写入 mdat 数据，只有在点击'停止录制'并正常关闭文件时，才会生成并写入 moov 信息，就像给书写上目录。如果录制异常中断，mdat 数据虽然存在磁盘上，但由于缺少 moov 索引，播放器不知道如何解析这一堆二进制数据，从而导致文件无法播放。此外，视频流中的 I 帧（关键帧）损坏也会导致解码器无法参照后续的 P 帧和 B 帧，造成局部的花屏或卡顿。
基于 Python 的视频修复方案
方法一：调用 FFmpeg 重建容器索引
这是处理轻微损坏最有效的方法。通过 FFmpeg 的流复制模式，将原始数据流提取出来并重新封装到一个新的 MP4 容器中。在这个过程中，FFmpeg 会尝试重新计算并生成丢失的 moov 索引信息。这种方法速度极快，因为不涉及重新编码。
import subprocess
import os
def quick_fix_ffmpeg(input_file, output_file):
# -c copy 表示直接复制流，不重新编码，速度最快
# -err_detect ignore_err 尝试忽略解码错误
cmd = [
'ffmpeg', '-y', '-err_detect', 'ignore_err', '-i', input_file,
'-c', 'copy', output_file
]
try:
# 捕获 stderr 以便分析错误日志
subprocess.run(cmd, check=True, stderr=subprocess.PIPE)
print(f"容器重建完成，输出文件：{output_file}")
except subprocess.CalledProcessError as e:
print(f"修复失败，错误日志：{e.stderr.decode()[:]}")
quick_fix_ffmpeg(, )
