很多人第一次把一段老素材丢进超分工具，期待的是"点一下、清晰十倍"，结果拿到手的是一堆塑料感十足的锐化画面，边缘发光、皮肤像蜡像、字幕糊成一团。问题不在工具，而在于绝大多数人根本没搞清视频超分辨率这件事的边界在哪里。这篇内容围绕 Video2X 这个把多种超分算法串成流水线的工具展开，讲清楚它到底做了什么、为什么这么做、哪些参数值得调、哪些坑几乎人人都踩。适合手里有老片源想抢救的普通用户，也适合想把超分接进自己压制流程的进阶玩家。看完你至少能做到两件事：判断一段素材值不值得超分，以及独立跑通一次可控质量的放大任务。

1. 从"放大"到"重建"：超分到底在解决什么问题

视频超分辨率和我们平时说的"把画面拉大"完全是两件事，但这两件事在播放器和剪辑软件里经常被混为一谈。理解这个分水岭，是后面所有参数选择的前提。你如果连工具在做什么都不清楚，调参就变成了盲猜。

1.1 双三次插值的天花板：放大只是在摊薄已有信息

传统放大用的是插值算法，双线性、双三次、Lanczos 都属于这一类。它们的共同逻辑是：新像素的值由周围已有像素按距离加权算出来。这个过程不产生任何新信息，只是把原有的信息摊到更大的画布上。你放大的倍数越高，单个像素承载的信息密度就越低，画面就越是"糊而不锐、锐而不真"。

举个直观的例子。一段 720p 的素材，横向 1280 个像素，你要放到 3840，中间凭空多出 2560 个像素。插值算法能做的只是在这 1280 个已知点之间画平滑曲线，它不知道那里原本应该是一条领带的纹理还是一块皮肤的高光。放大两倍还能看，放大四倍就是明显的软糊加锯齿，边缘出现台阶，细节全部消失。

这就是为什么很多人用播放器的"实时放大"功能之后觉得画面"变大了但变差了"。放大的本质是采样率变换，不涉及任何内容理解，天花板从第一天就锁死了。

1.2 超分模型在"猜"什么：先验知识与纹理生成

超分模型走的是另一条路。它在大规模图像对上训练过，见过大量"低分辨率—高分辨率"的对应关系，因此学会了某种先验：知道边缘在放大后应该保持陡峭，知道皮肤有毛孔和高光过渡，知道动画的线条是硬边且有抗锯齿。推理的时候，它拿这些先验去补那些插值补不出来的高频信息。

这个"补"字很关键，它意味着模型是在生成，不是还原。生成就有可能出错。真实世界里没有的高频细节被凭空造出来，观感上就是"过度锐利""油画感""纹理重复"。人脸尤其明显，模型会把模糊的五官强行修成一张符合训练分布的脸，结果就是每个人都长得有点像，俗称"AI 脸"。

我在实际项目里最常见的误判，是拿超分去救一段码率极低的压缩视频。压缩块和振铃效应本身就是高频噪声，模型会把它们当成细节一起放大，输出比源片更难看。所以第一件事永远是判断源片的问题类型：是分辨率不够，还是编码太狠，还是拍摄时就失焦。三种情况的处理路径完全不同。

1.3 Video2X 在流水线里的位置：它是调度器，不是算法

Video2X 这个名字容易让人误解，以为它是一个自研算法。实际上它的核心价值在于把一条完整流水线串起来了：调用 ffmpeg 解码视频、按帧率抽帧、把每一帧交给后端超分引擎处理、再把处理完的帧按原帧率重新编码成视频、最后把音频流复制回去。

它支持的后端大致分几类：面向二维动画的放大算法、基于生成式网络的通用超分模型、以及基于着色器实时放大的方案。不同后端的速度、显存占用、风格差异非常大。Video2X 做的是统一入口、统一参数、统一进度管理，让你不用为每个算法单独写一套脚本。

理解这一点很重要：调参调的是后端模型和编码参数，Video2X 本身几乎不产生画质。所以当你看到有人说"这个工具画质不行"，八成是他选错了后端，或者编码参数把画质吃掉了。把工具当成调度的胶水，你的排查方向就对了。

