5.1 视频读取与处理

5.1 视频读取与处理

本节摘要：视频分析的地基是把帧稳定地读进来、把处理结果顺畅地写出去。本节讲 VideoCapture 的文件与摄像头两种打开方式、逐帧处理的标准循环骨架、waitKey 与帧率控制的关系、VideoWriter 的编码参数，以及打不开、播放速度异常、黑屏三类高频故障的排查。读完你能写出任何视频程序的输入输出骨架。

学习目标

阅读完本节，你应当能够：

1. 用 VideoCapture 打开视频文件与摄像头并判空
2. 写出"读取 → 处理 → 显示 → 按键控制"的标准循环
3. 说清 waitKey 毫秒数与播放帧率的关系
4. 用 VideoWriter 保存处理结果并选对编码四字符码
5. 排查打不开、变速、黑屏三类典型故障

先跑起来：标准视频循环

import cv2

cap = cv2.VideoCapture('input.mp4')
if not cap.isOpened():
    raise RuntimeError('打开失败：检查路径、编解码支持或摄像头占用')

while True:
    ret, frame = cap.read()
    if not ret:
        break                                  # 读完或读失败，退出

    gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY)   # 这里换成任何处理
    cv2.imshow('frame', gray)

    if cv2.waitKey(25) == 27:                  # 约40fps的节奏；ESC退出
        break

cap.release()
cv2.destroyAllWindows()
​

这十几行就是所有视频程序的骨架：打开 → 判空 → 循环读帧 → 处理 → 显示 → 键盘控制 → 释放资源。换摄像头只改一行：cv2.VideoCapture(0)，参数是设备索引（0 是默认摄像头，外接摄像头依次 1、2）。多个摄像头同时开，就建多个 VideoCapture 对象各读各的。

顺手把元信息读出来，处理逻辑常要用：

fps = cap.get(cv2.CAP_PROP_FPS)                 # 帧率，如 25.0
w   = int(cap.get(cv2.CAP_PROP_FRAME_WIDTH))    # 帧宽
h   = int(cap.get(cv2.CAP_PROP_FRAME_HEIGHT))   # 帧高
n   = int(cap.get(cv2.CAP_PROP_FRAME_COUNT))    # 总帧数（文件才有意义）
​

核心原理：帧、缓冲与节奏

2.1 视频就是一摞图，但不只是

第 1 章说过图像即数组；视频即数组的序列。但 VideoCapture 在"序列"之上做了两件额外的事：解码（压缩流还原成帧数组，背后是 FFmpeg 等后端）与缓冲（预读若干帧，保证读取节奏平稳）。理解这两件事，一半的视频故障就能自查。

read 的返回值是 (ret, frame) 二元组：ret 为 False 表示"到了结尾"或"读取失败"——两类原因共用一个返回值，流媒体场景（网络不稳）下循环中途 ret 变 False 未必是播完了，重试或重连才是正确反应，写服务时要区分处理。

2.2 waitKey 的双重职责

waitKey(ms) 在等待键盘之余干了第二件事：让 imshow 的窗口有机会渲染（第 1 章第 3 节讲过）。这个 ms 值顺带决定了播放节奏：每帧显示后等 ms 毫秒，再加上解码与处理耗时，实际播放帧率约等于 1000 除以总耗时。所以 waitKey(25) 大约 40fps 的节奏，waitKey(40) 约 25fps——想按原速播放，ms 取 1000 除以视频 fps，再视处理耗时而微调。处理本身耗时长（比如每帧跑检测要 200 毫秒），waitKey 再小也快不起来，这时瓶颈不在播放而在计算，要么优化算法要么接受慢放。

2.3 逐帧处理的性能常识

