学习式图像压缩Learned Image Compression这几年的进展很清晰压缩率一点点逼近甚至超过传统编码器但一个容易被忽略的问题也跟着冒出来了——码流对丢包极其敏感。网络传输不是本地读文件尤其在 UDP、RTP、弱网推流这些场景里丢包是常态不是意外。这篇论文标题里的 Every Packet Counts说的就是要在学习式压缩的码流和分组传输之间补上“抗丢失”这一环。如果你做实时图像传输、边缘端推流或者正在研究学习式压缩怎么落地这条思路值得专门拆开看一遍。下面我不替论文背书只按这类工作常见的设计路径把问题、方法、训练和排查流程梳理清楚。1. 先搞懂一个反直觉的结论码流越紧凑越怕丢包1.1 学习式图像压缩的码流长什么样学习式图像压缩和 JPEG、WebP、HEVC 这类传统编码器最大的区别在于“变换”不是人设计的而是网络学出来的。典型流程是输入图像 x经过编码器网络提取特征得到潜变量 y再经过量化变成离散值 ŷ然后用一个自回归熵模型常见的是超先验 hyperprior或者超先验加上下文模型 Context Model估计每个符号的概率最后用算术编码把整数序列压成一段连续比特流。解码端拿到比特流后用对应的概率模型做算术解码还原出 ŷ再经过解码器网络重建成图像 x。这套流程压缩率确实高但注意一个关键点算术编码是一种强序列编码后面符号的概率依赖前面已经解码出来的符号。也就是说整张图压缩后几乎是一段“一损俱损”的二进制序列。文件存在本地没问题但一旦涉及网络传输问题马上就来了。还有一个容易忽略的差异传统编码器里有大量人为设计的容错点。JPEG 可以按 block 独立解码部分内容HEVC 有 slice、tile、参数集等结构丢了一部分还能靠其它信息兜底。学习式编码器默认没有这些结构它的所有容错能力都必须重新设计、重新训练不能指望白捡。1.2 丢掉一个包为什么整张图都解不出来以太网的 MTU 一般是 1500 字节一张压缩后可能有几十 KB 甚至上百 KB 的图像必然要拆成多个 IP 分片或者走 RTP 分包。网络丢包时比如丢了一个 1400 字节的分片接收端拿到的码流中间少了一块。对传统编码器来说影响要看这块落在哪里对学习式编码器来说算术解码器的状态是全局的中间任何一段缺失都会让后续概率模型错乱最终要么直接解码失败要么输出一张完全花掉的图。很多论文用“catastrophic failure”来形容这个现象。你可以理解为本地存储时码流紧凑是优点网络上传输时这种紧凑反而是脆弱点。所以“抗丢包”从来不是一个附加功能而是从训练阶段就要考虑的问题。等你把模型训完、测完再拿去做 RTP 封装发现丢包后一片花屏这时候再回头改结构成本极高。1.3 搜索 Packet 时容易混入一堆无关工具这里顺手说个搜索体验的问题。如果你在搜索引擎里输入“packet”“丢包”“图像压缩 抗丢包”这些词很可能会翻出 Cisco Packet Tracer、Colasoft Packet Builder、Wireshark 抓包分析这类网络教学和调试工具还会翻到 DHCP 报文、MySQL 的 “reading authorization packet” 报错。这些工具本身没问题Packet Tracer 是做网络拓扑仿真的Packet Builder 是构造网络报文的但它们和“学习式图像压缩里的 packet”完全是两件事。前者关心报文怎么封装、怎么转发后者关心压缩后的语义信息怎么分散到多个分组里。搞混了会浪费不少时间。2. 信息分散的思路让每个包都能“撑起一片天”2.1 从“整段码流”到“多个描述”传统实时传输里对付丢包最常见的办法是三类重传、前向纠错FEC、错误隐藏。重传适合文件传输不适合实时推流FEC 会增加固定冗余信道差的时候会浪费带宽错误隐藏是解码端硬补图像结构复杂时补出来的效果很有限。于是有了 Multiple Description CodingMDC多描述编码这个经典方向。它的核心是把一份图像信息编码成多个描述每个描述单独能解出可看版本描述越多质量越高。传统 MDC 实现复杂而且冗余控制不够灵活。学习式压缩给 MDC 提供了新的实现空间既然特征表示是学出来的那“怎么把信息分散到多个包里”也可以一起学出来。论文标题里的 Dispersing Information基本就是这个意思——不是把同一份数据重复放几遍而是让信息在多个包里形成一种有冗余、但不重复的分布。这几种方案的差异可以放在一起比较方案核心思路冗余成本适用场景对实时推流的友好度重传丢哪个包补哪个包只有丢包时产生文件传输、容忍时延的会话低FEC预生成冗余包任意丢 n 个可恢复固定比例丢包率稳定、时延敏感中错误隐藏解码端利用邻域信息补块几乎为零丢包发生后应急高但效果有限学习式分散信息分布在多个描述中部分到达即可重建训练学出来的可变冗余弱网实时图像/视频传输高2.2 分散的不是重复数据而是结构信息我在第一次看这类思路时也有个疑问既然怕丢包那每个包都塞一份完整图的缩略信息不就能保证任何丢包都能恢复了吗理论上可以但是冗余太大压缩率会变得很难看。更合理的做法是让网络自己学“怎么分散”。常见设计是编码器输出潜变量后不直接一股脑做算术编码而是先经过一个分散模块把特征图按通道或按空间区域切分、重排、加上不同程度的跨包依赖形成多组子码流每组子码流放进一个或多个网络包。训练时随机丢掉其中一部分包让解码器学会在“只拿到一部分码流”的情况下也能重建出尽量接近原图的图像。这样每个包都有独立重建价值又保留了包之间的协作增益。标题说 Every Packet Counts强调的正是即使只收到一个包也应该能解出点东西收到越多质量越好而不是“全收/全废”二选一。从信息论角度说这是在“总码率”和“条件可重建性”之间做权衡。你可以把整个潜变量想象成一组共同描述图像的多面体每个包是一个视角任何一个视角都不能完整描述对象但描述数量的增加会稳步降低不确定性。真正的难点在于网络必须学会在没有某个视角时仍然能把已有视角映射回合理图像而不是把缺失当成一种完全无法处理的输入。2.3 和 FEC、重传、错误隐藏不是替代关系需要明确一点这种分散式学习压缩不是要替代传输层的所有保护手段。它解决的是“有条件地降级”也就是 graceful degradation。FEC 解决的是“低丢包率下不触发重传”重传解决的是“关键数据必须完整到达”错误隐藏解决的是“解码端拿到残缺帧后的应急”。这些可以组合使用。比如对最重要的基础描述做 FEC对增强描述不做保护整体带宽利用率可能更优。很多人会把“抗丢包”理解成“只要用这个模型网络怎么丢都没事”这个预期是错的。模型只能减少丢包带来的损害不能凭空恢复已经丢失的语义。真实系统里该做拥塞控制还得做该用 QoS 还得用编解码端的抗丢包能力只是最后一道防线。3. 这类系统通常会怎么做训练、丢包模拟和损失设计3.1 整体框架编码器 分散模块 条件解码器按常见实现路径一个抗丢包学习式图像压缩系统一般包含四块编码器网络 E把图像 x 映射为潜变量 y。分散/分组模块 P把 y 拆成 K 组描述并完成每组独立的熵编码输出 K 个包。解码器网络 D输入是“收到的部分描述”输出重建图。它必须能处理任意子集所以通常要做成条件解码比如把收到的包索引作为条件信息一起喂进去。熵模型/概率估计为每组描述提供概率估计丢包模拟会影响解码端可用概率。这里的概率模型要特别小心。训练时如果随机丢包那么解码端算术解码时缺少某几个包熵模型能参考的范围就变了。所以训练时的丢包和测试时的丢包必须一致地建模否则训练和推断就不匹配。很多复现工作出了问题不是模型结构不对而是训练时“假装丢包”和测试时“真丢包”的粒度不一样导致性能对不上。3.2 丢包模拟是训练的关键丢包模拟不是直接对像素加噪而是在“分组后的描述集合”上做掩码。比如把潜变量分成 8 组训练时随机生成一个 8 位二进制掩码1 表示该组到达0 表示丢失。常见做法是让丢包率在一个范围内随机采样比如 0% 到 20%、0% 到 30%而不是只固定 5% 或 10%。因为真实网络的瞬时丢包率是波动的固定一个值训练会过拟合。还有一个容易踩的坑丢包模拟应该在“语义分组”层面做而不是在字节层面随机删一段。像素级加噪模拟不了算术编码器的全局依赖只有整组丢包时解码器才学得会“这个描述没了我用其他描述补”。如果你在字节流里随机删一段训练模型学到的东西对真实网络的包丢失几乎没有迁移能力因为真实网络丢的是一整个 UDP/RTP 报文不是比特流里随机几个字节。3.3 损失函数怎么平衡“全收全得”和“丢包可解”训练损失一般至少包含三部分码率损失 R所有到达描述的总比特数要尽量小。完整重建损失 L_full假设所有包都到达时的重建质量。部分重建损失 L_partial随机丢弃部分包后的重建质量误差可以取平均也可以对“丢包率更高”的情况加大权重。可以这样理解如果只优化 L_full模型会倾向于把所有信息高度耦合一旦丢包就崩如果只优化 L_partial又可能牺牲无丢包时的性能。所以两者之间有一个 trade-off。很多工作会把 L_partial 写成在多种丢包率下的期望误差用随机采样来近似。伪代码层面的思路大概是这样# 示例训练逻辑非某个论文的官方实现 for batch in dataloader: y encoder(x) packets disperse(y, num_packets8) mask sample_loss_mask(loss_rates[0.0, 0.05, 0.1, 0.2]) received [p for p, m in zip(packets, mask) if m] received_idx [i for i, m in enumerate(mask) if m] bits sum(entropy_estimation(p) for p in received) recv_full decoder(packets) recv_partial decoder(received, received_idxreceived_idx) loss rate_weight * bits \ distortion(recv_full, x) \ partial_weight * mean(distortion(recv_partial, x)) loss.backward()实际项目里还要注意训练稳定性。解码器要对“任意子集”都稳定不然测试时丢掉两三个包输出会出现大块异常。我一般建议先在小图上训练观察不同掩码下的重建图是否平滑变化如果出现跳变优先检查掩码采样分布和 partial 损失权重。训练初期可以把 partial 权重设低一点等无丢包性能稳定后再逐步调高这样能减少两个目标互相拉扯导致的震荡。4. 从论文到可复现实验环境、数据、指标和排错4.1 建议先跑通的基础环境和数据这类方向的实验通常基于 PyTorch 和 CompressAI。CompressAI 是目前学习式图像压缩最常用的开源工具库里面实现了 Ballé 的 hyperprior、Minnen 的 context model、Cheng 的 attention 模型等经典结构。如果你要从零复现论文我的建议顺序是先在 CompressAI 自带环境里跑通一个基础模型比如 hyperprior确认能正常训练和评估。再在基础模型上加“分散 丢包模拟”模块先不要改熵模型结构保证改动可控。用 Kodak 数据集做测试CLIC 可以做主观质量进一步验证训练集常用 DIV2K、Flickr2K 这类高清数据集裁块训练。环境准备可以按通用流程来。用 conda 创建独立 Python 环境安装 PyTorch 和 CompressAI再准备数据集和评估脚本。下面只是示例具体版本要以你本机环境为准# 示例创建环境和安装依赖 conda create -n lic python3.9 conda activate lic pip install torch pip install compressai # 准备 Kodak 测试集和训练集目录 # 训练前先运行基础模型评估确认环境没问题硬件方面一块 24G 显存的显卡可以比较舒服地跑基础实验显存不够时把输入裁块改成 256×256 或 512×512先验证逻辑对不对再上全分辨率。不需要一上来就追求和论文完全一致。低配置能跑通不代表适合批量训练尤其是加了分散模块后模型输入变成“包集合”前向计算路径变多显存和内存消耗都会上升。4.2 需要重点看的指标和曲线这个方向只看“无丢包时的 PSNR”没有意义。核心是看一条曲线横轴是测试丢包率比如 0%、1%、5%、10%、20%纵轴是重建质量PSNR 或 MS-SSIM。理想的曲线应该是缓慢下降而不是在某个丢包率上断崖式下跌。评估时还要记录几条信息比特率加了分散和抗丢包机制后比原始模型多消耗多少比特。多丢包率下的质量方差方差大说明模型在某些丢包模式上不稳定。不同丢包模式的差异随机丢包和连续突发丢包结果往往差很多。对照实验至少要加两个基线一个是“直接把标准学习式码流做 RTP 分包后丢包再用错误隐藏或者简单填充”的基线另一个是“加同样比例 FEC 冗余的标准编码器”。为什么因为不对比你分不清质量的提升到底来自分散机制还是仅仅来自增加的冗余。如果加了 10% 冗余只换回 10% 的丢包鲁棒性那这个方向和传统 FEC 没有本质区别。评估维度可以参考下面这张表评估维度要看什么判断标准无丢包性能PSNR / MS-SSIM丢包率 0%与基线差距尽量小抗丢包曲线质量随丢包率变化平滑下降无断崖冗余代价相比基线增加多少 bitrate与抗丢包收益平衡稳定性多次重复实验的结果方差方差小可复现突发丢包连续丢失多个包不能出现整块花屏4.3 常见坑点和排查顺序我在复现或者评估这类模型时遇到过几类问题按排查优先级排列先确认丢包是在哪一层发生的。如果代码只是在特征图上加 mask但实际传输的是算术编码后的字节流那么“包”的边界和 mask 对不上结果会不稳定。先把包边界定义清楚。再确认解码器是否真的收到了“已到达包的索引”。只把到达的包喂给解码器还不够还要让解码器知道哪些包没到这是条件解码的关键。看训练日志时把 L_full 和 L_partial 分开打不要只看总 loss。总 loss 下降可能是 L_full 在主导L_partial 可能已经崩了。如果无丢包性能比基线低很多先降低 partial 权重或者把丢包率上限调低找到性能损失的临界点。最后再检查测试时丢包率、种子、包顺序是否可复现。实验要稳定最好固定随机种子记录每个包的字节数和到达顺序。这个排查顺序每次都能帮我省不少时间。很多“模型效果差”的问题最后查出来都是数据预处理或掩码逻辑不一致而不是网络结构本身的问题。5. 落地时最容易误判的四件事5.1 抗丢包不等于不需要传输层保护这类方法能让接收端在丢包时仍解出可用图像但代价通常是带宽上升、编码复杂度上升。真实系统里还是要在 RTP/UDP 层尽量抗丢包该用 FEC 用 FEC该做拥塞控制做拥塞控制。抗丢包图像编解码解决的是“网络已经丢包之后应用层还能不能撑住”而不是“网络可以不防丢包”。两者是叠加关系不是替代关系。5.2 “每个包都有用”不等于平均分配重要性Every Packet Counts 这个口号强调的是“没有无用包”但实际训练出来的分组往往存在优先级差异。有的包包含全局结构信息有的包包含高频细节。如果带宽和重传预算有限优先保护全局结构对应的包收益可能远大于平均保护。这也是为什么有些研究会把“包重要性排序”和“非均匀信道保护”结合起来。不要一看到分散就以为所有包必须同等待遇训练出什么结构要看损失函数怎么引导。5.3 指标好看不等于时延可控论文实验通常只评估图像质量和比特率但实时系统还要看解码时延。条件解码器要处理“任意子集”模型结构往往比固定输入更复杂推理时还可能要对每种到达模式重新整理输入特征。这会导致最坏情况解码时间不可控。做产品评测时如果只看平均 PSNR 不看 P95 时延会很危险。尤其在做视频会议、云游戏、远程控制这类低时延场景时解码时延的抖动比平均时延更致命。5.4 网络条件理想化是最大的坑很多实验用独立随机丢包但真实网络经常是突发丢包、乱序、队列延迟抖动一起出现。突发丢包会让连续几个包同时丢失对“分散”设计是更严酷的考验。建议在测试阶段加入一阶马尔可夫丢包模型或者直接用真实录制丢包 trace 回放。再有条件就做一个小型端到端测试把压缩码流通过 RTP 封装、经过丢包模拟器、到达解码端测完整链路的可用性。这一步发现的问题往往比单独跑训练集更有价值。现在回到开头那句话Every Packet Counts。做学习式图像压缩的人不能只在无损环境下追求码率做传输系统的人也不能只在下层堆 FEC 和重传。真正能落地的方案一定是编解码器和网络之间一起设计。如果你要复现这类工作我仍然建议先从“小图 基础模型 丢包模拟”开始跑通之后再看复杂结构。先把那条“质量随丢包率缓慢下降”的曲线画出来再谈优化。踩过几次之后我发现很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。抗丢包这件事也一样先把包的边界、丢包模拟、条件解码这三个点对齐了后面才会顺。