短视频批量下载与水印去除：ffmpeg素材流水线实战

去年帮一位做本地生活内容的同行整理素材库，他手机里躺着两千多条自己拍的短视频，散落在十几个相册文件夹里，命名清一色是缩略图时间戳，想做成合集却发现连"先把手里的东西收拢到一个地方"这一步都卡住了。短视频批量下载与水印去除，听起来是两件不相干的事，实际是一条流水线上的前后两段：前一段负责把散落的内容收拢成本地可管理的文件，后一段负责把画面上那行账号角标清理掉，让素材变成能直接进剪辑时间线的干净底片。这套东西适合三类人——做内容归档的运营、需要复用自有素材的剪辑、以及想搞明白"文件到底是怎么从网页变成磁盘上一个 mp4"的技术爱好者。它不需要多深的算法功底，但确实有很多只有踩过才知道的细节：链接为什么十分钟后就失效、并发开到八个为什么全被限流、delogo参数差两个像素为什么就糊成一片。下面这些内容是我从零搭这套流水线时留下的完整记录，包括选型理由、参数计算、脚本骨架和一堆不太好意思写进文档的翻车现场。

1. 先把边界和技术路线想明白

动手写第一行代码之前，有两件事必须先定下来：这套流水线处理的是谁的素材，以及整个系统分成几层。前者决定你后面会不会白干，后者决定你三个月后还改不改得动这份代码。我见过太多人上来就抓链接、写正则、堆并发，跑到一半发现文件全糊在一起，回头重构的成本比从头写还高。

1.1 场景边界：这套技术只对"你有权处理的内容"成立

先把话说在前面，这不是一句免责声明，而是实打实的技术前提。水印在技术上的本质是一段叠加在画面上的像素信息，它在编码阶段就已经和画面融为一体了，去除它的过程本质上是"有损修复"——用周围的像素去猜被覆盖的像素应该长什么样，猜得再准也不可能百分百还原原始画面。所以但凡涉及他人作品，这件事既没有技术上的完美解，也没有使用上的正当性。

真正站得住的场景只有三类。第一类是自有内容归档：你自己账号后台能导出、能下载的作品，批量拉回本地做备份或者二次剪辑，这是最干净的一类。第二类是已获授权的内容：合作方明确授权你使用并二次加工的素材，注意要留存授权凭证，别口头说说。第三类是公开授权素材：明确标注可商用、可修改的素材源，这类通常本身就无水印，处理环节只是格式统一。

我个人的做法是把"来源标记"写进任务清单的每一个字段里，每条任务带一个license_tag，值为own、authorized、public三选一。跑批之前先按这个字段过滤一遍，own之外的必须人工确认过才放行。这个字段看起来只是个字符串，但它在半年后你回头看一堆文件时，能救命。

注意：任何平台的用户协议里几乎都有关于自动化访问的条款，动手前花十分钟读一遍，比事后删库跑路省事得多。真要做规模化归档，优先走平台官方提供的创作者导出功能，那是最稳的路。

1.2 四层架构：把"下载"和"处理"彻底解耦

整套流水线我拆成四层，层与层之间只通过文件系统和一张任务表通信，不共享内存状态。这个设计的直接好处是：下载卡住了不影响处理，处理脚本改坏了不用重下。

为什么坚持用 SQLite 而不是内存里的字典？因为批处理跑到第 800 条的时候，你的脚本大概率会崩一次——网络抖动、磁盘满、某条视频编码异常。内存状态一崩全丢，SQLite 至少能让你从第 801 条接着跑。状态机也很简单，就五个值：pending、resolving、downloading、processing、done，再加一个failed。每次状态变更写一行日志，出问题直接查表就知道卡在哪。

1.3 三次选型踩坑：为什么最后落在 requests + ffmpeg 上

第一条路我试的是无头浏览器方案，用 Playwright 模拟真实用户操作，滚动、点击、嗅探网络请求。优点是不用逆向任何东西，缺点是慢得离谱——单条视频平均要 8 到 12 秒，2000 条就是六个多小时，而且内存占用随页面加载蹭蹭往上涨，跑到 300 条左右浏览器就自己崩了。这条路适合做原型验证，不适合跑批。

