一段 AI 生成的竖屏短片剪辑和字幕都完成了导出时却发现源片只有 448×768。直接把编码尺寸改成 1080×1920文件确实会变大画面却不会因此获得真实细节如果逐帧交给增强模型又会遇到画幅变化、处理耗时、音轨保留和帧间闪烁。问题不是“怎样输出一个 1080p 文件”而是在可接受的成本下交付一个尺寸正确、音画完整、没有明显伪细节的视频。下面以一条 25.97 秒、623 帧、24 帧/秒的竖屏短片为例。输入为 H.264、448×768含 AAC 音轨一次逐帧增强后的输出为 H.264、1080×1920仍为 623 帧、24 帧/秒并保留 AAC 音轨。本文解释如何选择普通插值与模型增强、为什么要先算画幅、如何组织解码—推理—编码以及最后该查什么。案例文件已经生成但没有可追溯的同机复测日志和人工盲评记录所以不宣称“提速百分之多少”或“画质提高多少分”。目录先确定要解决的是哪一种低清问题插值、超分模型与重生成该怎么选448×768 到 1080×1920先处理画幅逐帧处理怎样接上音轨与编码器怎样比较增强结果避免只看像素数用媒体探测与测试确认交付文件失败边界与上线使用建议一、先确定要解决的是哪一种低清问题“不清楚”至少包含三种不同问题。第一种是尺寸不足在手机全屏或大屏播放时448 像素宽的原片必须放大边缘容易显得软。第二种是源画面本身缺信息人物眼睛、文字、衣服纹理在原片里已经模糊放大只能估计它们不能还原拍摄现场并不存在的“真值”。第三种是时间维度不稳定同一张脸相邻帧时而锐利、时而改变纹理单帧看起来清楚连播时反而闪烁。因此这次处理的目标分两层文件层要满足尺寸、帧数、帧率、时长和音轨要求观看层要核对人物、字幕、细线条以及动作片段。文件层能写成自动校验观看层仍需要同一位置的前后对照和连续回放。把这两层混为一个“输出 1080p 即通过”的指标最容易把问题带进交付版。已知输入目标或约束为什么重要448×768、24 帧/秒、623 帧1080×1920帧率与帧数保持一致避免无意加速、掉帧或重复帧原片带 AAC 音轨输出仍有可播放的音轨逐帧图像管道不会自动带上声音竖屏画幅约 0.5833目标画幅 0.5625不能无解释地把人物横向压窄源文件约 6.58 MB输出文件约 40.26 MB清晰度、编码码率与存储成本要一并考虑图1这次处理先锁定帧数、画幅、帧率与音轨再讨论画质“像素增加”不是观看层的验收结论。二、插值、超分模型与重生成该怎么选如果只是需要一个指定尺寸的展示文件双三次或 Lanczos 插值通常是第一条基线快、行为可预测也不凭空构造强纹理缺点是原片模糊的脸和远景不会真正恢复。如果源片还有可辨认的边缘但放大后明显发软可以试超分辨率模型再与普通插值做同帧对照。若原视频已经出现双人、错手、文字乱码或动作跳变增强会把这些错误放大得更清楚此时该回到生成或剪辑阶段而不是继续调“锐化强度”。处理方式适用前提常见代价或风险这次怎么用普通插值主要缺显示尺寸源片内容本身可接受细节仍软但不易产生模型式伪纹理作为对照基线图像超分模型逐帧处理原片有一定结构信息可接受较高处理成本脸、草叶和字幕可能出现伪细节跨帧可能抖动对模型输出做尺寸调整和强度混合视频时序增强模型闪烁是主要问题模型与硬件条件合适时序窗口、显存、速度与边界帧处理更复杂本次未使用不能借其能力评价结果返回源头重生成主体、动作、文字本身已错需要重新筛选镜头并回归时间线画面错误时优先考虑本案例选的是“逐帧模型输出 普通插值基线按强度混合”。它的价值是能在增强过头时降低模型影响而不是保证结果一定自然。不同超分模型的训练数据和适用画面不同动画、真人、文字密集画面不要共用一次主观判断。公开示例只解释管线不把某个模型权重当成通用答案。解码、模型推理、编码也是三段不同的耗时。即使推理跑在 GPU 上读入原片、CPU/GPU 数据往返和 H.264 编码都还存在看到 GPU 利用率不满不能直接断定“模型没有加速”。先分别记录每段耗时、内存和磁盘吞吐再决定优化批量、编码器还是解码策略。图2音轨来自原片的独立映射逐帧图像流只负责视频不会自动保存声音。三、448×768 到 1080×1920先处理画幅这个尺寸变化藏着一个容易忽略的比例问题448 / 768 ≈ 0.5833而1080 / 1920 0.5625。若直接把原帧拉成 1080×1920人物会略微横向压缩。按高度等比放大到 1920 时宽度应为448 × (1920 / 768) 1120。本案例的做法是先得到 1120×1920再从左右各裁去 20 像素形成 1080×1920。这比直接拉伸更忠于人物比例但裁切不等于零损失画面两侧各有约 1.8% 的放大后宽度被移除。如果人物、字幕、产品或界面元素恰好贴边应该改为留边、调整构图或者接受另一种目标尺寸。横竖比不能只在处理脚本里写死文章发布前要用边缘主体的画面再检查一次。source_w,source_h448,768target_w,target_h1080,1920scaled_wround(source_w*target_h/source_h)# 1120crop_each_side(scaled_w-target_w)//2# 20assertscaled_w-2*crop_each_sidetarget_w模型可能先输出更高分辨率随后再用双三次插值调整到 1120×1920普通插值基线也调整到同样尺寸才能逐像素混合。不能把尺寸不同的两张图直接加权或者先裁一张、后裁另一张。下面是本案例中决定输出画幅与增强强度的核心计算model为已加载且处于推理模式的超分模型tensor是形状为[1, 3, 768, 448]、值域为 01 的 RGB 图像importtorchimporttorch.nn.functionalasFwithtorch.inference_mode():enhancedmodel(tensor)enhancedF.interpolate(enhanced,size(1920,1120),modebicubic,align_cornersFalse)[:,:,:,20:1100]baselineF.interpolate(tensor,size(1920,1120),modebicubic,align_cornersFalse)[:,:,:,20:1100]strength0.7outputtorch.lerp(baseline,enhanced,strength).clamp(0,1)assertoutput.shape(1,3,1920,1080)strength0是普通插值strength1是当前模型输出0.7只是这次处理脚本采用的参数不是通用最优值。应把同一帧在不同强度下并排比较再连播人物移动和细密背景尤其不要因为一张静帧更锐就无条件开到 1。图3按高度等比放大得到 1120×1920再左右各裁 20 像素主体靠边时应重新评估裁切方案。四、逐帧处理怎样接上音轨与编码器完整管线不是“打开图片调用一次模型”那么简单。解码器把视频解成连续rgb24原始帧Python 每次按宽×高×3字节读满一帧转换为张量进行推理编码器从标准输入读回处理后的rgb24帧。同时它从原文件读取音频将视频帧与音轨封装到新 MP4。原项目使用 FFmpeg 解码/编码、PyTorch 推理和 Spandrel 加载模型下面只保留决定正确性的关键点frame_size448*768*3count0whileTrue:rawread_exactly(decoder.stdout,frame_size)ifnotraw:breakiflen(raw)!frame_size:raiseRuntimeError(输入在一帧中间结束不能交付半帧视频)tensorrgb_bytes_to_tensor(raw)# [1, 3, 768, 448], 01resultenhance_and_crop(tensor)# [1, 3, 1920, 1080]encoder.stdin.write(tensor_to_rgb_bytes(result))count1encoder.stdin.close()ifencoder.wait()!0orcount0:raiseRuntimeError(编码失败或没有产生视频帧)这里的read_exactly、张量转换和enhance_and_crop需要由实际程序实现代码块刻意突出三件事不能把管道一次read返回不足一帧误判为视频结束不能在编码器失败时仍把文件标成完成不能只看处理循环计数而不看最终封装文件。完整工程还应捕获解码器退出码、保存标准错误日志、清理失败的临时输出并在验收通过后才将临时文件改为正式文件。在 FFmpeg 侧原项目将处理后的原始帧作为输入 0再把源 MP4 作为输入 1使用-map 0:v:0 -map 1:a:0 -c:a copy明确选择处理后视频和原音轨。FFmpeg 官方文档说明-map控制输出流选择不显式映射时不能假设“原片有音轨所以输出也有”。该命令要求输入含音轨若产品还接受静音视频应先探测音频流再选择有声和无声两条封装路径不能让1:a:0在无音频时直接报错。另外本案例原片是固定 24 帧/秒原始帧管道本身不带每帧时间戳编码器按-r 24重建时间轴。可变帧率视频不能直接照搬否则可能改变节奏和音画关系。遇到手机拍摄的 VFR 素材应先决定是否规范化为 CFR并记录丢帧、补帧策略或采用可保留时间戳的处理管线。五、怎样比较增强结果避免只看像素数本案例的第 620 帧适合观察人物、树桩、衣服褶皱和枯草。先用同一帧号抽取原片和增强片再以接近的显示尺寸观看否则右侧 1080p 文件天然显示得更大比较会失真。全貌图检查构图与字幕安全区局部图检查面部、袖口、草叶和物体边缘。下面两张案例图来自同一帧不是两次生成的不同画面。案例图1第 620 帧全貌对照。增强版像素尺寸更大但交付前仍要检查边缘裁切和字幕位置。同一张图的局部区域放到近似相同的屏幕占用面积后才看得到“视觉更清楚”和“纹理是否可靠”之间的区别。脸部和衣服边缘可以更明确但模型也可能把泥土、草叶的随机纹理修饰成不存在的细节。没有原始高分辨率真值图时不能把看起来更锐等同于恢复了真实细节PSNR、SSIM 这类有参考指标也缺少可靠的配对真值。此时更适合做固定区域的人工对照记录具体接受或拒绝的理由。案例图2人物与树桩局部同帧、近似同屏尺寸对照单帧不能证明相邻帧没有纹理闪烁。实际复核至少选三类片段静止人物看五官和衣物运动人物看脸与手是否一帧一变细纹理背景看草叶、瓦片和树枝是否闪烁。字幕若已经烧进原片也会跟着进增强模型必须看笔画是否发毛如果字幕仍是独立轨道通常应先增强画面、后合成字幕以免字幕被模型“修复”。这不是对所有模型的绝对规定而是由字幕是否已烧录决定的处理顺序。图4原片、普通插值和模型增强应在同帧、同区域下比较模型结果还要连播检查时间稳定性。六、用媒体探测与测试确认交付文件人工看画面之前先让程序检查可量化事实。使用ffprobe -count_frames读取实际解码帧数而不只信容器里可能缺失或不准确的声明值提取视频宽高、平均帧率、音频编码和时长。下面是这个案例的实际探测结果字节数是文件大小不是“画质得分”字段输入输出结论画面尺寸448×7681080×1920达到目标尺寸解码帧数623623未见帧数变化平均帧率24/124/1保持固定帧率音频编码AACAAC音轨存在、编码类型一致容器时长25.966 秒25.958 秒相差约 0.008 秒小于一帧文件大小6,577,236 字节40,262,752 字节约增至 6.12 倍“音轨存在”还不等于“人听起来同步”。结构校验通过后至少试听开头、中间转场和结尾字幕与旁白要按同一时间码复核。画面也要完整解码到最后一帧不能只看播放器能打开首屏。读者可以先分别对原片和增强片执行下面的命令。-count_frames会遍历视频流长视频上需要时间验收阶段值得做任务进度页却不应每刷新一次就重跑。把两份 JSON 中的帧数、帧率、宽高、音频流及容器时长代入后面的断言即可ffprobe-verror-count_frames\-show_entriesstreamcodec_type,codec_name,width,height,avg_frame_rate,nb_read_frames\-show_entriesformatduration,size-ofjson input.mp4为了避免验收逻辑只覆盖成功路径测试至少包含输出少一帧、音轨缺失、尺寸错误三个拒绝案例。以下是结构校验核心假设source、output已从探测结果整理为字典defaudit(source,output):checks{target_size:(output[width],output[height])(1080,1920),frame_count:output[frames]source[frames],frame_rate:output[fps]source[fps],audio_codec:output[audio]source[audio],duration_delta_under_frame:abs(output[duration_s]-source[duration_s])1/24,}return{checks:checks,pass:all(checks.values())}拒绝路径同样应运行。例如原片和输出均为 623 帧、均有aac音轨时通过把输出改为 622 帧或清空音频流即应失败source{width:448,height:768,fps:24/1,frames:623,audio:[aac],duration_s:25.966}output{width:1080,height:1920,fps:24/1,frames:623,audio:[aac],duration_s:25.958}assertaudit(source,output)[pass]assertnotaudit(source,output|{frames:622})[pass]assertnotaudit(source,output|{audio:[]})[pass]assertnotaudit(source,output|{width:1120})[pass]这段断言的时长容差以本案例 24 帧/秒为前提通用脚本应从输入帧率计算一帧的时长。它能发现漏帧、丢音轨和尺寸不符却不能发现“脸变假”“动作卡顿”。结构正确是观看复核的起点不是替代品。图5本次文件结构检查通过主观细节、时间闪烁与音画同步仍要按片段人工复核。七、失败边界与上线使用建议第一不要把输出尺寸当质量指标。源片有严重压缩块、错误人脸、重影或错误动作时超分只能制造更大的错误。第二不要只估算 GPU 推理时间。长视频的总耗时还包括解码、数据搬运、编码与文件写入这次有成片文件但缺少同环境可追溯的逐段计时因此不把某个历史运行时间当作公开性能结论。第三要给输出设置存储和失败处理边界。本例文件体积从约 6.58 MB 到 40.26 MB批量处理时应限制并发、预留磁盘空间失败时保留原片并清理未验收的临时文件。真正可复用的工作顺序是先核对源片问题属于尺寸、细节还是内容错误为普通插值建立基线计算画幅后再跑模型同帧对照并连播最后检查帧数、时长、音轨和文件大小。只有当结构检查和观看复核都过关才把增强版作为交付文件。这个流程适用于短剧也适用于低分辨率演示视频、历史素材和竖屏产品视频不同素材要重新选模型、强度与裁切方式不能直接继承本例参数。参考资料FFmpeg 文档流选择与映射、PyTorch推理模式、PyTorch张量插值、Spandrel模型加载。