2. 动手之前的三笔账：片源、硬件、时间

我见过太多人上手就冲，跑了六个小时发现输出还不如原片，或者跑到 90% 显存爆掉重来。真正省时间的做法是先花十分钟算清楚三笔账，把不可能的任务提前砍掉。

2.1 片源体检：先判断它是"分辨率低"还是"信息少"

分辨率低和信息少是两码事。分辨率低但码率充足，比如早期用高码率录制的 720p 素材，超分收益非常明显；分辨率标称 1080p 但码率被压到 1Mbps 的视频，画面里大量 8x8 的压缩块，超分只会让块更明显。

我的体检流程是三步。第一步，用播放器逐帧看静止画面，找一块平坦区域（天空、墙面），看有没有方块和色带。第二步，抽出三到五帧原始画面，用图像工具放大到 400%，观察边缘是"软"还是"碎"。软是分辨率不足，碎是编码损伤。第三步，看动态场景有没有拖影和交错，如果有，说明它是隔行源或者帧率被降过，需要先做反交错或补帧再超分。

提示：交错源直接超分是最典型的浪费。模型的训练数据基本都是逐行扫描的画面，你把隔行场喂进去，它会老老实实把两个场当成完整画面放大，运动区域会出现严重的梳齿。

如果体检结果是编码损伤为主，正确的顺序是先做轻度降噪或去块滤波，再超分，而不是让模型去猜。这一步做不做，输出质量能差出一个档次。

2.2 显存换算：为什么 1080p 到 4K 会突然爆掉

显存占用和"单帧像素数"强相关，而且不是线性的。模型推理时要保存中间特征图，通道数通常是输入的几十倍。粗略的经验值是：单帧 1080p 输入、2 倍放大，8GB 显存基本够用但余量不大；4 倍放大或者输入到 4K，16GB 也会紧张。

这里有个很多人忽略的点：分块处理。后端通常会把一帧切成若干小块分别推理，再拼回去，用时间换显存。块越小显存越省，但块边缘的接缝风险越高，速度也越慢，因为每块都有独立的预热开销。所以"跑不动就调小块"这句话是对的，但调太小会带来新的问题，后面第 5 节会具体讲。

还有一个更隐蔽的坑：分辨率不是决定显存的唯一因素，色深也有影响。10bit 输入的缓冲区大小是 8bit 的两倍。如果你处理的是 10bit 素材，同样的分辨率下显存需求要往上翻一截，按 8bit 的经验值去估必然失算。

2.3 时间账本：一帧多少毫秒，乘上总帧数才是真相

超分是逐帧处理的，时间成本基本线性。你要做的计算很简单：找到后端在目标分辨率下的单帧耗时，乘以总帧数。

举个具体的例子。一段 3 分钟的 30fps 视频，总帧数 5400 帧。某个通用超分模型在 1080p 输入、2 倍输出下，单帧 400 毫秒，那么纯推理时间是 36 分钟。再加上解码、编码、磁盘读写，实际耗时通常要乘 1.3 到 1.5，也就是 50 分钟左右。

如果目标是从 480p 拉到 1080p，单帧耗时降到 150 毫秒，那么 5400 帧只要 13.5 分钟，实际 20 分钟。这也是为什么我建议先拿 10 秒片段做基准测试，把数字算出来再决定要不要跑整片。工具一般都有基准测试模式，跑一次能直接给出单帧耗时，别省这一步。

表里的数字只是量级参考，不同显卡、不同后端差异可以达到三倍以上，但用它来判断"这个任务今晚能不能跑完"是够用的。

3. 环境搭建与首次跑通：依赖、后端与最小命令

环境这一块是新人最容易卡住的地方，因为报错信息往往和真正的原因隔着两层。我把踩过的顺序整理出来，按这个顺序走能省掉大部分无效搜索。

3.1 后端选型：通用图形接口够用，专用计算接口更快但挑硬件

超分后端跑在 GPU 上有两条常见路径：一条是基于通用图形计算接口（Vulkan 这类），兼容性好，N 卡、A 卡、集显都可能跑得起来；另一条是基于厂商专用计算接口，速度通常更快，但对显卡代际和驱动版本有要求。