第二条路是纯 asyncio + aiohttp 全异步。理论吞吐最高，实测也确实快，单条能压到 1.5 秒以内。但问题出在调试成本上：断点续传的异常处理在协程里写起来极其啰嗦，一个CancelledError冒出来能把整个事件循环带崩；再加上限速逻辑要自己实现令牌桶，稍微写错一点就是几百个请求瞬间打出去，直接吃限流。

最后落地的方案是混合制：采集层用轻量的 HTTP 请求 + 结构化解析拿元数据，拿到真实媒体地址后交给下载层；下载层用ThreadPoolExecutor(max_workers=4)配requests的流式下载。为什么是 4 不是 16？因为实测下来 4 个并发就能把百兆宽带的带宽吃满七成以上，再加并发只是增加被限流的概率，边际收益趋近于零。而线程模型的好处是阻塞式 IO 写起来直观，stream=True配合iter_content分块写盘，断点续传就是加个Range头的事。

后处理层没有任何悬念，就是 ffmpeg。它一个二进制文件解决了裁剪、缩放、模糊、修复、转码、抽帧、探测全部需求，而且是纯命令行，天生适合被脚本调用。唯一的"选型"是要不要上 libvpx 之类的高质量编码器——结论是不用，H.264 配 CRF 对这类素材完全够用，编码速度和兼容性都更划算。

2. 批量下载的骨架：任务表、并发与断点续传

采集层拿到地址之后，真正决定这套流水线稳不稳的是下载层。这一层要解决的核心矛盾只有一个：如何在尽可能快地拿到文件的同时，不把自己搞成被限流的对象。剩下的全是细节，但细节堆起来就是稳定性。

2.1 任务清单该存哪些字段

一条任务记录我固定存这几个字段，多一个浪费，少一个就难受：

• id：自增主键，不要用 URL 做主键，同一个视频可能有多个地址
• source_ref：来源标识，短哈希即可，用于反查
• title/author/duration/publish_ts：元数据，后面命名和排序都要用
• media_url：解析出来的真实媒体地址，有时效性
• license_tag：前面说的授权标记
• status/retry_count/last_error：状态机三件套
• local_path/file_hash：成品路径和内容哈希
• created_at/updated_at：时间戳，排查问题时按时间排序特别有用

这里有个非常关键的点：media_url是有寿命的。绝大多数平台的媒体地址带了签名参数，有效期从几分钟到几小时不等。所以整条链路的顺序必须是"解析 → 立刻下载"，绝不能"先把 2000 条全解析完，再统一开始下载"。我第一版就是这么写的，结果解析完第一批，开始下载时全部返回 403，白折腾一晚上。正确的做法是解析和下载做成流水式，解析一条、入队一条、下载一条，队列长度控制在 20 以内。

去重我用了双保险。第一道是元数据三元组(author, title, duration)做唯一索引，插入时就挡住明显重复；第二道是下载完成后算blake2b内容哈希，同哈希的直接删掉新文件。第二道防止的是同一条视频被不同来源重复收录的情况。哈希计算要注意用分块读取，别把 500MB 的文件一次性读进内存。

2.2 并发、限速和那些让人抓狂的 403

并发模型定了 4 个 worker，但光有并发不够，还得有节流。我实现了一个极简的令牌桶：全局共享一个Semaphore(4)控制并发数，另外每个 worker 在发起请求前，从桶里取一个令牌，桶以每秒 2 个的速率补充。这个速率是我对着实际响应调出来的——每秒 2 个请求能稳定跑几个小时不出问题，每秒 5 个跑十分钟就开始零星返回 429。

请求头这块，别偷懒。至少要带User-Agent、Referer（很多时候缺了它直接 403）、Accept-Encoding里不要包含br（某些老版本 requests 解 brotli 会出问题，直接导致你拿到一堆乱码）。超时设置成(5, 30)的元组，连接 5 秒、读取 30 秒，别用单一数值，连接超时和读取超时是两个完全不同的概念。

失败重试我用指数退避，间隔是2^n + random(0, 1)，最大重试 5 次。加随机抖动是为了避免多个 worker 在同一时刻集体重试，反而形成一个小峰值。重试之前先判断错误类型：403和404不重试，直接标记失败，因为这类错误重试一万次还是同样的结果；429和5xx才值得退避重试；ConnectionError和Timeout单独统计，超过阈值就整体降速。

