智能终端永不眠
2026/7/19 7:01:20
前面的分享有超分：yuv420p视频超分demo_yuv420p的视频-CSDN博客
也有vp9-svc编码：RTC中实时编码器Libvpx：vp9-svc的优化实践-CSDN博客
它们的性能在博客里已经做过介绍，实时性能和低功耗完全满足rtc的需求。
我们为什么在svc编码时采用端侧超分，而不是将vqc编码与端侧超分结合呢？
目前，所有的超分算法模型都是面对下采样的分辨率图片或视频进行训练的，对编码后块效应，振铃效应，模糊的各种退化还是不能hold住。即使我们对svc编码的视频图片做迁移学习，还不能完全达到理想的超分效果。Svc编码对每层的视频质量也已经很可控，所以超分的品质一致性能够得到保障。而VQC编码后画质很难统一，h264编码QP超过20，解码超分的质量就变得不可控。以上所说正是从模型原理与实践中得出的一致结论！
言归正传，编码侧有空域 SVC 做分层、解码渲染侧有超分做画质恢复，那么网络传输层就需要一套匹配的技术来串联两端，否则"管道"本身会成为瓶颈。
以下是网络传输层需要的关键技术，按层次组织：
一、拥塞控制与带宽估计（Congestion Control & BWE）
这是整个传输层的"大脑"，决定发送端以多大码率推送数据。
技术 | 说明 | 与 SVC+超分的配合 |
GCC（Google Congestion Control） | WebRTC 默认算法，结合延迟梯度（delay-based）和丢包信号做带宽估计，通过 TWCC（Transport-wide Congestion Control）机制收集接收端反馈 | 带宽下降时，GCC 触发码率下调，SVC 可以只丢弃增强层而非整体降质，保证基础层完整到达；超分在解码端补偿画质 |
BBR / BBRv2 | 基于带宽和 RTT 估计（而非丢包）的拥塞控制，抗丢包能力更强，但在低带宽+深缓冲区场景下带宽估计可能偏高 | 适合高丢包弱网场景，与 SVC 配合时需注意 BBR 的带宽估计偏差可能导致增强层发送过多而被丢弃 |
SCReAM / NADA | IETF RMCAT 标准化的另外两种方案，SCReAM 自时钟适配，NADA 网络辅助动态适配 | 可作为 GCC 的替代，尤其在卫星/LEO 等高抖动场景 |
关键配合点：拥塞控制输出的带宽估计值，直接决定 SVC 发送哪些层（基础层必须保，增强层按需发）。如果估计不准，要么浪费带宽发增强层（导致拥塞加剧），要么过度保守（浪费超分能力）。
二、丢包恢复机制（Packet Loss Recovery）
RTP/UDP 不保证可靠传输，弱网下丢包不可避免，需要应用层恢复。
1. ARQ（自动重传）—— NACK 机制
- 接收端检测到序列号缺失后，发送 RTCP NACK 请求重传
- 发送端缓存近期数据包，收到 NACK 后重传（通常走独立 SSRC 便于统计）
- 关键参数：初始请求延迟、重传间隔（≥1 RTT）、最大请求次数、ARQ 带宽上限
2. FEC（前向纠错）
- 发送冗余校验包，接收端无需重传即可恢复少量丢包
- 与 NACK 互补：FEC 适合随机丢包、NACK 适合突发丢包
3. 与 SVC 的协同
- 分层保护策略：基础层（Base Layer）优先保护——可以为基础层配置更强的 FEC、更积极的 NACK 重传；增强层（Enhancement Layer）可接受更高丢包率，甚至主动丢弃
- RED（Redundant Encoding）：对音频或关键帧做冗余编码，提升基础层到达率
三、SVC 感知的数据包调度与丢弃策略
这是编码层与传输层的衔接点，也是最容易被忽视但最关键的部分。
策略 | 说明 |
分层优先级队列 | 发送端将 SVC 不同层的 RTP 包放入不同优先级队列，基础层高优先级、增强层低优先级。拥塞时优先丢弃增强层包 |
依赖感知的丢弃 | 空域 SVC 中，增强层依赖基础层解码。如果基础层包丢失且无法恢复，对应的增强层包即使到达也无效，应直接丢弃避免浪费带宽 |
K-SVC 模式 | W3C WebRTC SVC 规范中的 L2T1_KEY、L3T3_KEY 等模式，通过关键帧间隔和层间依赖关系优化可丢弃性 |
Simulcast vs. SVC | Simulcast（S2T1、S3T1 等模式）发送多条独立流，接收端选其一；SVC 发送单条分层流。两者可结合使用，Simulcast 做粗粒度适配，SVC 做细粒度分层 |
四、传输层反馈与自适应（Transport Feedback）
机制 | 作用 |
TWCC（Transport-wide CC） | RTP 头扩展携带全局序列号，接收端通过 RTCP 反馈每个包的到达时间、丢包状态，发送端据此精确估计带宽和 RTT |
Receiver Estimated Maximum Bitrate (REMB) | 接收端直接上报估计的最大接收带宽，发送端据此调整 |
Transport-cc + SVC 联动 | 带宽下降时，不是简单整体降码率，而是按层裁剪：先砍最高增强 层，再砍中间层，最后才动基础层。超分负责在解码端"补齐"被砍掉的层 |
五、完整的端到端抗弱网链路
plain
┌─────────────────────────────────────────────┐
│ 发送端（Sender） │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ 空域 SVC │─▶ │ 分层 RTP │─▶ │ 拥塞控制 │ │
│ │ 编码 │ │ 打包 │ │ (GCC/BBR) │ │
│ │ (L1T2/L3T3) │ │ (基础层优先) │ │ 带宽估计 │ │
│ └─────────┘ └─────────┘ └────┬─────┘ │
│ │ │
│ FEC 编码 / NACK 缓存 / 分层优先级队列 │
│ ▼ │
│ ┌─────────────────────────────────────────┐ │
│ │ 网络传输层 (RTP/UDP) │ │
│ │ • TWCC 反馈 • 分层丢包恢复 • 带宽自适应调度 │ │
│ └─────────────────────────────────────────┘ │
│ │ │
└───────────────────────────────┼─────────────┘
│
▼
┌───────────────────────────────┼─────────────┐
│ │ 接收端（Receiver） │
│ ▼ │
│ ┌────────────────────────────────────────┐ │
│ │ 网络传输层 (RTP/UDP) │ │
│ │ • 丢包检测 → NACK 请求 • FEC 解码恢复 • TWCC 反馈上报 │ │
│ └────────────────────────────────────────┘ │
│ │ │
│ ┌─────────┐ ┌──────────┐ ┌──────────┐ │
│ │ SVC 分层 │─▶ │ 基础层解码 │─▶│ 超分渲染 │ │
│ │ 解码器 │ │ (保证流畅) │ │ (恢复画质) │ │
│ │ (可选增强层) │ │ │ │ (LUT/IM-LUT) │ │
│ └─────────┘ └──────────┘ └──────────┘ │
└────────────────────────────────────────────┘
六、关键配合原则总结
层面 | 技术 | 与 SVC+超分的配合要点 |
编码 | 空域 SVC | 分层编码，基础层保流畅，增强层保画质 |
传输 | GCC/BBR + TWCC | 精确带宽估计，指导分层裁剪策略 |
传输 | NACK + FEC + 分层优先级 | 基础层优先保护，增强层可容忍丢包 |
传输 | SVC 感知调度 | 依赖感知的智能丢弃，避免无效传输 |
解码 | SVC 分层解码 | 基础层必解，增强层可选 |
渲染 | LUT/IM-LUT 超分 | 用计算换带宽，在低码率输入上恢复高分辨率画质 |
七、业务层联动
最后还要考虑到终端业务层布居需求，比如娱乐中PK业务，页面布局只需要360p大小，那么传输就不要超越这个分辨率，超分也是一样的。还有就视频会议不在焦点的成员频道的分辨率，这些都是要和传输与端侧超分联动，减轻传输带宽需求、编解码与超分的计算资源。
八、总之一句话
空域 SVC 解决"该发什么"，超分解码解决"怎么看"，而网络传输层的 GCC/BBR 拥塞控制 + TWCC 反馈 + NACK/FEC 丢包恢复 + SVC 感知分层调度，解决"怎么发"——三者缺一不可，共同构成端到端抗弱网闭环。