Python 层面逐帧调用 OpenCV 函数，1080P 视频通常能到每秒几十帧；但每帧再叠加深度推理就骤降到几帧。常用优化三板：隔帧处理（每 2 到 3 帧处理一次，中间帧复用上次结果——跟踪场景尤其常用，第 5 章第 3 节详述）；降分辨率处理（帧缩小一半，计算量降为四分之一，检测精度略降）；ROI 处理（只处理上一步锁定的区域）。视频的信息在相邻帧间高度冗余，"不必每帧全图算"是视频工程的第一直觉。

2.4 写出视频：VideoWriter

writer = cv2.VideoWriter('out.mp4',
                         cv2.VideoWriter_fourcc(*'mp4v'),
                         fps, (w, h))
writer.write(frame)      # 每帧写入
writer.release()         # 收尾释放，缺了它文件可能损坏
​

三个要点：尺寸参数必须与写入帧的实际尺寸一致，不一致时静默失败或文件为空；fourcc 是编码格式四字符码，mp4v、XVID、MJPG 是常用选项，平台支持度不同（树莓派与 Windows 对某些编码器支持有差异），打不开输出文件时先换 MJPG 加 .avi 试试；release 不调用，文件尾部信息缺失，播放器打不开是常态。

工程实践要点

3.1 三类高频故障排查表

Windows 上摄像头黑屏还有一个经典原因：默认后端兼容性差，显式指定 cv2.VideoCapture(0, cv2.CAP_DSHOW) 常能解决打开慢或黑屏。

3.2 帧抓取与跳帧

逐帧推进太慢时可以按位置跳：cap.set(cv2.CAP_PROP_POS_FRAMES, 1000) 跳到第 1000 帧。注意不同编码格式下这个跳转的精度不同（关键帧对齐问题），跳完读到的帧号可能略有偏差；做精确统计时以 get 读回实际位置为准。

3.3 与检测、跟踪的衔接

本节的循环骨架是第 4、5 章其余内容的宿主：处理那几行换成检测就是视频检测，换成背景减除就是运动分析（下一节），加上跟踪器状态就是跟踪（第 5 章第 3 节）。骨架一次写对，后面换的是"处理"函数，这是结构上的复用。程序退出时 cap 与 writer 都要 release，长跑的监控服务更要严格释放，句柄泄漏会让下一次打开失败。

⚠️ 常见坑：循环里没有 ESC 判断也没有 break 条件，程序"假死"——其实是在无限等 waitKey(0)，每帧都无限等待。waitKey(0) 只该用于静态图，视频循环里永远传正数。另一个坑是 imshow 放在了"读帧失败 break"之后，末尾一帧 None 去显示直接崩溃。

💡 关键直觉：写视频程序先跑通"只读只显示"的最小版本，确认节奏与画质正常，再往循环里加处理逻辑。一次加一步，每步都可验证——视频链路的环节多，一上来就写全长流水线，出错时你不知道断在哪。

3.4 动手实验清单

1. 跑通骨架循环，waitKey 取 200、40、10 各一次，感受节奏差异。
2. 打开摄像头实时显示自己的脸，加上左右翻转（第 1 章的 flip），体会镜像视角。
3. 把每帧转灰度并实时显示，再用 VideoWriter 落盘成视频，用播放器回放验证。
4. 给循环加帧计数与实测帧率（time 模块计时），打印处理耗时，找出你机器上的性能瓶颈环节。

3.5 常见疑问与解答

处理速度跟不上帧率，帧会丢吗？

取决于你怎么写。逐帧 read 的同步循环里，处理慢就整体慢放（帧不会丢，只是落后于实时）；想只处理"最新的帧"（监控场景常见需求），要么开线程读帧并只保留最新一帧（丢旧保新），要么用 grab 检索跳帧。设计取舍：丢帧换实时性，还是保完整性换延迟，业务说了算。

网络摄像头（RTSP 流）怎么接？

VideoCapture 直接传流地址即可打开，但网络抖动会带来延迟累积与 read 失败。工程要点：失败重连（ret 为假后 sleep 再重开）；超时控制（部分后端在网络断开时会卡死在 read 上，需要设超时或用独立线程读取）；解码负载（高码率流解码本身吃 CPU，必要时降流分辨率）。