提示：跑到中途突然大面积 403，别急着改代码，先换个出口 IP 或者停半小时再试。大多数限流是按时间窗口算的，硬刚只会让窗口越拉越长。

2.3 断点续传落地：.part文件的三个约定

断点续传的代码不复杂，难的是约定。我定了三条规矩，跑了几千条没出过乱子。

第一，下载中的文件一律用.part后缀。这样任何时刻你扫一眼目录，都知道哪些是半成品。后处理脚本只扫.mp4，天然不会碰到半成品。

第二，续传前必须校验本地文件大小和服务端返回的Content-Range是否对得上。具体做法是发一个Range: bytes={local_size}-的请求，如果返回 206，说明服务端支持续传，把响应体追加到.part文件末尾；如果返回 200，说明服务端不支持 Range，这时候要么从头下，要么直接放弃续传。第二种情况我选择"从头下 + 清空.part"，因为混着写必然损坏。

第三，下载完成后校验总长度再改名。校验依据有两个：Content-Length（如果有）和实际写入字节数。两者不一致就判定失败，保留.part等下一轮续传。改名用os.replace，这是原子操作，避免出现"文件已存在但内容不完整"的中间态。

还有一个隐蔽的坑：如果服务端返回的是分片流（m3u8），那requests拿到的根本不是视频，而是一个文本清单。这种情况Content-Type通常是application/vnd.apple.mpegurl或者text/plain。我的处理方式是在下载层之前加一道类型嗅探，识别到分片清单就直接转交给 ffmpeg 处理，用ffmpeg -i "清单地址" -c copy -bsf:a aac_adtstoasc out.mp4一次性拉完。让 ffmpeg 去处理分片拼接比你自己下载几百个 ts 再拼要稳得多。

2.4 命名与目录分层：三个月后还能找到东西

文件命名规则我用的是{发布日}_{作者}_{标题精简}_{哈希前6位}.mp4。为什么带哈希后缀？因为标题经常重复、作者名里可能有全角字符和斜杠，光靠前两段保证不了唯一性。哈希取前 6 位，碰撞概率对几千条的规模来说可以忽略。

标题精简要做几件事：去掉首尾空白、把/ \ : * ? " < > |这些文件系统非法字符替换成下划线、连续空白压成一个、超过 40 个字符截断。中文标题别按字节截断，按字符截，不然后面会出乱码。

目录按年/月两层分，例如library/2024/06/。为什么不再细分到日？因为一天内的文件数量通常不多，分太细反而增加跳转成本。为什么按发布时间而不是下载时间？因为你要做合集的时候，是按内容的时间线来组织的。

3. 水印去除的三条技术路线与选择依据

这一节是整篇文章里最容易被人误解的部分。很多人以为水印去除是个"点一下就干净"的操作，实际完全不是。你需要先搞清楚水印是怎么叠上去的，才能决定用哪条路线。

3.1 先分类：三种水印，三种命运

从技术特征上，水印可以分成三类，处理难度天差地别。

第一类是叠加型水印，即平台在你上传之后，用图形方式把角标、账号名叠加在画面固定位置，然后重新编码。这类水印的特征是位置固定、大小固定、颜色半透明。它是三条路线里最好处理的，因为你知道它确切在哪、占多大。

第二类是内嵌型水印，即在编码阶段就把标识信息嵌进了画面像素里，甚至嵌在色度通道或者频域里。这类水印的位置可能不固定，也可能人眼看不出来但算法能检出。遇到这类，任何像素级处理都是在破坏画面，正确做法是放弃处理，去找有无水印的源文件。

第三类是动态水印，位置会随时间缓慢漂移，今天在右上角，半分钟后跑到左下角。这类最难，因为固定区域的裁剪和修复全部失效，必须做逐帧追踪。

我处理的大多是第一类。识别方法很简单：抽三帧不同时间点的画面，差分一下，看水印区域是否稳定。稳定就是第一类，漂移就是第三类。这个判断花不了两分钟，但能省掉后面大量的无用功。

3.2 路线一：几何裁剪，快、稳、但会丢画面

