早几年我从地下室翻出来一堆VHS录像带转出来的老动画兴冲冲往客厅的大电视上一放结果惨不忍睹满屏锯齿、色块崩坏、线条发虚有的画面连脸都看不清。当时我就琢磨能不能自己写一个工具把这些老片子修到孩子愿意盯着看的清晰度。后来折腾了大半年绕了不少弯路总算做出了一版能用的东西C# WinForms做界面、APISR做超分模型、Vulkan负责GPU侧的图像处理。这篇文章就是把这套方案整个摊开讲一遍从选型逻辑到代码骨架到踩坑记录给想做同类工具的朋友一个可以照抄的参考。先说清楚这工具能干什么。它接收一段分辨率很低的老动画视频输出一段分辨率翻倍甚至翻四倍的新视频同时尽量去压缩噪声、修线条、稳定颜色。适合的对象很明确手里有一堆旧动画DVD或者录像带转录文件、想在家用PC上批量修复的人以及想研究如何把AI模型集成进C#桌面软件的开发者。不需要你懂太多深度学习照着做就行。1. 老动画在4K时代为什么反而更难看了1.1 清晰度只是最表面的问题很多人以为老动画画质差就是分辨率低放大一下、补点像素就完事。但你把一段480p的动画丢给普通的视频放大软件出来的往往不是变清楚而是更脏边缘出现一圈一圈的振铃噪点变成油画一样的涂抹感字幕和口型全是糊的。原因在于老动画的画质问题从来不只是像素格子太大这一个因素。以常见的VHS转录文件和早期网络发布版为例它们普遍经过了几层折腾原始胶片/母带扫描、模拟信号转数字、再经过低码率压缩。这三步各自引入不同种类的损伤。扫描阶段带来胶片颗粒和扫描噪声模拟转数字阶段带来色度串扰和亮度抖动压缩阶段则带来色块、振铃和线条周边的小碎点。这些损伤混杂在一起单纯靠拉高分辨率根本解决不了反而会被放大。我测试过一批老动画片段发现最影响观感的其实是两点线条断裂和色块漂移。动画片主要靠黑白线稿勾勒轮廓一旦压缩或者转录把线搞断了视觉上就会觉得脏模糊。而大面积平涂的色块一旦出现边缘色斑颜色看起来就很不干净。这种问题你用普通的去噪滤镜处理又会把本身清晰的线条给磨平非常两难。1.2 为什么动画片需要专门的超分模型这就引出了关键问题做老动画修复选什么模型。通用超分模型比如Natural-SR、Real-ESRGAN这一类它们的训练数据以真实照片为主擅长修复纹理细节比如草地、皮肤、砖墙。但动画画面大部分是平涂色块和相对平整的线条照片类模型在里面经常过度发挥——把本应干净的区域补出纹理、把线条描出不必要的笔画感出来的画面反而像PPT加了个浮雕效果。动画专用模型就是冲着这个问题来的。APISRAnime Production-oriented Image Super-Resolution这一类模型训练时专门把动漫制作特点考虑进去了线稿的连续性、色块的平整性、动漫压缩噪声的模式。它的目标不是让画面看起来更像照片而是让画面变成一张干净的高分辨率动画原稿。我用同一个片段对比过多次动画专用模型在主观观感上完胜通用模型尤其是在线条笔锋和纯色背景这两个地方。另外还要提一个反常识的点超分模型不是倍数越高越好。4倍超分是这类模型的默认能力但老动画源本身信息量有限强行上4倍常常得不偿失细节补不出来不说还容易产生塑料感。我实际测试下来720p源素材上2倍观感提升最大480p源素材上2倍是安全和质感之间的平衡点除非源非常干净否则尽量别动不动就4倍。等下讲到流水线的时候我会把这个做成界面上的一个可选项。2. 技术选型的账怎么算为什么是C# APISR Vulkan2.1 为什么不在Python里一条路走到黑你要是去看APISR的原始项目就会发现官方实现是Python写的跑起来也很顺畅。那为什么我还要套一层C# WinForms答案很简单交付对象不一定是程序员。我的实际使用场景里要处理的老动画存在一台配置普通的Windows机器上使用的家人朋友不可能去命令行里敲python test.py --input xxx.mkv更别说装Anaconda、配CUDA、创建虚拟环境这一整套流程了。我需要的是一个能双击打开、有任务进度条、退出时还能弹出已完成提示的普通桌面软件。C# WinForms在这方面几乎是最省事的选择单机发布方便、不需要额外运行时、对Windows API和文件系统操作顺手图形界面代码写一天就能出活。当然这中间也有替代方案比如用Electron包Python也做过但安装体积和内存占用都大得离谱。WPF上手也还行但我个人觉得WinForms做这种工具型软件够用了代码直观、控件齐全、异步UI更新也没有那么多弯弯绕。工具型的软件界面简单直接才是正路。2.2 Vulkan在这种场景里到底负责哪一段这里得说清楚Vulkan在整套工具里的定位因为很多人一看到Vulkan就以为是用它做AI推理。实际上把APISR这种深层的卷积神经网络全部手工搬进Vulkan compute shader并不现实工作量巨大而且调试成本高。我用Vulkan的场景是视频处理管线里那些脏活累活第一是颜色空间转换。视频解码器出来的原始帧通常是NV12或者YUV格式而APISR模型默认接受RGB输入。这个转换如果用CPU来做每一帧720p的画面也就是几毫秒感觉不出来但一个半小时的片子上万帧累计下来就很可观了。放到Vulkan的compute shader里一次性并行处理所有像素几乎不占额外CPU时间还能顺便在显存里完成数据搬运。第二是数据布局转换。ONNX Runtime要求输入张量的排布是NCHW或者NHWC而解码器给出的帧是高度方向宽度方向排列的紧密像素数据。如果直接在CPU上做维度重排会带来大量非连续内存访问慢且伤缓存。用Vulkan把帧数据读进显存、通过shader重排成模型需要的布局、再直接送给推理引擎性能能拉出一截。第三是显存侧的内存复用。Vulkan的buffer和image分配好之后可以长期复用结合GPU缓冲区池来管理整个视频处理过程中不会频繁申请释放显存也就不会出现跑到一半显存碎片化报错的情况。2.3 整体架构一览说清楚各部件职责之后整条流水线就非常清晰了输入层读取视频文件拆成一帧帧数据用FFmpeg系列库做解码我这里通过OpenCvSharp的VideoCapture封了一层。预处理层Vulkan compute shader 把YUV色彩空间帧转成RGB再做归一化和NCHW数据重排。推理层ONNX Runtime加载APISR导出的ONNX模型使用GPU执行提供程序我实际用的是DirectML方案Vulkan负责前后处理。后处理层Vulkan compute shader 做RGB转合适编码格式的组合、可选轻量锐化、范围裁切。输出层把处理后帧按序喂回FFmpeg编码器输出H.264或H.265文件。中间帧与帧之间通过阻塞队列衔接解码、推理、编码各跑各的线程互不等待太久。这样设计之后哪怕单帧推理只要几十毫秒整个流水线也能像生产车间一样连续转动不会出现解码等推理、推理等编码的相互拖累。3. 搭建一个可用的超分流水线分几步3.1 环境准备和项目骨架开发环境这一块我用的是Windows 10/11 64位Visual Studio 2022项目目标框架选.NET 8。WinForms本身跨不了平台但我也没这个需求老实待在Windows生态里。几个关键依赖OpenCvSharp4 和 OpenCvSharp4.runtime.win负责读视频、取帧、写帧。Microsoft.ML.OnnxRuntime.Gpu加载ONNX模型并执行推理Windows上默认走DirectML后端。Vulkan SDK1.3版本以上提供C#侧调用Vulkan的底层函数通过VulkanNative库做P/Invoke。FFmpeg通过FFmpeg.AutoGen库负责最终的编码封装。项目结构上我分成四个工程UIWinForms界面、Pipeline流水线调度、GPUVulkan封装、Models模型加载和推理封装。分层的好处是以后想把它改成WPF或者控制台批量工具只需要替换UI层。你先用WinForms模板建一个空项目然后NuGet把上面几个包装进去。Vulkan SDK装完后记得在系统环境变量里确认VULKAN_SDK是否被正确指向不然跑起来会提示vkEnumerateInstanceExtensionProperties找不到入口。3.2 拆帧与帧队列设计视频处理的第一步是把视频按时间顺序变成可处理的帧序列。核心逻辑用OpenCvSharp就很简单using var capture new VideoCapture(inputPath); if (!capture.IsOpened()) { throw new InvalidOperationException(无法打开视频文件); } var totalFrames (int)capture.FrameCount; var fps capture.Fps; var width (int)capture.FrameWidth; var height (int)capture.FrameHeight; var frameQueue new BoundedBufferFrameData(capacity: 16);这里我把FrameData设计成一个可复用的容器里面放一个Mat和一个帧编号而不是让每次读帧都new一块内存public sealed class FrameData { public Mat Data { get; set; } public long Index { get; set; } }队列用有界阻塞队列容量设成16左右。太小的话解码线程会频繁阻塞、浪费CPU太大则会让显存里堆太多等待处理的帧容易爆显存。读者可以按自己的GPU显存量调整6GB显存以下建议调成8甚至更小。3.3 将APISR模型从PyTorch导出为ONNXAPISR本身是PyTorch模型C#这边不能用torch直接推理所以第一步是把模型导出成ONNX格式。这里简要说明通用流程具体入口以你下到的模型仓库说明为准import torch # model 为加载好的 APISR 模型比如 RRDB 4x 版本 model.eval() dummy torch.randn(1, 3, 256, 256) torch.onnx.export( model, dummy, apisr_4x.onnx, opset_version17, input_names[input], output_names[output], dynamic_axes{ input: {0: batch, 2: height, 3: width}, output: {0: batch, 2: height, 3: width}, } )我建议导出时尽量把动态维度开启。因为输入的每一帧尺寸可能有细微差异有些视频源剪辑过、分辨率会跳变写死shape会导致中途报错。动态维度意味着ONNX Runtime允许每次传入不同的宽高代价是某些GPU执行提供程序性能略降但换来的是稳定性。如果工程上确定所有帧尺寸一致也可以写死shape换取一点速度但要做好视频中途尺寸变化时的熔断处理。3.4 C#端加载模型并跑推理ONNX Runtime在C#里的使用相当直白var options new SessionOptions { EnableMemoryPattern true, ExecutionMode ExecutionMode.ORT_SEQUENTIAL }; options.AppendExecutionProvider_DML(0); // 也可用 CUDA 或 CPU 备选 using var session new InferenceSession(apisr_4x.onnx, options); var width 960; var height 540; var input new DenseTensorfloat(new[] { 1, 3, height, width }); var inputs new ListNamedOnnxValue { NamedOnnxValue.CreateFromTensor(input, input) }; using var results session.Run(inputs); var output results.First(r r.Name output).AsTensorfloat();这里有个小细节输入张量的形状是[1, 3, height, width]也就是NCHW排布而视频帧的原始数据是[height, width, 3]的NHWC形式。如果直接在C#里用嵌套循环转换每一帧都会产生大量的array[channel, h, w] array[h, w, channel]式跳跃访问慢到让你怀疑人生。这也是我在前一章强调要用Vulkan做布局重排的原因下面就来写这一部分。3.5 用Vulkan接管预处理和数据搬运Vulkan这层我封装了一个FramePreprocessor类核心逻辑是把OpenCvSharp拿到的Mat绑定到Vulkan的buffer上启动compute shader做YUV转RGB、归一化再把结果写入模型输入所需的NCHW显存buffer中。shader核心片段大致是这个意思#version 460 layout(local_size_x 8, local_size_y 8, local_size_z 1) in; layout(set 0, binding 0) buffer InputFrame { vec4 pixels[]; }; layout(set 0, binding 1) buffer OutputTensor { vec4 data[]; }; layout(push_constant) uniform Params { int frameWidth; int frameHeight; } params; void main() { ivec2 pos ivec2(gl_GlobalInvocationID.xy); if (pos.x params.frameWidth || pos.y params.frameHeight) return; int inIdx pos.y * params.frameWidth pos.x; vec4 bgra pixels[inIdx]; // BGRA 转 RGB再近似标准化到 [-1, 1] vec3 rgb; rgb.r bgra.z * 2.0 - 1.0; rgb.g bgra.y * 2.0 - 1.0; rgb.b bgra.x * 2.0 - 1.0; // 输出数据按 NCHW 排布 int y int(gl_GlobalInvocationID.y); int x int(gl_GlobalInvocationID.x); data[(0 * params.frameHeight y) * params.frameWidth x] vec4(rgb.r, 0.0, 0.0, 1.0); data[(1 * params.frameHeight y) * params.frameWidth x] vec4(rgb.g, 0.0, 0.0, 1.0); data[(2 * params.frameHeight y) * params.frameWidth x] vec4(rgb.b, 0.0, 0.0, 1.0); }请注意实际工程里输入数据不是BGR就是NV12你读取的视频格式不同shader里的通道映射也不同。最稳妥的做法是先跑一帧输出看看颜色通道是否错乱再决定要不要交换R和B的顺序。第一步就用错了通道后面所有帧全废这种低级失误一定得在一开始就排掉。3.6 推理后的后处理与重新编码推理出来的张量是[1, 3, newHeight, newWidth]的float数组需要把它还原成可编码的图像。这一步我也交回给Vulkan一个shader把NCHW拆回RGB像素做一次范围裁切避免某些帧出现诡异的负值或超出0-255的溢出点再写进Vulkan的image最后回读到Mat。之后就是编码。如果你希望保留老动画的味道、也不想让文件过大我建议用H.264配合中低CRF值。命令行类似ffmpeg -f rawvideo -pixel_format bgr24 -s 1920x1080 -r 23.976 -i pipe:0 -c:v libx264 -preset slow -crf 17 out.mp4转换成C#代码就是拉一个FFmpeg子进程把每帧的Mat数据写进它的标准输入流。别忘了同时拷贝原始音轨和字幕否则处理完发现没声音又要重新合成一遍。4. 性能瓶颈与调优记录4.1 先定位瓶颈再动手别瞎优化我第一版跑起来之后的画面非常感人一集24分钟的动画处理到第3分钟发现显存占用到了8GB进度条几乎不动。当时第一反应是推理太慢后来一算账发现根本不是一回事。我们先把账捋清楚一部720p动画假定有35000帧。如果APISR的实时版模型在消费级GPU上单帧推理耗时50毫秒那么推理环节大约需要 35000 × 0.05 秒 1750 秒也就是半小时左右。RRDB高精度版如果单帧需要500毫秒那就意味着接近5小时。慢的主要是模型本身预处理和拷贝在实测里通常只占每次帧处理的10%上下。所以调优的顺序应该是先选对模型档位再优化数据搬运最后才谈线程调度。我最终默认采用APISR实时版模型把高精度版留给那些确实需要精修的单张关键帧。判断依据只有一条实时版在1.5米外看一集动画观感和高精度版差距并不明显但处理速度快了十倍以上这个性价比很难拒绝。4.2 让流水线真正跑起来异步与批量WinForms界面是UI线程负责的而视频处理刚才说了是解码、推理、编码三个线程。如果直接在按钮点击事件里同步跑界面就会卡死拖动窗口像拖一块砖头。解决思路是老一套要用async和await把重活扔到后台线程界面只负责接收进度刷新。更重要的优化是批量推理。ONNX Runtime支持把多帧拼成一个batch一次性推理也就是输入shape从[1, 3, h, w]变成[4, 3, h, w]。批量推理利用率更高而且可以摊薄多项固定开销。但batch不是越大越好我试过8帧一拼和2帧一拼在6GB显存的中端显卡上4帧往往已经是最优值了。看GPU显存容量超过推荐值就会爆显存。4.3 内存池避免GC和显存抖动的关键视频处理最怕两种内存问题一是托管堆频繁分配导致GC卡顿二是显存反复申请释放导致碎片化。两边的解法都是池化。C#侧我维护了一个FrameDataPool里面的对象用完不扔放回池中复用。关键点是视频帧Mat的内部像素 buffer 是 native memory被GC回收的时机不可控如果不池化会出现处理到一半内存占用缓慢上升的偷内存现象。GPU侧Vulkan的buffer和image也尽量在最初就申请好全部需要的大小之后用同一个块反复写。这样整个处理过程GPU内存分配次数接近于零几乎不会遇到显存耗尽或者分配失败的幽灵报错。public sealed class FrameDataPool { private readonly ConcurrentBagFrameData _pool new(); public FrameData Rent() { if (_pool.TryTake(out var item)) { return item; } return new FrameData { Data new Mat() }; } public void Return(FrameData item) { _pool.Add(item); } }4.4 进度、取消和崩溃恢复处理一个小时以上的视频是常态中途用户可能想暂停或者取消电脑也可能断电。这几个场景都得早做打算。我用CancellationTokenSource传递取消信号流水线里每个环节都检查IsCancellationRequested。取消时不要立刻杀线程而是让处理完当前帧后自然退出否则可能出现编码器写入不完整的数据。进度上解码和编码各自知道自己的帧数中间队列也会积压帧所以进度条不能只看处理完多少帧最好综合考虑已读取、已推理、已编码三者的位置关系。崩溃恢复我用了最朴素的方案每1000帧记录一个处理位置重启后用户可以手动选择从中断位置开始。做不了很精细因为老动画的版本复杂精确续跑需要帧级对齐验证性价比不高。5. 老动画修复最容易踩的五个坑5.1 动态尺寸导致推理中途报错有一类老动画片源本身是多段拼接出来的前面24分钟720p后面加了个ED又是608p甚至有的DVD提取视频是真交错扫描导致的半高画面。如果你按第一帧的尺寸写成固定shape运行到中间就会突然报shape mismatch。我处理这个问题的方式是在解码线程里维护当前帧的尺寸记录一旦发现宽高变了就暂停流水线、重新创建推理Session需要的输入输出绑定再继续处理。必要时还可以给用户弹提示让他知道源视频本身不规则。遇到这种情况宁可拆成多个片段单独处理也不要指望一个Session吃到底。5.2 噪点和胶片颗粒被超分模型当成细节放大这是所有把AI超分用在老片子上的人都会踩的坑。老动画的噪点不是画面细节超分模型却会认真地把它们一个个修复成很锐利的小点。结果就是人物脸上一片麻点干净的天空像砂纸。我的对策是分级处理。第一步做一次轻度的时域降噪让相邻帧的随机噪点互相抵消第二步再做超分。降噪强度要小因为动画片本身细节少降噪太狠线条会软掉。两种处理配合起来效果好了不止一个档次。5.3 单帧超分导致线条闪烁另一个只属于视频超分的坑是闪烁。模型对每一帧单独处理它不知道上一帧线条经过什么变换。于是同一根线在第10帧被增强得粗糙一点第11帧又平滑一点播放起来就是线条在不停地抖比原始视频还累眼。便宜而有效的抑制手段对连续三帧的输出做加权平均中间帧权重高一些。再狠一点的方法是把输入切小窗做重叠推理然后对窗口边界做羽化融合。如果APISR的模型本身带时域模块直接喂多帧输入是更优解但工程复杂度会显著提高——我目前还是用前者后者的Onnx模型导出和Session配置都够折腾一阵。5.4 音频和字幕没处理白干一场处理完视频满心欢喜结果一播放发现音轨没了外挂字幕也没了。这种错误最让人崩溃因为它和技术水平没关系纯粹是不细心。我最后的解决方式是把工具逻辑改成只替换视频流用FFmpeg把原视频分离成原始音轨和字幕文件超分处理完视频流之后再把原来的音轨、字幕和增强后的视频封装在一起。封装这一步顺带解决了一个隐藏问题老视频帧率经常是23.976fps、29.97fps这些奇怪值写死25fps会导致声音画面对不上。5.5 软件在不同电脑上启动崩溃开发完工具后我给家里两台电脑各装了一份一台跑得好好的另一台一启动就报DLL not found查了半天是缺Visual C运行库。ONNX Runtime和OpenCvSharp的native库都很依赖这套运行库但目标机器不一定装了。后来我采用两条措施第一发布时选择win-x64自包含模式把.NET运行时打进程序目录第二把VC运行库也装一份到程序目录边上程序启动时提前加载。这一套搞完基本所有Windows机器都能双击就跑了。如果还要更省事可以直接做一个简单的安装包把必要条件全塞进安装向导里。6. 效果验证与后续优化方向工具基本成型后我拿一段90年代经典的剧场版动画做了测试。源片段是DVD转录的720×480分辨率压了很多次码线段周围全是细小毛刺颜色也有点灰蒙蒙。经过轻度时域降噪 → APISR 2倍超分 → 轻锐化 → 音轨字幕回封整条流程后输出1440×960。客观上说画质并没有变成那种惊艳的4K重制毕竟源数据本身信息有限神化工具没意义。但主观观感提升明显线条干净、颜色平实、毛刺消失画面不再有那种被水泡过的模糊感。我拿给孩子看的时候她完全没意识到这是一部快三十年前的片子。这件事让我意识到修复老动画的核心意义不在技术参数而在于让那些差点被时代淘汰的作品重新具备被新一代看到的可能性。后面我还想在这个方向上加两个能力其一是批量目录处理把整个文件夹文件夹的视频排队自动修其二是简单的颜色管理针对赛璐璐时代独特的低饱和色彩做轻度校正让画面不浓艳却也不那么灰。前者工程工作量不大后者涉及颜色科学要小心别把原本的风格修没了。如果正在读这篇文章的你也有一堆吃灰的老动画资源不妨试试搭一条最简单的流水线先跑三五分钟片段看看超分后的人物线条和背景色块是否顺眼。工具和技术都不是目的把一部好看的老故事重新放到今天的屏幕上这件事本身就挺值得。