视频元信息里的总帧数靠谱吗？

文件场景基本靠谱，流场景无意义（没有"总长"概念）。另一个坑是可变帧率视频（手机拍摄的常见格式）：帧间隔不均匀，按"帧号除以帧率"换算时间会有累积误差，严格的时间轴任务用帧的时间戳属性（CAP_PROP_POS_MSEC）而不是帧号。

长时间运行的稳定性要注意什么？

内存与句柄两条线：循环里别不断创建 VideoCapture、VideoWriter、窗口（复用句柄）；imshow 的窗口在无交互的服务器环境有泄漏风险，改用周期性 imwrite 抽帧存档。跑一晚上监控任务，睡前把这两项检查一遍，是老工程师的肌肉记忆。

3.6 实战配方：可复用的视频处理脚手架

把本节内容组装成一个项目级脚手架，后续两节的分析模块直接往里插。

骨架分层：输入层（VideoCapture 的打开与重连）、处理层（每帧调用的处理函数，可插拔）、输出层（imshow 预览加 VideoWriter 落盘，均可开关）、控制层（帧率节奏、ESC 退出、周期性抽帧存档）。

输入层按场景选模式：文件模式读完即止；摄像头模式加打开失败重试；流模式再加独立读取线程保最新帧（本节 FAQ 的方案）。处理层定义统一接口——进一幅帧、出一个结果，第 5 章后两节的分析模块都按这个接口实现，脚手架不用改。

输出层两个细节容易被忽略：预览开关节省显示开销（本节 3.5 讲过 imshow 的隐藏成本）；落盘的帧率参数写实测值而不是源视频标称值，处理耗时拉长了实际节奏，按标称帧率写的输出视频会"快放"。

控制层加一个调试利器：按键切换"原始帧与处理结果"的显示，实时对比是调参时最想要的视野。再加周期性抽帧存档（每秒一帧存 PNG），长跑任务出问题时有现场可查——这两个功能加起来二十行代码，价值远超成本。

脚手架的意义：视频项目的差异都在处理层，输入输出与控制是通用件。一次写好、处处复用，把精力留给真正与分析相关的部分。

3.7 补遗：本章的接口约定

后两节的分析模块要插进本节的脚手架，接口约定在此立好：处理函数收一幅帧（BGR 数组），返回一个结果（掩码、框列表或标注帧），不做任何显示与保存——显示归控制层、保存归输出层。分析模块保持"纯函数"形态的好处：单元测试可以直接喂数据验证、替换模块不动脚手架、日后接到图片流（不只有视频）也不用改。第 5 章第 2、3 节的所有示例代码都默认遵守这个约定，读者自己的扩展模块也建议照此办理——约定本身就是架构。

3.8 补遗：帧率实测的小工具

给脚手架配一个五行的帧率计：处理循环里记下每帧的时间戳，每秒打印一次"最近一秒处理了多少帧"与"最近一帧耗时"。有了它，后面两节做任何优化（隔帧、降分辨率、换算法）都有量化的前后对比，调优不再是体感。视频工程的一切性能讨论，起点都是"先测出来"。

本节要点回顾

• 骨架七步：打开、判空、循环读、处理、显示、按键控制、释放——所有视频程序的宿主结构。
• waitKey 一职两用：渲染机会加播放节奏，视频循环里永远传正数，按 1000 除以 fps 设定。
• ret 为假两种含义：文件结尾与读取失败，流媒体场景要区分处理。
• VideoWriter 三纪律：尺寸一致、fourcc 可用、release 收尾，缺一个都会"静默失败"。
• 冗余是视频的本性：隔帧处理、降分辨率、ROI 处理三板斧，先砍计算量再谈算法优化。
• 增量式搭建：先跑通只读只显，再逐步加处理，链路长时这是唯一可控的写法。

帧能稳定读进来了，下一节问第一个分析问题：画面里什么在动——背景减除、帧间差分与光流三套方案各有地盘。