最朴素的办法是把带水印的那块直接切掉。如果水印在边角，而画面主体在中间，这一刀切下去几乎无损。

为什么这条路线值得优先考虑？因为它不涉及任何像素重建，是无损的。裁剪只是改变了取景框，画面内容本身一个像素都没动。相比之下，后面两条路线全是"猜"，猜错了就是糊块。

代价是分辨率会变，或者宽高比会变。常见处理是"切完再缩放回原尺寸"，但这会引入一次重采样，画面会轻微变软。如果原片是 1920×1080，水印在右侧占了 120 像素宽，切完是 1800×1080，直接输出也可以，很多播放器会自动加黑边，不影响使用。是否缩放回原尺寸，取决于你的下游流程——如果下游是固定尺寸的模板，那就缩；如果下游会自适应，那就别缩，保留原始像素更划算。

适用性判断有个简单标准：水印占据的画面比例低于 8%，且不覆盖主体，就优先走裁剪。

3.3 路线二：区域覆盖，模糊与马赛克的取舍

水印压在画面正中间，或者压在人脸上，裁剪就废了。这时候考虑区域覆盖——在那一小块区域上做模糊或者打码。

模糊用什么？ffmpeg 的boxblur或者gblur都行，参数是模糊半径。半径太小（比如 3）水印还能看出轮廓，太大（比如 20）那一块就是个明显的毛玻璃块，反而更扎眼。我的经验值是半径取水印区域短边的 1/6 到 1/4 之间，具体看水印的笔画粗细。比如水印框是 300×90，短边 90，半径取 15 到 22 之间比较合适。

为什么要用overlay而不是直接对整个画面加滤镜？因为 ffmpeg 的滤镜链默认作用于全帧。要做局部模糊，必须先split成两路，一路原样，一路模糊，再用crop配合overlay把模糊的那块贴回去。这个链路的写法我在下一节给完整命令。

马赛克（像素化）比模糊更"诚实"——它明确告诉观众"这里被处理过了"，不会有"画面怎么糊了一块"的观感。ffmpeg 里没有现成的马赛克滤镜，得用scale缩小再放大，配合neighbor标志位实现。缺点是处理时间翻倍。

注意：区域覆盖只适合处理边角料性质的水印，比如账号名、平台角标。如果水印底下是重要内容，糊掉它等于毁掉画面，那就该走第三条路线。

3.4 路线三：内容感知修复，效果最好也最娇气

第三条路线是让算法去"猜"被水印覆盖的像素原本是什么。ffmpeg 自带一个叫delogo的滤镜，原理是从矩形区域四周的像素采样，然后用插值的方式填充内部。它不算真正的智能修复，但对纯色背景、渐变背景、缓慢运动的画面效果相当不错，而且速度快——720p 视频处理速度大概能到实时的 8 到 10 倍。

delogo的参数就四个核心的：x、y、w、h，加上一个band（采样带宽度）和一个show（调试用，设为 1 会画出绿框）。参数怎么算？假设 1920×1080 的视频，水印在右上角，你用播放器逐帧暂停，目测水印左上角大概在 (1560, 40)，右下角在 (1860, 120)。那么：

• w = 1860 - 1560 = 300
• h = 120 - 40 = 80
• 但是不能直接用这个值，必须向四周各扩 4 到 6 个像素，把水印边缘的抗锯齿和半透明过渡带一起包进去
• 最终x = 1554，y = 34，w = 312，h = 92

为什么必须外扩？因为水印边缘不是硬边，是带羽化的。如果框得太紧，框外的残留边缘会在修复后形成一圈明显的亮边，比不处理还难看。这个教训我是吃了两次才记住的。

band参数控制采样带的宽度，默认是 1，指的是从框外取多宽的一条像素来参与插值。画面纹理复杂的时候，把band调大（比如 4 到 8）能拿到更多参考信息，但也会让边缘过渡更软。纯色背景上band=1就够，复杂背景建议 4 起步。

如果delogo的效果不理想——比如水印横跨了一条明显的物体边缘，修复后那条边缘会断裂——那就得上前沿方案了：基于深度学习掩码的视频修复。思路是用第一帧手工画出水印掩码，然后让模型逐帧生成填补内容，同时保证时间一致性，避免闪烁。这类方案效果确实好，但代价是算力：一段 1 分钟的视频，在消费级显卡上跑十几分钟是常态，而且对掩码的精确度极其敏感。我一般只在确实要用的少数素材上开这条路线，批量处理不会碰它。

