视频压缩这个行当，第一次有了「解码一步完成」的生成式方案。VoRTeC 把「解码」这个词的含义换掉了：不再从纯噪声里把画面「想」回来，而是把压缩码流当成生成模型轨迹上的一个中途站，顺着往回走一步就到。
现在的做法，卡在哪
视频能塞进这么小的体积，靠的是预测：关键帧（I 帧）完整编码，后续帧（P 帧）只编「跟预测差多少」。神经编解码器把这套搬进网络，套路没变——老老实实算运动、算残差。码率压到极低就露短板：块效应、糊脸，招牌上的字直接糊成色块。
于是有人反着来：信息不够，让生成模型补。DiffVC、GNVC-VD 这类扩散式视频压缩把解码改写成「去噪」——从纯噪声出发，让一个大参数量视频生成模型迭代十几步，把画面想回来。画质惊艳，死穴也明显：解码要在几十亿参数的模型里跑很多步，一秒视频要等几十秒甚至几分钟；从纯噪声起步，每一步都在猜，帧间一致性也难保。
关键转折：码流本来就在轨迹上
VoRTeC 的重看很朴素：解码为什么非要从纯噪声开始？流匹配（flow matching，一类把「噪声→数据」拉成直线、模型学每个点流速的生成建模方式，开源视频生成底座 Wan2.1 就是这么训的）的轨迹状态，是「数据掺一点噪声」的混合。而压缩码流恰恰是「大部分是数据、只掺了一点压缩噪声」的东西——它本来就是这条轨迹上靠后的一站，只是从来没人这么用过。
于是解码被改写成：估出码流里掺了多少压缩噪声，对应成轨迹上的一个时间点，再沿轨迹往数据端回走一步。怎么估？论文给了闭式解：时间点 = σ/(1+σ)，σ 是压缩噪声的量，量化成一个整数随码流传下去，几乎不占码率。这不是玄学：消融里把它换成固定值，同等观感要多花 44% 码率——每帧「带了多少压缩伤」本身就是信息。解码的代价，是完整跑一遍冻结的 Wan2.1（13 亿参数）一次前向，框架全程不碰它的参数。
时序那半边用老招式配新结构：视频分组编码，I 组完整编；P 组的第一帧隐码（视频先被压成的小尺寸特征，后续编解码都在它上面做）干脆不传，直接复用上一组重建末帧的缓存——零比特锚点，既省码率又把组缝焊住不闪；加上跨组共享的先验缓存，整段观感就连起来了。
结果：对比已有扩散式视频压缩，同等观感省 58% 码率，解码快 3–197 倍，480p 下 32 FPS、720p 下 13 FPS；480p 上用比 H.266/VVC 更少的码率拿到更好观感。0.007 bpp（每像素比特数）下，VoRTeC 解出的骑手裤上字母还读得出来，同码率段的对手已把字糊成花纹。
会先落进哪些工作流
最先受益的是「字要能读」的场景：弱网传视频、直播降码率、老片重发，都撞过「压狠了没法看」的墙，生成式解码把这堵墙往更低码率推了一截。结构上它是「云端慢编码、端上快解码」的不对称形状，正好对上现有分发架构——编码 1080p 一秒内容约需 0.26 秒，放云端无所谓；解码一步化之后，手机实时播生成式压缩的片子开始可行。更远一层，同一个基础模型既做生成又做压缩，「模型即编解码器」——码流里出现「轨迹时间戳」这种新物种，压缩的表示正在跟着生成模型迁移。
局限与存疑
1080p 优势收窄：底模按 480p 训的，1080p 解码掉到约 4 FPS，天花板暂时被底模分辨率钉住；编码端也还慢。更根本的是生成式解码的老问题——解码器会「补」细节，补得合理但不保证真实：车牌、人脸、票据这类有取证合规要求的场景，进不了严肃工作流。另外部分对比方法的数字取自原论文而非复跑，横向比较要留点余地。