选择逻辑很直接：如果你的显卡较新且驱动完整，优先试专用接口；如果跑不起来或者频繁崩，退回到通用接口。别在环境上死磕超过一小时，通用接口的速度损失一般在 20% 到 40%，对于一次性任务完全可接受。真正影响产出的是模型选择和编码参数，不是这 30% 的速度。

另外提醒一句：很多人的机器是核显加独显的双显卡笔记本，程序默认可能跑在核显上，表现为"能跑但慢得离谱"。这种情况需要在系统显示设置里显式指定用高性能显卡运行，或者设置相关的环境变量。我第一次跑的时候就栽在这里，单帧耗时 3 秒，换了显卡之后 200 毫秒。

3.2 解码与编码依赖：ffmpeg 的编译选项比版本号更重要

整条流水线的出入口都是 ffmpeg。它负责把视频拆成帧，也负责把帧重新压成视频。这里有个坑：不同来源的 ffmpeg 构建，开启的编码器不一样。你需要确认它支持你打算用的硬件编码器（比如各类 GPU 加速编码）以及你需要输出的像素格式。

装好之后先验证三件事：能不能正确解码你的源文件、能不能用你想要的编码器、能不能写出带音频的封装格式。命令行验证一遍比在工具里报错再回头查要快得多。

# 查看可用编码器 ffmpeg -hide_banner -encoders | grep -i -E "264|265|av1" # 验证源文件解码是否正常（只解不写） ffmpeg -v error -i input.mp4 -f null - # 查看源文件的像素格式、色彩标记、帧率类型 ffprobe -v error -select_streams v:0 \ -show_entries stream=pix_fmt,color_range,color_space,color_transfer,r_frame_rate,avg_frame_rate \ -of default=nw=1 input.mp4

第三条命令的输出非常关键，它告诉你源片是 8bit 还是 10bit、是有限范围还是全范围、是恒定帧率还是可变帧率。这三项信息直接决定后面编码参数怎么填，很多人跳过这一步，最后拿到偏色、灰蒙蒙或者音画不同步的成品。

注意：如果r_frame_rate和avg_frame_rate的数值差很多，说明源片大概率是可变帧率。可变帧率必须先在抽帧前转换为恒定帧率，否则帧数和时间戳会对不上，输出必然音画不同步。

3.3 最小可用命令与每个参数背后的意图

先用一条最小命令把链路跑通，别一上来就堆参数。结构大致是这样：指定输入输出、指定后端和模型、指定放大倍数，其余走默认。

# 最小可用示例（不同版本参数名可能略有差异，先用 --help 确认） video2x -i input.mp4 -o output.mp4 -p realesrgan -s 2

逐个说清楚每个参数在干什么。-i和-o是输入输出路径，输出扩展名决定了封装格式，建议先用.mkv试跑，它对编码格式的兼容性最宽松。-p选后端处理器，这个决定了用什么算法，是画质和速度的最大变量。-s是放大倍数，2 倍是最稳的起点，4 倍以上要谨慎，后面会讲。

跑通之后再逐步加参数。第一步加输出分辨率控制，把倍数换算成明确的宽高，避免奇数分辨率导致的编码失败；第二步加像素格式，明确指定 8bit 还是 10bit；第三步加编码器和质量参数。每加一步跑 10 秒片段验证一次，出问题能立刻定位到是哪一步引入的。

我见过有人把十几个参数一次性写完然后报错，再去逐个注释排查，来回折腾两小时。增量式调试是唯一高效的方式。

4. 模型选型对照：真人、动画、老片各配什么

这是决定成品观感的一步，比所有参数调优加起来都重要。同一个算法，在二维动画上是神来之笔，在真人实拍上就是灾难。原因在于训练数据的分布完全不同。

4.1 二维动画和真人实拍，先验差得比想象中大

二维动画的画面构成非常简单：大块平涂色、硬边缘线条、少量渐变。这类画面超分的本质是"把线条修直、把色块边缘修干净、把抗锯齿重建出来"。专门针对动画训练的模型在这一点上几乎完美，因为它只需要学会几类有限的图形元素。

