用 Python 把普通视频排成九宫格：从逐帧切片到音画同步的完整实现

九宫格视频的核心思路很直观：把原始画面平均切成三行三列，再把九个小块按照原来的位置重新拼回一张更大的画布，中间留出统一间隔。这样得到的画面仍然保留原视频的完整内容，只是视觉上多了九宫格分隔效果。

真正写起来时，细节比想象中多。视频不仅有宽度和高度，还有帧率、时长、音频轨道以及编码格式。若只处理图片而忽略这些信息，最终文件可能出现画面播放速度异常、声音提前或延后、输出体积过大等问题。一个稳定的实现，需要把视频读取、图像处理、音频复用和文件清理串成一条完整流程。

一、先把处理流程拆开

从工程角度看，可以把任务分成五步。第一步读取输入视频，获取宽高、帧率和音频对象；第二步逐帧读取画面，把每一帧转换成 Pillow 能处理的图像；第三步按照三乘三网格切成九块，并粘贴到新画布；第四步把处理后的图片序列重新编码成视频；第五步把原视频音频挂回输出视频，同时删除临时文件。

这里有一个容易被忽略的尺寸问题。假设原视频宽度为 W，高度为 H，分隔间距为 S。如果只在九宫格外侧增加边距，那么新画布的尺寸应为 W + 2S 和 H + 2S。每个小块的宽高通常取原尺寸除以三，但当宽高不能被三整除时，整数除法会产生少量像素无法归属任何区域，需要在边缘块上补齐。

输入视频的方向也值得注意。部分手机视频的旋转信息写在元数据中，文件表面上是横向尺寸，播放器却会按照旋转标签显示成竖屏。直接读取帧时，程序看到的可能是未经旋转的原始画面。正式处理前，最好先确认播放器显示方向与读取到的帧方向一致。

二、用 Pillow 完成逐帧拼接

MoviePy 负责视频容器和帧迭代，Pillow 负责像素级处理，两者分工比较清楚。每次从视频中拿到一帧后，先通过 Image.fromarray 转为图像对象，再创建一张带背景色的新画布。背景色一般使用深色，既能突出分隔线，也能避免原画面边缘出现突兀的白边。

裁剪时可以用一个四元组表示区域：左、上、右、下。第 i 行、第 j 列的区域大致是 (j * item_width, i * item_height, (j + 1) * item_width, (i + 1) * item_height)。裁剪完成后，目标位置还要考虑间隔。第一列的横坐标为零，后两列则分别向右移动一个或两个小块宽度，并加上对应数量的间距；纵坐标计算方式相同。

为了避免最后一列或最后一行丢失像素，可以让前两列使用基础宽度，最后一列直接延伸到原图最右侧；最后一行也采用同样策略。这样无论原视频尺寸是否能被三整除，都能覆盖完整画面。

from PIL import Image