3.5 动态水印：追踪加逐帧修复的工程思路

位置漂移的水印没有什么一劳永逸的办法，只能做追踪。工程上的实现路径是：先抽帧（每秒 2 帧足够），在每帧上用模板匹配或者特征点对齐定位水印位置，得到一条位置随时间变化的轨迹；然后按段切分视频，每段内水印位置近似不变，分别用不同的delogo参数处理；最后把各段拼接回去。

这条链路的坑在于拼接处的接缝。即使只是把位置参数变了一下，编码边界处也容易看出色差或者跳变。缓解办法是让相邻段有 0.5 秒的重叠，拼接时用交叉淡化。整套流程写下来代码量不小，除非你真的大批量处理动态水印素材，否则不建议自己造，性价比太低。

4. ffmpeg 实操：从单条命令到可跑批的脚本

理论讲完，落到命令上。这一节给的都是我在实际生产里跑过、验证过的东西，参数可以直接抄，但务必先拿一条素材试跑，别直接怼整个目录。

4.1 三条核心命令与参数计算

裁剪去角标，水印在右侧 120 像素：

ffmpeg -i input.mp4 \ -vf "crop=iw-120:ih:0:0" \ -c:v libx264 -crf 19 -preset slow \ -c:a copy \ output.mp4

crop的语法是crop=宽:高:x:y，iw-120表示宽度取输入宽度减 120，ih是输入高度，0:0是左上角起点。注意这里-c:a copy是直接复制音频流，不重新编码——音频重编码既浪费时间又损失质量，除非你确实要改采样率或者声道。

局部模糊，水印框在 (1554, 34)，尺寸 312×92：

ffmpeg -i input.mp4 \ -filter_complex "[0:v]split=2[base][tmp]; \ [tmp]crop=312:92:1554:34,gblur=sigma=18[blurred]; \ [base][blurred]overlay=1554:34" \ -c:v libx264 -crf 19 -preset slow \ -c:a copy \ output.mp4

这里split=2把画面复制成两路，[tmp]那一路先crop出目标区域再模糊，最后overlay贴回原位置。顺序不能反——先模糊再裁剪会把整个画面都糊掉，白白浪费计算量。

delogo 修复：

ffmpeg -i input.mp4 \ -vf "delogo=x=1554:y=34:w=312:h=92:band=4" \ -c:v libx264 -crf 18 -preset slow \ -c:a copy \ output.mp4

CRF 这里给到 18，比裁剪那一档低一点，因为修复过程中产生的插值细节比较容易被压缩吃掉，给足码率能让过渡更自然。

参数选择的逻辑补充：CRF是恒定质量模式，数值越低质量越高体积越大。19 到 23 是常用区间，20 以上肉眼开始能看出区别，17 以下体积膨胀明显但收益递减。我统一用 19，除非素材本身噪点极多——噪点多的画面 CRF 太低保体积会爆炸，这时候提到 21 反而更合理。preset从ultrafast到veryslow共九档，直接影响编码耗时，slow相比medium大约慢一倍、体积小 8% 左右，批量跑的时候时间成本很可观，赶时间的话medium也完全够用。

4.2 批量脚本骨架

单条命令手敲没问题，几百条就得靠脚本。下面这个 Python 骨架我用了很久，逻辑是"读任务表 → 逐个调 ffmpeg → 写回结果"：

