我一度是那种“宁可错杀一千不可放过一屏”的截屏狂魔。一门 200 分钟的网课我能截出 800 多张图相册里密密麻麻全是画面真正翻出来复习的时候却根本找不到重点。后来我实在受不了这个状态花了一个周末用 Python 搭了一条自动化流水线让程序自己判断“哪些画面值得被记录”把关键帧提取出来自动做文字识别最终压成一份带文字层、可搜索、可打印的 PDF 笔记。整个过程没有一帧关键画面被跳过也不需要我手动点一下截屏。这套流程说白了就是三件事找帧、认字、合成 PDF。听起来不复杂但每一步都有不少坑尤其是“找帧”这一步如果只按固定间隔截图出来的 PDF 能有三四千页完全没法用。这篇文章我把整个方案的选型逻辑、核心代码思路、实测数据和踩坑过程都摊开讲给正在被网课笔记折磨的朋友一个可以直接参考的完整方案。1. 截屏风暴的根源手动截图根本不是记笔记是无效劳动先说个扎心的事实截图这个动作本身没有错错的是“截完就完”的后续处理。我翻过自己过去的相册一节 40 分钟的课通常会留下 150 到 200 张截图其中至少有一半是同一页 PPT 的重复画面——老师翻了一页 PPT停顿几秒讲一个知识点我就本能地按下截屏过一会儿老师又翻回去回顾我又截一张。等真正开始复习我需要在一千多张图里做二次筛选而人眼筛选一千张图的效率和耐心消耗基本等于自杀式复习。真正让我决定写自动化工具的是三个无法忽视的痛点。第一截图是信息孤岛。手机相册里的图片无法全局搜索我明明记得某个公式出现过但就是想不起来它在第几张截图里第二图片没有文字层无法做目录、无法标注、无法快速打印成纸质材料全部依赖肉眼第三截图时机完全取决于我的注意力上课走神两分钟重点就漏过去了等回过神只能拉进度条反复补一来一回浪费的时间比视频本身还多。所以我把需求定义得特别清楚我需要的不是“更多截图”而是“更少但更精准的画面”。理想状态下200 分钟的课程应该被压缩成一份 200 到 300 页的 PDF页页都有有效信息每页都带可搜索的文字层PDF 体积还不能太大。这个需求一明确方案选型就顺理成章了。2. 整体架构与选型三条主流路线我为什么走了最难的那条2.1 技术路线对比整个项目市面上能走的路子大致有三条。第一条是找现成的字幕或讲义文件直接转 PDF这个方案最快但绝大多数网课根本没有字幕文件更别提讲义而且就算有字幕公式和图表全都丢了内容不成体系复习价值有限。第二条是固定间隔抽帧加 OCR比如每秒截一帧200 分钟就是 12000 张图。听起来很“全量”实际上重复画面爆炸每一页 PPT 停留 30 秒就意味着有 30 张几乎完全一样的图OCR 一遍下来还要做海量去重效率和体积都扛不住。第三条是我最终采用的方案用场景检测算法找出画面的突变点只保留“真的发生变化”的帧再对这批关键帧做 OCR 和相似度去重最后合成 PDF。这条路工程量和理解成本最高但它最贴近人眼记录笔记的逻辑——我只截“新出现的内容”重复的内容自动忽略既保证了画面信息无损又把页数控制在了合理范围。不同方案的对比如下方便你根据自己的课程类型做取舍方案信息完整度页数控制实现成本适合场景字幕/讲义直接转 PDF低无画面无图表好最低有配套讲义且以文字为主固定间隔截屏 OCR高但重复严重差动辄几千页低临时应急不追求效果场景检测抽帧 OCR PDF高好200 页量级中高所有以画面为主的网课2.2 组件清单与环境准备决定走第三条路之后我列的组件清单是这样的Python 3.10用于串联整条流水线PySceneDetect核心的场景检测库基于内容变化率找关键帧OpenCV负责图像预处理、模糊帧过滤和画质判断PaddleOCR负责中文文字识别带坐标输出img2pdf把已经处理好的图片无损嵌入 PDFffmpeg作为底层解复用器配合 PySceneDetect 快速定位帧环境安装部分有个细节值得提醒PySceneDetect 依赖 ffmpeg 或者 OpenCV 做视频解码我建议直接装 ffmpeg 并把可执行文件加进系统 PATH因为 OpenCV 的逐帧解码速度太慢200 分钟视频逐帧读会接近真实时长而 ffmpeg 可以做高效的随机帧定位。安装阶段最容易出现的坑是依赖版本冲突我建议新建一个干净的虚拟环境不要在全局环境里直接装。3. 从 200 分钟视频里抽出“该被截屏”的帧3.1 为什么固定间隔抽帧是灾难在介绍场景检测之前我想先算一笔账。假设视频是 25 帧每秒按“每秒截一帧”的策略200 分钟就是 12000 张候选图。如果按“每 0.5 秒截一帧”直接翻倍到 24000 张。这些图里一页停留 30 秒的 PPT 会贡献 30 张几乎一模一样的图真正的有效画面不到 5%。我试过先固定间隔抽帧再统一去重思路听着合理实际执行下来很狼狈。24000 张图先去重就要写哈希比对去重完还剩 1800 多张OCR 又跑了一个多小时最后 PDF 将近 300 页其中大量是老师讲某段代码时鼠标划过引起的细微差别复习时根本分不清重点。这让我意识到抽帧这个环节必须从源头就“带着脑子”不能指望事后补救。3.2 场景检测的原理与 PySceneDetect 实战场景检测的思路是用算法判断相邻帧之间的内容差异差异超过阈值就认为发生了“场景切换”也就是老师翻页、切换到下一个知识点、或者镜头切换。PySceneDetect 的 content 检测器用的就是这个逻辑它会把视频切成一个个场景片段每个片段代表一个完整的画面停留区间。我实际跑的命令是这样scenedetect -i course_video.mp4 -o output_dir \ --detector content \ --threshold 27.0 \ --min-scene-len 2.0 \ list-scenes --num-frames 3 \ save-images --jpg --quality 90这几个参数都是我试出来的。threshold 是场景切换的敏感度默认值是 27.0PPT 录屏课建议调到 30 以上不然鼠标箭头划过也能触发切换把一页 PPT 切成好几个片段实拍加 PPT 混合的课程要降到 15 到 20因为实景画面本身变化大阈值太高会把真正的翻页漏掉。min-scene-len 表示最短场景时长我设了 2 秒用于过滤掉视频里的闪烁和快速动画低于 2 秒的切换直接忽略。save-images 导出时我一开始用的 PNG导出 1800 多帧之后发现磁盘空间直接爆掉一张 1080p 的 PNG 要 3 到 5 兆40 多分钟视频就能吃掉 6 个 G。后来改成 JPG 并且把质量定在 90单张体积降到 300 KB 左右肉眼完全看不出质量差别文件体积却小了十几倍。这一点在后面合成 PDF 时同样重要。3.3 画质筛选把模糊帧、纯色帧踢出去场景检测筛出来的帧不一定都有价值至少有两类垃圾帧需要二次过滤。第一类是模糊帧比如老师切换画面的瞬间视频画面常常是半透明的过渡态如果用这时候的帧做 OCR识别率惨不忍睹。我用 Laplacian 算子计算图像方差方差越大说明边缘越清晰小于 80 的帧直接丢弃。代码实现如下import cv2 def is_blurry(img_path, threshold80.0): img cv2.imread(img_path, cv2.IMREAD_GRAYSCALE) if img is None: return True laplacian_var cv2.Laplacian(img, cv2.CV_64F).var() return laplacian_var threshold第二类是纯色帧或近纯色帧比如视频的开场黑屏、片尾的结束画面。这类帧的平均亮度极端可以通过计算灰度均值来过滤均值低于 20 或者高于 235 的帧直接丢掉。对了还有一个容易被忽略的坑如果视频源文件分辨率很低比如只有 720x480那么 OCR 识别前一定要放大不然小字基本认不出来。4. OCR 识别的选型与中文优化4.1 为什么第一选择是 PaddleOCR 而不是 TesseractOCR 选型我纠结过一阵子。Tesseract 是老牌开源方案但它的中文识别能力实在一般尤其是面对视频截图里的斜体、彩色文字和复杂背景错字率能到 20% 以上而且 Tesseract 输出的文本框坐标处理起来不够顺手做段落重建很费劲。PaddleOCR 在中文场景的识别率明显高一个档次自带方向分类器能处理旋转后的文字最重要的是它的 OCR 结果带每个文本框的坐标重建段落时非常方便。我也顺手对比了桌面级用户反馈比较多的 RapidOCR它本质上是 PaddleOCR 模型的 onnxruntime 移植版优势是 CPU 环境下的安装包更小、依赖更干净识别速度也不差。如果你的机器性能一般又只需要识别文字不需要复杂排版RapidOCR 是更轻的选择。我整套流程里 PaddleOCR 的 CPU 占用确实偏高后面会专门讲怎么缓解。PaddleOCR 的安装和初始化很简单pip install paddlepaddle paddleocrfrom paddleocr import PaddleOCR ocr PaddleOCR( langch, use_angle_clsTrue, show_logFalse, use_gpuFalse )4.2 关键调优先放大再识别视频截图里的文字尺寸普遍偏小1080p 画面上 16 号字在电脑上看还行直接喂给 OCR 模型识别率会掉。我在实践中发现把图片统一放大 1.5 到 2 倍再识别错字率能降低一半以上。放大用 OpenCV 的 resize 加 INTER_CUBIC 插值算法就好然后转灰度再做一次简单的对比度增强把背景和文字的界限拉得更开。这套预处理做完PaddleOCR 的识别结果稳定多了。识别后我还会按置信度过滤低于 0.6 的文本框直接丢弃因为视频画面里的水印、角标经常被当成文字识别出来这些内容混进笔记里反而是噪音。过滤之后把高置信度的文字按文本框坐标排序从左上到右下重组成段。4.3 文本框坐标排序与段落重建这里有个排序的细节值得展开。PaddleOCR 返回的文本框坐标是 (box, text, confidence)box 是四个角的坐标。直接按“先按 top 再按 left”排序会出问题同一行里明明有中文和英文混合英文识别出的 box 可能比中文略高或略低结果一行文字被切成两段段落结构全乱了。我的做法是先按 box 中心点的 y 坐标聚类中心点 y 坐标差的绝对值小于 20 像素的文本框视为同一行行内再按 x 坐标排序。行与行之间用换行符拼接段落之间根据行距判断是否要空一行。这个逻辑看着简单却直接影响最终 PDF 里文本的可读性值得花时间调一调。5. PDF 组装与相似页去重让“犹豫要不要截”的页面自动消失5.1 图片转 PDF 的三个方案对比OCR 完成后我手里是一个个图片文件加对应的文本文件接下来就是合成 PDF 的环节。这一步我试过三个方案直接上对比表方案图片编码方式体积控制速度适用场景Pillow save_all重新压缩编码差体积偏大中等快速原型img2pdf原始数据直接嵌入好无二次损失快大批量合成reportlab重编码图片并建矢量文本层可控但图片仍重编码慢需要目录和批注最终选择 img2pdf 的原因很直接它把 JPG 里已有的压缩数据原样嵌入 PDF 容器不重新编码速度快质量几百页的文档只需要几秒体积就是你存的那批 JPG 加一点容器开销。Pillow 的 save_all 虽然能在一行代码里搞定但它会重新压缩图片放大质量损失和体积。img2pdf 的用法也简单import img2pdf pdf_bytes img2pdf.convert(sorted_image_paths) with open(网课笔记.pdf, wb) as f: f.write(pdf_bytes)需要说明的是“无损”这个词在这儿有边界我追求的是画面信息无损用高质量 JPG 嵌入 PDF不是逐像素无压缩。真用 PNG 无损嵌入200 多页 PDF 能上 2 个 G根本不具备实用性。我用质量 90 的 JPG肉眼识别不出和原画的差别PDF 体积却只有原来的几十分之一。5.2 相似页去重用感知哈希先粗筛虽然场景检测已经把重复画面过滤掉了一大半但动画翻页、老师拖动进度条回看等操作还是会产生相似页。我给这层去重写的逻辑是感知哈希加汉明距离每张图片缩成 16x16 的灰度小图比较相邻像素的亮度变化生成一串哈希值两张图的哈希值差异汉明距离小于 3 就视为重复保留前一张。这种方法对“整体页面相同但鼠标划过某处”的情况免疫比像素级比较实用得多。有个特殊情况需要小心PPT 自带的切换动画比如淡入淡出会产生一系列连续渐变的帧。如果只按汉明距离去重这些过渡帧会全部保留导致 PDF 里连续好几页都是同一内容的逐步显现。我的处理方式是在去重前再套一层人工规则连续 5 帧汉明距离都小于 3就只保留第一帧和最后一帧中间的过渡帧全丢。这样既能保留动画的完整内容又不会把 PDF 撑爆。5.3 文件名与目录整理到了输出阶段梳理文件结构是最后一公里。我按视频章节份建目录一个视频对应一个子目录子目录里分两张表存档images 目录放关键帧图片ocr_text 目录放每张图片对应的文本。全流程跑完后我再把所有 ocr_text 合并成一个总索引文本文件这样以后想看某个知识点的上下文用搜索工具在总索引里一搜就能定位到对应页码和原视频时间点比在几百张截图里翻找高效得多。这个总索引文件我觉得是整个方案里被低估的设计。它让 PDF 从单纯的图片合集变成了一个可检索的知识库而这一切只因为我在流水线最后多写了一个合并步骤。6. 实测200 分钟网课压成 286 页 PDF 的真实数据与耗时分布6.1 输入输出数据对照我把这套流程跑在了一门 200 分钟的全 PPT 录屏课上输出结果我用一张表完整列出指标数值视频总时长200 分钟分 4 个视频文件视频分辨率1920x1080初始候选帧0.5s 间隔约 24000 帧PySceneDetect 检出的场景数1873 个模糊/纯色过滤后保留1321 帧相似度去重后最终页数286 页每页平均 OCR 文本长度约 180 字最终 PDF 体积61 MB这个数字对比当初人工截图的 800 多张页数少了近三分之二但内容覆盖率反而更高因为我漏截图的地方程序帮我补上了。286 页对应 200 分钟课程大概每 42 秒一页和老师讲解的节奏基本吻合。用 61 MB 的体积换回一份可以搜索、打印、批注的完整笔记我觉得这笔账是划算的。6.2 耗时分布与硬件影响流程里的时间开销分配很关键我用一台 i5-12400、32G 内存、无独显的机器实测总体耗时如下阶段耗时说明场景检测与抽帧26 分钟PySceneDetect ffmpeg真正逐帧读取画质过滤3 分钟OpenCV 批处理 1873 张图OCR 识别36 分钟PaddleOCR CPU 模式1321 帧单帧约 1.6 秒相似度去重与 PDF 合成4 分钟感知哈希 img2pdf总耗时大约 70 分钟换来的是过去人工 4 到 6 个小时才能勉强完成的笔记整理。如果机器有 NVIDIA GPUOCR 阶段可以降到 5 分钟左右整体压缩到 40 分钟以内。所以我建议有条件的同学尽量让 PaddleOCR 走 GPU这是全流程里性价比最高的一项升级。6.3 不同课程形态的参数调整建议实测跑通之后我拿着同一套流程试了几种不同形态的网课发现参数不能一概而论。PPT 录屏课是最理想的场景threshold 设 30 以上、min-scene-len 设 3 秒就够稳实拍加 PPT 混合的视频threshold 要降到 15 到 20因为实景画面的光照和摄像头位置变化会频繁触发切换条件阈值低了反而会把真正的 PPT 翻页过滤掉。还有一类课程是代码实操录屏终端里的文字比 PPT 还小OCR 前不放大两倍基本没法看。这种课程我额外在每帧左侧裁剪了代码区只 OCR 代码部分把旁边的桌面背景和系统通知栏全部排除掉识别率直接提升一个档次。刚需场景加刚需参数这套流程的灵活性我觉得相当可以了。7. 调试中踩过最深的四个坑7.1 中文路径让 OpenCV 读不出视频和图片第一个坑就出现在环境搭建环节。我习惯把文件放在中文目录比如“网课视频”结果 OpenCV 的 VideoCapture 一碰到中文路径就返回空对象视频始终打不开。后来我用 os.chdir 切到工作目录、再传相对路径也不行最稳妥的办法是全局用英文临时目录处理最后再改回中文文件名。处理图片时也可以直接用 numpy 从字节流解码来绕过路径问题import cv2 import numpy as np data np.fromfile(中文路径/图片.jpg, dtypenp.uint8) img cv2.imdecode(data, cv2.IMREAD_COLOR)7.2 PNG 帧把 PDF 撑到 1.2GB第一次跑完整流程我用 PySceneDetect 默认的 PNG 格式导出帧配上 Pillow 合成 PDF最后生成的文件高达 1.2GB。这个教训让我明确了两件事一是中间产物必须用 JPG 控制体积二是 PDF 合成必须用 img2pdf 而不是 Pillow。img2pdf 直接把 JPG 数据搬进 PDF不重新编码这一步就把体积从 1.2GB 压到了 58MB质量还更高。7.3 OCR 把上下结构的两页内容混在一起还有一个坑出在段落重建上。某页 PPT 上半部分是标题和正文下半部分是横放的表格PaddleOCR 返回的文本框坐标里表格的文字 y 坐标跨度很大我初期按 x 排序结果表格内容被拆成好几段塞到正文里整页文本逻辑全乱。后来改为按 y 坐标聚类分块先判断整块文字区的结构再把表格区单独拎出来处理。这个逻辑我调了好几次才稳定属于典型的“细节决定成败”。7.4 OCR 进程 CPU 占用高识别速度慢PaddleOCR 在 CPU 模式下默认吃满多核识别速度快但电脑基本没法干别的你要是边跑 OCR 边看别的课程风扇噪音能比 PPT 声音还大。可以显式限制线程数并开启 mkldnn 加速代码里加两个配置能改善不少。如果对识别速度有硬要求建议直接换 RapidOCR它是 PaddleOCR 模型的 onnxruntime 版本CPU 占用更平稳安装也轻量。截止到这里这套流程已经能稳定处理我遇到的绝大多数网课场景了。不过在用了几次之后我的体会是自动化真正改变的不是“记笔记”这个动作而是把记笔记的重心从“机械采集”挪回到了“理解内容”上。过去我花 4 个小时截屏整理不如现在花 70 分钟跑完流程再用 30 分钟认真读一遍 PDF。如果你也有同样被截图吞没的烦恼我建议你不用一步到位复刻全部功能先跑通“场景检测抽帧 img2pdf 合成”拿到一份不带文字层的纯图 PDF就已经比人工截图高效太多了。后面再逐步加 OCR 和去重你会明显感觉到每一层优化都在把笔记往“知识库”的方向推进一点。
