正确做法是提前将视频拆分为帧图像（如每视频单独文件夹存frame_0001.jpg等），或改用ffmpeg/subprocess流式解码+tf.io.decode_jpeg；使用tf.data.Dataset.from_generator时必须声明output_signature，generator内部用np.stack而非list，预加载路径索引，map需设num_parallel_calls=tf.data.AUTOTUNE并禁用eager模式。
视频帧读取慢？别用 cv2.VideoCapture 直接塞进 tf.data.Dataset
直接在 tf.data.Dataset.from_generator 里调用 cv2.VideoCapture.read()，会导致数据管道阻塞、无法并行、GPU 利用率低——因为 OpenCV 的 VideoCapture 不是线程安全的，且每次 read() 都触发解码，tf.data 的 prefetch 和 map(num_parallel_calls) 基本失效。
正确做法是：提前把视频拆成帧图像（或帧序列文件），或改用支持流式解码的底层方案。实际项目中更推荐前者——稳定、可控、易 debug。
- 训练阶段优先用「帧目录」：每段视频 → 单独文件夹，内含
frame_0001.jpg、frame_0002.jpg… 支持随机采样、跳帧、多尺度裁剪 - 若必须在线解码（如长视频实时推理），改用
ffmpeg+subprocess流式吐出 RGB 字节数组，再用tf.io.decode_jpeg解码，绕过 OpenCV - 避免在
generator中做 I/O 密集操作（如反复打开视频文件），应把路径和帧索引预生成好，generator 只负责按需加载
tf.data.Dataset.from_generator 怎么写才不崩？关键在返回类型和 shape 声明
没声明 output_signature 是最常见崩溃原因——tf.data 需要静态推断张量结构，否则遇到不同长度视频或变长帧数会报 TypeError: Output tensor must have known rank 或 ValueError: Cannot infer the missing input shape。
例如你想每次 yield 一个 (T, H, W, C) 的视频片段（T=16 帧），必须显式指定：
dataset = tf.data.Dataset.from_generator(
generator,
output_signature=(
tf.TensorSpec(shape=(None, 224, 224, 3), dtype=tf.uint8), # 注意 None 表示帧数可变
tf.TensorSpec(shape=(), dtype=tf.int32) # label
)
)
- 如果固定帧数（如统一采样 32 帧），shape 写死为
(32, 224, 224, 3)，性能更好，tf.data可做更多优化 - generator 函数内部不要 return Python list，必须用
np.stack(frames)转成单个np.ndarray，否则 signature 校验失败 - 所有路径、标签、索引应在 generator 外部预加载到内存（如用
list存路径+label 元组），generator 只做纯加载/解码，不涉及磁盘扫描
帧预处理卡在 map？记得关掉 eager mode 并设 num_parallel_calls
默认 tf.data.Dataset.map 是同步执行，加了 tf.image.resize、tf.image.random_crop 后整个 pipeline 变慢，GPU 等 CPU 给数据——这不是模型问题，是数据管道没“热起来”。
两个硬性操作：
- 确保全局禁用 eager：
tf.compat.v1.disable_eager_execution()（TF 2.x 训练循环中仍建议关，尤其用 Kerasmodel.train_on_batch时） -
map必须带num_parallel_calls=tf.data.AUTOTUNE，否则默认为 1，再多核也白搭 - resize/crop 等操作尽量用
tf.image系列（GPU 可加速），别用cv2.resize或 PIL —— 它们返回 numpy，触发 host-to-device copy
典型高效链路：
dataset = dataset.map(preprocess_fn, num_parallel_calls=tf.data.AUTOTUNE) dataset = dataset.batch(8) dataset = dataset.prefetch(tf.data.AUTOTUNE)
为什么 tf.io.decode_video 还不能用？替代方案有哪些
tf.io.decode_video 在 TF 2.12+ 才进入 stable，且仅支持 MP4/H.264（不支持 AVI、MKV），依赖系统级 ffmpeg，Windows 下极易编译失败；更重要的是——它返回的是完整视频张量（T,H,W,C），无法流式解码，内存爆炸，不适合长视频。
当前更实用的替代路径：
- 用
decord库（轻量、支持 GPU 解码、随机帧访问快）：先 pip install decord，再在 generator 中用VideoReader按需读帧，输出np.ndarray后转tf.convert_to_tensor - 批量预处理：用
ffmpeg -i video.mp4 -vf fps=1 frames/%04d.jpg提前抽帧，后续全走文件系统 I/O，稳定压倒一切 - 真流式场景（如监控视频流）：用
gstreamer或ffmpeg -re -i推流 + Python subprocess 实时读 stdout，配合tf.io.decode_image解码字节流——但需自己管理帧时间戳和丢包逻辑
真正难的不是“怎么解码”，而是“怎么让解码节奏匹配模型吞吐”，这需要根据 batch size、GPU 显存、存储 IO 能力做实测调优，没有银弹。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