import subprocess, sqlite3, pathlib, json, time def build_filter(meta): """根据元数据决定用哪条路线，返回 vf 字符串""" if meta["wm_ratio"] < 0.08: return f'crop=iw-{meta["crop_w"]}:ih:0:0', "crop" if meta["mode"] == "blur": return None, "blur" # 走 filter_complex 分支 return (f'delogo=x={meta["x"]}:y={meta["y"]}:' f'w={meta["w"]}:h={meta["h"]}:band=4'), "delogo" def run_one(row): src, dst = pathlib.Path(row["local_path"]), pathlib.Path(row["out_path"]) tmp = dst.with_suffix(".tmp.mp4") if dst.exists(): return "skip", "" vf, mode = build_filter(row) if mode == "blur": cmd = ["ffmpeg", "-y", "-i", str(src), "-filter_complex", f"[0:v]split=2[a][b];[b]crop={row['w']}:{row['h']}:" f"{row['x']}:{row['y']},gblur=sigma=18[c];[a][c]overlay={row['x']}:{row['y']}", "-c:v", "libx264", "-crf", "19", "-preset", "slow", "-c:a", "copy", str(tmp)] else: cmd = ["ffmpeg", "-y", "-i", str(src), "-vf", vf, "-c:v", "libx264", "-crf", "18" if mode == "delogo" else "19", "-preset", "slow", "-c:a", "copy", str(tmp)] try: subprocess.run(cmd, check=True, capture_output=True, timeout=1800) tmp.replace(dst) # 原子改名，避免半成品被下游读到 return "ok", "" except subprocess.CalledProcessError as e: tmp.unlink(missing_ok=True) return "fail", e.stderr.decode("utf-8", "ignore")[-500:]

几个关键点说明一下。-y是覆盖输出文件，不加的话 ffmpeg 会卡在交互提示上，脚本直接挂起——这个坑我踩过，批量跑到一半全部卡死，排查了半天才发现是等用户输入。capture_output=True必须配timeout，否则某个文件触发 ffmpeg 的死循环（罕见但存在），整个批处理就停在那儿了，timeout=1800是 30 分钟，对绝大多数短视频绰绰有余。输出到.tmp.mp4再replace，是为了防止下游的监听脚本读到写了一半的文件。

失败处理里我只截取stderr的最后 500 个字符。为什么是最后？因为 ffmpeg 的报错信息永远在最后几行，前面全是无用的流信息。存全部会把数据库撑爆。

4.3 处理完必须做的三项质检

跑完不算完，必须质检。我固定做三项检查，成本很低但能挡住绝大多数事故。

第一项是流信息核对，用ffprobe拿到分辨率、时长、码率：

ffprobe -v error -select_streams v:0 \ -show_entries stream=width,height,duration,bit_rate \ -of json output.mp4

比对处理前后的时长，偏差超过 0.1 秒就说明有问题——通常是裁剪参数让帧数对不齐，或者音频流复制失败。分辨率要和预期完全一致，不一致说明crop语法写错了，比如把iw-120写成了iw-120:ih之类。

第二项是抽帧目检。取首帧、中间帧、末帧三张图，缩略图拼一起看一眼。主要看三件事：水印区域有没有残留、边缘有没有明显的矩形色块、画面有没有整体偏色。这项检查自动化程度不高，但几秒钟的事，我一般批量跑完抽十条看看，发现问题再回头查。

第三项是体积异常检测。同一条视频，处理前后体积比应该在 0.5 到 2.0 之间。比值小于 0.3 说明编码参数出了大问题（通常是 CRF 被误设成了 35 以上），大于 3.0 说明码率给太足了，白白浪费空间。这个规则抓过我好几次——有一次脚本里的 CRF 变量被覆盖成空字符串，ffmpeg 默默用了默认值，体积直接翻四倍。

5. 常见故障排查与独家避坑清单

跑了大概四千多条之后，我发现故障其实高度集中，七八个原因能解释九成以上的问题。下面这份表是我自己整理的速查清单，遇到报错先对号入座，比从头 debug 快得多。

5.1 下载环节的问题速查

这张表里最值得展开的是第一条。媒体地址过期这个问题，本质上是个时序问题，不是网络问题。我第一次遇到时疯狂加User-Agent、换Referer、加Cookie，折腾两小时无果，最后发现把"先全解析再全下载"改成"解析一条下一条"，问题自己就消失了。这类问题的特征是第一批能下、后面全挂，看到这个模式就该往时效性上想。

第二条也值得说。限流的触发阈值往往不是固定的，而是滑动窗口。你可能前 5 分钟每秒发 5 个都没事，第 6 分钟突然全挂。所以限速策略要留余量，宁可跑慢点也别贴着阈值跑。我的做法是先按 2/s 跑 20 条，观察响应码分布，如果全是 200 就维持，出现一个 429 立刻降到 1.5/s 并保持整轮。