真人实拍就复杂得多。皮肤有次表面散射造成的柔和过渡，毛发有半透明的边缘，织物有高频随机纹理。这些内容在低分辨率下已经丢失，模型只能靠先验生成。生成得保守，画面偏软；生成得激进，塑料感就出来了。

所以选型第一条规则：动画片源优先用动画专用算法，真人片源用通用超分模型，绝对不要混用。我试过用动画模型处理真人访谈，人物的脸被修成了二次元风格的平滑面，眼睛周围的皱纹全部消失，看着像蜡像馆的展品。

4.2 降噪档位：它比你想象的更影响最终观感

几乎所有通用超分模型都有一个降噪强度参数，通常分几档。这个参数的作用是在推理前先对输入做抑制，把模型认为是噪声的部分压掉，避免它被当成细节放大。

档位选高了，画面干净但细节一起没，头发丝变成一片色块，织物纹理直接消失，整体像蒙了一层磨皮滤镜。档位选低了，噪点和压缩块被放大，画面"脏"得厉害。中间那一档通常最平衡，但具体选哪档要看源片质量。

我的经验判断法是：截图放大到 200%，看画面里最细的那类结构（比如远处的人脸、衣服的织纹、树叶）。如果这些结构在源片里还能辨认出形状，选低档；如果已经糊成一团，选中档；如果源片本身噪点极重（比如夜间高感光度拍摄），先做一次轻度降噪再走低档，比直接拉高档位效果好得多。

4.3 一张对照表，把选择收敛到三个选项

参数空间看着很大，实际上常用组合就那么几种。我把自己反复验证过的场景整理成表，你可以直接照着选，再微调。

这张表里最值得说的是最后一行的"倍数保守"。老旧录像的噪声极重，放大倍数越高，噪声被放大的幅度越大，即便降噪拉满也压不住。1.5 倍甚至 1.25 倍虽然看着收益小，但成品可用度反而最高。

5. 参数调优：分块、倍数与编码的三角平衡

到了这一步，画面已经从"不能看"变成"能看"，剩下的工作是把"能看"推到"好看"。这三组参数互相牵制，改一个另外两个的体感都会变，所以必须一起考虑。

5.1 分块大小：显存、速度与接缝的三方博弈

分块（tile）的作用是把一帧切成小块分别推理，降低峰值显存。块大小的取值直接决定三件事的平衡。

块越大，模型看到的上下文越多，接缝越少，速度越快（预热开销摊薄），但显存占用越高。块越小，显存省，但每块边缘附近的推理结果缺少远处的信息参考，拼接处可能出现亮度跳变或纹理断裂，表现为画面上出现规律的网格状痕迹。

我的调法是：从默认值开始，逐步往下调，直到能稳定跑完不报显存不足，然后观察输出画面有没有横竖的规则网格。如果有，往上调一档再试。如果显存实在不够，宁可降低放大倍数，也不要无限制地缩小块，因为接缝的观感损失比分辨率不足更刺眼。

还有一个技巧：如果块边缘必须很小，可以开启块之间的重叠区，让拼接时有过渡带。这会增加时间开销，但能显著缓解接缝。不同后端对这个参数的支持程度不一样，用之前先查一下帮助信息。

5.2 放大倍数：2 倍往往比 4 倍好看

这是最反直觉的一条。很多人觉得既然要做，就一次做到 4K。实际测试下来，从 1080p 直接 4 倍到 4K 的成品，观感经常不如 2 倍到 1440p 再交给播放器做最后一档缩放。

原因在于模型的工作负载。4 倍放大的中间特征图规模远大于 2 倍，模型需要在更大的空间尺度上保持一致，出错概率显著上升，表现为局部纹理崩坏、边缘出现奇怪的折线。而 2 倍放大是模型最擅长的区间，训练数据里这个倍率的样本最多，效果最稳。

所以我的建议是分档：480p 以下可以做到 3 到 4 倍，因为原始信息实在太少，额外倍数的收益大于风险；720p 到 1080p 建议 2 倍，目标落在 1440p 到 2160p；已经是 1080p 以上的素材，1.5 倍甚至 1.25 倍就够了，再往上纯属浪费算力。