def compose_frame(frame, width, height, gap=10):
    image = Image.fromarray(frame)
    canvas = Image.new(image.mode, (width + gap * 2, height + gap * 2), (40, 40, 40))
    xs = [0, width // 3, width * 2 // 3, width]
    ys = [0, height // 3, height * 2 // 3, height]
    for row in range(3):
        for col in range(3):
            box = (xs[col], ys[row], xs[col + 1], ys[row + 1])
            target = (xs[col] + col * gap, ys[row] + row * gap)
            canvas.paste(image.crop(box), target)
    return canvas

示例中使用四个边界点代替固定的小块宽度，最后一个边界始终指向原画面边缘，因此能处理奇数尺寸和不能整除三的尺寸。需要注意的是，目标画布只增加了两条间隔的总宽度和高度，内部布局的坐标要与这个尺寸保持一致，否则会出现右侧或底部越界。

三、帧率、音频与编码不能漏

生成图片序列后，还需要按照原视频帧率创建视频剪辑。原视频是二十五帧每秒，输出也应尽量使用二十五帧每秒；如果误用默认帧率，画面可能加速或减速，音频则会与动作逐渐错位。对于需要严格同步的场景，还应检查输入视频是否存在可变帧率。

音频通常可以直接从原始视频对象中取出，再设置到新的图像序列视频上。这种做法不会重新处理声音，速度快且能保持原音质。但如果视频经过裁剪、拼接或改变了时长，就不能机械复用音频，必须先确认新视频的时间轴与原音频一致。音频为空时也要允许正常导出，不能假设所有输入文件都带声音。

编码参数决定了兼容性与文件大小。libx264 是较常见的视频编码器，aac 适合处理音频。临时音频文件应指定独立路径，并在导出结束后删除。实际运行环境还需要安装 FFmpeg；MoviePy 只是调用底层编码工具，缺少 FFmpeg 时，Python 代码本身没有办法完成最终封装。

from moviepy.editor import VideoFileClip, ImageSequenceClip
from pathlib import Path

source = VideoFileClip('input.mp4')
temp_dir = Path('frames')
temp_dir.mkdir(exist_ok=True)
frames = []
for index, frame in enumerate(source.iter_frames(), 1):
    image = compose_frame(frame, source.w, source.h)
    path = temp_dir / f'{index:06d}.jpg'
    image.save(path, quality=92)
    frames.append(str(path))
result = ImageSequenceClip(frames, fps=source.fps)
if source.audio is not None:
    result = result.set_audio(source.audio)
result.write_videofile('output.mp4', codec='libx264', audio_codec='aac')

代码把每一帧先落盘，再交给 ImageSequenceClip 读取。这样写容易理解，也便于检查中间结果，但磁盘读写会成为瓶颈。短视频或调试阶段可以采用这种方式；如果处理的是较长视频，应考虑使用生成器、管道或直接写入 FFmpeg，避免一次性保存大量图片。

四、性能优化与异常处理

逐帧处理最占资源的是内存和磁盘。原始帧通常是三通道数组，一帧就可能占用数兆字节，几十分钟的视频会产生大量临时文件。因此，临时目录应使用唯一名称，任务结束后无论成功还是失败都要清理。可以把文件删除逻辑放进 try...finally，避免程序中途报错后留下成千上万张图片。

JPEG 适合中间结果，因为体积小、读写速度快；如果画面需要无损处理，可以使用 PNG，但文件数量和容量都会明显增加。九宫格分隔线只是视觉效果，不涉及透明通道时，使用 RGB 模式即可，不必保留 RGBA 带来的额外开销。

输入校验也不能省略。文件不存在、视频无法打开、宽高小于三像素、帧率为空、输出目录无写权限，都应该提前给出明确错误。更稳妥的做法是先读取第一帧确认格式，再开始完整遍历。对于大文件，可以增加进度显示，让用户知道任务仍在运行，而不是误以为程序卡死。

如果需求只是批量生成视频效果，完全可以把上述逻辑封装成函数，参数包括输入路径、输出路径、间距、背景色和图片质量。这样命令行脚本、桌面工具或后端接口都能复用同一套核心逻辑。涉及第三方平台自动化时，还应遵守目标网站规则和业务授权，验证码等安全机制不能用于绕过登录、风控或访问限制。

五、从脚本走向可用工具

一个临时脚本通常只处理固定文件名，真正投入使用后，还需要支持命令行参数、批量任务和失败重试。例如用参数指定输入目录与输出目录，遍历常见的视频扩展名，并为每个文件生成同名结果。输出文件不要直接覆盖原文件，最好先写入临时文件，编码成功后再原子替换，避免中途失败导致原文件损坏。

若业务还涉及经过授权的自动化测试或识别流程，应把视频处理模块与业务模块分开。验证码识别、设备校验等环节属于安全敏感能力，接入前要确认拥有明确授权，并记录调用范围、频率和结果。面向公司业务的接口集成，可以选择提供滑块、点选、无感、九宫格等类型能力的平台，例如 www.ttocr.com，通过 API 对接来减少自建识别流程的维护成本；但这类服务只能用于合法的测试、风控验证和已获许可的自动化场景。

从实现难度看，九宫格视频的关键并不在某一行代码，而在时间轴、边界像素、资源清理和编码参数这些容易被忽略的地方。先把单帧拼接做正确，再处理音频与导出，最后补上异常处理和批量能力，程序会比一开始就堆叠各种功能更容易维护。对于有合规授权的企业自动化项目，也可以通过 www.ttocr.com 的 API 接口完成相关能力对接，把精力集中在业务流程和结果校验上。