5.2 后处理环节的问题速查

Invalid too big or non positive size这个报错我遇到不下五次，全是同一个原因：裁剪参数超过了视频实际尺寸。有些视频标称 1080p，实际是 1080×1920 的竖版，你按横版的逻辑去减 120，宽度就成负数了。所以在生成crop参数之前，必须先ffprobe拿到真实尺寸，别信文件名里的标注。

音画不同步这个问题更隐蔽。它的成因是：视频重编码会重新排列帧的时间戳，而音频直接copy保留了原始时间戳，两者的起点就对不上了。短视频场景下这个偏差通常在几十毫秒，人耳刚好能感觉到。解决办法要么是音频也重编码（加-c:a aac -b:a 128k），要么在视频侧做时间戳对齐。我现在的默认策略是：只要动了视频流，音频就统一重编，用 128k 的 AAC，代价可以接受，换来的是零同步问题。

5.3 几条不太好意思写进文档的经验

并发别超过 4，真的。我知道 8 个 worker 的吞吐看着更漂亮，但你会在跑到第 500 条左右迎来一波集体 429，然后为了恢复限流状态又得等半小时。算总账下来，4 个 worker 的完成时间反而更短，因为它不用等窗口冷却。

边下边处理是个坏主意。我试过下载线程和 ffmpeg 同时跑，想着能省一半时间。结果是磁盘 IO 被打满，下载速度掉一半，ffmpeg 编码也掉一半，两边互相拖累。正确做法是分阶段：先集中下载，再集中处理。如果非要并行，把处理的临时目录放到另一块物理盘上。

留着原始文件。处理完的第一版千万别急着删源文件。我有一次delogo参数设错，把 200 条素材全糊了一片，源文件早被脚本清理了，只能重下。现在我的策略是：源文件保留 30 天，或者至少保留到成品通过质检为止。

-y参数是把双刃剑。它省掉了交互确认，但也意味着一旦路径拼错，它会毫不犹豫地覆盖已有文件。我在run_one里加了if dst.exists(): return "skip"这道保险，代价是重跑时要手动删掉想重做的文件，但比误覆盖安全得多。

先跑 10 条，再跑 10 条，再跑全部。这个节奏听着啰嗦，但能救命。第一批 10 条验证参数，第二批 10 条验证稳定性（尤其是限流），都没问题再放开。我跳过这一步的后果是一次性跑挂了 800 条，其中 300 条是参数错误产生的废品。

提示：把每批的last_error汇总看一遍，哪怕没有失败，也留意警告信息。很多时候 ffmpeg 返回 0 但stderr里有deprecated pixel format之类的提示，这类提示往往是后面出问题的前兆。

6. 关于这套技术，我最后想说的一点体会

整套流水线搭下来，代码量其实不大——核心逻辑加起来不到四百行，剩下全在调参数和处理边界。真正花时间的不是"怎么写"，而是"怎么判断"。判断一条素材该走裁剪还是修复，判断这个水印框该外扩 4 还是 6 像素，判断这批失败是限流还是地址过期。这些判断没有标准答案，只能靠一条条跑出来。

我现在的做法是先做参数档案：给每类素材（竖版、横版、带黑边、带字幕）单独存一份x/y/w/h和 CRF 配置，跑批的时候按素材特征匹配。这样新来的素材基本不用再手工量一遍，命中率大概八成，剩下两成手工微调。档案存在一个profiles.json里，字段就四个坐标加一个 CRF，简单到不需要文档。

另外一个是抽样质检的频率。一开始我每条都看，累到放弃；后来改成每 50 条抽 1 条，结果漏过了连续 30 条参数错误。现在的折中是每批前 10 条全看，之后每 20 条抽 1 条，同时监控体积比异常的告警。这个频率跑了半年，只漏过一次，那次是因为源素材本身色彩空间异常，属于极端情况。

至于水印去除的效果预期，我的建议是把它当成"让画面变得可接受"，而不是"还原到没有水印"的状态。任何区域修复都会留下痕迹，透明水印覆盖过的纹理是永久丢失的信息，任何算法都只能猜。接受这个前提之后，选参数的标准就从"看不出来"变成了"不突兀"，反而好判断多了——缩略图尺寸下看不出明显异常，就及格了。