另外一个实用技巧是"超分后再降采样"。先按 2 倍放大，再用高质量算法缩回 1.5 倍输出，等效于做了一次轻微的抗锯齿和锐化，边缘会比直接 1.5 倍干净。这个技巧在处理带明显锯齿的老片源时特别有效。

5.3 编码参数：画质最容易在这里漏掉

超分做完了，如果编码参数没配好，前面的努力全白费。三个参数最关键：编码器、质量档位、像素格式。

编码器选择上，如果追求质量优先用软件编码器的慢速预设，追求速度用硬件编码器。硬件编码器在同码率下质量确实差一些，但它能把编码时间从几小时压到十几分钟，对大工程来说这个交换通常划算。

质量档位用恒定质量模式，不要用固定码率。固定码率会在简单画面浪费码率、在复杂画面给不够。恒定质量的取值参考：软件编码器 18 到 22 之间比较合适，数值越小质量越高文件越大；硬件编码器要相应往下调 2 到 4，因为同等数值下它的实际质量更低。

像素格式这一项最容易出错。源片是 10bit 就必须输出 10bit，强制降到 8bit 会出现明显的色带，尤其在天空、渐变背景这类区域。源片是 8bit 但你想通过 10bit 中间处理减少累积误差，也是可以的，但最终输出格式要和播放环境匹配，别输出一个大部分设备放不了的格式。

# 编码阶段的参数示例（软件编码，恒定质量，保留 10bit） ffmpeg -framerate 24000/1001 -i frames/%08d.png \ -i original.mp4 \ -map 0:v:0 -map 1:a:0 \ -c:v libx265 -crf 20 -preset slow \ -pix_fmt yuv420p10le \ -color_primaries bt709 -color_trc bt709 -colorspace bt709 \ -c:a copy -shortest output.mkv

这段命令里有几个细节值得说。-framerate 24000/1001用分数形式而不是小数，避免帧率累积误差；-map显式指定视频来自帧序列、音频来自原片，防止 ffmpeg 自动选择时搞错；色彩三要素必须显式标注，否则播放器可能按错误的色彩空间解释，画面会偏色。最后一句-shortest是保险，防止音视频长度不一致时输出被拉长。

注意：抽帧时如果用 PNG 序列，一定要确认输出的文件名是零填充且位数固定（比如 8 位），位数不够在超过 99999 帧时会排序错乱，帧序直接乱掉。用一段长视频踩过这个坑，重跑了三小时。

6. 故障排查链路：黑屏、花屏、音画不同步的定位过程

下面这三个故障占了我在实操中遇到问题的八成以上。我把排查顺序完整写出来，你照着走能复现定位过程，而不是记住一个结论。

6.1 输出全黑或整体偏绿：从像素格式和色彩范围查起

拿到全黑或者整体发绿的输出，第一反应往往是"模型崩了"。实际上九成是像素格式或色彩范围错配。

排查链路是这样走的。第一步，检查中间帧序列是否正常。直接打开抽出来的第一帧和中间某一帧看，如果帧本身是正常的，问题在编码或封装环节；如果帧本身就是黑的，问题在解码或推理环节。这一步能把范围砍掉一半。

第二步，如果帧正常，检查编码时的像素格式。全绿通常是 YUV 格式下的色度平面全零导致的，说明某个环节把色度信息丢了，常见于像素格式转换时参数写错。全黑则可能是色彩范围标错，有限范围（16-235）被当成全范围（0-255）解释，画面整体压暗；反过来则会发灰发白。

第三步，检查色彩标记。源片标了 BT.709，输出没标或者标成了 BT.601，颜色会有明显偏移，肤色尤其明显。修复方式是在编码命令里显式写上三个色彩参数，别指望自动探测。

我遇到过最隐蔽的一次是中间帧用 16bit PNG 保存，编码时转成 8bit 没有做正确的位深映射，结果高光全部截断，画面一片死白。这种问题只能靠逐步缩小环节范围来定位，靠猜是猜不出来的。

6.2 音画不同步与帧序错乱：可变帧率是最大嫌疑

