1. 这个项目到底在解决什么问题

老动画的片源大多停留在480p甚至360p的时代，那个年代做动画用的是胶片扫描加标清数字后期，分辨率放到今天的显示器上，满屏都是糊的。但问题在于，这些片子的线条是手绘的，色块是平涂的，跟实拍视频的纹理完全不是一回事。你拿市面上通用的视频超分模型去跑，结果往往是线条边缘出现振铃、色块内部被“脑补”出根本不存在的纹理，甚至人物脸部被重绘成另一个人。

这个项目的出发点很朴素：把那些陪伴过一代人的老动画，用一套可控的超分流程处理成至少1080p的版本，让新一代孩子在正常尺寸的屏幕上看得下去。技术栈选的是C# WinForms做界面、APISR做超分推理、Vulkan做GPU加速后端。为什么是这三个东西凑一起，而不是直接上Python加PyTorch？因为目标用户不是研究员，是普通家长或者小工作室的剪辑人员，他们需要的是一个双击就能跑、拖进视频就能出结果的桌面工具，而不是配环境配到崩溃的命令行脚本。

我先把结论摆在这里：这套组合的核心价值在于把重推理任务从Python生态里剥离出来，用原生桌面应用的方式封装，同时通过Vulkan绕开CUDA的硬件绑定。这意味着它能在更广泛的显卡上跑起来，包括一些没有CUDA支持的集成显卡和A卡。代价是你要自己处理模型转换、内存管理和多线程调度，工作量比调个Python脚本大得多。

适合读这篇内容的人有三类：一是想给自己收藏的老片子做修复的个人用户，二是想了解如何把AI推理嵌入桌面应用的开发者，三是手头有批量视频处理需求、想搭一套半自动化流水线的小团队。如果你只是想快速跑个超分看看效果，那直接用现成的Python脚本更省事；但如果你想做一个能分发给别人用的工具，或者想深入理解推理引擎和图形API之间的配合，那这套方案值得细看。

2. 整体架构设计与技术选型逻辑

2.1 为什么是WinForms而不是WPF或Avalonia

WinForms在2024年听起来像个老古董，但它有一个WPF和Avalonia都比不了的优势：跟原生Windows控件的互操作成本极低。这个项目需要嵌入视频预览窗口、进度条、文件拖拽区域，还要在推理过程中实时刷新帧预览。WinForms的Panel控件可以直接承载Vulkan的渲染表面，而WPF要搞D3DImage互操作，Avalonia的GPU互操作层在Windows上还不够成熟。

另一个现实原因是部署体积。WinForms应用发布成单文件exe，加上Vulkan运行时和模型文件，总体积可以控制在200MB以内。WPF因为要带.NET桌面运行时的一堆依赖，体积会翻倍。对于要分发给非技术用户的小工具来说，体积和启动速度是硬指标。

当然WinForms的坑也很明显：高DPI缩放支持稀烂，界面在4K屏上要么模糊要么错位。我的处理方式是在app.manifest里声明PerMonitorV2的DPI感知级别，然后手动处理所有控件的缩放逻辑。具体做法是重写OnResize事件，根据当前DPI比例重新计算控件位置和字体大小，而不是依赖WinForms自带的AutoScaleMode。这个后面在实操部分会展开。

2.2 APISR为什么适合动画超分

APISR这个模型的核心设计思路是针对动画图像的线条和色块特性做优化。普通超分模型在训练时用的是自然图像数据集，里面全是纹理、噪点、渐变，模型学会的是“猜纹理”。但动画图像的特点是：线条锐利、色块均匀、边缘清晰。用自然图像模型去跑，模型会忍不住在色块里加纹理，在线条边缘加过渡，结果就是画面变“脏”。

APISR的训练数据里包含了大量动画截图和线稿，损失函数里专门加了边缘保持项。实测下来，它在处理老动画的锯齿线条时，能保持边缘的锐利度，同时把色块内部的噪点压下去。但要注意，APISR不是万能的，它对实拍视频的效果一般，对动画的特定风格（比如水彩背景、赛璐璐上色）效果最好。

模型文件方面，APISR通常提供ONNX格式的导出。ONNX的好处是跨平台、跨推理引擎，你可以用ONNX Runtime、TensorRT、OpenVINO等各种后端去跑。这个项目选的是ONNX Runtime加Vulkan执行提供程序，因为ONNX Runtime的Vulkan EP在Windows上对A卡和N卡都支持，而且部署简单，不需要额外装CUDA工具包。