音画不同步的根因几乎总是帧数对不上。可能的原因有三个：源片是可变帧率、抽帧时帧率参数给错、编码时帧率标记错误。

排查第一步，用前面给过的 ffprobe 命令看r_frame_rate和avg_frame_rate。两者差距大就说明是可变帧率，必须先把源转成恒定帧率再走后续流程。转换命令里明确指定目标帧率和帧同步模式，别用默认值。

第二步，数一下总帧数。抽出来的帧数应该等于时长乘以帧率，误差在一两帧以内正常。如果差了几十帧，说明抽帧环节有问题，可能是解码时丢了帧，也可能是帧率参数没写成分数形式导致累积漂移。

第三步，检查编码时的时长对齐。如果帧序列的时长比音频短，输出会被截断；比音频长，末尾会有一段静音。用-shortest能兜底，但根治还是要让帧数和时长严格匹配。

还有一种情况是帧序错乱，表现为画面内容前后跳动。这基本可以确定是文件名排序问题，帧编号位数不一致导致字典序和数值序不一致。解决办法是抽帧时统一用零填充的固定位数，并且在读取时按数值排序。

6.3 显存溢出与进程被系统杀掉：分批处理的实操方案

跑到一半进程消失，日志里没有明显报错，通常是显存溢出被系统终止。这种情况在长视频里特别常见，因为某些场景（比如画面剧烈变化、大量高频细节）的显存峰值远高于平均值。

处理方案分三层。第一层是降低分块大小，把峰值压下来，代价是速度和接缝风险。第二层是降低放大倍数，这是最有效的手段，显存占用和倍数近似平方关系，从 2 倍降到 1.5 倍能省下将近一半。第三层是分段处理，把长视频按时间切成若干段分别跑，最后拼接。

分段处理有几个注意事项。切分点要选在场景切换处，避免在运动中间切断导致拼接处跳帧；每段要重叠几帧，拼接时去掉重叠部分，防止边界缺帧；音频要单独处理，最后统一混流，不要每段各带一份音频再拼。我一般按 10 分钟一段切，既能控制单次运行时长，又不至于产生太多碎片。

如果以上都不行，最后一招是换更轻量的后端。有些着色器类的放大方案几乎不吃显存，速度极快，代价是它不做生成式重建，只是更聪明的插值加锐化。对于"只想要清晰一点、不追求细节重建"的需求，这类方案其实是更理性的选择。

7. 批量流水线与质量抽检：把重复劳动交出去

处理单个文件是一回事，处理一整个素材库是另一回事。批量作业的核心不是"能跑"，而是"跑挂了能续、跑完了能验"。

7.1 目录级批处理与断点重试

批量脚本的骨架很简单：遍历目录、对每个文件调用一次处理命令、记录成功和失败。但有几个细节决定了它能不能真正用起来。

第一，输出文件名的规则要统一，我习惯用"原名 + 倍率 + 后端缩写"的格式，这样一眼能看出这个文件是怎么来的，过几个月回头看也不会搞混。第二，跳过已存在的输出，实现断点续跑，脚本中断后重新执行不会重复处理。第三，失败重试要有上限，最多两次，避免某个坏文件把整个队列卡死。第四，日志要带时间戳和耗时，方便事后分析哪个环节慢。

#!/usr/bin/env bash set -u IN_DIR="./input" OUT_DIR="./output" LOG="./batch_$(date +%Y%m%d_%H%M%S).log" mkdir -p "$OUT_DIR" for f in "$IN_DIR"/*.mp4 "$IN_DIR"/*.mkv; do [ -e "$f" ] || continue base="$(basename "${f%.*}")" out="$OUT_DIR/${base}_x2.mp4" if [ -s "$out" ]; then echo "[SKIP] $out 已存在" | tee -a "$LOG" continue fi start=$(date +%s) ok=0 for try in 1 2; do if video2x -i "$f" -o "$out" -p realesrgan -s 2 >>"$LOG" 2>&1; then ok=1; break fi echo "[RETRY $try] $f" | tee -a "$LOG" done end=$(date +%s) if [ "$ok" -eq 1 ]; then echo "[OK] $f -> $out 用时 $((end-start))s" | tee -a "$LOG" else echo "[FAIL] $f" | tee -a "$LOG" rm -f "$out" fi done