2.3 Vulkan在这个项目里扮演什么角色

Vulkan在这里不是用来做渲染的，虽然它确实也负责预览窗口的绘制。它的核心作用是作为ONNX Runtime的计算后端。ONNX Runtime支持多种执行提供程序：CPU、CUDA、DirectML、Vulkan。CPU太慢，CUDA绑定N卡，DirectML在Windows上对老显卡支持不好。Vulkan的好处是跨厂商、跨代际，只要显卡支持Vulkan 1.1以上，就能跑。

但Vulkan EP的坑在于：它的算子覆盖率不如CUDA EP完整。APISR模型里如果用了某些特殊算子（比如某些版本的GridSample），Vulkan EP可能不支持，会回退到CPU执行，速度直接掉一个数量级。所以在模型转换阶段，要用ONNX Runtime的工具检查算子支持情况，必要时对模型做算子替换或图优化。

另一个坑是显存管理。Vulkan EP不像CUDA那样有成熟的显存池机制，处理4K视频时如果帧缓存没及时释放，很容易爆显存。我的做法是把视频按场景切分成小段，每段单独跑推理，跑完一段释放一次显存。虽然增加了模型加载次数，但稳定性大幅提升。

2.4 整体数据流设计

整个工具的数据流是这样的：用户拖入视频文件 → FFmpeg解码成帧序列 → 帧序列送入ONNX Runtime做超分 → 超分后的帧写回临时目录 → FFmpeg重新编码成视频 → 输出到目标路径。中间穿插着进度回调、预览刷新、异常处理。

这里的关键设计决策是用FFmpeg做解码和编码，而不是用C#自带的MediaFoundation。原因是FFmpeg的格式支持更全，而且可以通过命令行参数精确控制编码质量。MediaFoundation虽然集成度高，但对老动画常见的编码格式（比如某些MPEG-2变种）支持不好，而且编码参数调节不够灵活。

FFmpeg的调用方式是用Process类启动子进程，通过标准输入输出传递帧数据。但这里有个性能陷阱：如果每帧都启动一次FFmpeg进程，开销巨大。正确做法是启动一个长驻的FFmpeg进程，通过管道持续传输帧数据。具体实现后面会讲。

3. 核心细节解析与实操要点

3.1 模型转换与算子兼容性检查

APISR的原始权重通常是PyTorch格式的.pth文件。要转成ONNX，需要用torch.onnx.export函数。转换时的关键参数是opset_version，建议设为17或更高，因为低版本opset对某些插值算子的支持不完整。

转换命令大概长这样：

import torch import torch.onnx model = load_apisr_model("apisr_x4.pth") model.eval() dummy_input = torch.randn(1, 3, 256, 256) torch.onnx.export( model, dummy_input, "apisr_x4.onnx", opset_version=17, input_names=["input"], output_names=["output"], dynamic_axes={"input": {2: "height", 3: "width"}, "output": {2: "height", 3: "width"}} )

注意dynamic_axes参数，它允许模型处理任意尺寸的输入。如果不设这个，模型只能处理固定尺寸，处理视频时就得把每帧裁剪成固定大小，很麻烦。

转完之后，用ONNX Runtime的onnxruntime.tools里的check_model函数检查模型有效性。然后重点来了：用ONNX Runtime的Vulkan EP加载模型，看哪些算子会回退到CPU。代码大概是这样：

var sessionOptions = new SessionOptions(); sessionOptions.AppendExecutionProvider_Vulkan(); var session = new InferenceSession("apisr_x4.onnx", sessionOptions); // 打印session的profiling信息，看算子分配情况

如果发现大量算子回退到CPU，有两个解决方案：一是用ONNX Runtime的图优化工具把不支持的算子替换成支持的等价算子；二是把模型拆成两部分，不支持的算子单独用CPU跑，支持的用Vulkan跑。第二种方案实现复杂，但效果更好。

注意：Vulkan EP对Resize算子的支持在不同版本间有差异。如果模型里用了Resize且模式是cubic，某些ONNX Runtime版本会回退到CPU。解决办法是把Resize改成linear模式，或者在模型转换时把Resize替换成Upsample加卷积的组合。

3.2 视频解码与帧管道的搭建

FFmpeg解码视频的标准命令是：

ffmpeg -i input.mp4 -f rawvideo -pix_fmt rgb24 -

这个命令把视频解码成RGB24格式的原始帧，通过标准输出吐出来。C#这边用ProcessStartInfo启动FFmpeg，设置RedirectStandardOutput = true，然后从StandardOutput.BaseStream读取数据。

关键点在于帧大小的计算。假设视频是640x480，RGB24格式每像素3字节，那么每帧的字节数就是640 * 480 * 3 = 921600字节。你需要精确地按这个大小读取，不能多读也不能少读，否则帧就错位了。

int frameSize = width * height * 3; byte[] buffer = new byte[frameSize]; int bytesRead = 0; while (bytesRead < frameSize) { int read = stream.Read(buffer, bytesRead, frameSize - bytesRead); if (read == 0) break; bytesRead += read; }

这段代码看起来简单，但有个坑：Stream.Read不保证一次读满。必须用循环确保读够一帧的数据。我见过有人直接stream.Read(buffer, 0, frameSize)然后就用，结果帧错位，画面全是雪花。

读取到的RGB24数据要转换成ONNX模型需要的张量格式。APISR通常接受float32类型的输入，形状是[1, 3, H, W]，数值范围是[0, 1]。所以要做两步转换：一是把byte转成float并除以255，二是把HWC布局转成CHW布局。

float[] tensorData = new float[3 * height * width]; for (int y = 0; y < height; y++) { for (int x = 0; x < width; x++) { int pixelIndex = (y * width + x) * 3; int channelIndex = y * width + x; tensorData[0 * height * width + channelIndex] = buffer[pixelIndex] / 255f; tensorData[1 * height * width + channelIndex] = buffer[pixelIndex + 1] / 255f; tensorData[2 * height * width + channelIndex] = buffer[pixelIndex + 2] / 255f; } }

这个转换过程是CPU密集型的，对于1080p的帧，每帧要处理200多万个像素，循环开销不小。优化方式是用Span<T>和MemoryMarshal做批量转换，或者直接用System.Numerics.Vector做SIMD加速。实测下来，SIMD版本比朴素循环快3到4倍。

3.3 Vulkan推理会话的配置与调优

创建ONNX Runtime的Vulkan推理会话时，有几个关键配置项：