这段脚本里最值得学的是失败时删除残留输出。很多工具在报错前已经写了一个不完整的文件，如果不删，下次执行会因为"文件已存在"而被跳过，你就永远拿不到这个文件的正确版本，而且很难发现。

7.2 中间格式与磁盘空间管理

超分流水线会产生大量中间文件。一帧 1080p 的 PNG 大约 2 到 4MB，一段 3 分钟 30fps 的视频有 5400 帧，中间文件就能吃掉 15GB 以上。4K 素材更是成倍增长。

三个应对办法。用无损压缩率更高的格式保存中间帧，PNG 比 BMP 省一半以上空间。设置处理完成后自动清理，但保留最近一次以便复盘。如果磁盘实在紧张，用管道模式让抽帧和编码不落地，缺点是中断后无法续跑，适合短片段。

我个人的习惯是准备一块专门的工作盘，容量至少是源素材总大小的 20 倍，并且单独分区，避免中间文件把系统盘撑爆。这个教训是用一次系统盘写满、桌面都打不开换来的。

7.3 抽检方法：客观指标加主观对比

批量跑完之后不要直接交付，一定要抽检。抽检分两层：客观指标和主观对比。

客观指标可以用 PSNR 和 SSIM 与源片比对，但它们只能反映"结构相似度"，反映不了观感。超分产生的塑料感在指标上往往得分很高，因为结构确实更清晰了。所以指标只能用来筛出明显异常的文件，比如编码出错的会导致指标断崖式下跌。

主观对比才是关键。我的做法是每个文件抽三个时间点：一个静止画面、一个快速运动画面、一个暗部画面。三张截图并排对比源片和成品，重点看四件事：边缘有没有光晕、平坦区域有没有色带、暗部噪点是被压掉了还是被放大了、人物面部有没有失真。四个都过关才算合格。

快速运动画面特别重要，因为很多模型在运动模糊的帧上会生成奇怪的纹理，静止画面看着挺好，一动起来就露馅。这一点在动画的快速镜头切换时尤其明显。

8. 一些文档里不会写的经验

写到这里，主要的技术路径已经讲完了。剩下几条是我在实际项目里反复验证过的判断，散着说，但都挺值钱。

第一，字幕和时间轴要单独处理。超分改变的是画面分辨率，字幕如果是硬字幕会被一起放大，边缘会变糊甚至产生重影。软字幕不受影响，但要确认封装时字幕流被正确复制。如果字幕是内嵌的图形字幕，考虑先分离再重新叠加高质量版本。

第二，超分不是万能的，有些素材应该放弃。分辨率极低（比如 240p 以下）且噪声极重的素材，超分之后大概率是"清晰的一团糊"，投入产出比极低。这种情况下更好的方案是接受它的粗糙感，改用降噪加轻微锐化，保留原始质感，反而更耐看。

第三，保存好中间产物和参数记录。同一段素材用不同参数跑出来的结果差异很大，过一段时间想复现某个效果，如果没有记录参数和版本号，基本等于重来。我习惯在每个输出目录里放一个纯文本的参数说明，写清楚用的什么后端、什么倍率、什么编码参数、什么日期。

第四，注意版权和素材来源的合规使用，个人收藏的整理和公开传播是两回事，这一点不用多说。

第五，长期跑大批量任务时留意硬件状态。超分是持续满载的负载，长时间运行对散热和供电都是考验。我给工作机加了一个简单的温度监控，超过阈值就暂停队列，这个习惯让机器的故障率明显下降。

回到最开始那个问题：超分工具能不能"点一下、清晰十倍"。答案是不能，但它能在你搞清楚素材问题、选对算法、配对编码参数之后，把一段原本没法看的素材救回到可以正常观看的水平。这个"救回来"的过程需要判断，而判断来自对这些细节的理解。我自己现在的习惯是，每拿到一批新素材，先花十五分钟做体检和十秒片段测试，把参数定下来，再开跑。这十五分钟，往往比后面几小时的算力更值钱。