var options = new SessionOptions(); options.AppendExecutionProvider_Vulkan(new Dictionary<string, string> { { "device_id", "0" }, { "memory_limit", "2048" } // 单位MB }); options.GraphOptimizationLevel = GraphOptimizationLevel.ORT_ENABLE_ALL; options.EnableMemoryPattern = false; // Vulkan EP下建议关闭

memory_limit这个参数很重要。如果不设，Vulkan EP会尝试分配尽可能多的显存，可能导致其他图形应用崩溃。设成2048MB是个保守值，处理1080p视频够用。如果处理4K视频，要调到4096MB以上。

EnableMemoryPattern建议关闭，因为Vulkan EP的内存模式跟CUDA不同，开启后反而可能导致内存碎片。关闭后每次推理都会重新分配内存，虽然慢一点，但稳定性好。

另一个调优点是批处理大小。ONNX模型支持动态batch，你可以一次送多帧进去推理。但Vulkan EP对动态batch的支持有限，建议固定batch size为1，然后用多线程并行处理多帧。具体做法是开一个线程池，每个线程持有一个独立的推理会话，各自处理不同的帧。这样能充分利用GPU的并行能力，又避免了动态batch的兼容性问题。

实操心得：Vulkan EP在第一次推理时会做算子编译和内存分配，耗时可能是后续推理的10倍以上。所以要在正式处理前先跑几帧“热身”，把编译开销摊掉。我在代码里会先送3帧空白图像进去，等推理完成后再开始正式处理。

3.4 内存管理与显存泄漏排查

Vulkan EP最让人头疼的问题是显存泄漏。表现是处理了几百帧后，显存占用持续上升，最终爆显存崩溃。原因通常是输入输出张量的Dispose没调用，或者推理会话没有正确释放中间缓存。

在C#里，ONNX Runtime的InferenceSession和OrtValue都实现了IDisposable。每次推理完成后，必须显式释放输入和输出张量：

using (var inputTensor = new DenseTensor<float>(tensorData, new[] { 1, 3, height, width })) using (var inputs = new List<NamedOnnxValue> { NamedOnnxValue.CreateFromTensor("input", inputTensor) }) using (var outputs = session.Run(inputs)) { // 处理输出 }

using块确保即使发生异常，张量也会被释放。但session.Run返回的IDisposableReadOnlyCollection在某些版本里不会自动释放内部张量，需要手动遍历释放：

foreach (var output in outputs) { if (output.Value is IDisposable disposable) { disposable.Dispose(); } }

排查显存泄漏的工具推荐用Vulkan SDK自带的vulkaninfo和RenderDoc。vulkaninfo可以看当前显存占用，RenderDoc可以抓帧分析内存分配。另一个土办法是在任务管理器里看GPU显存曲线，如果呈锯齿状上升，基本就是泄漏了。

4. 完整实操流程与关键环节实现

4.1 环境准备与依赖安装

先列一下需要装的东西：

ONNX Runtime的NuGet包要选Microsoft.ML.OnnxRuntime.Gpu，这个包包含了Vulkan EP。但注意，这个包默认只带CUDA EP，要手动把Vulkan EP的native库拷到输出目录。具体路径在NuGet包的runtimes/win-x64/native下面，文件名是onnxruntime_providers_vulkan.dll。

FFmpeg建议下载essentials build，体积小，够用。下载后把ffmpeg.exe放到项目输出目录，或者加到系统PATH里。我倾向于放输出目录，避免用户环境变量冲突。

Vulkan Runtime通常显卡驱动自带，但为了保险，可以装一下Vulkan SDK的runtime组件。注意不要装完整SDK，那个太大，只装runtime就行。

4.2 项目结构与核心类设计

项目结构大概是这样：

AnimeSR/ ├── Forms/ │ ├── MainForm.cs # 主窗口 │ └── PreviewPanel.cs # 预览面板 ├── Core/ │ ├── VideoDecoder.cs # FFmpeg解码封装 │ ├── VideoEncoder.cs # FFmpeg编码封装 │ ├── SuperResolver.cs # ONNX推理封装 │ └── FramePipeline.cs # 帧处理流水线 ├── Utils/ │ ├── TensorConverter.cs # 张量转换工具 │ └── DpiHelper.cs # DPI缩放辅助 └── Program.cs

SuperResolver类是核心，它封装了ONNX Runtime的会话管理和推理调用。设计上采用对象池模式：预先创建N个推理会话（N等于GPU能同时处理的帧数），每个会话独立处理一帧，处理完归还到池里。这样避免了频繁创建销毁会话的开销。

public class SuperResolver : IDisposable { private readonly ConcurrentBag<InferenceSession> _sessionPool; private readonly string _modelPath; public SuperResolver(string modelPath, int poolSize) { _modelPath = modelPath; _sessionPool = new ConcurrentBag<InferenceSession>(); for (int i = 0; i < poolSize; i++) { _sessionPool.Add(CreateSession()); } } private InferenceSession CreateSession() { var options = new SessionOptions(); options.AppendExecutionProvider_Vulkan(); options.GraphOptimizationLevel = GraphOptimizationLevel.ORT_ENABLE_ALL; return new InferenceSession(_modelPath, options); } public float[] Resolve(float[] input, int height, int width) { if (!_sessionPool.TryTake(out var session)) { session = CreateSession(); } try { // 推理逻辑 return RunInference(session, input, height, width); } finally { _sessionPool.Add(session); } } }

4.3 视频处理流水线的搭建

流水线的设计目标是解码、推理、编码三个阶段并行。解码线程负责从FFmpeg读帧，推理线程池负责超分，编码线程负责写回FFmpeg。三个阶段之间用BlockingCollection做缓冲队列。

var decodeQueue = new BlockingCollection<Frame>(boundedCapacity: 30); var encodeQueue = new BlockingCollection<Frame>(boundedCapacity: 30); // 解码线程 Task.Run(() => { while (true) { var frame = decoder.ReadFrame(); if (frame == null) { decodeQueue.CompleteAdding(); break; } decodeQueue.Add(frame); } }); // 推理线程池 for (int i = 0; i < threadCount; i++) { Task.Run(() => { foreach (var frame in decodeQueue.GetConsumingEnumerable()) { var resolved = resolver.Resolve(frame.Data, frame.Height, frame.Width); frame.Data = resolved; frame.Height *= 4; // 假设4倍超分 frame.Width *= 4; encodeQueue.Add(frame); } }); } // 编码线程 Task.Run(() => { foreach (var frame in encodeQueue.GetConsumingEnumerable()) { encoder.WriteFrame(frame); } encoder.Finish(); });

队列容量设成30是个经验值。太小会导致线程频繁等待，太大则内存占用高。30帧大概对应1秒的视频，缓冲1秒的延迟对用户体验来说可以接受。

注意：BlockingCollection的CompleteAdding要在所有生产者完成后调用，否则消费者会一直阻塞。另外，如果推理过程中发生异常，要确保调用CompleteAdding，否则整个流水线会死锁。

4.4 进度反馈与预览刷新

WinForms的UI线程不能被阻塞，所以进度更新要用Invoke或BeginInvoke切回UI线程。但Invoke是同步的，如果UI线程忙，会阻塞工作线程。推荐用BeginInvoke做异步更新。

private void OnProgressChanged(int current, int total) { if (this.IsHandleCreated && !this.IsDisposed) { this.BeginInvoke(new Action(() => { progressBar.Value = (int)((float)current / total * 100); labelStatus.Text = $"处理中 {current}/{total}"; })); } }

预览刷新要控制频率，不能每帧都刷，否则UI线程会被刷爆。我的做法是每处理10帧刷新一次预览，用Interlocked计数器控制。

private int _frameCounter = 0; private void UpdatePreview(Bitmap frame) { if (Interlocked.Increment(ref _frameCounter) % 10 != 0) return; this.BeginInvoke(new Action(() => { previewPanel.Image?.Dispose(); previewPanel.Image = frame; previewPanel.Invalidate(); })); }

4.5 输出编码参数的选择

FFmpeg编码超分后的视频，参数选择很关键。老动画的特点是色块多、线条锐利、运动平缓，所以编码器要选H.264 High Profile，CRF设18到20，preset用slow。这样能在保证质量的前提下控制文件大小。

ffmpeg -f rawvideo -pix_fmt rgb24 -s 1920x1080 -r 24 -i - -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -movflags +faststart output.mp4

-movflags +faststart把元数据放到文件开头，方便在线播放。-pix_fmt yuv420p确保兼容性，虽然会损失一点色度精度，但老动画的色块本来就不需要4:4:4。

如果输出要用于存档，建议用H.265 CRF 16，体积能小30%左右，但编码速度慢一倍。这个可以在界面上给用户选。

5. 常见问题与排查技巧实录

5.1 推理结果出现网格状伪影

这是Vulkan EP最典型的问题。表现是超分后的图像上有规律的网格纹路，间距通常是8像素或16像素。原因是Vulkan EP的卷积算子在某些tile尺寸下会出现边界计算错误。

排查方法：先用CPU EP跑同一帧，对比结果。如果CPU正常，Vulkan异常，那就是EP的问题。解决方案有三个：一是换ONNX Runtime版本，某些版本修复了这个问题；二是调整模型的输入尺寸，避开有问题的tile边界；三是用GraphOptimizationLevel.ORT_DISABLE_ALL关闭图优化，让算子按原始方式执行。

我实测下来，ONNX Runtime 1.17.0的Vulkan EP在输入尺寸是64的倍数时最稳定。所以我在送推理前会把帧padding到64的倍数，推理完再裁掉多余部分。

5.2 处理速度突然变慢

如果处理前几十帧速度正常，后面突然变慢，大概率是显存碎片化。Vulkan EP在反复分配释放不同大小的张量后，显存会变得碎片化，导致后续分配变慢。

解决办法是定期重启推理会话。我的做法是每处理500帧，就把会话池里的所有会话销毁重建。虽然重建有开销，但比碎片化导致的性能下降划算。

另一个可能原因是CPU端的数据转换成了瓶颈。如果GPU利用率很低但CPU跑满，那就是张量转换太慢。用性能分析工具（比如Visual Studio的CPU Profiler）定位热点，然后用SIMD优化。

5.3 FFmpeg管道阻塞

FFmpeg进程如果标准输出缓冲区满了而C#端没及时读，FFmpeg会阻塞，整个流水线卡死。表现是进度条不动，CPU占用为0。

解决方案是确保读取线程独立且优先级高。不要把FFmpeg读取放在UI线程或推理线程里，要单独开一个线程专门读。另外，设置ProcessStartInfo.RedirectStandardOutput = true后，要立即开始读，不能等。

还有一个坑是FFmpeg的错误输出。如果FFmpeg报错但你没读标准错误，错误信息会填满缓冲区导致阻塞。所以RedirectStandardError也要设为true，并且用单独的线程读。

process.ErrorDataReceived += (s, e) => { if (!string.IsNullOrEmpty(e.Data)) { Debug.WriteLine($"[FFmpeg] {e.Data}"); } }; process.BeginErrorReadLine();

5.4 常见问题速查表

5.5 独家避坑技巧

技巧一：用--verbose模式跑ONNX Runtime。在创建会话时设置options.LogSeverityLevel = OrtLoggingLevel.ORT_LOGGING_LEVEL_VERBOSE，然后把日志输出到文件。这样能看到每个算子分配到哪个EP，以及内存分配情况。排查性能问题时非常有用。

技巧二：给FFmpeg加-threads参数。默认FFmpeg会用所有CPU核心，但跟推理线程抢资源。建议设成-threads 2，把更多CPU留给张量转换和UI。

技巧三：用ProcessPriorityClass.High提升FFmpeg进程优先级。这样在系统负载高时，FFmpeg不容易被饿死，减少管道阻塞的概率。

技巧四：输出视频前先做一次快速预览。用低分辨率（比如480p）跑一遍完整流程，确认没有颜色错误、帧错位等问题，再跑全分辨率。这样能节省大量调试时间。

技巧五：保存中间帧用于对比。在处理过程中，每隔100帧保存一张原始帧和超分帧的对比图。这样如果最终结果有问题，能快速定位是哪一帧开始出错的。

6. 性能优化与扩展方向

6.1 多GPU并行处理

如果机器上有两张以上显卡，可以通过创建多个推理会话，每个会话绑定不同的device_id来实现多GPU并行。ONNX Runtime的Vulkan EP支持通过device_id参数指定GPU。

options.AppendExecutionProvider_Vulkan(new Dictionary<string, string> { { "device_id", gpuIndex.ToString() } });

然后在线程池里，每个线程从对应的会话池里取会话。这样两张卡各跑一半的帧，理论速度翻倍。但要注意PCIe带宽可能成为瓶颈，如果两张卡都是中低端卡，提升可能不明显。

6.2 模型量化与加速

APISR的FP32模型在Vulkan上跑，速度还可以，但如果想进一步提升，可以做FP16量化。ONNX Runtime支持在加载模型时自动转换FP16，但Vulkan EP对FP16的支持要看显卡。较新的N卡和A卡都支持FP16加速，老卡可能不支持。

量化后的模型体积减半，推理速度提升30%到50%，但画质可能有轻微下降。建议在界面上给用户一个“性能模式”选项，让用户自己权衡。

6.3 批量处理与队列管理

如果要处理整个文件夹的视频，需要加一个任务队列。每个任务包含输入路径、输出路径、超分倍数、编码参数。队列管理器负责调度任务，支持暂停、恢复、取消。

实现上用ConcurrentQueue存任务，用一个后台线程逐个取出执行。执行过程中要处理异常，比如某个视频解码失败，不能影响后续任务。我的做法是每个任务独立try-catch，失败的任务记录到日志，继续下一个。

6.4 界面响应性优化

WinForms界面在处理大视频时容易卡顿，因为UI线程要处理重绘、进度更新、用户输入。优化方式是把所有耗时操作放到后台线程，UI线程只做渲染。另外，用DoubleBuffered = true减少闪烁，用SuspendLayout和ResumeLayout批量更新控件。

预览面板的刷新用Invalidate而不是Refresh，Invalidate是异步的，不会阻塞UI线程。如果预览帧很大，可以先缩放到面板大小再显示，减少绘制开销。

7. 一些实际使用中的体会

这套工具我断断续续做了大半年，中间踩的坑比预想的多。最开始想用Python加PyQt做，结果打包出来的exe在别人机器上各种缺DLL，用户体验极差。后来换成C# WinForms，虽然界面丑了点，但部署确实省心，单文件exe拷过去就能跑。

Vulkan EP的稳定性是个玄学问题。同样的代码，在N卡上跑得好好的，换A卡就可能出网格纹。后来发现是驱动版本的问题，更新到最新驱动基本能解决。所以我在工具里加了个启动检查，检测Vulkan版本和驱动日期，太老的直接提示用户更新。

APISR模型对老动画的效果确实比通用模型好，但也不是万能的。有些片子本身画质太差，超分后反而把噪点放大了。我的处理方式是在超分前先做一次轻度降噪，用FFmpeg的hqdn3d滤镜，参数设轻一点，保留线条细节。这个步骤可以在界面上做成可选，让用户自己决定。

最后说一个实际效果：一部24分钟的480p老动画，用这套工具处理成1080p，在RTX 3060上大概跑15分钟，输出文件大小1.2GB左右。画质提升很明显，线条干净了，色块均匀了，在55寸电视上看完全能接受。对于想给孩子看自己童年动画的家长来说，这个效果足够了。